破局 | 连滚带爬做项目管理？

作者简介

 

都云霞，Agilean 公司管理顾问、敏捷教练，CSM 、PMP 、CSPO 认证。近 10 年金融软件项目管理背景，曾服务于穆迪等国际金融咨询公司，参与中原银行、平安银行等的敏捷精益辅导。本文源自公众号Agilean。

 

由于某些不恰当的实施方式，敏捷导入有时在企业里处于「两头不讨好」的尴尬状态：业务认为敏捷是造成低质量交付的推手，而研发觉得敏捷是管理者压榨团队的帮凶。

通过分析众多敏捷实施失败案例，我们发现大多数情况下，版本迭代节奏不匹配组织和业务特点是导致失败的根本原因之一。本文将结合 Agilean 咨询团队的实践经验，推荐一种适合复杂业务场景（如金融科技）的版本迭代节奏：RISE（Release-Iteration Schedule for Enterprise)。

介绍 RISE 之前，让我们先看一下，在复杂的业务场景中，传统的双周迭代会遇到什么问题。

 

双周迭代？还是死亡行军？

 

我们曾对一个采用「双周迭代」的研发团队进行了访谈：

双周迭代，指每两周进行一次发布。这意味着从业务侧承接过来的需求，要在1-2天内完成需求分析和澄清。但对很多复杂业务场景来说，需求澄清通常要花2-3天才能真正完成。现实中很多的交付质量不合格，就是由需求不清晰这个源头问题造成的。

交付质量差，会促使人们不断将「功能移交测试时间」前移，比如要求迭代第二周开始之前提测，以避免上线风险。于是，开发同学必须加班加点，自测、联调也只能对付了事，上线时候还是一堆的故障。

最后，他对当前状态进行了这样的评价：

做软件研发，大脑是我们最重要的生产工具。但团队一直处于又紧张又疲惫的状态，别说高质量交付了，连最基本的质量都难以保证。这不是在做迭代，而是连滚带爬，「死亡行军」。

在调侃的语气中，我们仍能感受到满满的无奈和倦意。仔细分析上面状况的产生，能发现两个主要原因：

• 团队将一个版本的所有活动，都压缩进入了同一个迭代。对于一些复杂业务和复杂系统，这样做往往导致时间过于紧张。

• 迭代内部以「一周开发，一周测试」的方式运行，这种情况下，迭代变成了小瀑布。

 

解决思路：用流式开发破解小瀑布

如何发现「小瀑布」？来瞧瞧下面这个看板：

 

上图中，团队所有事项都集中在开发区域。有些卡片进入了开发的「已完成」列，没有任何卡片进入「测试」。看板呈现了浪涌式流动——这就是团队以小瀑布方式运行的表现特征。

在小瀑布模式下，为了避免资源浪费，往往将迭代时间按流程切开，比如上半周开发，下半周测试。

听起来很有「节奏」，对不对？问题来了，测试在上半周的时间里，要做些什么？在现实中，上半周往往用来测上一个迭代的内容，于是，团队中开发测试的协作被强行割裂。

 

小瀑布模式的核心问题在于，「开发完成」并不是真的完成，还属于WIP（在制品），并不能产生真正的质量反馈。开发完成的需求，在测试时可能暴露出大量缺陷，造成返工。迭代管理的核心目标是降低交付风险，确保质量可控，但小瀑布模式显然无法有效实现这点。

如何破解小瀑布？我们通常建议团队采用「流式开发」。即以小颗粒度需求（如用户故事）为单位，让需求像水一样不断向下个阶段流动，从而快速获取反馈，真正达到利用迭代管理降低风险的目标（如下图）。 

 

以「流式开发」运行的迭代，看板往往呈现下面的变化形式：

 

诚然，流式开发对需求拆分提出了更高要求，需求要被拆解成可测试可验收的细小单元。其实，这是敏捷产品经理和敏捷教练需要具备的硬核技能，也是敏捷需求管理的基础。

另外，为了减少开发测试工作的并发打扰，开发人员要采取开发自冒烟、代码评审等质量措施，来保证需求的顺畅流动（这方面的详细内容可以参见FLEET的「润滑」原则）。

 

解决思路：将版本和迭代解耦

