双周迭代死亡行军怎么破？

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

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

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

1

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

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

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

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

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

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

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

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

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

2

解决思路：用流式开发破解