敏捷开发“松结对编程”实践之三：共同估算篇（大型研发团队，学习型团队，139团队，师徒制度，敏捷设计，估算扑克，扑克牌估算）

转载自： http://blog.csdn.net/cheny_com/article/details/6587277

本文是“松结对编程”系列的第三篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之后文章请见栏目总目录。）

估算是经久不衰的管理话题，大致分为两种流派。

第一种是领导指派，领导说这是10天的活，就必须当是10天的活来干，如果干不完，可以用加班、损失质量、功能缩水等各种方法曲线救场。另一个变种是大家自己估算，但是交给领导审批；领导审批其实就是砍一半的过程，还好大家之前就已经加了一倍，所以不怕。

第二种是自我管理派（偏敏捷），就是由具体开发的人员自己说开发工作量，领导和他人不干预。尽管“自组织”了，但是领导深以为这种方法留下了偷懒的种子，而队员也觉得某人的估算很不靠谱（太长或太短），到底怎么办呢？

共同估算吧。

--------------------------------------------

基本概念

假设现在是一个计划会上，PO（产品经理，策划组长，项目经理，某销售……）刚刚讲完需求，下一步不是交给某人做估算，而是交给某个潜在的组（师傅+1～3徒弟）。

由师傅带头打牌，对，在计划会上玩扑克：

1. 大家各自思考可能要花多久时间完成任务，扣一张牌出来；

2. 师傅喊开牌，大家亮牌，比较大小；

3. 一般最小和最大的两个人PK，说出自己的观点，大家一起讨论；

4. 差异无非来自于两个方面：做什么，怎么做；PO参与讨论回答做什么的问题，师傅和徒弟们讨论解决怎么做的问题；

5. 讨论过后再来几轮，直到大家觉得结果差不多了。

扑克牌估算的匿名性和开放性保证了大家不会人云亦云，也不会因为缺少沟通而难以达成一致。

笔者的经验是一局扑克牌估算大约持续1～5分钟，还是很快的。偶然有黄庄的，一般都是因为PO那里回答不了做成什么样子，某某附加功能是否也要做……等等问题时。

几个问题

1. 为什么分给组而不是个人？

不分个人就打牌使得每个人都不得不思考，因为怕出错了牌又说不出所以然。这样即使日后他不做这个功能，也对这个功能很了解。

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

因为他很可能因为不知道某代码可用、不知道某软件不行、不懂template（我们因此扔过1个人月代码）……而选择了错误的实现方法。

3. 为什么不让师傅估算大家采纳，他不是最厉害吗？

师傅的想法常常是徒弟们理解不了的——比如为什么不留在女儿国而偏偏去西天取经之类的，呵呵——共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。

4. PO怎么还参加？不是不让别人干预吗？

很多问题比如在游戏中“显示武林排行榜”，具体工作量可能不在于怎么做而在于做什么：凭什么排名？排多少名？实时排名还是每周排名？怎么显示排名？……因此PO不能写出一堆文档，然后以不便干预估算为名不参加敏捷计划会议。

PO可以挑战估算，比如：“这真的要这么久吗？我记得上次……”但要有理有据。其实实践中更容易看到的是，团队往往过于激进乐观，PO反而要让他们意识到完整的需求和要求，做出更现实的估算。估算不准确，PO也有责。

5. 一直无法达成一致怎么办？

其实估算不是为了最后那个数字，而是弄清楚做什么和怎么做的问题，如果这两件事情清楚了，但结果却是偏偏有人说4天有人说6天，随便取个数就可以了（事实是应该按墨菲定理取6天）。有师傅在，一般很少会就实现方法争执不下；有PO在，一般很少会就要实现什么争执不下。

不排除有特殊情况比如PO发现自己也没想过排行榜凭什么排行，那么就应该搁置此用户故事；又比如大家觉得如果数据库给力可能实时排名也行但又拿不准，可以暂时搁置到开发的时候再说，但把故事上标注一下“若需要每周自动排名+1天”。如果经常黄庄，Scrum Master要分析总结避免。

6. 四个人出牌不同，师傅先说还是徒弟先说？

想起个脑筋急转弯：科学家 医生 士兵 护士 ……等等一群人在飞机上，飞机结冰快坠落了需要有人（可能不止一个）跳下去，问谁跳？答案是从体重最重的人开始跳，因为可以少跳几个。

因此我们是出牌数字最小的先说，和师徒无关。因为他极有可能掌握最佳实现方法。如果后来发现不是如此，请参考下一条。

7. 都有什么理由可陈述？

按下面的顺序，越靠前的越接近真理，感觉自己接近真理的就一定要举手先说，马后炮招人嫌：

经验事实：我以前做过……咱们有个类库……那个方法我试过不可行……

蛛丝马迹：谁还记得上次……听说隔壁……与上回相比……你以前不是……

逻辑推理：理论上说……我觉得……

几个注意事项

1. 小组内不要有强分工，否则大家会缺省认为肯定是某人的工作。

2. 师傅不要太抢眼，要通过估算鼓励徒弟思考，同时也掌握徒弟的真实水平。

3. 师傅不要太较真，编程规范、易用性、易维护性这些纪律不能放松，但如果徒弟想尝试一种不同但工作量也差不多的方法，可以适当鼓励。

4. Scrum Master监控整个过程，防止太细/争执……等问题。

5. PO必须参加。

----------------------------------------------------------

共同估算依靠PO的参与解决了做什么的问题，依靠师傅的带动解决了怎么做的问题。

共同估算是“跨职能团队”的基础活动之一，之后他们之所以能在每日立会上分享当前进展与困难，就是因为当初是他们一起思考这一任务的，因此对这一任务后来的实际情况非常关心。在发生问题的时候，大家也更可以互相帮助，而不是毫不所知。

下一篇将会涉及日常工作/每日立会等迭代期内的工作。

 

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》