问题

来自提问帖 15楼 http://blog.csdn.net/cheny_com/article/details/7564388

原问题摘录如下：

开发组中可能同时进行几个专项开发，那么就有人参与这个专项，不参与另一个专项。
那么扑克估算的时候，针对某一专项的任务，要怎样做，是否是开发组所有人员都参加评估，还是这个专项相关的人员才参与？

可能一个专项就一两个人来做，专门估算，跟单独拍脑袋差别不大；
如果大家一起估算，存在效率很低的问题；

分析

估算的目的是什么？

在估算之前，一个非常重要的一定要问自己的问题是：估算的原因或目的是什么？

估算有很多原因，但实际上有些不太经得住推敲，或者说若遇到有人喜欢杠头，则很难反驳。比如：

1. 为了知道多少行代码可以完成（如果用代码行估计）。

杠头：无论知道是1000行还是不知道，做完了一数都是1000行，为什么要提前估计呢？（这个是我8年前被问到的一个问题）

2. 为了知道多久才能完成，以便做计划。

杠头：我们计划都是反推的，领导说多久，我们就做多久，估算有什么价值？

……

那么有哪些估算是无缺缺少或极具价值的呢？大致有两种。

1. 在报价/合同发生之前的估算

若能在此之间完成估算，就能把握商务的主动。即使“被迫签订合同”，做到“心里有数”还是要好很多。

这个属于早期造价估算，以后再详述，但可以参考http://blog.csdn.net/cheny_com/article/details/7672333。

2. 能改善结果的估算

如果之前以为要1000行——而且直接做也真的要1000行，结果估算完了发现只要100行，就很值得估算。

如果之前以为要100天——而且直接做也真的要100天，结果估算完了发现只要10天，也很值得估算。

这个是扑克牌估算的最佳应用场景。

预备活动

原理

估算能改善估算结果的原理是：通过沟通共享信息，从而降低浪费。

一般而言浪费活动有两种：

1. 需求理解错误造成的浪费

在估算中，通过不同的人、不同侧面的问题，来抽丝剥茧发现需求的真相，可以有效避免这种浪费。

测试人员和开发人员共同估算，是一种弄清楚需求的常见方法。尤其是开发人员，由于经常深入内核，所以常常听到一点点需求，就想当然地理解为自己曾经想过的一个类似需求，然后急于思考实现方法。

2. 实现方法错误/重复造成的浪费

一种是重复代码，重新发明轮子……；

一种是错误实现，比如曾经有人由于不擅长使用“模板”（就是泛型），而把1个函数写成65个；

一种是蛮干，比如曾经有人为了图省事使用硬编码来实现码流打包拆包，结果码流在接下来的日子里不断变化，结果骑虎难下，2个月的工作因为质量低下而被扔掉，2周就重新设计编码结束了。

……

水平不同、负责不同部分的程序员充分沟通、共同估算可以避免这些情况。尤其是高手、老手，可以提醒新手避免犯错。

浪费与反浪费

必须意识到一点，尽管估算可以防止浪费，估算本身也要花费时间，因此要思考估算的效率。

提高效率的方法包括：

1. 若无必要，不牵涉太多人员进行估算

139团队是一种方法，就是如果我们有13个人，那么尝试分为3组，每组有4个人，这四个人是基本估算单元。他们应该负责相似的功能，平时也坐在一起，因此沟通起来比较顺畅。

2. 尝试使用较大的颗粒度

常常听说有敏捷开发实践者把任务且分到2小时左右的，甚至有0.5小时的。这里不直接说应不应该切分，而是提醒一下：4个人吵吵15分钟，就是1小时。我们可以花费1小时，但一定要知道获得了什么，如果真的值得，就去做；如果不值得，就换大一点的颗粒度。

3. 尝试更快速的估算方法

扑克牌估算就是一种很快速的方法了，因为如果出牌数字相同，基本上就不讨论了（如果第一次就相同，推荐让一个人说一下，其他人没有太大的不同意见就过）。

方案

分析清楚了，方案就比较好写了。

方案1最容易实现但效果也最不好，后面的则效果好但实施起来更费劲。

方案1

