今天你被 SCRUM 祸害了没有？

引入敏捷方法后，许多研发同学抱怨加班比之前严重了，仿佛敏捷成为了管理者剥削研发人员的高级手段。这里所说的「敏捷」，往往指 Scrum。由于其市场营销的成功，许多人错误地将敏捷等同于 Scrum。坦白说，「敏捷」在这里替 Scrum 背了黑锅。

Agilean 在多年一线敏捷落地过程中意识到，研发同学感到「被祸害」的根源在于 Scrum 框架本身的局限性。Scrum 诞生之初，适用于简单团队的简单场景。它引入了迭代（Sprint）这个管理单元，试图用一个单元同时管理产品目标、团队容量和交付进度。

这样的好处是框架简单易懂，方便培训和发证。经过参与几天培训，人们便可在不同场景、不同团队中尝试“敏捷”落地，这是 Scrum 营销的成功之处。犹如佛教中的净土宗，信徒每天勤念“南无阿弥陀佛”，希冀死后升入西方极乐世界，自然拥趸者众。

在现实工作场景中，大型组织按 Scrum 要求拆开原有的系统团队，组成端到端的跨系统特性团队（Feature Team），这个思路原则上没错。但如果只强调 Scrum 里的迭代概念（Sprint），弱化用于进度管理的系统版本概念（Release），将造成管理的缺失甚至混乱。

我们在敏捷辅导中发现，在大型组织里，需要团队迭代和系统版本两个管理单元并存，才能进行真正有效的管理。或者说，Scrum 框架的先天不足（诞生于简单场景），是导致其在大型组织里频繁翻车、研发团队加班加点的根本原因。

1

Scrum 框架的舒适区

小型研发团队运用 Scrum ，往往感觉最为舒适。一个团队负责一个系统，一个迭代产出一个系统版本，迭代和系统版本之间是一对一关系。在这种小团队，你可以发现许多迭代和版本混用的现象，如下图所示：

燃尽图是 Scrum 的一个核心管理工具，在小团队场景下，它也是够用的。迭代初期，它可以用于团队的开发容量估算。由于迭代和系统版本一一对应，在迭代过程中，燃尽图也能用于管控系统版本的进度风险。

下面，我们将逐一谈谈对Scrum有些挑战的场景。

2

一个迭代，多个版本

这里有两种可能性：

• 快速发布的 DevOps 小团队

能够快速发布的 DevOps 小团队，可以采用两周迭代的方式来管理团队，同时，也可以在一个迭代内按需发布多个系统版本。

• 同时负责多个系统的特性小队

敏捷组织中标准的特性小队，一个小队可以修改多个系统的代码，在一个迭代内，也可能发布多个系统版本。

在上面两种情况里，如果团队只按迭代进行管理，很可能出现 A 系统版本进度超快，但 B 系统版本还未启动的情况，这就造成了系统交付进度风险（由于只关注一种管理单元造成）。但是，由于团队较小，出现问题的概率还比较低，好像对付着管理也还凑合。下面让我们进一步进入大型组织的复杂日常场景，重现一下翻车现场。

3

多迭代、多版本并存

在微服务的终极理想状态下，一个团队负责且仅负责一个微服务（系统）。但在现实里，多个团队同时负责多个系统也是常见的场景。在很多大型组织当中，多个团队，执行多个迭代，需要发布多个系统版本，也就是共同负责多个系统的众多特性小队协同工作。

在这样的敏捷现场，往往团队早上对着一个任务板（只有To Do、 Doing、Done）开站会。任务条飞来飞去，但进度全貌并不清晰，因为暗流之下，迭代中有多个版本在并行。

图 / 迭代冰层下的系统版本并行

经常等到某个版本要封版了，才发现时间已经不够，团队挑灯夜战追赶进度。好不容易系统熬夜上线，第二天出了生产缺陷，接着加班修复，陷入「进度滞后 -> 质量变差 -> 缺陷进一步延迟进度」的恶性循环。

因此，在这种复杂场景下，我们就建议团队使用迭代和系统版本两个管理视角来进行管理了，这已经超出了Scrum框架的原始范围。我们首先建议团队用迭代来进行团队容量规划，并密切监控团队产能趋势。

图 / 用迭代进行产能趋势追踪

其次，在监控产能时，非常关键的是要分别监控迭代中各版本进展，独立管理各版本的进度风险。这样才能预知风险，提早应对，帮助团队走出恶性循环。

图 / 使用知微来分别监控各版本进度风险

4

