《敏捷软件开发：用户故事实战》—小的

小的

就像金发女孩（Goldilocks）[1]寻找舒适的床一样，有些故事太大，有些太小，有些则恰到好处。故事大小很关键，因为如果故事太大或者太小，都无助于计划。史诗在工作中很难应用，因为它们经常包含多个故事。例如，在旅游预订系统中，“用户可以计划休假”是一个史诗。计划休假是旅行预订系统的重要功能，包含很多任务。史诗应该拆分为多个较小的故事。最终确定一个故事是否大小适当取决于团队规模、团队能力和使用的技术。

拆分故事

史诗一般分为以下两种。

l   复合故事。

l   复杂故事。

复合故事是由多个较小的故事组成的史诗。例如，BigMoneyJobs系统可能包括这样的故事“用户可以发布自己的简历”。在系统最初规划时这个故事可能是合适的。但是当开发人员与客户讨论时，他们发现“发布简历”实际上包括以下几点。

l   简历包括教育信息、工作经历、薪资历史、出版物、演讲、社区服务和求职目标。

l   用户可以将简历标记为非激活状态。

l   用户可以有多份简历。

l   用户可以编辑简历。

l   用户可以删除简历。

上述需求取决于开发完成需要的时间量，每一个都可以成为独特的故事。然而，也不能走向另一个极端，把它变成一系列太小的故事。例如，根据使用的技术和团队的规模大小和技能情况，下面这样的故事通常都太小了。

l   求职者可以在简历中输入每个社区服务条目的日期。

l   求职者可以在简历上编辑每个社区服务条目的日期。

l   求职者可以在简历上输入每一份之前的工作的日期范围。

l   求职者可以在简历上为每一份之前的工作编辑日期范围。

一般来说，更好的方法是将多个较小的故事合并如下。

l   用户可以创建简历，包括教育信息、工作经历、薪资历史、出版物、演示文稿、社区服务和目标。

l   用户可以编辑简历。

l   用户可以删除简历。

l   用户可以有多个简历。

l   用户可以激活简历，也可以使简历失效。

通常有很多方法来拆分一个复合故事。前面的拆分是依照创建、编辑和删除等通常使用的操作来拆分的。如果关于“创建”的这个故事足够小，就可以把它作为一个故事来处理。另一种方法是根据数据的边界进行拆分。要做到这一点，可以将简历的每一个组成部分单独地添加和编辑。这就导致了如下一个完全不同的分类。

l   用户可以添加和编辑教育信息。

l   用户可以添加和编辑工作经历信息。

l   用户可以添加和编辑薪资历史信息。

l   用户可以添加和编辑出版物。

l   用户可以添加和编辑演示文稿。

l   用户可以添加和编辑社区服务。

l   用户可以添加和编辑一个目标。

等等。

与复合故事不同，复杂故事是一个用户故事，但是它本身庞大，不容易拆分成一组组件故事。如果一个故事因为与它相关的不确定性而变得复杂，你可能会想把故事拆分成两个故事：一个是研究性的，另一个是开发新功能的。例如，假设开发人员给出了“一个公司可以用信用卡支付职位招聘”的故事，但没有一个开发人员曾经做过信用卡处理的相关工作。他们可能会选择把故事拆分成下面两部分。

l   在网上研究信用卡处理过程。

l   用户可以用信用卡支付。

在这种情况下，第一个故事将会以探针形式让一个或者多个开发人员进行研究试验。当复杂故事以这种方式拆分时，总是用时间盒来限定研究性故事或者探针故事。即使这个故事不能以任何合理的准确性进行估计，我们仍然可以用时间盒来定义花费在学习上的最大时长。

在开发新的或者扩展已知算法时，复杂故事也很常见。有家生物技术公司的一个团队有一个故事：将新的扩展添加到称为期望最大化的标准统计方法中。这个复杂故事被改写成两个故事：第一个是研究和确定扩展标准统计方法期望最大化的可行性；第二个是将该功能添加到产品中。在这样的情况下，很难估计研究性故事要花费多长时间。

考虑把探针放入不同的迭代中

可能的话，把研究性（探针）故事放入迭代，而其他的故事放入后续的一个或者多次迭代是比较有效的。一般情况下，只有研究性的故事可以估算。如果一次迭代既包括研究性故事也包括无法估算的故事，往往意味着不确定性会高于正常水平，因为我们无法预知这次迭代可以完成多少工作内容。

拆分一个无法估算的故事的主要好处是能够让客户将研究性故事从新功能之中分离出来并进行优先级排序。如果客户只对复杂的故事进行优先级排序（“添加新的扩展到标准的EM”）和估算，那么她可能会根据错误的假设来排列故事优先级和预估新功能交付的大概时间表。反之，客户有一个研究性的探针故事（“研究扩展EM的可行性”）和一个功能性的故事（“扩展EM”），她必须在这次迭代中进行选择：要么增加没有新功能的研究性故事，要么加入一些其他的故事来增加新功能。

合并故事

有时候故事太小了。通常情况下，一个太小的故事是开发人员说她不想写出来或者估算的故事，因为这样做可能比去实现故事需要花费的时间更长。常见的典型太小的故事例子比如bug报告和用户界面更改。在极限编程团队中，一个很好的方法是将它们合并成更大的故事，估算大约从半天到几天。合并后的故事像其他故事一样被赋予一个名字，然后进行计划并实现。

例如，假设一个项目有5个bug，并且请求在搜索界面上更改一些颜色。开发人员可以估算涉及到的全部工作，并把整个集合当作一个单独的故事来处理。如果选择使用纸质卡片，可以把它们用一张封面卡片装订在一起。