在完全一穷二白从来没有估算过的团队，如果他们本来业务也是各自负责一块，建议先以“技术相同”为条件拉几个人在一起估算；如果这几个人平时就坐在一起更好，可以在平时补充一些会上讲不到的地方。

在公开课课堂训练这种彻底“强分工”的环境下，我发现只要技术说的通，两家公司的人都可以在一起估算的，何况一个团队的小组内部。但前提是产品经理要能说明需求。

不过初期一定会发现估算很花时间，因为初次估算的时候很多背景知识都不知道，甚至那位直接负责此事的人也说不清楚，所以沟通的成本比较高。如果大家月月都花上一天讨论，很快就可以避免对基本背景知识的交流了。

刚开始的两三个月，不用太强求有何效果，大家互相理解了背景，就是个效果。

方案2

一点点建立有固定组织结构的小组，然后把估算组与小组绑定。

139团队是一种，其实即使简单任命一个小组长然后带领其他3～4个人开发某种东西，就可以称之为一个固定的小组了。

固定的小组应该开发相对接近的功能（技术是否相同反而次要），即使技术不同也可以从不同的角度提出自己的看法。有很多人认为，如果我不懂某个技术，就说不出来那部分的开发要多久，这个其实不对。如果我距离那个人不到5米远，我们在开发同一个模块的不同部分而已，他用的技术也不涉及广义相对论之类的很费解的内容，人们就没有理由对某个技术“说不什么意见出来”，尤其是小组的组长。

在01年的团队中，我们的25人的部门经理基本上参加过每个小组的开发，包括类似机顶盒这样的和PC完全不同的开发平台。当时机顶盒小组发现代码里边有一些难以处理的缺陷，他就过去“顺便帮忙”，结果是发现整个代码过于混乱，于是用了两周他就重构了整个机顶盒里边的代码结构，在C环境下实现了接近C++的面向对象结构。当然要做到这一点需要相当天才的人。但如果只在3～4个人的范围内，这件事情就不那么复杂，人才也不需要太好。

方案3

建立L型代码结构。L型代码结构具体情况请参考松结对编程系列中的相应文章（大约第9篇左右开始，当前有三篇）。

我现在和程序员也“分工”，估算虽然不做（现在只有两个人，沟通太多了所以前面提到的估算的第二个目的早实现了），但给他布置任务的时候，会讨论每个方法的实现方法。主要的讨论内容，是告诉他两样东西：

1. 整个业务过程类似我编写过的哪个部分，可以作为整体过程的参考（一般集中于View/Controller两个层面）。

2. 可能用到哪个底层类和函数（集中于Model，我们的Model库占总代码量的67%，多数是我在编写我的上层应用时顺便写的，他也做过维护）。

第二部门有时候我不会主动交流，因为看过1之后基本上就能看出来，有疑问时再交流。

L型代码给估算带来了几个变化：

1. L型代码的高层调用过程非常容易理解，因此关于“如何实现”的讨论比较简单，不用涉及太深的底层实现。

2. 很容易找到相似业务的模块做参考。

我们平均一个Controller大约有5～10个函数（比如“用户”的增删改查等操作：UsersControler.Index/Details/Create/BatchCreate/Delete/Freeze/Edit），每个函数的代码量是4～5行，所以如果要学另外一种东西的增删改查全过程，看完这50行代码就能大概了解整个过程了。

3. 由于底层库都用过，很容易找到使用样例（用IDE搜）。

4. 每次讨论的时候，会发现需要扩展一些底层库尚未实现的功能，无论谁最终实现它们，讨论过程两个人都知道要多这个功能了，对未来充分复用很有帮助。

不过，L型代码要彻底形成相对困难，对“顺便”产生底层库的人要求比较高。

当然最后一个问题：“你们不但不打牌，还甚至不估算，这算敏捷吗？”

怎么说呢，这么久以来，我们没有因为新人参加而发生重新发明轮子的事情，代码也没有因为新人来了而发生迅速增加或质量下降，人们知道代码中发生的几乎所有重大变化……目的达到了，过程就不重要了。

我参加了2012IT博客大赛，欢迎投票

2楼xfallingdacing3天前 14:07

有点受教了...目前学校里面6个人的小团队都搞不好呢...唉

1楼fengzi2009F5天前 21:11

不错，成本控制和风险控制很重要