第3章 计划
3.1 初始探索
在项目开始时，开发人员会和客户商讨一下关于新系统的情况，以确定出所有真正重要的信息。然而，他们不会试图去确定所有的特性。随着项目的进展，客户会不断的发现新的特性。特性发现的过程会一直持续到项目完成。
当识别出一个特性时，会把它分解成一个或者多个用户故事，并把这些用户故事写在索引卡片之类的东西上面。除了用户故事的 名字之外，无需记录其他任何内容（比如Login，Add User，Delete User 或者Change Password）。此时，我们不会试图记录细节。我们只是希望有些东西能够提醒我们想起曾经谈论过这些特性。
开发人员共同对这些故事进行估算。估算是相对的，不是绝对的。我们在记录故事卡片上写上一些“点数”来表示这个故事所需要的相对时间。我们也许不能确定一个“点”代表多少时间，但是我们知道，实现8个点故事所需要的时间是实现4个点的两倍。
探索、分解和速度
过大或者过小的故事都是难以估算的。开发人员往往会低估那些大的故事而高估那些小的故事。任何过大的故事都应该分解成小一点的部分，任何过小的故事都应该和其他小的故事合并。
例如，考虑下面的用户故事：“用户能够安全的地进行存款、取款、转账活动。”这是个大的故事。对它进行估算将会很困难，有肯能还不准确。然而，我们可以把它分解成以下几个更容易估算的故事：
- 用户可以登录
- 用户可以退出
- 用户可以向其账户存款
- 用户可以从其账户取款
- 用户可从其账户向其他账户转账
在分割或合并一个故事时，应该对其重新进行估算。简单的加上或者减去估算值是不明确的。对用户进行分解或者合并完全是为了使其大小适于被准确的估算。当一个估算为25点的故事分解为几个点数总和达到30点的故事时，不要觉得奇怪！30点是更精确的估算。
每周，我们都会实现一定数量的故事。这些已经实现了的故事的估算之和是一种度量，称为速度。如果我们在上周实现的故事的点数之和为42，那么我们的速度就是42.
3或4周后，我们就会比较了解我们的平均速度。我们可以使用这个平均速度来预测在后面几周内能够完成多少工作。在XP项目中，跟踪速度是最重要的管理手段之一。
在项目开始时，开发人员对他们的速度没有很好的认识。他们必须给出一个初始的猜测值，在猜测时，可以采用他们感觉会带来最好结果的任何方式进行。此时并不需要非常准确，所以他们无需在上面花费过多的时间。事实上，做到和保守的凭直觉测试（SWAG）一样好就足够了。
3.2 发布计划
如果知道了开发速度，客户就能够了解每个故事的成本及其商业价值和优先级别。据此，客户就可以选择那些想最先完成的故事。这种选择不是单纯依据优先级别进行的。一些重要的但是实现起来代价高昂的故事可能会被推迟实现，而会先去实现，而会先去实现一些不那么重要但是代价要低廉得多的故事。此类选择属于商务决策范围。由业务人员来决定哪些故事会给他们带来最大利益。
开发人员和客户对项目的首次发布时间达成一致，通常也就是2~4个月后的事情。客户挑选在该发布中他们想要实现的故事，并大致确定这些故事实现顺序。客户必须根据当前的开发速度来选择要实现的故事的数量。由于开发速度开始时并不准确，所以选择也是粗略的。但是测试选择的准确性不是非常重要。当开发速度变得准确时，可以在对发布计划进行调整。
3.3 迭代计划
接着，开发人员和客户决定迭代规模，一般是1到2周。同样的，客户选择他们想要的首次迭代中的故事，但是不能选择与当前开发速度不符的更多的故事。
迭代期间用户故事的实现顺序属于技术决策范畴。开发人员采用最具技术意义的顺序来实现这些故事。他们可以串行的实现，完成一个在完成下一个；或者他们可以分摊这些故事，然后一起并行地开发。这完全有开发人员来决定。
一旦迭代开始，客户就不能再改变该迭代期内需要实现的故事。除了开发人员正在实现的故事，客户可以任意改变或重新安排项目中的其他任何故事。
即使没有实现所有用户故事，迭代也要在先前指定日期结束。他们会合计所有已经实现的故事的估算值，并计算出本次迭代的开发速度。这个速度会用于计划下一次的迭代。规则很简单：为每次迭代做计划时采用的开发速度就是前一次迭代中测算出来的开发速度。如果团队在最近一次迭代中完成了31个故事点，那么他们应该计划在下一次迭代中也完成31个点。他们的开发速度是每次迭代31个点。
这样的速度反馈有助于保持计划和团队实际状况同步。如果团队在专业知识和工作技能反面有所提高，那么开发速度也会得到相应提高。如果有人离开了团队，开发速度就会降低。如果系统架构朝有利于开发的方向演化，那么开发速度就会提高。
3.4 定义“完成”
除非所有的验收测试都通过，否则不能说一个故事实现完成了。这些验收测试是自动执行的。验收测试是由客户、业务分析师、质量保证专家、测试人员甚至包括程序员，在每次迭代开始一起编写的。这些测试定义了每个故事的细节，并且是判断故事的行为方式正确与否的决定性依据。
3.5 任务计划
在新的迭代开始时，开发人员和客户共同定制计划。开发人员把故事分解成开发任务。一个任务就是开发人员能够在4~16小时之内实现的一些功能。开发人员在客户的帮助下对这些故事进行分析，并尽可能地列举出所有的任务。
可以在活动挂图、白板和其它方便的媒介上列出这些任务。接着，开发人员逐个签订他们想要实现的任务，并以以随意的任务点数对每项任务进行估算。
开发可以签订任意类型的任务。数据库专家并非必须要签订数据库相关的任务。如果愿意，精通GUI的人员也可以签订数据库相关的任务。看起来好像无法人尽其能，不过会使用一种方法对这种状况进行管理。这样做的好处是显而易见的：开发人员对整个项目了解的越多，那么团队就会越健康、越有知识。我们希望项目的知识能够传递给每一个团队成员，即使这种知识是和他们的专业无关的。
每一个开发人员都知道上一次的迭代中所完成的任务点数；这个点数就是开发者的预算。没有人会签订超出他们预算的点数。
任务的选择一直持续到所有的任务都被分配出去，或者所有的开发人员都已经用完了他们的预算时为止。如果还有任务没有分配出去，那么开发人员会相互协商，基于各自的专长交互相应的任务。如果这样做都不能分配完所有任务，那么开发人员就要求客户从本次迭代中去掉一些任务或者故事。如果所有的任务都已经被分配，并且开发人员仍然具预算空间去完成更多的任务，那么他们会想客户要求更多的故事。
在迭代进行到一半的时候，团队会召开一次会议。在这个时间点上，本次迭代中所安排的半数故事应该被完成。如果没有完成，那么团队会设法重新分配没有完成的任务和职责，以保证在迭代结束时能够时能够完成所有的故事。如果开发人员不能实现这样这重新分派，则需要告知客户。客户可决定从迭代中去掉一个任务或故事。至少，客户可以指出那些最低优先级别的任务和故事，这样开发人员可以避免在其上花费时间。
例如，假设在本次迭代中客户选择了8个故事，总共24个故事点。同样假设这些故事被分解成42个任务。在迭代的中点，我们希望应该完成21个任务即12个故事点。这12个故事点代表的必须是全部完成的故事。我们的目标是完成故事，而不仅仅是任务。如果迭代结束的时候90%的任务已经完成，但是没有一个故事是完成的，这将是恶梦一般的情景。在迭代的中点，我们希望看到拥有一半故事点数的故事被完成。
3.6 迭代
每两周，本次迭代结束，下次迭代开始。在每次迭代结束时，会给客户演示当前可运行的程序。要求客户对项目程序的外观、感觉和性能进行评价。客户会以新用户故事的方式提供反馈。
客户可以经常看到项目的进展。他们可以度量开发速度。他们可以预测团队工作快慢，并且可以在早期安排实现高优先级别的故事。简而言之，客户拥有按照他们意愿进行管理所需的所有数据和控制权。
3.7 跟踪
对于XP项目来说，跟踪和管理就是记录每次迭代的结果，然后使用这些结果测试后面几次迭代的内容。
3.8 结论
通过一次次的迭代和发布，项目进入了一种可以预测、舒适的开发节奏。每个人都知道将要做什么，何时去做。利益相关者经常地、实实在在地看到项目进展。他们看到的不是画满了图、写满了计划的记事本，而是可以接触到、感觉到的可以工作的软件，并且他们可以对这个软件提供自己的反馈。
开发人员看到的是基于自己估算并且由自己度量的开发速度控制的合理计划。开发人员选择自己感觉舒适的任务，并保持高的工作质量。
管理人员在每次迭代总获取数据。他们是使用这些数据来控制和管理项目。他们不必采用强制、威胁或者恳求开发者的方式去表达武断的、不切实际的目标。
这听起来是美好轻松的，其实不是这样。利用相关者对过程产生的数据并不总是满意，特别是刚刚开始时。使用敏捷开发方法并不意味着利益相关者就可以得到他们想要的。它只不过意味着他们将能够控制团队以最小的代价获得最大的商业价值。