什么是价值流

传统的工作中，不同的职位都只关注本人所交付的货色，比方产品经理关注产品需要文档的交付，开发人员关注软件代码的交付，运维人员关注于软件产品的部署。

随着 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 精要》