场景1：一个5个人的小团队在开会，他们在对工作包进行时间的估算，他们每人手上一幅牌，牌上面是一些1/2,1，2，4，5这些数字。A:4,B:1+2,C:4+1/2,D:5...这样他们各自表达了自己对当前任务的开发时间的估计，由于每个人的善长点，考虑的点都不同，所以时间几乎不相同。然后组长在分别收集他们每人对当前讨论任务给出时间的依据，特别注意用时最长和用时最短的人的想法，最后他们沟通后找到一个折中的时间，如果其中有些成员想法没有统一，最后也只能双方妥协，听组长安排，比如A说，这个地方肯定会用2天的时间，B又说这个地方用不到，只要半天。双方都说了理由，但是最后还是没有改变两方的看法，最后队长说那我们用1.5天来完成吧。
场景2：团队前一段时间组合大家的意建把工作包时间估算出来了。现在是分派任务，然后就A做这几个，B做这几个，C做这几个……，或者是他们先自己选自己最想做的，最后来协调剩下的，总之最后是把所有的任务分到了每个人手上。
从上面两个场景来看，认是还是很和谐的场景。但是没有经过细想，仔细想这两个中都会存在一些问题。第一个场景里面听取大家的意建来估算时间，这一点很不错，但是最后又把一个任务时间强行落到一个时间上面，这里有些略微的不妥，不过目前能这样来估算时间的都是不错的了，更不用考虑其它的情况。然后看看第二个场景，确实坑爹了不少，以前真的见过一公司是把任务列出来，大家选，最后剩下的都是大家不原意做的，而且大家这样乱选你觉时间时没有大问题吗？反正这样做肯定不是最优的做法。
下面是本文提出的一种设想，同一活动节点下面多个工作包一起估算时间，也要考虑参与的人数，比如三个人做一个节点的工作，那么我们把下的工作包三个一组三个一组的分，尽量做成三个一组。那么我们估算时间的时候分别对三个工作包估算，比如工作包x，三个人A：2，B：3,C:3结果，当然这个过和同上面场景1是一样的效果，只是我们不急于去定死这个x包确定的时间。我们可以收集他们的意建，并公布，然后再来几次估算时间，是后得到一组比较折中的时间，但是我们不把这个确定成一个时间。那么最后我们出来的就是一个矩阵，然后我们再用匈牙利法求得最优解，这样子分配下去任务肯定最后时间是用得最少的方案。
这种方式的重点：
1.在大的节点下考虑，不用所有的成员都参与，只是要参与结点工作的人参与。这样每一个节点用时最后，项目的总体时间下来就最少。（这里说明一下，这里是用自下而上的方式，每个节点的时间少了，项目的总时间肯定少，但是不能说节点的时间缩短了，项目的工期就变短了）
2.按组来估时间，不确定到一个数字上面，保持大家对任务的意建和方案（这里也要说明，这不是成员说一个时间我们就保留这个时间，我们是在经过几轮下来确定的，也就是中间的难点，易点我们在过程中已经提出，大家也是清楚的情况下来保留的，这个点像德尔菲法）
3.最后就是要对这些数量还是较大的矩阵来求最优解。
到目前为止我认为我说得不是很清楚，这个只是一个初步的设像，主要灵感来源就是效率矩阵，平时我们任务分派中没怎么用上这些方法。然后再结果敏捷里面的一些方法综合得出。这种方法我认为是较好，但是过程中的投入会较大，主要是上面的2，3两点会用时比前面场景的方法要多一些，不过我认为多不了多少，第3点这个是由项目管理来做的，这也更能体现项目管理人员的价值所在，第2点我们也可以减少中间估时的轮数，代价也不是很大。相比直接分配，最终效果肯定是会更好的。
原文地址：http://www.cnblogs.com/gw2010/p/3696848.html
