本文是王晓明同学在InfoQ发表的文章《关于项目估算的微博讨论》中提到的排序法详解。

一、引言

软件项目的估算历来是一个难题。由于软件开发活动还无法实现土建工程那种成熟度，所以也无法像做土建工程那样通过预算速查手册来评估。但是，对于一项投资来说，总要说出要投资多少吧，软件开发也要给出投资额，这就需要做估算了。 本文主要讨论敏捷软件开发中的用户故事（User Story）估算。估算方法有很多，但大体上分为绝对估算和相对估算。在本文中，“绝对估算”就是指以绝对时间（如小时或天）为单位进行估算。而“相对估算”就是通过用户故事之间的大小对比进行估算，估算后的结果没有时间单位（它们之间的差异，不在本文讨论范围之内）。在相对估算方法中，也有很多种不同方式。而相对估算的过程中常常会出现下面的现象，尤其是对那些第一次使用相对估算的团队： - 当确定相对估算的基准单位“1”时，开发人员很难找到一个合适的用户故事做基准； - 开发人员更关注于讨论单个用户故事的点数是多少，而不是关注与其它用户故事比较的相对大小； - 估算所花费的总时间比较长（常常是整个下午，甚至一天）。 本文所述的估算方法仅是作者在指导工作中曾经使用过且收效不错的经验总结，但并不确保任何情况下都有效。

二、排序估算法

1、使用目标

制定发布计划，通常有一定数量的故事卡。

2、曾使用过的场景

项目规模较大（一到三个月的周期），已根据用户故事的拆分原则（INVEST原则）得到一个用户故事列表，该列表由各角色共同讨论过，且对每个用户故事的内容已达成共识。同时，团队基本上可以保证，每个卡片都会有两个或两个以上的开发人员了解，并有能力开发。

3、基本依据或假设

1. 用户故事的客观规模不会因为具体开发人员的差异而不同（尽管人员不同，花费的时间可能不同）。 2. 开发人员基本了解每个用户故事的工作内容。 3. 由于用户故事有一定的数量（从统计学的角度看），所以客观规模不会偏差太多。 4. 开发人员是整个交付过程的瓶颈，所以仅由开发人员估算其开发规模，不包括用户故事的测试规模。

4、估算过程

* 将待估算的所有用户故事写在卡片上，并分发给每个参与项目的开发人员（均分即可）； * 先让一个开发人员取一张卡片A，贴到墙上（随便哪张都可以）； * 然后让每个开发人员按以下规则将手中的卡片贴在墙上： 1. 从自己手中取出一张卡片B，与墙上已有的那些卡片进行对比（开始时仅有一张卡片，即A）。 2. 如果手中的卡片B与墙上A的大小相当，就将其贴在卡片A的下方；如图1所示。

  图1. A与B的大小相当

3. 如果手中的卡片B比卡片A大，就将其贴在A的右侧，如图2所示。 图 2 B大于A

4. 如果手中的卡片B比卡片A小，就将其贴在A的左侧。 5. 继续再拿出一张卡片C，与墙上的卡片相比，如果比墙上所有卡片都小，则放在左侧；如果比它们大，放在右侧；与墙上某张卡片差不多大小，就放在其下方。 6. 如果C的大小在A和B之间，就把它放在A 和B 之间，如图3所示。以此类推。在这个过程中，可以让所有开发人员同时贴卡片，只要彼此不干涉，保持独立判断即可。

图3 C介于A和B之间

7. 当全部卡片贴完以后，再请全体开发人员重新看一看，是不是每个卡片的位置都很适当。如图4所示。 图 4 排好序的卡片墙

8. 如果对某个卡片的位置有异议，请拿出来讨论。这也许是因为大家对它的内容和理解不一致造成的。因此需要对其进行深入讨论，直至一致认为它应该在哪一列为止。 9. 使用数字 1,2,3,5,8,13或 1,2,4,8,16按顺序将其放在有对比关系的列上，如图5所示。注意，这时团队成员间还会发生对一些卡片的大小进行讨论，有可能也进行位置调整。图5中，列在“2”的每个故事卡片，其大小应该是“1”列的一倍左右。由于是估算，所以并不需要精确，只要相当即可，以此类推。 图 5 已设定好每列大小的卡片墙