面向业务的产品版本

在复杂组织中，多个团队同时交付多个系统版本，这里还有一个产品版本的概念。同时上线多个系统版本时，会形成一个跨小队多系统的「产品版本」。例如，业务同学说 0315 （产品）版本，是由3月15日上线的、系统 A 的0315版和系统 B 的0315版本构成的。

尤其在规模化敏捷里，公司的战略项目往往横跨多个部门、多个系统才能完成，业务口中的版本是多个系统所有工作的集合。采用产品版本的概念，可以很好地跟踪业务需求的进展，保障团队间对齐。这个也是Scrum框架里面缺乏的内容。

5

应迭代管理&版本管理并重

好的研发管理方法论，应「迭代管理」与「版本管理」并重。

迭代是一个时间盒，是针对团队的，用于团队容量管理和进度管理。但是需要注意的是，对于统一迭代节奏的组织而言，即使整个组织都在「迭代1」，但 A 团队的「迭代1」和 B 团队的「迭代1」实际上是不同的两件事。

版本是一个批量，是针对系统的，用于版本进展管理和交付风险管理。对于复杂的大型组织，系统版本为管理者提供了跨团队管理视角，帮助管理者了解版本的需求澄清、研发、测试进度。

为了在实践中把两者有机结合，Agilean 团队提出了 RISE 框架 (Release-Iteration Schedule for Enterpise)。迭代管理大家已经熟悉，这里不再赘述。以下列举了版本管理的八个要点，未来我们将专文展开详述。

6

八个版本管理要点

对小团队来说，迭代和版本基本等同，只用迭代管理即可，不需要独立的版本管理活动。

但在大型组织，多个团队在同一迭代、多个版本上进行协作，需要在版本层面（产品版本和系统版本）进行有效管理，以降低管理的复杂性，提高可预测性。具体机制参见下图：

• 需求选择机制：产品需求在复杂组织中往往需要由多个团队在多个系统上开发完成，因此，需求选择的过程往往比Scrum框架描述的过程复杂许多。我们建议采用产品版本概念，由业务、产品和研发负责人共同完成需求选择，快速将选中的需求分拆出系统任务，再由各研发团队进行容量决策，决定是否可以纳入迭代。整个沟通过程可能需要沟通几轮，过程相对复杂。

• 产品版本范围管理：由于上述过程沟通成本较高，需要更早地由产品经理澄清需求，并在研发过程中不断根据系统版本研发进展、外部市场变化，对产品版本范围进行动态调整。

• 系统版本架构评审、代码评审： 一个系统的代码可能由多个团队修改，因此，需要指定系统负责人（守护者）对架构或核心代码修改进行评审。

• 系统版本进度管理：考虑引入系统版本经理的角色，督促系统版本关联团队的进度，避免个别团队拖后腿的现象，并保证系统及时封版，为后续的质量保证活动留出充足的时间。

• 系统版本代码封版：系统封版后，拉出系统版本分支，既保证后续开发版本开发可以继续进行，又保证无关代码不会偶然合入，带来质量风险。

• 系统版本测试管理：版本分支建立之后，开启回归测试。回归测试可以由参与开发的一个团队牵头负责，或者由多个参与团队协同完成。

• 系统版本协同管理：需求提出方和研发负责人针对跨小队的需求，提前规划好排期，定义关键节点以提高沟通效率，降低因进度信息不一致带来的交付风险。

• 系统版本发布管理：版本经理确保发布的版本符合各种质量要求，所有需求完整上线，没有遗漏，也没有夹带不属于该版本的需求。

综上所述，在大型组织中，版本管理和迭代管理缺一不可。通过两者的有机结合，管理者可以利用产品版本管理帮业务、产品、研发三方统一目标，聚焦价值交付；可以利用迭代管理来管理团队容量，不断监测和提升团队交付能力可以定期检测研发产能和进度，提升团队能力；可以利用系统版本管理来管理系统交付进度、交付风险、质量风险。

如果组织长期忽视迭代管理，很难及时了解团队产能和成长情况，无法采取针对性的改善措施，会导致团队能力停滞不前；如果长期忽视版本管理，容易丢失业务目标，给业务和科技紧密协同造成障碍，久而久之，企业的数字化战略难以真正落地。

点击原文链接，查看 Agilean 提出的 RISE 企业版本迭代管理框架。

本文作者

RECOMMEND

推荐阅读

RISE 企业版本迭代框架

都云霞，公众号：Agilean双周迭代死亡行军怎么破？