05 | 价值流分析：关于DevOps转型，我们应该从何处入手？

作者回复: 你好，其实我在文章中也有提到过，稍微展开一下。 关于增值时间和不增值时间，可以划分为两个层面。首先是从全局的维度统计等待时间，如果你已经用了电子看板工具，那么一个任务从开始到结束的周期内，有多长时间处于等待状态，比如待开发，待测试，待发布，那这些都是典型的不增值时间。 其次，从微观角度，深入到各个环节内容，比如开发环节，统计那些除了真正写代码之外的活动时长，比如构建打包，比如提测任务，比如没人评审的提交，比如审批活动，这些理论上都是不增值的时间，可以尽量优化掉。 至于说开发本身的效率高低，这个不方便度量，但我相信，只要外部这些不增值的时间被优化掉，其实就能解决大头的问题。 关于完成度和准确率，完成度最简单的就是统计迭代周期内的任务，有多少按时完成了，有多少延期了，比如按时提测率，虽然刚开始的时候对于任务的工作估计会有很大偏差，但随着团队磨合以及对于业务的理解，这个估计会被不断的矫正，更加贴近于真实情况。 准确率方面，可以重点考察被下游打回的流程，比如研发提测后，测试发现自测不达标打回研发，可以统计提测打回率，再比如上线发布后，发现有问题出现回滚，那就是上线失败率，也可以进行统计。 关键点是，指标贵精不贵多，预期一次性度量10个指标，不如把一个关注点的指标做透，直到改进流程影响行为。

作者回复: 你好，你把下一讲的问题提前剧透了，以我们公司现有的实践来说，需求提出时间，具体指业务方提出需求的实践，以业务方在系统中录入原始需求为准。需求录入之后，会经过需求承接，产品设计，PRD评审，到准备就绪，这些就是需求管理层面的事情，再往后就进入了开发阶段。 至于需求拆分的粒度，根据不同业务形态也不尽相同，我们现行的指导原则是，在一个迭代周期内可以上线交付，平均统计下来3-5天居多。另外，除了需求粒度之外，还有一个比较重要的指标，就是配置化需求比例，也就是不需要额外开发代码，仅需要调整配置就可以完成交付的功能。

作者回复: 你好，感谢你的留言，我在整理内容的时候，也在纠结工具本身的介绍要占据多大的篇幅，其实如果展开来说，每个工具都可以成为一个独立的专栏，所以权衡下来会采用实践为主，工具和案例为辅的方式，也就是先说明白为什么要做这个实践，实践的正确姿势是怎样的，再结合实践和工具列举一些小的案例帮助理解。至于工具本身，一方面网上有很多资料，另外一方面DevOps本身也不强依赖于某个具体的工具，所以我推荐还是以问题驱动学习的方式。你好，感谢你的留言，我在整理内容的时候，也在纠结工具本身的介绍要占据多大的篇幅，其实如果展开来说，每个工具都可以成为一个独立的专栏，所以权衡下来会采用实践为主，工具和案例为辅的方式，也就是先说明白为什么要做这个实践，实践的正确姿势是怎样的，再结合实践和工具列举一些小的案例帮助理解。至于工具本身，一方面网上有很多资料，另外一方面DevOps本身也不强依赖于某个具体的工具，所以我推荐还是以问题驱动学习的方式。 顺便说下，你既然提到了Adminset，也给你一些小的福利，关于这个工具的问题，我会收集起来邀请作者来跟大家一起互动哈。

作者回复: 你好，我今天跟团队还在学习谷歌的代码评审文档，不知道你看了没？其中感受特别深的一点就是国外这些所谓的优秀公司，在总结规范和实践的时候，对人的关注非常高。比如举个例子，在谷歌的代码评审实践中，特别提到了要如何给出评审建议，怎么样的话术比较容易让人接受，如果两方争执不下，要怎么处理的好，甚至要关注评审双方的情绪，等等。 但是我们在做类似的事情的时候，很多时候都是指标先行，通过定义指标，来考核团队的落实情况，至于指标是否合理，人员的情绪是否有照顾到，说实话，并不太关心。这也是值得反思的一点吧。

作者回复: 你好，感谢你的回复，我觉得说的特别好。 没错，问题的关键就在于组织的运作不是面向效率建设的，换句话说只要符合现有的流程前提之下，效率的高低其实并没那么重要。但是另外一方面，我们又看到ITILv4的指导原则，也体现出一种DevOps的特征，比如关注价值，关注现状，自动化，流程与反馈等等，所以你说的这种现状不会长期存在，迟早也会进行调整。除非IT服务变成了铁饭碗，也没有行业竞争的压力，那么当竞争的重心从服务全面性，到服务质量，再到运作效率的转变时，消除浪费也就在所难免了。 我还是始终强调一点，如果公司想在不改变流程的前提下推行DevOps，那么大概率是会失败的。所以思想和流程的共同转变，再辅以工具技术的支撑，才有可能改变现状。

作者回复: 从需求到开发人员手中这个时间，关键是如何定义开发开始的时间，这一点我们并没有强加要求给到研发人员，而是通过分支策略的方式来实现的。简单来说，每个特性有一条独立的分支，分支的创建由系统自动完成，那么如果研发开始工作，必须要有一条分支，而分支创建的动作是需求卡片从就绪到开始开发的状态自动完成的， 所以通过这种方式，来实现了系统跟踪，当然你说这是不是百分百精确，倒也未必，其实，只要规则在内部统一，自己跟自己能对齐就可以了。

作者回复: 你好，这个并非我发明的哈，甚至这个概念都不是软件行业发明的，质量门禁是内建质量的一种实践，内建质量来源于管理学大师戴明的质量14条，也是很多精益理论的核心思想，在SonarQube中就存在质量门禁的功能，也就是将规则内建在平台中，并自动检查校验给出反馈哈

作者回复: 我觉得咱们平台用户的留言都非常高质量，有见地，赞一个。甩锅这事吧，说到底还是职责不清，要么就是你并没有做到无懈可击，比如一个线上版本问题，开发说代码没变，然后甩锅运维，运维自身有嘴说不清，原因还是自己有值得提升的点，所以反过来看这个问题，其实是一个挺好的反馈和改进的契机。回到工具，的确通过工具平台联通不同角色，相当于多了一个裁判，或者是多了一个新的背锅团队，所以做得好坏，就看平台上的业务路径，当然核心咱们还是希望自动化能替代一部分人工的事情，这样多出来的精力就可以解决开始提到的甩锅问题了。

作者回复: 你说的很对，很多时候团队倾向于自我保护，所以刻意的会去隐藏一些真实的情况，这个时候就得让数据说话啦，当然不建议上来就用数据考核，这会导致走向另外一个极端哈。

作者回复: 上来就调整文化和思维模式很难，所以大多数企业选择了相对容易的道路，这也是为什么工具决定论实际上影响更大的原因，但就像你说的，如果选择了容易的道路，自然难有质的飞跃，不破不立，还是那句话，如果不改变现有流程的基础上实施DevOps，是很难达到目标的。