10. 对于那些列头上还没有数字标识的列（如图5中“L”列、“A”列和“K”列），请开发人员根据其规模的接近程度将其放到相邻的列中。 如图6所示。 图6 已估算好的卡片墙

最后，将每列的用户故事数与列头的数字相乘，得到的数字再相加以后，就得到该项目的总体规模。

三、注意事项

1. 在估算之前，应该确保所有用户故事之间的规模差异不要过大。例如，某个用户故事大约需要一个小时完成，而另一个用户故事则需要两周。此时说明，用户故事的粒度不合理，不符合INVEST原则中的S原则，需进行合并或分拆。 2. 如果各列卡片的数量不符合正态分布，而是两头的卡片多，中间的卡片少，也说明用户故事粒度可能有问题，需要重新审视一下。在这种情况下，会为后续的迭代计划带来困难。 3. 如果在一列中有数个相关联且同样大小的故事（比如支持银联卡、支持MasterCard、支持VISA卡），且先做完一个卡片，其它两个工作量会减少的情况下，可以将任意一个放在当前列，其它两个可以考虑放在比较小的一列中。但是，具体情况还是要具体分析，因为实际情况较复杂。但在整体审视环节中，这类的分析和验证工作不可缺少。 4. 在讨论和移动卡片时，应该更多地与其它卡片进行对比，而不是直接说某个卡片属于哪一数字列。因为列头的数字都是相对值，没有其它卡片的对比，这些数字没有意义。 5. 在讨论的过程中，会捕捉到一些之前没有发现的问题或信息，此时一定要及时记录下来。对于不清楚的问题，应该当场由业务人员给出结论。 6. 这种方法在那些没有尝试过相对估算的团队中首次使用时，最好能有一定经验的人加以引导，对已排定的顺序进行适当验证。

四、实际应用的一个案例

这种方法比较快捷。作者已做过数次实践，所带团队各不相同，但结果比较满意。在最近一次实践中，一共有40多张用户故事，用时大约1.5小时，就完成了规模估算和发布计划的制定。下面两张照片就是当时估算的情景。由于该团队一直使用传统的瀑布开发方式，首次尝试使用敏捷开发方法，所以在这次估算中，作者并没有要求团队一定使用仅包含1,2,3,5的数字序列，而是使用是1,2,3,5,8,13的数字序列。但在开发后期，团队已经有能力将较大的用户故事（8和13）进行拆分，使其变成由1,2,3,5组成的多个用户故事。另外，值得注意的是，如图8所示，本次估算中，在大小为“1”的这一列上，并没有任何用户故事。这也是正常现象，从侧面反映了，并不是所有的估算都需要基准“1”。

图7 开发人员正在向墙上贴用户故事卡片，尚未决定每列的数字。

图8 开发人员正在讨论将一个没有数值的用户故事放在哪个数值列下

五、小结

对于刚刚接触敏捷软件开发方法的团队来说，这种规模估算和计划的方法的确不太容易接受，尤其是在那些已习惯于使用WBS分解方式做计划的团队中，他们会纠结于“1”到底代表多长时间，是代表资深开发人员的一天呢，还是新手的一天？因此，如前所述，这种排序法有其前提条件与假设。而且，在进行用户故事拆分时，进行充分的讨论，让团队成员了解每个用户故事，这是该方法成功的前提，当然，也是敏捷软件开发方法成功的前提。 值得再次强调的一点是，该方法只估算开发工作量。其前提假设是测试工作不是整个交付过程的瓶颈。 另外，用户故事的INVEST原则包括：独立性（Independent），可协商性（Negotiable），有价值（Valuable），可以估算性（Estimable），小的（Small and similar size）和可测试性（Testable）。作者认为，其中的“S”有两方面的含义。一是“small”：一个好的故事在规模上要尽量小，至少要确保在一个迭代内能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。二是“similar size”：所有用户故事规模不应相差太大，不要为了追求“小”而出现半个小时就能完成的用户故事，结果使得最大和最小的用户故事之间相差数十倍（不要笑，现实中的确见过这种情况）。 原文发表于InfoQ中文站。原文链接在这里