反对迭代0：停止拖延，开始迭代

很多项目都不会一开始就完全就绪——例如，需要分配人员和准备工作。为了处理这些项目开始前的任务，很多团队使用了“迭代0”的做法。虽然理解其由来，但我仍然感到担心。以下是我的理由。

停止“迭代0”的三个理由：

首先，尽管很难相信，但绝大多数的项目都是可以立刻启动的。我所听过的所有声称需要在Scrum项目启动前完成的事项有：需要组建团队，包括调配人员到项目上或雇佣新人；需要获取或者设置硬件设备；需要写一个初始的产品待办列表（即使只是高度概要的）。然而现实情况是：诸如技术环境、初始产品待办列表之类的事项都可以在第一个迭代中完成（一个完全是正常的和传统模式的迭代一），同时至少还可以交付了某些潜在可发布产品增量。

其次，有了“迭代0”就制造了一个特例，即某些迭代或者迭代类型可以有特别的规则。例如，团队实施迭代0，就违背了在迭代结束时要提供潜在可发布产品增量的理念。毕竟如果迭代的目的是组建产品开发团队，又怎么可能提供潜在可发布产品增量呢。提供潜在可发布产品增量的要求，有助于帮助Scrum团队避免出现分析瘫痪和感受迭代中开发工作的紧迫性。只有具备适度的紧迫感才能使团队产生更大的创造力。这条规则也有助于帮助团队保持诚实，它能避免团队在没有真正完成任何待办项的情况下声称有进展。

第三，对于少数项目，确实需要进行前期工作（我称之为项目前项目）。这些前期工作可能需要花费一个甚至更多的迭代来完成。毕竟，大项目是真的需要开展前期工作的。这种情况下，我们可能真的需要一个迭代0、迭代0.5、迭代0.75，直到前期工作结束。

但如果我们是例外的少数，该怎么做？

因此，大多数项目不需要前期工作，因为其准备工作可以和开发工作一起进行。但如果说，你们的项目恰恰是少数需要项目前项目的项目，该如何确保分析工作不会停滞不前以及不会比那些第一时间就开始的项目成本更高呢？

提示1：保持“项目前项目”轻量化，甚至可以使用Scrum来管理项目前项目，在团队中使用受时间盒限制的迭代来工作。在每个迭代结束时，都要问一个问题“我们现在可以开始迭代一了吗”，即使项目前项目的规模很小，我们也要决策剩下的时间如何进行。通常，如果你创造性地思考问题，都能够找到解决方法。

提示2：细分工作。就算只是对潜在系统的分析工作，也可以分解成更小的、可完成的任务。例如，假设你们正在决策是否开发一个新的医院系统，或该开发哪种医院系统。不要仅仅把任务描述成“访谈所有相关干系人”，团队可以先访谈所有药剂师的基本需求，任务完成后就可以访谈所有医生。或者可以把工作细分成不同的细分领域：向所有相关干系人访谈其对系统处方部分的需求。这种情况下，团队在迭代中的访谈对象可以不仅限于药剂师，也可以访谈医生、护士等，但与这些相关干系人讨论的内容仅限于系统处方部分。团队可以将来回来再继续向相关干系人访谈其他功能。然而现在，团队可以说已经完成了关于处方部分的相关干系人需求分析。

再说一遍：绝大多数开发项目在开始之前并不需要项目前项目，任何时候分析工作都可以在实际的迭代中完成。当你们确实需要进行前期工作时，把它细分成可完成的小块，紧急快速地完成。

 

本文译者：李洁（Jerry Li） ，CSM，CSP，Scrum中文网资深敏捷顾问和培训师，敏捷教练

原文作者：Mike Cohn

文章转自：scrum中文网

文章链接：http://www.scrumcn.com/agile/scrum/18813.html