令人烦恼的项目估算

 　对一个项目的评估，往往被要求在项目需求还不明确的时候开始。不知道你是否有这样的体会，客户给你简单介绍了一点需求，或者发给你一份写的很粗略的文档，就要求你给个价格看这东西大概是要花多少钱多少时间才能建成。以前我做网站的时候，遇到过好多好多的这类问题。

　　在软件开发过程中，总要面临一个"估算(Estimation)"的问题。这个项目需要多长时间？这个模块你大概多久完成？一共要花多少钱才能搞出来？软件开发的成本主常常用人月来计算，当然，也有人/小时，人/天。从数学上说，计算一个时间的先决条件，是必须要知道速率和距离。那软件开发度速率是多少？开发要走完的距离又怎么估计？

　　假定"人天"可以作为我们需要找到的速率(Velocity)的单位，就是某个人每天8小时能干的活的工作量，或说他的开发能力。对于一大堆待要开发的需求，它的总工作量和整个团队的单位开发能力的计算需要考虑更多的因素。

　　先来考虑需求的总量。我们来看这一个例子，列举你认识的满足下面条件的人：人，男人，20岁的男人，20岁的 头发有些染黄的男人，20岁的头发有些染黄抽烟的男人。从这一组词中，我们可以看到，从左到右描述的越来越具体，你能列举出的也越来越少。而反过来顺序，词的外延更大，你的能想到的却越来越多的。

　　同样的，对于需求的描述，如果描述的越细致，你就越能够准确的估算它的工作量。 登录系统，这样的需求很难说要多久。而一个使用用户名密码登录，支持找回密码功能的登录系统就稍微好一些。如果能够画出界面原型图那就更加清晰了。对于这样的需求，我们可以用"理想的人天"来评估。我们说某一个需求的成本，是2 Ideal Days。 就是一个人在理想的2天内能够完成这个工作。

　　说到开发人员的"理想的人天"，就不能离开团队孤立的看。一个团队包括项目经理和需求分析师、测试员等角色。他们的工作不直接反应到代码量的多少。如果只考虑一个项目开发人员的代码开发量成本，毫无疑问要亏损的。另外，团队成员水准参差不齐，不同的任务不同程序员来完成所花费的时间也不同。因此，单独相加每个成员的"人天"毫无意义。必须要整体考虑一个团队的总"人天"。

　　那么如何衡量一个团队的总"人天"？如果一个团队已经经过长期的磨合，那么可以从以往的数据来获得他们的开发量。 如果是新建立的团队，没有经过磨合，那就需要开始实际进行一段时间的开发，在开发后3-4个星期再回头来计算这几个星期的团队速率。一般的，一个团队经过一段时间的磨合，在开发速率上会有缓慢的提升。例如一个需求的估算是5理想人天，而团队实际开发了10天。那么团队的速率就是5理想人天，团队的负载系数，即正常被其他事情干扰而降低的比率是2。

　　有了这个团队的速率，项目经理就可以放心大胆的说，我们团队有10人，开发能力是"n理想人天每周"，负载系数是2，由于有20n的需求总量，我们大概在40周左右完成。因此，我们的报价是xx,xxx,xxx元。

　　如果你有幸长期跟踪过一个团队的开发速率，就会发现很多有趣的现象。一开始，团队速率很低，但慢慢的成长。到达一定时期后，就会稳定在一个固定值附近。有时候有新的成员加入进团队，团队的开发速率会出人意外的降低一段时间再慢慢回增。

　　成本、时间、范围、质量，这是项目管理常见的四要素，四者很难同时满足。如果关心时间，又不想出钱，还要完成那么多功能，那牺牲的就真正是质量了。常说的一分钱一份货，在软件开发中反映的淋漓尽致。所以，为了能够保证按时按质完成任务，一个合理的开发价格是合格的项目经理必须能够估算出来的。而这需要长期经验和实践的积累，急不来的。

　　但有些时候，也有些不好处理的问题。有人问：我是老板，如果我的开发团队合起伙来编造一个估算，把我的需求估算的很多，而把他们的速率估算的很低，工起来工作量不饱和，老消极怠工怎么办？呃。。我只能说，这只好借助于开发方法以外的事情了，例如奖金激励、绩效考核、引入外部咨询团队(例如ThoughtWorks)等等，人的问题不是能够简单靠过程就解决了的，如果道歉有用的话，要警察干嘛？