这是 “超越敏捷框架” 系列文章第三篇。本系列文章目的是介绍一个流程定制（Agile Flow 流程定制工作坊）的简单套路，敏捷教练和PMO 可以通过它为组织量身定制敏捷实践，达到企业治理的一致性要求和团队自组织自管理之间的平衡。

上一篇超越敏捷框架：确定范围、目标和生命周期模型，我们理解了敏捷项目管理最适用的场景是业务生命周期（表述为S曲线）的中段（10倍速增长期），并通过6种项目管理生命周期匹配练习来理解团队正在采用的基准项目管理生命周期模型。

接下来，我们开始对团队的基本流程进行定制。在本文中当我们说流程时，我们指的是团队如何在一起工作的工作方法。我们重点聚焦软件交付这一过程，并实践如何从当前团队所采用工作方法（如 ScrumBut、SAFe、看板、传统项目管理，等）向更高效的方式演进。

这是整个工作坊的第二步。这一步的重点是对团队的当前的工作流程（推荐用价值流图）进行分析，发现约束团队绩效的关键瓶颈点，并分析识别造成该约束的关键原因。

1.识别关键约束

研发效能改进应该围绕限制团队绩效的瓶颈环节进行。如何寻找瓶颈环节呢？简单来讲，就是看在哪一个步骤前队列中的工作项最多，有积压。我们可以想象一下在医院看病的场景，哪一个环节排队的人最多？公立医院通常是在等候医生问诊的环节。同样的，从乘客到达机场到登机的流程中，多数时候我们能体验到安检环节是该流程的瓶颈环节。

我们能够得出这样的结论是因为我们可以观测到在这两个环节排队的人数最多，等待的时间最长。我们可以很直观地通过观察队列长度获得这样的认知。但在软件交付工作中，如果我们不能通过可视化的方式呈现这一流程以及每个步骤前的队列，我们就无法正确识别瓶颈（也称为约束，也就是流程中限制吞吐量的最弱一环）。

我们可以通过多种方式可视化软件交付流程，最为普遍使用的是：

1. 通过价值流图（Value Stream Map）来映射流程；
   

2. 通过看板方法（物理看板或者是电子看板）各个纵列来映射流程中的步骤。

价值流图的优点是可以从全局视角理解流程，抓大放小。缺点是价值流图是一种静态呈现，难以反映出动态变化。

而看板方法更适合聚焦在某个大流程中的某个特定环节而且看板方法可以动态反映工作流动的的变化，随时发现当下的瓶颈。缺点是过于聚焦在某个局部流程，可能导致局部优化。

光是可视化流程并不足够让我们发现瓶颈，我们需要用数据来得出准确结论。仅凭经验和直觉有可能会引导团队得出错误的结论。数据的来源有几种：

• 来自研发效能管理工具平台，如 JIRA 等。
  

• 来自物理看板的每天的手工记录整理出的统计数据。
  

• 根据最近的几个典型需求回溯分析获得，比如该需求在流程的各个环节停留了多长时间。

如果数据暂时不可得，而且受限于工作坊的时间，我们可以利用 DA（规范敏捷）中给出的 “理想价值流图” （见下图1）来先从全局上做定性分析。所谓理想价值流（Idealized Value Stream）就是 DA 中根据多数企业软件交付流程，总结出来的一个 “通用的“ 过程：需求永远从顶部的客户开始，经过左侧业务探索阶段，到下方的的开发实施阶段，然后是右侧的部署、支持和运营，最后再回到顶部的客户（客户获得价值）。

图1: DA（规范敏捷）中给出的 “理想价值流图”

如果我们观察图1中的工作项队列（蓝色和橙色方块堆叠），从左至右可以看到工作项流经战略（也就是组织可能的战略选择）→ 举措（也就是为实现战略立项的项目/产品）→ 业务想法（从举措分解来的Epic，或者高层级需求）→ 待排期需求（Epic或特性）→ 已排期需求（特性或故事）→ 进入开发团队的用户故事列表。

