控制迭代，控制团队的节奏

本文一共7000字左右，会涉及：

• 迭代的三个目的
  • 打破无限时间错觉的调整机会
  • 协作节奏的容器
  • 交付进度的预测
• 四种迭代进化阶段
  • 瀑布迭代
  • 融合迭代
  • 滚动迭代
  • 流式迭代
• 两个强化迭代进化的强化剂
  • 延展需求分析
  • 强化自动化能力
• 最后回顾Scrum和极限编程的迭代概念，并进行点评

阅读完成之后你会对迭代有更深入的理解，并明确知道该如何实施迭代来促进团队在敏捷状态下的协作。

你可以浪费时间吗？

这个问题有意思吧，当你认真思考这个问题之后。你会发现你只能浪费自己的时间，那如果是自己的时间的话，那其实就不是时间，而是自己的生命。但我们每个人有一种拥有无限时间的错觉，这种错觉只会在我们行将就木的状态才会意识到这是一个错觉。

迭代一方面就是……

打破无限时间错觉的调整机会

对于商朝开国君主成汤来说，他刻在澡盆边上的“苟日新、日日新、又日新”就是他每天想成为一个迭代的证明。他每天躺在澡盆之中的时候，这可能是一天的晚上，低头看到这些字的时候。一个让他萦绕脑海的问题又浮现出来了：今天我有什么新的改变呢？成汤的目标就是更新的自己，每一天就是一次迈向更新自己的一次迭代过程。这个过程，会让他把这种思考逐渐地带入到生活的每一分钟、每一秒钟。

传统大型项目的交付过程会把一个大目标拆分成若干目标，从时间的维度来看不同目标需要组合在一起才能发挥最终威力。这样的最终价值的反馈环路过长，就如同你在跌落的过程中，拼凑一个能让自己飞起来的飞机一样，到最后一步你可能发现缺少某个关键零件。

相似的例子是新房的销售，为什么现在的开发商不把所有的房子盖好了再销售呢？而是整体设计完毕之后，一部分一部分建造，一部分一部分的销售呢？因为这样，开发商拥有更多的选择。

我们在之前的例子：成汤的自我提高、跌落中拼凑飞机、房屋销售其实都有一个非常明确的假设：自我提高的场景不确定、空中的零件不确定、房屋销售情况不确定。在目标和假设都模糊的状态下，我们需要有更多的选择。

更多的选择意味着更多的思考

这种整体成本是要增加的。比如，战争的一方所有的资金都花费在摧毁敌人的火药上，而另一方把资金花费一半在寻找敌人的目标上。战争的结果可能取决于这场战争发生的时间是近代还是现代。

在近代战争之中，火炮是战争的主力力量。但为什么在现在战争之中火炮就不能成为主力力量呢？一个主要的原因是因为攻击目标移动速度在变快，另一方面战场上不可预测的因素越来越多。这就会使得制导导弹在现代战争中扮演重要的角色。

每次调整就是对目标变化的一次适应。这种适应让我们思考目标是否是真正的目标？方向是否就不需要进行调整。这样适应与调整的过程就是迭代的重要意义之一。如果是大炮思维中步骤的分解，这虽然在外部看来如同迭代一样，但本质上没有获得使用迭代应有的好处。

总结来说迭代拥有强烈的假设：

1. 目标（环境、假设等等）会变化
2. 过程（交付内容）可以进行调整

如果上面两个假设不成立的话，请不要使用迭代的概念，你只是在使用里程碑的概念而已。当然迭代概念是包含里程碑概念的，但反之则不一定生效。因为里程碑概念不会强调对目标的适应与调整，而只会强调对目标的分解。

给出一个大型项目或产品的交付时间，一年半甚至两年，在这期间所有人都在以一个半成品作为阶段性奋斗目标。这种以半成品作为阶段奋斗目标，对于简单甚至繁杂的状态是没有问题的。但现实情况很可能是我们的项目或产品活在一个充满变化的复杂环境之下。我们的假设可能被颠覆的彻彻底底，我们的设想可能只是美丽的幻象。

