敏捷开发之如何进行故事点估算？

敏捷估算的价值

敏捷估算，就是在敏捷开发中，对即将开始的工作进行工作量、复杂度和持续时间的相对估算。通常情况下，软件开发过程中有很多未知数：技术更新，需求变更，系统之间的依赖关系等，它们都会影响估算结果，所以说估算是一项费时费力的工作，并且得到的结果也是不精确的。既然如此，我们为什么还需要进行敏捷估算呢？

估算和计划是紧密相关的，估算结果是计划的重要依据。决策者需要这个估算结果，来调整需求优先级，进行资源安排，甚至砍掉这个功能。
对客户来说，估算结果可以给出一个功能上线的预期更甚至于承诺，尽管这不是绝对准确的。
估算对团队来说，给了团队一个机会来提前讨论需求，建立对需求一致的理解，消除疑问。
估算需要团队深入研究还未开始工作，提前考虑将会涉及到的团队合作甚至是跨团队的合作，大大提升实际工作中的团队效率。

估算的初衷虽然是得到完成功能时间的预期，但是我认为这项活动最重要的价值在于估算过程中对需求建立的深入理解，以及事先为实现功能的方法和策略做的全盘考虑。这一定会在接下来的实际工作中起到相当重要的作用，甚至决定了整个迭代能否完成目标。

为什么使用故事点

估算是一件很困难的事，它同所有预测未来的事情一样，结果往往都存在巨大的误差。想要得到精确的预测结果，则需要花更多的时间来了解细节。而团队进行估算所花时间的边际效益必然是递减的，因此花太多时间在估算上是相当不划算的。那我们该如何进行估算？

别忘了，人类的本质是什么？不是说复读机！

我的意思是，人类生来更擅长相对估算而不是绝对估算。因此，相对值的估算会更快和更容易理解。比如，我面前有两栋楼，一栋的高度是另一栋的两倍，我可以迅速判断出来。但是我可能无法得出一栋楼是100米，另一栋是200米的结论。所以，在敏捷估算中，我们引入了故事点。

故事点是一个对工作量、复杂度或者持续时间进行估算的相对计量单位，最早在scrum和极限编程这一类的敏捷方法中开始使用。因为主要估算对象是用户故事，所以被称为故事点。

杠精本精有必要出来杠一下了，故事点不一样是1个故事点，2个故事点的度量单位么，怎么就成相对估算了？

这是因为故事点的大小没有标准。也就是说，每个团队的故事点都是不一样的。对一个团队来说3个故事点的工作，可能对应了另一个团队5个故事点的工作。用故事点进行估算，我们不会说这个功能需要100个小时来完成，而是说这个功能是8个故事点，工作量大概是4个故事点的某功能的两倍。

故事点采用数字计数同时也带来了一个问题，它会让人自然的想追求精确，这和相对估算是冲突的。因此，我们建议采用斐波那契数列（0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144）来进行估算。因为当一个需求的估计值越大的时候，我们进行估算的结果误差也越大。我们要避免去纠结这个需求到底是20个故事点还是21个故事点，这是没有任何意义的。

估算的对象

由于估算需要我们同时做到尽量快速和准确，所以估算的对象选择也是相当重要的。敏捷开发中，需求经常被分为史诗、特性和用户故事三个等级，用户故事下又能拆分成任务。这么多类型，我们到底对谁进行估算？

首先，过大的工作量会导致估算结果误差过大，导致史诗和特性不太适合故事点估算。其次，任务又太过细致，对任务进行估算的话耗费时间。所以，按排除法我们还剩下用户故事。（当然，根据实际情况，有时候我们也可以对特性或者对缺陷进行估算。）

如何进行估算

估算的结果是属于团队的，不属于个人。首先，因为负责某个需求的人并不确定，所以整个需求是由团队负责。其次，团队决定的估算点数可能比个人估算更加合理。更重要的是，团队一起估算时，团队成员针对一个需求的讨论和见解分享是整个团队成长的契机。因此，比起个人估算，我们建议进行团队估算，团队中绝大部分成员参与估算是有必要的。

我们常用的团队估算方法是扑克估算，具体操作流程如下:

每个团队成员分发一套写着0、0.5、1、2、3、5、8、13、20、40、∞、？的卡片。
产品负责人负责讲解需求待办列表挑选出来的需求，团队成员提出自己的疑问，产品负责人一一解答。
团队成员进行估算，选出自己估算结果对应的卡片盖在桌上，不要告知其他团队成员。
所有人都确认自己的估算结果后，大家一起翻开卡片，展示自己的估算结果。
团队评估估算结果，让给出估算点数最大和最小的成员分别陈述自己给出当前结果的理由，团队讨论，消除分歧，得到一致的结果。（这一步尤为重要，讨论过程是团队分享知识和经验绝佳机会。）
选择下一个故事，重复第2步。

不过，既然到了斗地主都必须是在线活动的9012年了，扑克估算这种小事当然不再需要人手一副纸质卡片。

一、在线创建房间，添加估算需求，支持多种打分方式（扑克估算、T恤估算）。