第3章 计划
“当你可以度量你所说的并能用数字去表达，就表明你了解它了；但是，如果你无法去度量，不能用数字去表达，则说明你的知识是匮乏的，还不能令人信服。”
—开尔文勋爵(1)，1883
下面的内容是对极限编程（XP）[Beck99]和[Newkirk2001]中规划游戏的描述。它做计划的方式和其他敏捷方法（www.AgileAlliance.org.）类似，如Scrum（www. controlchaos.com.）、Crystal（crystalmethodologes.org）、特性驱动开发（Feature-Driven Development，FDD）以及自适应软件开发（Adaptive Software Development，ADP）[Highsmith2000]。不过，那些过程方法都没有极限编程描述得详细和精确。
初探
项目开始时，开发人员和客户会尽量识别出所有真正重要的用户故事。不过，他们不会去确定所有的用户故事。随着项目的进行，客户会不断地编写新的用户故事。这个过程会一直持续，直到项目结束。
开发人员共同对这些用户故事进行估算。估算是相对的。他们在故事卡上写下“点数”来代表实现这个故事所花的相对时间。这样可能无法确定每个故事点代表的确切时间，但是可以确定实现8个点的用户故事所花费的时间是4个点的两倍。
探究、分解和速度
过大或者过小的用户故事都不太好估算。开发人员往往会低估那些大的故事而高估那些小的故事。太大的用户故事应该拆成更小的故事，太小的用户故事也应该和其他小的故事合并起来。
例如这个故事：“用户能够安全地进行存款、取款、转账活动。”这是个很大的用户故事，很难估算，还可能不准确。不过，我们可以把它分解成以下几个更容易估算的故事。
● 用户可以登录
● 用户可以退出
● 用户可以向其账户存款
● 用户可以从其账户取款
● 用户可以从其账户向其他账户转账
当一个用户故事被分解或者合并时，应该重新进行估算。不是说简单地对估算做加减法，分解和合并用户故事的主要原因是让估算变得准确。如果发现估算的用户故事是5个点，分解之后变成10个点也没有什么大惊小怪的，10个点的估算更加准确。
相对估算并不能告诉我们用户故事的确切大小，所以它没法帮我们决定何时分解或者合并。为了了解故事的实际大小，我们需要一个叫速率（velocity）的因子。如果我们知道了确切的速率，就可以把它乘以任何故事的估算，从而得到每个故事的真实时间的估算。举个例子，如果我们的速率是“每个点2天”并且有个估算为4个点的故事，那么这个故事应该就需要8天去实现。
随着项目持续进行，速率的测量会变得更加精确，因为我们可以衡量每个迭代里完成的用户故事点的数量。不过，开发人员在一开始不太可能了解他们的速率。他们必须给出初始猜测，这个猜测是他们认为最好的结果。这个时机上的精确性要求不是特别重要，所以他们不必花费过多的时间在这上面。通常花费几天时间做一两个用户故事的原型就足够了解团队的速率了，这种原型会议被称为探究（spike）。
发布计划
知道了速率，客户就了解了每个用户故事的开销，他们也会了解每个用户故事的业务价值和优先级。这些可以让他们挑选出优先开发的用户故事。他们的选择并不是只依据优先级，有些故事很重要但开销也大，它们就会被推迟，其他不太重要但是开销更小的用户故事就会被选中。诸如此类的选择就是业务决策，业务人员会决定哪些用户故事能带来最大的价值。
开发人员和客户商量好项目第一次发布的日期，这对于未来2～4个月的开发非常重要。客户挑选出此次发布中需要完成的用户故事，以及它们之间粗略的顺序。客户选出的用户故事不能超过当前速率的限制。由于初始速率是不准确的，所以这种选择也是粗略的。不过，当下准确性并不重要。当速率更加准确后，发布计划可以调整。
迭代计划
接下来，开发人员和客户一起选择迭代的大小。一个迭代通常是2周时间。同样地，客户挑选出他们想在第一个迭代中完成的用户故事，挑出来的故事也不能超过当前速率的限制。
迭代中的用户故事完成顺序是一个技术决策。开发人员以最具技术意义的顺序开发用户故事。他们是串行地开发，完成一个接着开发另一个，还是均分后并行开发，都完全取决于他们自己。
一旦迭代开始后，客户就不能改变迭代中的用户故事了。他们可以自由地改变或者重新排序项目中的其他用户故事，但是不包含开发人员正在开发的故事。
迭代会在指定的时期结束，即便所有的用户故事都没有完成。完成的故事的估算会被统计出来，这个迭代的速率也会被计算出来。这个测量出的速率之后会被用来计划下轮迭代。规则非常简单，下轮迭代的计划速率由上轮测量出来迭代的速率决定。如果团队上轮迭代完成了31个用户故事点，那么下轮迭代就应该完成31个用户故事点。团队的整体速率就是每轮迭代31个用户故事点。
速率的反馈能帮助计划和团队同步。如果团队获得经验和技巧，速率也会适当提升。如果有人离开了团队，速率也会下降。如果架构演进可以引导开发，速率也会上升。(2)
任务计划
迭代伊始，开发人员和客户会一起做计划。开发人员把用户故事拆解成可以开发的任务。每个任务需要一个开发人员花费4～16小时的时间。开发人员在客户的帮助下对这些用户故事进行分析，并尽可能完全地列举出所有的任务。
可以在活动挂图、白板和其他方便的媒介上列出这些任务。接着，开发人员逐个认领他们感兴趣的任务。一旦认领了任务，他们就会随意估算出一个任务点数。（多数开发人员发现使用“理想编程时间”作为任务点数是好用的。）
开发人员可以认领任何类型的任务。精通数据库的人员不一定非得认领数据库相关的任务。如果有意愿，精通GUI的人员也可以认领数据库相关的任务。这种做法看上去并不高效，但后面你会看到针对这种情况有一种管理机制。这里的好处显而易见，开发人员对整个项目了解得越多，团队就会越健康、越有见识。我们期望项目的知识能够传播给每一位团队成员，即便这些知识和他们的专业无关。
每位开发人员都知道自己在上轮迭代中所完成的任务点数，这个数字可以作为下轮迭代中他个人的预算。没有人会认领超出他预算的点数。
任务的选择一直持续到所有的任务都被分配完，或者所有的开发人员都已经用完了他们的预算为止。如果还有任务没有分配出去，那么开发人员会相互协商，基于各自的专长交换任务。如果这样做都不能分配完所有任务，那么开发人员就要求客户从本轮迭代中移除一些任务或者用户故事。如果所有的任务都已经被分配完，并且开发人员还有余力，那么他们就会向客户要求添加更多的用户故事。
迭代中点
在迭代进行到一半的时候，团队会召开一次会议。此时，本次迭代中的半数用户故事应该已经完成。如果没有完成，那么团队会设法重新分配任务和职责，保证迭代结束时能够完成所有的用户故事。如果开发人员无法重新分配，则需要知会客户。客户可以决定从迭代中去掉一个任务或用户故事。最不济，客户可以指出那些最低优先级的任务和用户故事，以免开发人员在上面浪费时间。
举个例子，假设本次迭代中客户选择了8个用户故事，总共24个故事点，同样假设这些素材被分解成42个任务。在迭代中点，我们希望应该完成了21个任务和12个故事点。这12个故事点必须是指全部完成的用户故事。我们的目标是完成用户故事，而不仅仅是任务。如果在迭代结束的时候，90%的任务已经完成，但没有一个用户故事全部完成，这将是一场恶梦。在迭代中点，我们希望看到有一半故事点的完整的用户故事被完成了。
迭代
两周一迭代，每轮迭代结束时，团队会给客户演示当前可运行的的程序，让客户对程序的外观、感觉和性能进行评价。他们会把反馈写到新的用户故事中。
客户可以经常看到项目的进度，他们可以度量开发速率。他们可以预测团队工作的快慢，并且可以早早地安排高优先级的用户故事。简而言之，他们拥有所有的数据和控制权，可以按照他们的意愿管理项目。
小结
经过一轮轮的迭代和发布，项目进入了一种可以预测和舒服的开发节奏。每个人都知道将要做什么，以及何时去做。利益相关者可以经常、实实在在地看到项目的进展。他们看到不是画满图表和写满计划的记事本，而是可以接触、感受的可工作的软件，而且他们还可以对软件提供反馈。
开发人员看到的是合理的计划，这个计划基于他们自己的估算并且由他们自己度量出的速率控制。他们选择自己感觉舒适的任务，并保持高的工作质量。
管理人员从每次迭代中获取数据，他们用这些数据控制和管理项目。他们不必采用强制、威胁或者恳求的方式去达到一个武断的、不切实际的目标。
这听上去很美好，其实并非如此。利益相关者对过程中的数据并不总是满意的，特别是刚刚开始时，使用敏捷开发并不意味着利益相关者就能得到他们想要的东西。它只不过意味着他们可以控制团队以最小的代价获得最大的商业价值。
参考文献
1. Beck, Kent, Extreme Programming Explained: Embrace Change. Reading, MA: Addison-Wesley, 1999.
2. Newkirk, James, and Robert C. Martin. Extreme Programming in Practice. Upper Saddle River, NJ: Addisono-Wesley, 2001.
3. Highsmith, James A. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. New York: Dorset House, 2000.
(1)中文版编注：开尔文勋爵（Lord Kelvin，1824—1907），出生于北爱尔兰的英国数学物理学家和工程师，也是热力学温标（绝对温标）的发明人，被称为“热力学之父”。他在格拉斯哥大学时与休·布来克本进行密切合作，研究电学的数学分析、并将第一和第二热力学定律公式化，把各门新兴物理学科统一成现代形式。他因认识到温度的下限（即绝对零度）而广为人知。
(2)译注：事实上，我们还需要考虑可用人天的影响。需要将上轮迭代完成的故事点除以可用人天数，得到投入程度。然后再将投入程度乘以当前迭代的可用人天数得出估算的可完成点数。详情见《走出硝烟的精益敏捷》一书的第一部分。