争论：迭代和 Sprint 之于敏捷团队是浪费吗？

虽然很多人将“迭代”视作敏捷软件开发的关键特性，但仍有人质疑它的重要性何在、能否为敏捷方法增加价值、是不是多此一举，甚至根本就是浪费。InfoQ 收集了一些关于此主题的争论，以帮助敏捷团队判断“迭代”对他们是否重要。

在“lean-agile-scrum”邮件列表中， jdmcauliffe2002 问道：

我们知道：“精益”让我们要以不同的方式来做事，以更好地利用“流”。假定我们已经有了一个估算好工作量的待完成工作项目列表，如果我们不必为了安排迭代工作而对列表进行预估，而是直接选择优先级最高的用户故事进行处理（规划、详细估算、设计、编码、测试、验收）。当我们完成（验收通过）这个用户故事之后，接下来选择列表中下一个优先级最高的项目。这是不是更加有效和“精益”的工作方式呢？

Liz Sedley这样回复：

许多从业人员和团队正在抛弃 Sprint，其中包括 Yahoo 和 David Anderson（见译注 1）。

我想这样肯定能消除浪费。不过我想应该保证保留下面这些做法：

• 庆祝成功。
• 检视、调整与适应。
• 按照管理层的要求完成规划工作。
• 保持可持续的进展速度。

Max Guersey III认为去除迭代与否要看团队的规范遵循状况：

Sprint 同样可以成为被办公室政治利用的、强有力的工具。与可被测算的工作量相比，它是更容易理解的时间单位。可以看到 Sprint 中开发速率的高低变化。现在……也可以对日常的周、月、年或日展开类似的工作。Sprint 还有另一个重要的政治影响：通过它可以明确辨析一个团队的成败。 一旦抵抗被击溃——一旦组织的机构转换完成——就可以用更加灵活的过程来替代严苛的 Scrum 流程了。在此之前，仍然需要像 sprint 这样的做法来规范不守规矩的行为和人，消除仍有疑虑之人心中的畏惧，保护不愿卷入权力斗争阴谋的人远离浑水。

其他人提出一些不同意见。Aaron Sanders 在《透明规划详解——小团队中的看板》（Naked Planning Explained - Kanban in the Small）一文中说道：

使用长度不固定的 Product Backlog 来重新组织优先级和估算任务量，这样的想法已被抛弃，取而代之的是使用绘制了固定长度队列的白板，供 Product Owner（客户）填入“最小市场需求功能（Minimal Marketable Feature，MMF）”，或是 Scrum 中的用户故事。队列的长度是 7，Arlo 认为这是一个人一次最多能够记住的事务的数目。用来填入任务的空位是用不可擦除的马克笔进行标记的。因为 Product Owner 相信团队确实能够完成工作，团队也相信这些功能确实是产品上市必不可少的“最小”功能，可以马上为新用户以及原有用户带来价值。 客户可以随时根据需要调整这 7 个 MMF 功能。当开发团队准备选择一个新功能进行开发时，它肯定是位于第一位的。7 个 MMF 功能必须要能够达成白板上两个目标中的一个。在准备填入新功能时，客户要决定：如果完成队列中剩余的 MMF，是否可以达成现有目标；如果可以，那就能够向白板上添加一个新的目标；否则就应加入另外的 MMF 以满足现有目标。有一个“绿色畅通空位（expedite slot）”可供客户改写目前的 WIP（见译注 2）, 其他任何功能都应等待空出来的空位。

任何一个 MMF 完成后，都可以进行一次版本发布，因为在生产系统中可以隐藏 WIP 功能。客户也可以有一个“想法停车场（idea parking lot）”，用来保存 7 个 MMF 之外的其他功能想法，这些想法不一定必须与当前目标相关。在白板的下方，会标明发布某个功能需要的大约等待时间。MMF 们在被填入白板上后就已经安排好了，当它们开发完成后，就可以计算出一个功能的平均耗费时间。如果某项工作的耗费时间发生显著变化，并且对团队的整个工作进度和状况产生影响，这就会触发对于功能完成提前周期的重新计算。Arlo 将其称作“迪士尼乐园近似等待时间（approximate Disneyland wait time）”, 并会用类似下面的句子说明：“从这一点开始，您今天的期望等待天数介于 x 天和 y 天之间。”

