敏捷软件开发——计划

Initial Exploration 初始探索

在项目的初期，开发人员和业务人员将关于新的系统的构建进行交流以确定所有重要的feature。事实上，并不需要在一开始就确定所有的feature，因为随着项目的进行，业务人员会发现更多的feature。当一个feature被确定后，它将会被分解为一个或多个user story。在这个阶段，我们并不试图去捕获所有的细节。我们只是简单地希望user story能使我们记住有关feature的讨论。然后开发人员开始评估每个user story。开发人员将使用相对评估，我们可以在一个故事卡片上写下一个数字来表示该user story的相对成本，这时我们并不需要知道一个story点数究竟要花费多少开发时间。

Spiking, Splitting, and Velocity 探究、分解和速度

过大的story和过小的story都不便于评估。如果一个user story太大了，那么需要将其分解成多个小部分。如果一个user story太小了，那么需要将多个小的story合并成一个大的story。当一个story被分解或者合并后，需要对其进行重新评估。重新评估并不是简单地对原先的评估值进行加减，因为对story进行分解和合并的原因是为了能对其进行更准确的评估，所以重新评估的值会与原先的值有较大的出入，这是因为我们评估的更准确了。

每个星期我们将完成一定数量的user story。这些完成的story的评估的总和就被称作速度。再经历了三到四周之后，我们将更好的了解我们的平均速度。我们可以使用这个速度来预测下一周将完成多少工作。所以，XP项目中一个最重要的管理工具就是追踪速度。

Release Planning 发布计划

给定一个速度，业务人员可以知道每一个story将花费多长时间以及它的商业价值和优先级。这使得业务人员可以选择那些需要优先完成的story。这种选择并不仅仅只是比较优先级，它更偏向于是一个商业决策。业务人员将决定那些将带来更大效益和影响的story。