从价值流图分析研发效能

什么是价值流

传统的工作中，不同的职位都只关注自己所交付的东西，比如产品经理关注产品需求文档的交付，开发人员关注软件代码的交付，运维人员关注于软件产品的部署。

随着DevOps与敏捷的发展，它们越来越强调交付整体价值，而不是单一角色的交付内容。

因此，价值流的意义就体现出来了。价值流是DevOps的关键概念之一。

根据《DevOps精要》的解释，我们可以从创造价值以响应客户请求的角度，来考虑一下组织中的工作。完成请求所需要实施的相关行动，可以按顺序排列起来，这称为价值流。

什么是价值流图

价值流图就是可视化的价值流。

它大概长下图的样子。

如何画价值流图

画价值流图其实很简单：

1. 识别处理请求的关键步骤

2. 分析每个关键步骤所需的3个度量数据

   1. 前置时间 Lead Time，LT
   2. 处理时间 Process Time，PT
   3. 完成度与准确度百分比 the Percent Complete and Accurate，%C/A
3. 将这些步骤组织为一个创造预期结果的活动序列

价值流图画好之后，最有价值的信息是流中每个步骤的3个度量数据，即前置时间(Lead Time，LT)、处理时间(Process Time，PT)及 完整度与准确度百分比(the Percent Complete and Accurate，%C/A)。

前置时间

前置时间是供应链管理中的一个术语，是指从采购方开始下单订购到供应商交货所间隔的时间。

对应到我们的软件开发中，则是指一个任务从创建到完成的时间。如下图所示。

处理时间

处理时间指的是一个任务从开始做到完成所需的时间。如下图所示。

完整度与准确度百分比

一个任务完成了并不意味着它是准确的。

举个很简单的例子，我们读书的时候写作业，通常我们都能100%的完成，但并不能百分百的正确。

这在软件开发中也非常常见，一个需求被实现了，但和最初的描述并不一致。

通过完整度与准确度百分比（%C/A）可以分析项目的返工成本。

画价值流图的几个tips：

1. 不要过度细化关键步骤，大致可以按照看板上的列一一对应或略多。
2. 建议关键步骤数量不要超过15个。
3. 可以按有堆积或由于等待而产生延迟来画每个步骤。
4. 实践中，计算这些度量的数值是一个很大的挑战。一个比较可行的做法是取每个迭代的几张卡，然后计算PT的平均值。LT则看它从上一步挪动到下一步等待了多少天，也取平均值。%C/A则难免会拍脑袋得到数值了，这不可避免。
5. 某个关键会议也可以是步骤之一。比如发布评审会。

真实案例分析价值流图

下面这张价值流图是来自我一个真实的案例。

对于这个图上的数据我做一些说明：

• 不是所有公司的关键流程都长这个样子，公司不同项目不同，画出来的价值流图也不同。
• 设计审核的%C/A只有60%是因为当时这个项目的产品经理设计原型的时候并没有频繁和业务方沟通，导致设计的东西审核的时候经常返工。
• 软件开发的LT有12天那么长，是因为很多卡ready了之后，需要等待排进某个迭代，所以平均等待时间有7天。这个数字在很多公司可能更长。
• 发布申请和发布上线的LT都挺长的，也是因为申请需要等待领导审批，发布需要排期，所以等待时间也挺长。
• 用户验收测试的%C/A只有70%也是因为开发过程中并没有频繁获取业务方的反馈，导致用户验收测试的时候发现挺多不符合预期的情况。

从上图的数据中我们可以得到一些关键信息：

1. PT/LT只有39.2%，这就意味着中间有大量的等待时间。那我们就可以具体分析每个等待时间该如何优化。
2. 构建上传和测试环境部署这两步都没有等待时间，而且%C/A是100%。因为这个案例中它们都是利用pipeline自动化完成的。因此，自动化能帮助我们提高%C/A和缩短等待时间。
3. 平均%C/A是88.75%，意味着有可以改进的空间。那我们就可以具体分析每个步骤中为什么达不到100%。
4. 经过分析我们发现，很多%C/A不能达到100%的原因是，这个步骤的人并没有频繁的向前一个步骤获取反馈来验证自己是否做对了。
5. 经过分析我们发现，很多LT长是因为，有一些审批流程必须等到领导审核才能往下继续走，而领导往往不能及时审批。还有一些LT长是因为没有可视化看板，不同步骤的人并不知道工作已经ready了。

在上面的例子中，花费在创造预期成果上的工作时间比例， 仅占总开销时间的39.2%。这样的情况在常规IT部门中，类似的占比数字相当普遍，甚至更低。

上面的例子根据价值流图最终分析产出的报告有很多，这里就不详细展开说了。每个数字都可以研究背后的原因和找到改进的方案。

有了价值流图之后，通常我们可以提出来这3个问题：

1. 为什么这些工作步骤的%C/A值低于100%？我们如何才能够完全杜绝错误从一个步骤
   被传递到下一个步骤（并因返工而浪费时间和资源）？
2. 除了开发产品的时间，具体有什么因素导致了lead time？我们如何能够大幅降低队列和等
   待所损耗的时间？

3、我们如何改变工作实践，来降低每个步骤的处理的时长？

值流图的好处

1. 价值流图的好处在于让参与的团队成员对整个流程有可视化的数据化的认知。并清晰的知道该从哪个步骤入手开始改进。
2. 其次，过程的可视化呈现，有助于聚焦到被创造的价值上，而不是被实施的动作上。员工们和经理们常常能很好地理解他/她们的日常任务（做什么），而忽视了预期成果（为什么）。
3. 再次，价值流图有助于识别和消除瓶颈，并避免局部优化的陷阱：即把时间和精力花费在根本没有效果甚至带来负面效果的约束消除上。
4. 最后，对价值流的了解，有助于实现DevOps的关键思想：构建一个顺畅、一致经各个步骤的价值流，使得我们能够持续地、有节奏地、没有非必要的延迟、并以最优的资源使用方式来交付成果。

基于Eliyahu Goldratt提出的约束理论，任何系统中，在任何一个时间点上，有且仅有一个真正的瓶颈，这个瓶颈拖慢了工作，同时，花费在除了消除这个瓶 颈点之外的任何事情上的精力，都可以说是浪费。

总结

要画出完整的价值流图，一定要去研究项目中真实的实践是什么样子的，不能凭空想象，也不要去指望某些记录的文档信息，因为他们常常没人维护。

价值流图是帮助我们更好的构建DevOps的一种方式，要想做好DevOps只凭这一点是远远不够的。

如果大家对相关话题感兴趣，可以给我留言，我们一起讨论更多可能性。

参考：《DevOps精要》