敏捷开发“松结对编程”实践之三：共同估算篇

本文是“松结对编程”系列的第三篇。

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

第一种是领导指派，领导说这是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的参与解决了作什么的问题，依靠师傅的带动解决了怎么作的问题。

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

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