但坏消息是……

我们一般不想主动思考

思考需要额外的能量，人们倾向节约能量。我们能坐着坚决不站着，能躺着坚决不坐着。能跟昨天一样坚决不探索新的可能性，哪怕换一下工作的座位。这才是迭代的难点。

那如何让大家更积极的思考呢？

让每一个迭代都发布一次吧

这么想的一定都经历过Scrum的培训，每个迭代产生一个潜在可交付产品增量（Potential Shipable Product increment）。培训完了很多人都简单粗暴的理解一个迭代有一个发布。认真翻阅Scrum Guide 2020[^ScrumGuide] ，我发现PSPi已经替换成Increment（增量）了。

Scrum说一个或多个Increment。只要迭代完毕之后，拥有一个或多个增量的话你就满足Scrum的要求。

咱们退后一步提出个问题，在一个迭代之中，没有增量和发布是否合理？

Scrum会告诉你，请不要说你在运行的是Scrum。但我们应追求的是在一个迭代认真思考项目或产品是否需要调整。没有发布只是本迭代工作基于假设地完成了而已。

发布是什么？发布是一次真实的反馈与验证过程。但一个迭代之中可能没有任何真实的反馈与验证，这是值得思考的。就如同成汤躺在澡盆中，看着“苟日新、日日新、又日新”，感慨道：“无新”。

对于我来说一个迭代之后没有得到任何的用户反馈，我会思考一下是否需要进行调整。两个迭代之后依然没有得到任何的用户反馈，我就需要寻找安慰自己的理由。三个迭代之后什么声音都没有的话，我就会抓狂。

你要是纠结一个能够实现适应与调整的里程碑是否就是迭代的话，请让我介绍迭代的第二个关键特性……

协作节奏的容器

对于每一天来说，早上起床要刷牙、穿衣、坐车、早点、打卡、争吵、午饭、干活、晚饭、坐车、娱乐、睡觉，然后再次开始一天的工作。我们就是在每天这种容器下生活的，但我们也可以某一两天打破这种节奏。

对于迭代来说，站会、需求讨论、迭代启动会议都可能在一个迭代中发生。

对于协作来说，需要一个容器来承载关键事件。一般所说的迭代日历，其实就是关注这个领域的应对思路。但我们需要注意的是，对于不同团队的协作事件是不同的，如果一个组织内部所有团队迭代日历的内容都是相似的，这其实是值得思考的。

对于迭代节奏的话，有四个阶段和两个强化剂：

四个阶段

• 瀑布迭代
• 融合迭代
• 滚动迭代
• 流式迭代

两个强化剂

• 延展需求分析
• 强化自动化能力

四个阶段

敏捷的背后其实是协作的强化，这四个阶段是协作能力与工程能力的综合状态展示。越高的话则侧面证明团队行为层面越敏捷。

1、瀑布迭代

特征：明显开发测试分界线，所有需求统一移测。

优点： 方便理解、移测点统一、环境准备方便、依赖方管理简单。

缺点： 测试与开发存在责任墙、开发与测试存在任务等待时间（等待其他任务完成）

如果从瀑布的角度来看，这就是小瀑布。只是下一迭代的需求分析和确认的工作与测试的部分时间重合。发布准备的时间可能在迭代之中也可能在迭代之后。确定需求也可能在迭代之中。这种迭代可以认为是瀑布研发过程的若干里程碑的变形。它拥有迭代的外衣，但常常没有敏捷的内核。恰恰因为开发测试的责任墙存在，可能造成开发抱怨需求不完善，测试抱怨移测质量不够高。也因为存在完成任务等待的时间，所以开发工作存在不连续感。

也正是因为责任墙外加时间短的迭代加持，测试常常抱怨测试执行时间太短。这种痛其实可以让测试人员主持每日例会来缓解测试的压力。但如果测试人员是好好先生的话，加班就不可避免了。

