这是 “超越敏捷框架” 系列文章第三篇。本系列文章目的是介绍一个流程定制(Agile Flow 流程定制工作坊)的简单套路,敏捷教练和PMO 可以通过它为组织量身定制敏捷实践,达到企业治理的一致性要求和团队自组织自管理之间的平衡。 上一篇超越敏捷框架:确定范围、目标和生命周期模型,我们理解了敏捷项目管理最适用的场景是业务生命周期(表述为S曲线)的中段(10倍速增长期),并通过6种项目管理生命周期匹配练习来理解团队正在采用的基准项目管理生命周期模型。 接下来,我们开始对团队的基本流程进行定制。在本文中当我们说流程时,我们指的是团队如何在一起工作的工作方法。我们重点聚焦软件交付这一过程,并实践如何从当前团队所采用工作方法(如 ScrumBut、SAFe、看板、传统项目管理,等)向更高效的方式演进。 这是整个工作坊的第二步。这一步的重点是对团队的当前的工作流程(推荐用价值流图)进行分析,发现约束团队绩效的关键瓶颈点,并分析识别造成该约束的关键原因。 研发效能改进应该围绕限制团队绩效的瓶颈环节进行。如何寻找瓶颈环节呢?简单来讲,就是看在哪一个步骤前队列中的工作项最多,有积压。我们可以想象一下在医院看病的场景,哪一个环节排队的人最多?公立医院通常是在等候医生问诊的环节。同样的,从乘客到达机场到登机的流程中,多数时候我们能体验到安检环节是该流程的瓶颈环节。 我们能够得出这样的结论是因为我们可以观测到在这两个环节排队的人数最多,等待的时间最长。我们可以很直观地通过观察队列长度获得这样的认知。但在软件交付工作中,如果我们不能通过可视化的方式呈现这一流程以及每个步骤前的队列,我们就无法正确识别瓶颈(也称为约束,也就是流程中限制吞吐量的最弱一环)。 我们可以通过多种方式可视化软件交付流程,最为普遍使用的是:
光是可视化流程并不足够让我们发现瓶颈,我们需要用数据来得出准确结论。仅凭经验和直觉有可能会引导团队得出错误的结论。数据的来源有几种:
图1: DA(规范敏捷)中给出的 “理想价值流图” 如果我们观察图1中的工作项队列(蓝色和橙色方块堆叠),从左至右可以看到工作项流经战略(也就是组织可能的战略选择)→ 举措(也就是为实现战略立项的项目/产品)→ 业务想法(从举措分解来的Epic,或者高层级需求)→ 待排期需求(Epic或特性)→ 已排期需求(特性或故事)→ 进入开发团队的用户故事列表。 所以从全局的视角,一个产品的绩效瓶颈可能出现在1. 客户/市场(产品本身就没有那么大的市场需求),2. 业务探索(业务无法提供对市场和客户的足够洞察,形成准确的产品战略),3. 需求(开发团队经常处于等待状态,或者需求本身缺陷较多),4. 开发实施(任何一个需求都需要较长的的开发、构建和测试时间),5. 部署发布(经常处于等待状态但无法部署发布的版本)。 从现实场景考虑,敏捷教练和 PMO 能够影响的范围可能处于3~5之间,所以我们在 Agile Flow 工作坊上可以暂时不考虑市场和业务的问题。当然,即便3~5不是瓶颈,优化它们也有一定的意义,因为可以对1~2环节产生反馈。只是这样做的成本太高,收益有限。 从定性的角度确定瓶颈步骤后,我们可以进行深入 “下钻”。 比如进一步分解某个环节 —— 假设4. 开发实施是瓶颈环节,那么可以进一步展开这个步骤,然后分析子步骤中的瓶颈是在开发,测试还是集成? 我们识别到瓶颈后,需要做针对性的改善,以便提高整个系统的表现。大多数人可能想到通过自动化、流程优化或者工具实施等对瓶颈环节进行改善,但其实改善由两个有序的步骤组成:
图2: 五个为什么 我们也可以采用鱼骨图的方法,结合人员,流程,工具等类别来进行分析。 在上一步中的根本原因分析中我们可能会得到多个导致瓶颈的原因。注意这里分析得到的原因可能只是我们的观点,或者说是一种基于经验的推测,不一定有确实的证据支持我们的观点。 所以我们接下来要从两个方面对原因进行分类:对瓶颈环节造成的影响大小,以及是否有证据(该分析有没有数据或者其他证据支持),来可视化我们的分析结果。图3中示例假设测试环节是开发实施中的瓶颈环节。 图3: 对可能导致瓶颈的根本原因进行分析排序 其中对于影响大且没有证据的,我们应该积极收集寻找证据以支持我的结论。这一步骤的最终输出应该是影响瓶颈的关键原因(比如 Top 3)。 回顾 我们再来回顾一页纸画布,我们在上一篇中完成了1,2,3;我们在本文中完成了4 —— 通过价值流图确定瓶颈环节以及找出根本原因。 图4: 在一页纸画布上,我们在工作坊的这一阶段聚焦 “4” 在本文中,我们探索了 Agile Flow 流程定制工作坊的第二步,即
当我们充分利用瓶颈资源,并找到造成瓶颈最大影响因素之后,我们就可以进入下一步:确定改善解决方案。 香港大学商业学院客席讲师 |
|