携程PMO--扑克派对，我的估算我做主！

转自本人运营的公众号“ 携程技术中心PMO”（ID：cso_pmo）

 

---

 

作者简介

 

Ollie Guan，携程PMO高级项目集经理，负责敏捷总动员及携程技术中心PMO微信公众号运营。上海AUG Leader，Atlassian Community Champion，Top 10 super-contributors。

 

 

Why ？

 

 

做技术同学们都知道，在项目初始阶段我们会对需求、任务进行估算，估算往往很花时间，更要命的是总做不到准确。既然这个值即不准，又花时间，那为什么还要做估算呢？

 

• 对于用户：用户需要一个这样的预期（甚至是承诺），什么时候才能用上这个功能；
• 对于管理者：管理者需要这个估算来做决策，包括调整工作优先级、人员调整、甚至是否砍掉这个功能等；
• 对于团队自己：不仅是团队内的合作，还包括团队之间的合作（如联调的时间的确定），都需要基于估算给出。

 

除了上面这三个角色对估算的期望之外，估算还有一个重要的价值，那就是在估算活动中大家对需求能够趋向达成一致的理解，减少一些被忽略的假设和背景。所谓“磨刀不误砍柴工”，在估算上花费的时间是值得的。

 

What ？

 

 

扑克估算，顾名思义，我们在估算的活动中加入了扑克这套工具。

 

传统估算通常是一个人在思考，而扑克估算鼓励跨职能团队的多个团队成员参与，团队成员可以从不同的视角来思考和分析问题，考虑更加全面、估算也更加准确。

 

使用估算扑克来做估算基于两个结论：

 

• 团队的智慧要高于某一个人的智慧；
• 真正参与工作的人做出的估算要高于其他人做出的估算。

 

在估算的过程中，团队对估算的结果进行讨论和评判，在一个高度透明的环境下，估算的结果更加真实和客观。这样也避免了很多时候过于武断，或是拍脑袋做出的决定。

 

估算的过程也是一个知识分享和学习的过程，对某一个被估算的Backlog不清楚的成员通过其他成员的阐述会增加他对此Backlog涉及到的要点的认识。

 

Who ？

 

在常见的Scrum团队中，包含了PO、Scrum Master、Dev Team几个角色，扑克估算的过程Dev Team全员参与

 

• PO 负责讲解需求
• Scrum Master 负责主持估算活动
• Dev Team 全员参与估算

 

 

When ？

 

扑克估算是几个潜在的任务承担者共同估算的方法，他们一起听PO讲解，一起估算，以达到用集体的智慧解决问题的目的。

 

 

这项估算活动一般是在Refinement Meeting上进行，PO为Dev Team按优先级逐个讲解需求，当团队成员确认对该Backlog完全了解，无任何重大问题后，大家开始对该Backlog进行估算。

 

How ？

 

 

传统的估算单位一般是小时或是人天，敏捷估算中推荐的是使用相对估算的方式，用故事点（story point）作为单位。

 

相对值的故事点到底有什么好处呢？

 

人类天生更擅长相对值的比较，相对值的估算会更快，小时和人天受限于任务实际执行者的能力水平，在估算时引入这个不可控的变量会让估算活动更加复杂和达不成一致。

 

 

现在大家看到的这张图是由携程技术中心PMO定制的估算扑克。

 

牌面上印有供估算使用的数字与符号，数字分别是，0，1/2，1，2，3，5，8，13，正无穷大，？，咖啡杯等，此外我们把敏捷的一些文化，活动，实践方法，名词解释等内容印在扑克的卡面上展示。

 

采购估算扑克9.9元/副

 

细心的同学可能发现了，估算数字并不是一串连续的自然数，而是使用了斐波那契数列。这是因为当一个用户故事越复杂，我们估计值越大的时候，估算结果的准确性也就越低，这个时候再去纠结它的点数是13还是14已经没有意义了。为了避免没有意义的数字争论，以及提醒我们这个用户故事可能太大需要再次拆解，所以才使用了步长越来越大的斐波那契数列。

 

在实际操作中，一些团队内部会规定超过13的用户故事必须再次拆分。

 

 

扑克估算过程简述：

 

• 每人各自估算后独立出暗牌，听口令一起亮牌；
• 数值最大与最小者PK，其他人旁听也可以参与讨论；
• 讨论结束后重新出暗牌和亮牌；
• 重复上述过程，直到结果比较接近。

 

小贴士

 

Q：为什么每个人都要参与出牌，即便他可能对这个功能并不熟悉？

A：团队共同参与，使得每个人都不得不思考，因为怕出错了牌又说不出所以然。这样即使日后他不做这个功能，也对这个功能很了解。    

 

Q：为什么不让最后领任务的人自己估算？

A：因为他可能不知道某段代码可复用，不熟悉某项技术而选择了错误的实现方法，正如前文所述“团队的智慧要高于某一个人的智慧”。

 

Q：为什么不让团队里的专家做估算？他不是最厉害吗？

A：共同估算就是让大家在思考中对照自己的实现方法和专家差异的过程。

 

Q：PO是否参与估算？不是不让Dev Team以外的人干预吗？

A：PO可以挑战估算，但要有理有据。现实中团队往往过于激进乐观，PO反而要让团队意识到完整的需求和要求，做出更现实的估算，估算不准确，PO也有责任。

 

编者按

 

或许您刚完成一个敏捷项目，另外一个团队希望您能加入去帮助他们。当然，每个项目都是不同的。那么，您上次使用的实践会在这个项目中同样有效吗？不一定！这本书将帮助您了解为什么“不一定”，然后决定什么实践应该采纳，同时对于哪些实践需要调整，如何做调整也会给出一些提示。

 

关注“携程技术中心PMO”公众号

回复“模式”获取《敏捷实践实施模式》电子版

 

 

 

更多视频

 

• 小罗说敏捷--如何召开卓有成效的回顾会
• 小罗说敏捷--如何管理敏捷团队知识资产
• 敏捷工具实操--Jira&Confleunce使用讲解

 

---

部分图片及电子书来源于网络，版权归原作者所有，仅供学习勿作它用。如果侵犯到您的权益，请联系我们撤除。

---