这个阶段，版本分支（稳定主干）的代码管理方式还能应对团队协作。

如果迭代长度不变，需求任务也没少的痛苦之后。团队（测试人员）一般会驱动协作节奏发生调整，进入……

2、融合迭代

特征：需求移测没有统一的时间点，但单个需求有移测时间计划。

优点： 集中等待时间减少、责任墙弱化、测试执行时间变多。

缺点： 测试环境准备复杂、沟通（打扰）频密、工作量计算倾向更精确。

这是团队走向高效协作的关键一步，责任墙在开始拆除的同时，自动化的诉求也在疯狂提高。但需求的开始以及发布准备的时间点还是存在的，这造成对团队的要求更高，如果团队还存在依赖方，这就对管理和纪律性有更高的要求。

因为测试等待时间的压缩以及团队纪律刚刚形成，所以需求分析与设计也会是关键痛点。BA、PO、SA等角色是吐槽的重灾区。

在这样的协作状态之下，每天跟进细节的进展就显得非常重要了。尤其到迭代的后期，可能因为开发进度滞后，测试同学主持站会来推动事情的进度。

这样的设置之下，一般是自动化刚刚起步阶段，团队纪律也在刚刚起步阶段，所以团队在这个阶段会比较痛苦。这种痛苦也可能来自依赖方的发布要求，越规模配合的团队越会有更多的协作会议。

这个阶段，一般是团队级别敏捷实施的关键阶段。开发给需求压力、交付给测试压力、所有人给“改变”压力。会议（协作）的频度及深度与之前的研发过程发生了质的变化。团队人员的纪律性（主动+被动），自动化设施，协作技巧都在强化之中（青黄不接）。如果再遇到交付有巨大压力的情况，迭代的长度就可能无奈的被延长。一般的经验是减少交付的压力，让团队可以在这个阶段逐渐适应新的节奏，让更多思考和优化的行动得以发生。

代码管理来说，版本分支（稳定主干）的协作模式已经捉襟见肘。支持特性分支或不稳定主干的声音会逐渐浮出水面。测试环境可控程度一般也会持续的强化。

新的领导力（主动的人）很可能会浮现出来，所以一定要抓住那些积极主动的人。记得多吃吃饭，喝喝酒是重要的。如果你都不知道“拉拢”谁的话，那就不要再向下一个阶段前进。找一个所谓的“敏捷”电子管理工具，更细致的管控团队吧。

3、滚动迭代

特征：每个迭代有潜在的发布窗口，每周滚动预测发布。越近的发布点越明确且不能改动。

优点： 迭代只是统计和计划之用，发布与迭代解耦。如果研发测试可以承受的话，发布点可以相对频密。

缺点： 更频密的发布对测试与研发基础要求更高，如果基础能力不到位的话，潜在发布点基本是虚设的。研发过程很可能回到融合迭代。

很多时候，我们期待更频密的发布，把发布的频率不够高认为是受到了迭代的限制。滚动迭代可以应对这样的偏见。这个时候，迭代概念已经可以完全弱化，你可以用“月”或“周”的概念进行替换。迭代更强化的统计和预测的能力（成为一个筐）。

每周设置潜在发布时间点（比如周五晚），这里的“潜在”意味着可能有，但如果研发、测试甚至是需求的状态都有可能影响这个所谓的“潜在”是否可以成真。

越近的发布点就会越固定，越近的发布点就会越固定。每周可以向前滚动计划一个月的发布内容。比如每周一的上午开一个未来一个月的发布时间点计划会议。

但需要注意的是，如果研发整体基础（工程纪律与自动化能力）无法支持频密的发布节奏的话。这种迭代就会退化成融合迭代。

4、流式迭代

优点： 下一工序等待进一步减少，随需发布，协作紧密。

缺点： 自动化能力要求高，团队纪律（素质）要求高。有些研发团队因为无法减少发布过程中的事务性工作而无法达到此阶段。