针对复杂业务研发场景，RISE 倡导在流式开发基础上，将版本和迭代解耦。延长版本存续时间，将一个版本分成需求迭代和研发迭代，前一个版本的研发迭代和后一个版本的需求迭代并行。

上面描述的版本迭代节奏，使团队可以实现需求澄清前置，即由产品经理提前一个迭代与业务人员进行需求细化。在研发迭代开始时，团队拿着已经充分细化澄清的需求，直接投入开发工作。

对于发布流程复杂、生产质量要求高的情况，RISE 版本迭代节奏同时提倡，通过回归测试和版本发布后置进行优化。即在研发迭代之后，再进行回归测试和版本发布活动。这样做的前提是「需求澄清前置、流式开发、质量内建」等实践已经建立，移交质量能够得到充分保障，因此，回归测试阶段发现缺陷的概率变得很低。

 

综合前面描述，下图为详细到每日安排的 RISE版本迭代日历：

按上面迭代日历所示，对研发团队来说，在一个研发迭代内将拥有：

•  已经得到充分澄清的需求

• 8 天的开发时间

• 6 天的测试时间

• 2 天的缺陷修复时间

这样的时间分布，对于以双周迭代运行的团队来说，保障交付质量的各阶段时间已经相当充足了。并且，由于整个开发过程中并行事项较少，团队可以减少相互间的打扰，更加专注，交付效率也随之获得提升。

按照上面的迭代日历，进行双周迭代时，需要注意下面两点：

• 合适的需求粗细粒度。把需求拆成合适的粒度以便于其流动，单个粒度需求尽量控制在2-3人天完成。

• 对当前迭代的需求进行分步移测。让测试可以从第一周的第3天至第二周的第4天，持续测试不同的需求，而非堆积到一个时间点，一次性移测。

 

RISE 能否满足业务时效要求？

读者可能会有疑问，增加了一个完整的需求迭代，是否相当于开发后置了？会不会减慢整体交付时效？

首先，我们要引入前置时间（Leadtime）这个概念。需求前置时间指从需求提出到完成上线的整个时间周期。它包含意向形成、需求讨论、设计定稿、开发、测试、上线发布几个时间段（如下图），Agilean 自研的敏捷组织管理工具知微，已经可以实现需求前置时间的分段统计：

需求前置时间能够很好地反映研发的响应速度，是我们倡导优化的核心指标之一。通过缩短需求前置时间，持续进行高质量、有价值的研发交付，也是组织推进敏捷的重要目的。

让我们推演一下，RISE版本迭代节奏在现实中的运行方式：

运行双周迭代的团队，在第一周的第1天收到一个复杂业务需求。首先，由产品经理进行需求澄清，与业务讨论并梳理业务规则。通常情况下，这个需求会在第三周（即开发迭代的第一周）投入开发，经过 10 天的开发和测试后，进入回归测试，并在第五周上线。

可以看到，该需求从想法提出到上线发布，一共耗费 4 周 + 4 天 = 32 天。对大部分团队、大部分复杂业务需求来说，32天的需求前置时间已经很快了。

另外，因为采用了流式开发模式，在迭代运行过程中，业务方可以加入紧急需求，顺延一些还未进入开发的低优先级需求。确保团队对紧急需求，有更快速、更灵活的响应能力。

本文以一个不理想的双周迭代案例开始，分析了团队在迭代过程中时常遇到的问题以及背后成因，并介绍了稳定高效的 RISE版本迭代节奏，以及详细的迭代运作日历。这是Agilean基于十年来在企业内推动敏捷落地的实践总结，希望可以给有类似困扰的团队，提供一些启发和思考。

在迭代落地的过程中，架构设计、流程控制、资源配置、人员能力等很多因素，都可能影响其效果。如果您的团队在迭代运作过程中遇到问题，欢迎随时与我们展开讨论。

 

 

推荐阅读

 

• 来挑战吧 ！| PMI-ACP 模拟试题

• 租车订单团队敏捷新征程!

• 滴！请查收机票增值会员团队年度敏捷账单

• 团队遇上敏捷--携程无线酒店转型手记

• 2020 | 敏捷总动员启动啦！

---

部分图片及电子书来源于网络，版权归原作者所有，仅供学习勿作它用。如果侵犯到您的权益，请联系我们撤除。

---