问题是敏捷开发千零一问系列的第27篇。 【此处提问、之一、之二、之三、提问总目录】来自问题帖15楼http://blog.csdn.net/cheny _ com/article/details/7564388
原始问题摘录如下：
开发组中可能同时进行若干专业开发的，有人参加这个专业，不参加其他专业。 特朗普的报价中，对于某个特定项目的任务，怎么办？ 所有开发团队都参加评估吗？ 还是这个特定项目的利益相关者参加？ 一个专家可能一两个人做，但据专业估算，和单独磕头没有太大区别。 大家一起估算的话，存在效率低的问题；
分析估计的目的是什么？ 估算之前，一个非常重要的问题是估算的原因或目的是什么？
估算有很多理由，但实际上有些东西经不起推敲，或者遇到喜欢耍赖的人，就很难反驳。 例如：
1 .为了知道可以完成多少行代码(用代码行估算时)。
棒头(不管知道不知道是1000行，数完就1000行，为什么要提前估算呢？ (这是我八年前被问到的问题)
2 .为了制定计划，为了知道要多久才能完成。
杠杆，我们的计划都是要违背的，领导说什么时候，我们做什么时候，估计有什么价值？
.
那么，不缺或有价值的估计是什么呢？ 大致有两种。
1. 在报价/合同发生之前的估算
在此期间完成报价，您就可以了解业务计划。 即使“被迫签约”，也要“记在心里”。
这是初步的成本估计，稍后将详细讨论，请参阅http://blog.csdn.net/cheny _ com/article/details/7672333。
2. 能改善结果的估算
以前以为需要1000行——，如果直接做了还真的需要1000行，结果发现如果报价结束后是100行的话，就值得报价了。
以前我以为需要——天，直接做也真的需要100天，但估计结束后发现10天就值得了。
这是特朗普估算的最佳应用场景。
预备活动http://www.Sina.com/http://www.Sina.com /
一般来说，徒劳的活动有两种。
原理
测算中，通过各种人、各方面的问题，拔茧发现需求真相，可以有效避免这种浪费。
测试人员和开发人员共同估算是阐明需求的常用方法。 特别是开发人员，由于经常深入内核，所以他们希望通过询问一些小需求，将其理解为自己预想的那样的需求，并急于考虑实现方法。
估算能改善估算结果的原理是：通过沟通共享信息，从而降低浪费。
一是重复编码，重新发明车轮……；
一个是错误的实现，例如不擅长使用“模板”=泛型)，有人写了65个函数。
一个是野蛮行为。 例如，曾经有人为了省事，使用硬编码实现了码流的打包拆包。 结果，码流在第二天不断变化。 结果，骑虎难下，两个月的工作因质量下降而被丢掉，两周内代码的重新设计就结束了。
.
负责不同级别、不同部分的程序员充分沟通、共同估算，可以避免这些情况。 特别是强壮的棒棒糖和老手，可以提醒初学者避免失误。
1. 需求理解错误造成的浪费要有一点意识，尽管估算可以避免浪费，但估算本身也需要时间，考虑估算的效率。
提高效率的方法如下。
2. 实现方法错误/重复造成的浪费
139支队伍是一种方法，如果我们有13个人，试着分成三组，每组4个人，这4个人是基本的报价单元。 他们应该负责类似的功能，平时也坐在一起，所以沟通很顺畅。
浪费与反浪费
我经常听说敏捷开发实践者把任务分成2小时左右，也有人0.5小时。 请注意，这里不是直接说是否应该挂断，而是4个人吵15分钟的话就是1个小时。 我们可以花一个小时，但我们必须知道我们得到了什么。 如果真的有价值的话，我会试试； 如果没有价值的话，请换成大一点的粒度。
1. 若无必要，不牵涉太多人员进行估算
特朗普的估算是一种快捷的方法。 因为如果出牌数字相同的话，基本上就不讨论了(如果一开始就相同的话，建议让一个人说，其他人不要发表太多意见)。
方案分析清楚了，方案就容易写了。
方案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型代码要彻底形成相对困难，对“顺便”产生底层库的人要求比较高。
当然最后一个问题：“你们不但不打牌，还甚至不估算，这算敏捷吗？”
怎么说呢，这么久以来，我们没有因为新人参加而发生重新发明轮子的事情，代码也没有因为新人来了而发生迅速增加或质量下降，人们知道代码中发生的几乎所有重大变化……目的达到了，过程就不重要了。