在这个阶段，迭代只是一个时间单位。部分的会议已经实现JIT（Just In Time）即时召开，少量仪式性的会议还会固定时间召开。在这个阶段的话，管理的方向自然走向更远的需求分析与更精细化的追求。团队这个时候拥有一种莫名的默契感和规则感，纪律性彰显无遗。

团队这个时候会非常依赖自动化工具，这些自动化的工具常常是团队自己开发的。如同给自己打工作台的木工一样。

主干开发 加 特性分支的管理方式在这阶段不可避免，版本分支的生命周期会相对较短。

可以给出定义，这个阶段就是我们追求的目标。没有达到的话，给团队一些时间和耐心。如果想加速这个过程，你需要下面……

两个强化剂

你可以使用强化剂来加速实现流式研发，当然强化剂可能不止两个。这里，首先介绍的是：

延展需求分析

在一个伸手不见五指的屋子里大步向前，如果大步向前的话，你一定会磕得满头是包。对于黑暗之中伸出去的手，就是不会撞墙的保证。对于研发过程来说需求的远光灯就是伸向黑暗中的手。Scrum框架之内Refine Meeting夹杂了需求的部分远光灯的作用，但Refine的目的其实是模糊的。

需求远光灯其实就是控制项目风险的目的，如果在远光灯之后。需求交付的风险没有进一步的控制，远光灯的作用就会失去。

对于需求来说，拆分成板砖需求就是控制交付风险的重要手段。

打开需求远光灯的流程见下图：

关键就在于：

• 估算（参见：《面对估算的态度和方法》）
  • 平准需求粒度
  • 校准大家理解
  • 进行风险控制
• 假设（参见：《面对估算的态度和方法》）
  • 假设可能会成为风险
  • 风险可能会成为阻碍
  • 阻碍可能会影响发布
• 拆分（参见：《如何拆分需求实现渐进式交付》）
  • 敏捷的需求就是粒度小且用户可感知的功能增强
  • 业务人员确认可验证性
  • 技术人员确认粒度合适

强化自动化能力

自动化的能力可以实现更为轻松的发布过程，这句话估计没人反对吧。但事实上其实有很多细节：

1、自动化的责任主体是开发而不是测试人员

质量有内部与外部之分，但如果我们太关注外部质量，内部就会有一种不管不顾野蛮生长的力量。但我们要注意，测试人员的重要职责是提高团队的质量意识而不是更快的写自动化测试。

之前有一个台湾的测试哥们，他对我说了一比喻：

而且在程序的世界，程序员更为得心应手。在我辅导的有些团队，测试人员拥有更大的权力来协调日常工作。比如例会发出“圣旨”报事贴，要求开发人员最高优先级跟进，转天汇报今天情况。团队需要有相似的感知与紧迫感。

2、技术债务需要可视化并与需求一起排入迭代

在我辅导过的大部分团队中，开发人员不会去写单元测试，借口是我需求都做不完，哪有时间写测试呢？但问他们有什么技术债务吗？他们说有一堆。再问他们是否有列表呢？他们一般会回答说没有。

自动化的事情推动进展差强人意很大部分原因就是因为对于技术债务的不重视。对于技术债务，可以接受推迟，甚至是永远推迟，但千万不要熟视无睹。

在计划会议上起码讨论一下，排入一些到下一迭代之中。

3、以风险为驱动的自动化强化之旅

团队可能看不到自动化的意义在于这东西可以运行无数遍，在持续集成跑也感觉不到这东西的存在。驱动团队需要意义与名正言顺的理由。

风险就是这样的理由，如同技术债务一般，需要可视化，并纳入迭代之中。

总之不停强化这两个强化剂就可以使得团队向着流式迭代前进。但协作容器与调整机会不是迭代的全部好处，它还可以实现……

交付进度的预测

对于迭代的目标调整来说，其实可以拥有无数个所谓的“里程碑”。比如对不停逃离导弹追逐的飞机来说，一个飞行中的导弹根本不知道要飞行多久。对于它来说，下一步向哪个方向飞更为重要。