所以从全局的视角，一个产品的绩效瓶颈可能出现在1. 客户/市场（产品本身就没有那么大的市场需求），2. 业务探索（业务无法提供对市场和客户的足够洞察，形成准确的产品战略），3. 需求（开发团队经常处于等待状态，或者需求本身缺陷较多），4. 开发实施（任何一个需求都需要较长的的开发、构建和测试时间），5. 部署发布（经常处于等待状态但无法部署发布的版本）。

从现实场景考虑，敏捷教练和 PMO 能够影响的范围可能处于3～5之间，所以我们在 Agile Flow 工作坊上可以暂时不考虑市场和业务的问题。当然，即便3～5不是瓶颈，优化它们也有一定的意义，因为可以对1～2环节产生反馈。只是这样做的成本太高，收益有限。

从定性的角度确定瓶颈步骤后，我们可以进行深入 “下钻”。 比如进一步分解某个环节 —— 假设4. 开发实施是瓶颈环节，那么可以进一步展开这个步骤，然后分析子步骤中的瓶颈是在开发，测试还是集成？

2.分析造成瓶颈的可能原因

我们识别到瓶颈后，需要做针对性的改善，以便提高整个系统的表现。大多数人可能想到通过自动化、流程优化或者工具实施等对瓶颈环节进行改善，但其实改善由两个有序的步骤组成：

1、我们要保证瓶颈环节的资源得到充分利用。假设我们识别到开发是瓶颈，那么我们要尽量保证给到开发的需求是高质量的，减少因为需求质量问题造成的浪费和返工。另外，我们也要分析开发团队的工作内容，尽可能减少非增值活动的占比，比如和开发团队创造价值无关或者无效的会议、流程等。

2、在保证瓶颈资源被充分利用做有价值的工作后，我们开始探讨如何改善瓶颈环节。假设开发环节中的测试步骤是瓶颈，我们不要急于给出一个改善建议，而应该停下来问造成这个瓶颈的根本原因是什么。我们可以采用5-Why（五个为什么）的方法来做根本原因分析。

图2: 五个为什么

我们也可以采用鱼骨图的方法，结合人员，流程，工具等类别来进行分析。

3.确定最关键的原因

在上一步中的根本原因分析中我们可能会得到多个导致瓶颈的原因。注意这里分析得到的原因可能只是我们的观点，或者说是一种基于经验的推测，不一定有确实的证据支持我们的观点。

所以我们接下来要从两个方面对原因进行分类：对瓶颈环节造成的影响大小，以及是否有证据（该分析有没有数据或者其他证据支持），来可视化我们的分析结果。图3中示例假设测试环节是开发实施中的瓶颈环节。

图3: 对可能导致瓶颈的根本原因进行分析排序

其中对于影响大且没有证据的，我们应该积极收集寻找证据以支持我的结论。这一步骤的最终输出应该是影响瓶颈的关键原因（比如 Top 3）。

回顾
我们再来回顾一页纸画布，我们在上一篇中完成了1，2，3；我们在本文中完成了4 —— 通过价值流图确定瓶颈环节以及找出根本原因。

图4: 在一页纸画布上，我们在工作坊的这一阶段聚焦 “4”

下一步：

在本文中，我们探索了 Agile Flow 流程定制工作坊的第二步，即

根据一个 “理想价值流图” 去可视化和定位关键瓶颈点。

在充分保护和利用瓶颈资源的基础上，分析造成瓶颈的可能原因。

根据20/80原则，排序影响最大的原因，并积极寻找证据。

当我们充分利用瓶颈资源，并找到造成瓶颈最大影响因素之后，我们就可以进入下一步：确定改善解决方案。

作者：许峰 

精益创业 & 敏捷管理

香港大学商业学院客席讲师

EXIN 中国首批认证数字化转型官（DTO）

PMI DA 中国首位认证讲师