3.2  敏捷规划方法

对一个新项目的开发进行估计和规划是一件令人畏缩的工作，而我们对项目的误解更增加了它的难度。Macomber(2004)指出，我们不应把一个项目单纯看作是执行一系列的步骤。事实上，我们把项目看作是迅速、可靠地产生一个可用的新功能和新知识的流程是很重要的。新功能在产品中交付，新知识则被用于让这个产品达到它所能到达的最好状态。

在敏捷开发项目中，我们使用这个新功能和新知识的流程来指导正在进行的工作。项目产生的新知识可能是关于产品的，也可能是关于项目本身的。新的产品知识(product knowledge)帮助我们更好地认识这个产品应该是什么。新的项目知识(project knowledge)则是有关开发小组、使用的技术、风险，等等的知识。

我们常常无法承认这个新知识并为之做好计划准备。没有准备获取新知识，导致最终的计划是建立一个假设上，这一假设就是我们已经知道建立准确计划所需要的一切。在软件开发领域中，即使实际情况不是从不会是这样，也是很少是这样。Ward Cunningham说过：“更多的是对您要了解什么，而不是对它(产品)会是什么来作规划”(Van Schooenderwoert 2004)。

我常把对项目的传统看法比作跑10公里长跑。您知道终点线到底有多远，而您的目标就是尽快达到终点。而在敏捷开发项目中，我们并不知道终点线在哪里，但常常知道在某个特定的日期我们应该达到或者尽可能接近这个终点。敏捷开发项目更像是计时赛而不是10公里比赛：在60分钟里跑得越远越好。这样，敏捷项目小组知道他们何时应该结束，但不知道他们要交付什么。当我们承认在某种程度上不知道结果，也不可能提前知道结果的时候，规划就成为了一个设定和修正目标的过程，而这些目标则被用于实现一个更长远的目的。

3.2.1  规划的不同层次

设定和修正目标的时候，重要的是记住我们无法看到地平线以外的东西，我们试图规划的内容超出视线范围越远，计划的准确性降低得越迅速。假设您站在一条小船上，眼睛离水面有9英尺。这时候地平线的距离大约是刚刚超过4英里。如果您在为一次20英里距离的旅行作计划，就应该准备至少要往前看5次，每4英里一次。因为您无法看到地平线以外的东西，您需要不时地看一下然后调整计划。

如果对一个项目的规划远远超出了规划人员可见的地平线范围，而且没有包含给规划者抬头看看新的地平线并做出调整的时间，那么它是很危险的。逐步地确立计划是必要的。敏捷开发小组通过对3个不同的地平线做规划来达到这一目的。这3个地平线分别是发布、迭代和当前日。图3-1中的规划洋葱显示了这3个(和其他)规划地平线的关系。

图3-1  规划洋葱。敏捷开发小组至少在发布、迭代和每日3个层次上进行规划

大多数敏捷开发小组只关心规划洋葱的最里面3个层次。发布规划要考虑在产品或系统的新发布中需要开发的用户故事或是主题。发布规划的目标是为有关项目范围、进度和资源的问题确定适当的答案。发布规划在项目启动的时候进行，但并不是孤立的工作。一个好发布计划会在项目过程中被更新(通常是在每次迭代开始的时候)，以便它总是反映对发布中应该包含什么内容的当前期待。

下一个层次是迭代规划，它在每次迭代开始的时候进行。产品所有者会根据在刚结束的迭代中完成的工作，确定开发小组在新的迭代中应该处理的高优先级工作。由于我们现在正在看的是比进行发布规划时更近的地平线，迭代计划的组成部分可以更小。在迭代规划中，我们谈论的是把功能需求转变成经测试的可用软件所需要完成的任务。

最后是每日规划。大多数敏捷开发小组采用某种形式的每日例会来对每天的工作进行协调和同步。虽然看起来按正规的方式考虑这种规划似乎有些过分，但开发小组无疑要在这些例会上制定、评估和修正他们的计划。在这些每日例会上，开发小组把他们的规划地平线限制在不超过接下来的一天。正因如此，他们关注于对任务的规划，以及协调个人的活动来完成任务。

通过这3个层次(发布、迭代和每日)的规划，敏捷开发小组关注于对他们正制定的计划可见而且重要的内容。

在大多数单独的敏捷开发小组(以及本书)考虑范围之外，是产品规划、资产规划和战略规划。产品规划要求产品所有者超越本次发布以外，为已发布的产品和系统的发展作出规划。资产规划则是选择最合适的产品，来最好地实现公司的战略规划所确立的远景。

3.2.2  满意条件

每个项目最初都有一组目标。您当前的项目也许是创建世界上最好的文字处理软件。但是，建立世界上最好的文字处理软件通常只是这个项目的目标之一。毫无疑问还会有其他如进度、预算和质量等方面的目标。这些目标可以被看作客户或者产品所有者的满意条件(condition of satisfaction)—— 也就是用来衡量项目是否成功的标准。

读高中的时候，每当老师布置我写关于诸如Moby Dick之类的书的读后感，我都会问她需要写多少字。她的回答是类似于“5页纸”，我就知道了她的主要满意条件。当然，还有一些附加的、未写出来的满意条件，例如文章要好好写、是自己的内容、用英语写，等等。

在发布规划开始的时候，开发小组和产品所有者会共同研究产品所有者的满意条件。这包括了常见的事项，如范围、进度、预算和质量，不过敏捷开发小组通常希望把质量看作不可协商的。开发小组和产品所有者寻找可以满足所有满意条件的不同方法。例如，对产品所有者来说，花5个月时间得到具有一组用户故事的发布，与多等1个月获得具有更多用户故事的发布，满意程度可能是一样的。

但是，有些时候无法满足产品所有者的全部满意条件。比如说开发小组可以构建世界上最好的文字处理软件，但他们不能下个月就完成它。无法找到可行解决方法的时候，就必须对满意条件作修改。因此，发布规划和对产品所有者满意条件的探索具有很高的迭代性，如图3-2所示。

图3-2  满意条件驱动发布规划和迭代规划

一旦建立了大致覆盖接下来的3～6个月的发布计划，就可以把它作为进行第一次迭代规划的输入。迭代规划和发布规划一样，都是从考虑产品所有者的满意条件开始。对一次迭代来说，产品所有者的满意条件通常就是他希望接下来开发的功能，以及每个功能所需的一些高层测试。

作为一个例子，我们考虑一个旅行服务网站，它包含这样的用户故事：“作为用户，我希望能够取消预定。”在与产品所有者讨论这个用户故事的时候，开发人员了解到对这个用户故事的满意条件包括：

●       提前24小时以上取消预定的用户可以获得全额退款。

●       提前24小时以内取消预定的用户可以在扣除25币的手续费后获得剩余退款。

●       网站会显示一个取消代码并通过电子邮件发送给该用户。

和发布规划一样，迭代规划本身也是迭代式的。产品所有者和开发小组会讨论可以最好地满足这次迭代满意条件的不同方法。

图3-2中显示了从产生的新产品增量回到发布规划和迭代规划开始时的满意条件框的反馈。根据开发小组在这次迭代中开发产品增量时的经历，他们可能会获得在一个或更多层次上影响到规划的知识或经验。与之类似，向现有用户或可能用户展示产品也可能产生导致计划改变的新知识。敏捷开发小组会把这些变化结合到他们的计划中，直到获得具有更高价值的产品。