对于一个极限未知的迭代实施过程来说，就如同不停行走的人一样。不需要知道我未来100步走在什么地方，只需要知道我下一步走在哪里就好。

当然这是一个极限的状态，也有很多类型的项目需要看到更远，避免潜在的风险。只看到下一步对项目或产品来说风险就太大了。这时候我们需要看得更远一些。

这样目光所及的地方就是未来潜在的迭代内容，下一步就是下一迭代内容，这一步就是当前迭代内容。是否团队睁开眼睛看得更远完全依赖产品或项目风险与特点。形成下一迭代，甚至未来交付节奏的灰度预期就是迭代另一个关键特点。对于形成这种节奏，并不是说想干什么就干什么，也不是说发现什么咱们闷头冲，也不是原来需要10分钟走到的目标我们5分钟就能走到了。

简单来说，迭代化运作相比较瀑布里程碑式的交付过程更为消耗能量。因为在执行的过程之中需要不停的思考与调整，所以迭代化运作的过程会比大炮式的交付过程耗费更多的人力物力。在复杂和变化的环境之下（注意这个假设），这样的付出是有价值的。

但恰恰迭代在执行过程中需要关注更多层次的内容（需求、调整、方向、思考），就使得对团队的纪律性有更高的要求。很多时候团队在实施迭代化运作的过程中感受是疲惫的，这种疲惫的状态就是团队没有形成节奏感的一个侧面证据（另一种可能性是团队之前太舒适了）。

交付节奏预测为目标的话，迭代的长度也就没有临时调整之说。这样我们就能使用迭代燃起图来从时间角度思考我们的交付风险：

上面一张图的大面积区域是目光所及的风险控制区域。哪怕是前期类似瀑布的交付过程，我们也可以清晰显性地把风险明确的列出，期待反馈与调整。迭代的过程让项目或产品在承认现状之下拥有更多的选择，并使团队集体承担更多的责任。

注意，不要追求精确的迭代预测。一旦你追求的话，预测就不准了。（测不准）预测的过程可以使用需求数量，也可以点数。如果你不想强调迭代概念的话，你可以使用月、季、年为单位。

最后

迭代对于敏捷软件研发来说不是必须的，但我在支持团队的时候一般都把这东西列为必选之一。不是因为只有迭代可以：

• 有机会打破无限时间错觉
• 容纳协作节奏
• 预测交付进度

没这概念你也可以的，但这个概念强化了这三个东西，并且它没有限制团队无尽的可能性。另外本文使用“发布”一词，“发布” = 能够被真实用户感知到。另外如果你纠结“发布”还是“版本”，或有不同观点，不管如何你说的结论就是对的。

回顾Scrum及极限编程的迭代概念

Scrum的Sprint

这种迭代有理想主义的坚持：

• 协作容器：一定要这几个会议的坚持。（这个有些僵化了，有些团队为了开会而会，反而限制了团队）
• 交付进度预测：你看着办，但你不要太在意。
• 调整机会：一定要对目标调整的坚持。（这个还是不错的）

极限编程的Iteration

这种迭代有现实主义的坚持：

• 协作容器：你们自己知道交付进度，自己不能再计划一下？
• 交付进度预测：短就没问题。
• 调整机会：反正客户要啥我们就做啥。不停思考发布内容（这点和本文思路一致）。

极限编程让我思考以下几个问题：

• 我们的客户是谁？谁会用我们的东西？真实的需求是啥？
• 难道不应该弱化迭代而更多的思考发布嘛？
• 敢不敢挑战一周一迭代？

小小总结

国内很多人使用迭代的概念来自Scrum，但我更喜欢使用Iteration这个词，这个词让我更无依无靠，让我更愿意思考，让我更想尝试一周一次的迭代。

相关参考

• [^ScrumGuide]: 《Scrum 指南》
• [^XP]: 《极限编程》 （需要科学）