17 第一部分 敏 捷 开 发
3.1
初始探索
在项目开始时，开发人员会和客户商讨一下关于新系统的情况，以确定出所有真正重要的特性。
然而，他们不会试图去确定所有的特性。随着项目的进展，客户会不断地发觉编写新的特性。特性
的发现过程会一直持续到项目完成。
当识别出一个特性时，会把它分解成一个或者多个用户故事，并把这些用户故事写在索引卡片
之类的东西上面。除了用户故事的名字之外，无需记录其他任何内容（比如Login、Add User、Delete
User或者Change Password）。此时，我们不会试图记录细节。我们只是希望有某些东西能够提醒我
们想起曾经谈论过这些特性。
开发人员共同对这些故事进行估算。估算是相对的，不是绝对的。我们在记录故事的卡片上写
上一些“点数”来表示实现这个故事所需要的相对时间。我们也许不能确定一个“点”代表多少时间，但
是我们知道实现8个点的故事所需要的时间是实现4个点的两倍。
探究、分解和速度
过大或者过小的故事都是难以估算的。开发人员往往会低估那些大的故事而高估那些小的故事。
任何过大的故事都应该分解成小一点的部分，任何过小故事都应该和其他小的故事合并。
例如，考虑下面这个用户故事：“用户能够安全地进行存款、取款、转账活动。” 这是个大的故事。
对它进行估算将会很困难，有可能还不准确。然而，我们可以把它分解成以下几个更容易估算的故
事：
用户可以登录；
用户可以退出；
用户可以向其账户存款；
用户可以从其账户取款；
用户可以从其账户向其他账户转账。
在分割或合并一个故事时，应该对其重新进行估算。简单地加上或者减去估算值是不明智的。
对用户故事进行分解或者合并完全是为了使其大小适于被准确地估算。当一个估算为 25点的故事分
解为几个点数总和达到30点的故事时，不要觉得奇怪！30点是更精确的估算。
每周，我们都会实现一定数量的故事。这些已经实现了的故事的估算之和是一种度量，称为速
度。如果我们在上周实现的故事的点数之和为42，那么我们的速度就是42。
3或者4周后，我们就会比较了解我们的平均速度。我们可以使用这个平均速度来预测在后面的
几周内能够完成多少工作。在XP项目中，跟踪速度是最为重要的管理手段之一。
在项目开始时，开发人员对他们的速度没有很好的认识。他们必须要给出一个初始的猜测值，
在猜测时，可以采用他们感觉会带来最好结果的任何方式进行。此时并不需要非常的准确，所以他
们无需在这上面花费过多的时间。事实上，做到和保守的凭直觉猜测（SWAG）
1
一样好就足够了。
3.2
发布计划
如果知道了开发速度，客户就能够了解每个故事的成本及其商业价值和优先级别。据此，客户
就可以选择那些想要最先完成的故事。这种选择不是单纯依据优先级别进行的。一些重要的但是实
1
Scientific Wild-Assed Guess。
评论0