软件项目管理中价值流反馈回路的意义

在探讨价值流程图时，我们总会将交付时间与数据吞吐看作是静态的，但这些参数实际是价值流图的行为特征。价值流程通过步骤、能力、处理事件、反馈回路、概率等在内的结构，定义了价值流的交付时间、在制品（WIP）及动态吞吐量。

让我们从一个简单的价值流开始，只有一个步骤“工作”，负责材料的某些工作。材料每分钟到达一次，所有材料的处理时间步幅固定为一分钟，材料在输入队列中放置时间为一分钟。在这个简单实验中，我们只有一个重新处理的材料“返工”（redo）反馈回路。

如你所见，返工并不是必须执行的步骤。质量优秀的项目会直接进入输出队列，但如果项目质量堪忧那么它将进入返工队列，再次执行“工作”这一步骤。从我们的实验来看，质量不过关重新返回“工作”队列的概率很重要，我们将这种情况称作是“返工”概率。

在实际生活中，这种过程非常常见：

• 在代码审查中，代码修改提交者会收到代码是否存在问题的反馈，如违背代码标准、实施问题等

• 在质量保障实践中，测试团队会返回应用构建后存在的 bug

• 在场景可靠性工程中，新版本部署需要人工干预解决先前被忽视的问题

也许你会认为我们所用的例子过于简单，以至于无法完全反映上述例子中的场景，但我们现在还不需要过多的细节。正如一位科学家所言，所有模型都是错的，但有的可能错得有用。这句话完美符合我们现在的情况。让我们先从这个模型开始，看看能在其中学到什么可以应用至软件工程管理中的知识。

图 1.实验性质的价值流图

如果你想要对模型进一步探索，调整参数或根据需要添加细节，可以参考这个链接。

第一个实验是研究一个步骤中的“返工”概率对整体流程交付时间和吞吐量的影响。这种实验设置对软件工程经理来说非常现实，它能提示我们在不增加雇员的情况下要如何提升交付价值。让我们先从抽象案例开始，进一步探讨其对软件管理的实际意义。

在我们的模拟中，我们以 10%的步幅将返工概率从 0%提升到 90%，假设材料处理顺序代表结果差别，是输入队列还是返工队列的材料优先被处理，换句话说，我们是否需要将 bug 修复优先于功能开发。

我们将以下三种设置的价值流图模拟运行 100 分钟：

• 当输入队列优先级高于返工队列时，工程团队实际是在处理新需求而不是改 bug

• 当输入队列优先级与返工队列相同时，工程团队是将新需求与 bug 混合在一起

• 当输入队列优先级低于返工队列时，工程团队优先处理 bug 再处理新需求

输出模拟如下：

图 2. 三种情况的模拟结果

只有当输入队列优先级高于返工（bug），也就是新功能比改 bug 更重要的情况下，才会出现交付时间固定为两分钟的情况。解释也很简单，因为输入队列的材料（新功能）拥有更高优先级，所有返工队列（bug）的材料都积压在底层，无法进入“工作”这一步骤。尽管两分钟的交付时间看起来很美好，但这也只是一个假象，不断推迟处理的返工材料只会延长 WIP 的时间：这些 bug 或技术负债终究还是要处理的，新材料（新功能）无论如何都会被推迟。因此，将团队部分能力分配给已知问题的处理是合理的。

图 3. 高优先级输入队列中，在制品有 50%的概率返工

在制品（WIP），一个不能细看的东西。我们或许可以参考道路交通和网络流量这两个模型来研究在制品的影响，由于道路宽度和带宽的有限性，新加入的车辆或数据包都会对当前部分的基础设施造成影响。在低负载时，这些影响可以忽略不计；但随着负载的增加（车辆或数据包的数量），整体交通流动速度会下降。“降低流量水平”，这看板（Kanban）使用 WIP 作为流程机制的关键原因。以 WIP 为阈值指标确实可以帮助我们监控“流量”，但前提是它能够捕捉到全部的项目工作，包括计划内、非计划内、行政管理等等各种会占据我们精力和时间的活动，然后这一切又会变成优先级争夺的游戏。

让我们继续回到模型的研究。当输入队列（新功能）优先级高于返工队列（bug）时，事情大不相同了：交付时间会随着返工概率的增长而增长。原因是材料在离开过程，也就是项目工作完成前，会多次进入“工作”的步骤。另一个值得注意的现象是，随着返工的增长吞吐量反而会降低，这也是必然的，因为吞吐量的计算公式是离开材料和到达材料的比率。在一段时间内（在我们的模拟中是固定的 100 分钟），如果交付时间增长，那么离开的材料数量会减少，吞吐量也会下降。

那么这对于实际软件工程管理来说有什么实际意义呢？率先解决反馈回路中会出现大量 bug 或问题的部分，以恢复团队能力。举例来说，如果我们的架构脆弱或代码可维护性很低，在部署任何变更后都需要大量返工，那么重构是必要的，只有这样才能提高工程团队的能力，恢复生产力。

最后的一个观察结果是，模拟时长决定了交付时间。价值流模拟的时间越长，交付时间的变化就越多。这种行为是直接反应了价值流图结构中反馈回路，在输出队列与返工队列之间的概率分布。工程管理者在接手包含大量累计债务的历史遗留代码时，考虑对解决方案增量返工是较为合理的，否则，不仅仅是追赶进度的速度，交付速度也会一直迟缓。

追求简单的艺术：越是复杂就越容易提高结果在可接受范围外的概率。为避免这类情况发生的一种方法是，尽可能简化反馈回路，使其快速且直接。对数据质量评估和鉴定之前所收集到的一切信息应保持怀疑态度，让变更部署质量的反馈保持简单、简洁、快速，是 TDD 和 BDD 之类工程实践会如此强大的原因。

后续可以尝试单一变量的迭代变化，当然最好是通过实验设计自己搭建一个价值流，以充分性为目标，看看最后会是什么结果，你可能会面临“完美并不意味着好”的挑战。更高阶的挑战会包括跨流程影响、间接影响，甚至还会有活动和数据观测之间尚未被发现的关系。流程和数据透明化、可见性都能够成为价值流程图中传递意图和映射现实的强有力工具，并在利益相关者的参与中构建可信度和可用性。

下图列表展示了价值流图的多个流程是如何有多个交付时间，在输入和返工队列拥有相同优先级且返工概率为 50%时，材料在离开项目时留下的流程痕迹。如你所见，一个材料可以有各种形式的返工反馈回路。当软件工程经理面临这种多类型反馈回路的场景时，可以根据情景发生频率、对吞吐量和团队能力的不利影响等不同情况有不同处理方式。先找到反馈的根源，是什么导致工程师无法及时收到反馈？另一个重要的问题是针对重复性反馈，为什么工程师无法在收到反馈后立即做出变更？架构或环境配置本身都极可能导致工程师无法在本地进行测试、运行这套反馈流程，只能从其他团队或管道步骤中获取反馈。在生产力最高的环境中，工程师都可以在本地，不影响代码库的请胯下运行所有管道步骤和各类测试。

综上，我们会建议敏捷和DevOps领域使用价值流图的从业者透过价值流结构和视角来观察其包括交付时间、吞吐量、WIP 等在内的动态特征。搞清楚价值流中的哪些结构因素会导致动态观察的结果变化是对改进或新的、更平衡的价值流而言至关重要的。

希望这些想法和见解能在你的实践中派上用场。欢迎随时联系我们，分享你认为重要的经验教训。

原文链接：

The Implication of Feedback Loops for Value Streams

相关阅读：

DevOps 已死，平台工程才是未来

POC、Scrum 和低质量软件的解决方案