敏捷思想中有一条原则指导我们进行过程改进：每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。由于很多不确定性因素会导致计划失效，比如项目成员增减、技术应用效果、用户需求的改变、竞争者对我们的影响等都会让我们作出不同的反应。敏捷不是基于预定义的工作方式，而是基于经验性（Empirical）的方式，对以上这些变化，敏捷团队通过不断的反省调整来保持团队的敏捷性。敏捷为我们提供了过程改进相关的工程实践、工作流程和工具。
1. 敏捷中的过程改进实践
与CMMI所提供的重量级解决方案不同，敏捷方法为我们提供了针对过程改进的很多简单但又实用的工程实践，这里列举4个作为参考：
（1）五个为什么
5个为什么也是敏捷领域比较推崇的一个过程改进实践，原理很简单但确实很有效。所谓为什么，也就是对一个问题点连续以5个“为什么”来自问，以追究其根本原因。当然，这里的数字5知识一种虚数，使用时不限定只做5次为什么的探讨，主要是必须找到根本原因为止。5个为什么的关键在于鼓励解决问题的人从结果着手，沿着因果关系链条，直至找出原有问题的根本原因（如下图）。
（2）学习矩阵
学习矩阵相对比较少用，但在有些场景下也是我们可以用来进行灵感触发的有效工具。如下图中，针对分布式协作下的团队开发，我们首先总结做得好的和做得不好的方面，再看看有没有新的想法，如果实在不行我们也可以看看找谁帮忙，这些过程性成果都可以通过类似的学习矩阵进行细化和明确。
（3）头脑风暴
头脑风暴（Brain Storming）是我们经常使用的一种触发灵感的活动，下面是需求和UI界面匹配问题团队成员之间一次简单的头脑风暴，通过讨论大家就工作流程做了一项改进：
| 开发人员：现在由于开发周期比较短，产品经理在没有完全梳理清楚产品需求的情况下就召开需求评审会议，导致后期开发过程中出现很多问题，返工的现象比较严重。 技术管理者：我们可以开展二次评审，也就是说在面向所有开发人员的正式需求评审之前，先可以找部分技术代表作第一次评审，通过第一次评审对需求存在的问题先修订之后再召集所有人开第二次评审 产品经理：那我这边在产品初稿出来之后会找前后端的技术负责人先碰下 项目经理：恩，下一个版本我们在流程上就引入二次评审 |
（4）亲和图法
亲和图（KJ法/Affinity Diagram），把大量收集到的事实、意见或构思等语言资料，按其相互亲和性（相近性）归纳整理这些资料，使问题明确起来，求得统一认识和协调工作，以利于问题解决的一种方法。下图就是亲和图的一种表现形式，通过对团队成员提出的想法从“继续保持”、“停止”’和“尝试”者三个类型进行归类。
2. 敏捷中的过程改进工具
敏捷的各种方法中存在一些工具可以用于帮忙我们实施过程改进：
（1）燃尽图和燃烧图
燃尽图（Burndown Chart）和燃烧图（Burnup Chart）来自于Scrum，用于作为专门的工具对Sprint执行过程进行监控。Burndown Chart（见下图a）关注于剩余功能，而Burnup Chart（见下图b）关注已完成功能。图中我们在Burnup Chart中添加了一条异常情况下的曲线（下图b中位于下方的曲线），可以看到这种异常很大程度上源于使用了Water-Scrum-Fall模式，在Sprint的前一半时间内，团队并没有产出任何可交付成果导致后半程发力不足。
（2）价值流图
价值流图来源于TPS，TPS 的核心思想是，工作流中有以下三种制造约束的浪费必须要消除掉。你不得不做的事情中，有没有哪些是无用的或多余的？这类事情就属于徒劳，就是你不得不做，却不创造价值的事情。有没有一些时候，你只是闲坐着不能开工，焦急地等待某人给你答复？这就是不均衡，工作总是一阵多一阵少。是不是还有些时候，你不得不加班加点，因为你被要求完成比你所能承受的大得多的工作量？这就是超负荷，被要求做到不合理或不可能的事情。价值流图的作用就是通过可视化的效果让我们能够发现这些问题，从而通过拉动式系统等方式解决这些问题以达到持续改进的目的。关于价值流图的详细讨论可以参考《精益之识别和消除研发过程中浪费的思路和模式》一文中的内容。
（3）累积流量图
管道理论的一大话题是我们需要测量并管理管道中的流量，而在看板方法中，累积流量图（Cumulative Flow Diagram，CFD）为我们提供了这方面支持。下图就是一张累计流图示例，可以看到测试所对应的条带在变宽，这就告诉我们测试可能正在成为整个工作流中的一项瓶颈。图中还可以添加一些额外的线，用来表示平均到达速度（Arrival Rate，每天新增的工作项的数目）和平均工作存量（Inventory，工作流中工作项的总数），并展示平均交付时间（Lead Time，每个工作项在系统中存在的时间）。
使用CFD 管理系统流量的关键在于寻找那些能够表明存在问题的特征。看板可以告诉你今天你的工作流中哪里存在不均衡，并且帮助你通过添加在制品上限的方法来管理每一天的工作流。而CFD 的作用则是让你能够看到“在一个时间段内，你的整个流程的表现如何”，这样你就可以采取措施来找出并修复那些长期的问题。
结合上述限制在制品上限的方法，就可以通过CFD实验在制品上限的值并管理系统流量。一个软件开发的过程一开始可能处于不稳定的状态，通过对开发、测试等各个环节设置不同的在制品上限值，并观察对应的平均交付时间，找到基于现有资源的最合适的在制品上限值组合，确保开发过程的稳定性。
如果对文章感兴趣，可以关注我的微信公众号：程序员向架构师转型。
我出版了《系统架构设计：程序员向架构师转型之路》、《向技术管理者转型：软件开发人员跨越行业、技术、管理的转型思维与实践》、《微服务设计原理与架构》、《微服务架构实战》等书籍，并翻译有《深入RabbitMQ》和《Spring5响应式编程实战》，欢迎交流。
