我们需要第 0 个迭代吗？

在一个项目启动之前，通常需要完成一些准备工作。为了能够保证后面一系列的迭代顺利进行，团队往往会安排“第 0 个迭代”（Iteration Zero），把所有需要的系统都准备好。这是一个好的方法吗？

George Dinwiddie 认为，即使团队努力尝试去完成所有前期工作，他们也会很快意识到在接下来的几个sprint 中还是有许多等待着他们。如果他们尝试去做很多前期工作，那么基础框架（infrastructure）决策、技术选择以及第0 个迭代的功能列表可能会主导项目的进行，而不是别的因素。

George 觉得每个迭代都应该开发出可以工作的软件。

大家问问自己：“开始交付之前，什么是必须做的？”…我们要专注于这项工作，把它分解为更小的任务，同时找出这些任务的实际业务案例，用来作为验收标准。有些子任务并不是很清晰，存有疑问，可以暂时放在一边。相反，选择那些贯穿整个概念模型的核心子任务，或者尽可能关键的子任务。 然后进行估算，作为团队的一个迭代。（估算不必非常精确，毕竟只是估算而已。）接下来就可以着手干活了。

George 认为这是开始项目的最好的方法。团队应该学会必要的技术，在整个开发过程中，慢慢地构建开发所基础框架。

是的，在后续过程中还是需要去构建基础框架。我们不必急着把它一次性搞定。我们只需要不断地改进它，这样它才能帮助你完成更多的工作。是的，团队还是有些技术需要学习。学无止境，我们需要不断去实践，超越极限。是的，我们还是会有新的功能加入到待办事项列表中，也会去精炼待办事项列表，再一次重新排定优先级，或者分解用户故事。这些本就应该贯穿于整个项目过程中。

类似的，Artem也不太喜欢去安排一个什么也证明不了的迭代。Artem 觉得，即使所谓的第0 个迭代的主要工作还是前期准备，他还是愿意去试着走一下系统核心流程。

Alistair Cockburn 则提到：

我私下感觉，有些人介绍他的 Scrum 实践：他在开始阶段做了一些无明显商业价值的工作，他就当做是自己的新发明：“这就是 Sprint 0！”…而其他人听了之后觉得这是一个很好的主意，也这么命名它了…于是这也就成为了文化的一部分。

有人问，第0 个迭代和前期规划是不是相同? George 提到，他无法想象一个没有前期规划的第0 个迭代。这一切其实是项目章程的一部分。然而，绝大多数团队在第0 个迭代中却不讨论愿景和目标。相反，他们花很多时间编制一份详细的待办事项列表以及构建开发基础框架。

Ken Schwaber 也有相似的看法，他提到：

Sprint 0 已经被滥用了，它成为了第一个 sprint 开始之前的计划的描述…既然计划经常会变，在第一个 sprint 之前就应该尽量少做不必要的计划，而是在每个 sprint 评审会议或者计划会议的时候，再去制订相应的计划（实时计划）。

这样看来，这似乎是个共识：如果可能的话，最好还是避免安排第 0 个迭代。背后的关键就在于我们要从一开始就创造商业价值。各位读者，和从一开始就交付商业价值，随后在整个项目过程中逐步构建基础框架，决定技术细节比起来，你的团队是不是觉得安排第 0 个迭代会有更大的好处呢？

查看英文原文： Do We Need an Iteration Zero?