Amit Rathore 在他的博客上建议：

不要迭代，同时抛弃相关的人工产物。

• 确保业务分析师与 product owner 和相关干系人一起工作，以维护一个最新的用户故事优先级列表。
• 通过让业务分析、任务分配和开发以“准时制生产（just-in-time）”（见译注 3）的方式进行，保证开发团队以最大效率运转。
• 只要有需要，产品展示、过程回顾和停工休息这些活动可以随时进行！

Mary Poppendieck（见译注 4）关于“管道管理”的文章描述了节奏的重要性，并说明如果没有迭代就很难有好的节奏产生：

在精益工厂中，每个过程都以有规律的节奏执行，这个节奏称为“节拍时间（tact time）”。如果要在 8 小时内生产 80 辆汽车，那么每小时应生产 10 辆汽车，生产线每隔 6 分钟就应该产出一辆汽车。在软件开发过程中，推荐的实践是要以两周或一个月的周期来建立迭代的节奏，并且每个迭代都提交一小块可以马上发布的软件。 有规律的节奏，或“心跳”，可以让团队建立起以可信任的开发速率交付可靠软件的能力。能够以有规律的节奏交付软件的组织，就具备了流程控制能力，并且能够方便地测算其工作能力大小。

有规律的节奏，能够让互相依赖的团队找到可靠的同步点。用同步点来得到客户反馈是很好的，可以协调开发不同功能团队之间的工作，并帮助完成软件开与硬件开发之间的解耦。

我们可以用另外一种方式来考虑无迭代流程，那就是每个功能可以有其特定的功能迭代周期，并且互不干涉，也许可以用到功能分支：

功能分支，就是本章中介绍的主要例子，当 Sally 在“/trunk”上继续其工作时，你正在处理的分支就是功能分支。这个临时分支的创建，是希望在处理某个复杂的变更时，不会影响“/trunk”的稳定性。与版本分支不同（也许它要被永远支持），功能分支仅存在一段时间，并且会被合并回主干中去，最终会被删除。它们的可用范围是有限的。

有人可能会觉得这种做法没有真正去除迭代，而是将其简单地重新划分为“功能范围”和“并行”两种，这也许在复杂项目中用到的并行迭代方式没多大区别。

很多敏捷人士和自称为“后敏捷人士（post-Agile）”的人们会建议每个团队自己判断哪些流程对自己重要且有用，哪些流程不是。无论如何，上述争论应该有助于你考虑迭代对你和你的团队是否有用。这就是：它们能够添加什么样的价值，还是应该被当作浪费抛弃掉？

译注1： David Anderson ，现任 Corbis 公司软件工程资深总监。在 2006 年 9 月加入 Corbis 之前，于微软担任 MSF 方法论架构师。"Agile Management for Software Engineering"一书作者。

译注 2：Work In Process，在制品，企业供应链管理用语。此次应指在白板空位中的待完成功能。

译注 3：准时制生产，略作 JIT, 指建立在力求消除一切浪费和不断提高生产率基础上的一种生产理念. 它覆盖了从产品设计直到产成品发送一整套的生产活动. 只要这些活动是出产一件最终产品所需要的, 包括从原材料开始的各个在制品生产阶段, 都必须向消除一切浪费、不断提高生产率的目标看齐。

译注 4：Mary Poppendieck，《精益软件开发》作者，详见 http://www.poppendieck.com/people.htm 中对她的介绍。

查看英文原文： Are Iterations/Sprints Waste or Value to Agile Teams?