共计 2664 个字符，预计需要花费 7 分钟才能阅读完成。
背景
在某开发团队辅导的回顾会议上，团队成员对于优化预计具体方法上达成了一致意见。询问是否有什么具体的预计办法来做估算。
问题剖析
回顾意见上大家对本次 Sprint 的成果做回顾，其中 80% 的成员对于本次 Sprint 的估算成果不称心，最终团队心愿在下一个 Sprint 中，估算流动能有所改善。
经理解，团队目前的估算办法很简略，基本上是架构师和团队中有丰盛开发教训的成员一言堂。估算的速度也很快。对于有些有疑难的需要，开发成员也是保持沉默，草草认领了工作。
团队迫切希望学习新的估算办法来优化目前的估算流动，因而分享几个具体的估算办法给团队实际，让他们本人抉择适宜、喜爱的估算办法是解决问题的要害。
解决措施
咱们来学习下具体的故事点估算的实际，感受一下估算。这里介绍最罕用的两种估算办法：一个是打算扑克估算，另一个是麻利估算 2.0。下表内容展现了这两种估算办法在什么情景下抉择。
打算扑克估算
在麻利开发中，最典型的应用故事点做估算的办法是打算扑克（Planning Poker）。
打算扑克由 James Grenning 在 2002 年首次提出。打算扑克汇合了专家意见（Expert Opinion），类比（Analogy）以及合成（Disaggregation）这三种罕用的估算办法，使团队通过一个欢快的过程疾速而精确的得出估算后果。
打算扑克的参与者是团队的所有成员。典型的麻利团队规模举荐为 7±2 人，如规模比拟大能够思考拆分成为多个小团队各自独立进行估算。Product Owner 也须要加入，但不参加估算。
打算扑克开始时，每个参加估算的组员都会失去一副打算扑克，每一张牌上写有一个 Fibonacci 数字（典型的打算扑克由 12 张牌组成：?，0, ½，1, 2, 3, 5, 8, 13, 20, 40, 100,∞，其中? 代表信息不够无奈估算，∞代表该用户故事太大）。
开始对一个用户故事进行估算时，首先由 Product Owner 介绍这个用户故事的形容。过程中 Product Owner 答复组员任何对于该用户故事的问题。展开讨论时主持人 (通常由 Scrum Master 负责) 应留神管制工夫与细节水平，只有团队感觉对用户故事信息曾经理解到能够估算了，就该当停止探讨开始估算。
所有问题都被廓清后，每一个组员从 扑克中筛选他/她感觉能够表白这个用户故事大小的一张牌，然而不亮牌，也不让别的组员晓得本人的分数。所有人都筹备好后，主持人发口令让所有人同时亮牌，并保障每个人的估算值都能够被其他人分明的看到。
常常会呈现不同组员亮出的分值差距很大的景象。当呈现有很多不同分值的时候，出分最高的人和出分最低的人须要向整个团队解释出分的根据。（主持人须要留神管制会议气氛，避免出现意见不一导致的攻击性舆论。）所有的探讨应集中于出分者的想法是否值得团队其余成员进行更深刻的思考。
随后全组能够针对这些想法进行几分钟的自在探讨。探讨之后，团队进行下一轮的全组估算。一般来说，很多用户故事在进行第二轮估算的时候就能失去一个全组对立的分值，然而如果不能达到全组意见统一，那么就反复的进行下一轮直到失去对立论断。
麻利估算 2.0（Agile Estimating 2.0）
打算扑克是 Scrum 团队利用最宽泛的麻利估算办法，然而有时候打算扑克玩起来消耗比拟多的工夫，尤其是在十人左右的团队中。Ken Schwaber 在他的书《Agile Project Management with Scrum》中指出，在进行迭代布局时，迭代打算环节应该管制为一个 4 小时的固定工夫，然而从战术的角度看，如果一个会议继续 4 小时，大部分的参会者会有筋疲力尽的感觉，并且很难放弃长久的注意力。
为了解决这个问题，Brad Swanson 和 Björn Jensen 在上海 Scrum Gathering（2010/4/19）上介绍了 Agile Estimating 2.0 技术。这个新的估算技术同样基于的专家意见，类比和合成，同样实用 Fibonacci 数列，然而它能够显著地缩短会议工夫。它的估算过程大抵分为次要四步，如下图所示：
第一步：由 Product Owner 向团队介绍每一个用户故事，确保所有需要相干的问题都在做估算前失去解决。
第二步：整个团队一起参加这个游戏。
只有一个简略的游戏规则：一次仅由一个人将一个用户故事卡放在白板的适合地位上：规模小的故事在左，大的在右，一样大的竖向排成一列。整个团队轮流挪动故事卡，直到整个团队都认同白板上的故事卡的排序为止。
第三步：团队将故事点（Story Point）调配给每个用户故事（列）。
最简略的做法是应用投票来决定每个用户故事调配到哪一个 Fibonacci 数字。
最初一步：应用不同色彩来辨别影响估算大小的不同方面，并且重新考虑是否须要批改估算值。
例如，咱们应用红色来示意那些无奈被自动化测试脚本笼罩的用户故事，因而那些用户故事须要一个更大的数字来包容手工回归测试的代价。
在国内一些企业屡次实际 Agile Estimating 2.0 之后，反馈的后果还是令人兴奋。据称，团队对于估算的准确性更有信念了，并且只消耗原先的 1 / 2 工夫。
通过以上介绍，置信理解了如何应用用户故事来剖析理解需要。在学习了估算的外围概念及故事点后，对于估算办法的实际也有了更深的领会。不论是打算扑克估算还是麻利估算 2.0 都只是估算的一种实际，不是固定的惟一办法。只有了解估算的意义和外围概念，抉择适宜的办法就是没有问题的。另外补充一下，这里讲的估算偏重于用故事点估算，如果团队成员统一达成共识，用工时或现实人天成果更好，便能够尝试，给予团队试错的机会，说不定也有意想不到的播种。
实现了估算后，咱们须要对估算的内容进行治理。华为云 DevCloud 在用户故事或者 Task 中均有一个记录估算后果的属性，比方预计工时。所有工作项估算后果记录当前就能够以列表的形式进行查看。能够按解决人排序，查看每个成员认领的工作是否饱和。
开发团队实现的工作内容能够时时更新理论数据，这样每轮迭代也能够就估算准确度进行统计和剖析。看看估算后果和理论后果的差异，以便能够后续做估算调整和改善。
参考附录
- Kenneth S. Rubin. Scrum 精华[M]. 北京：清华大学出版社。
- Mark C. Layton. 麻利项目管理[M]. 北京：人民邮电出版社。
估算系列文章
【DevCloud · 麻利智库】估算第一篇：利用用户故事理解需要
【DevCloud · 麻利智库】估算第二篇：利用外围概念解决估算常见问题
【DevCloud · 麻利智库】估算第三篇：利用故事点做估算
点击关注，第一工夫理解华为云陈腐技术~
