如何估算项目进度才靠谱？

在项目开始之时，软件项目经理就会组织估计专家根据用户需求和项目团队的能力，制定开发计划。但是，这时的开发计划并不准确，因为即使项目的范围清楚，也明确了项目的任务活动，可是项目团队的开发速率也可能是错误的估计。

团队开发速率估计错误，必然导致项目进度估计错误。

项目早期估计团队开发速率，只能根据团队历史上的经验数据而定。但是，每个项目的具体情况千差万别（如开发环境、复杂度、利益相关方的配合等），其他项目的经验未必适用于当前项目。项目团队在别的项目上的生产率能够达到10Loc/人日，在这个项目可能连2Loc/人日都不到。

而且项目开发过程中会遇到什么意料之外的事情也很难预料。团队在一帆风顺的情况下的开发速率与各种意外频发时的开发速率会有天壤之别。

假如某软件项目估计规模1000Loc，团队上个项目的开发速率10Loc/人日，早期计划100天内完成开发进行交付。在项目开始10天，一切都按计划进行，软件进度完成1/10；接下来10天，出现了几个意外事件（有团队成员生病，有新的更为紧急任务要团队成员投入进去等等），导致团队开发速率下降到5Loc/人日，这个时候如果有领导问你项目何时能交付，你会如何回答：比原计划推迟5天，45天，还是按计划完成？

因为存在变数，其实任何一个答案都不是准确的。

相对合理的做法是参考极限编程的“昨日天气”。

所谓的“昨日天气”，就是只有刚刚发生的天气才是真实的，被认可的，将来的天气谁也无法预测，我们能做的只是使用我们刚刚获得的经验。

极限编程估计下一个迭代的生产率的做法是假定它不会超过上一个迭代刚刚结束的实际生产率。

所以，我们估计项目进度时，可以将项目划分为若干个短周期，每完成一个短周期就测量一次团队开发速率，以这个速率来测算项目进度。如果这个周期不是太长也不是太短，团队开发速率在统计学上是可信的，那么由此估算的项目进度也是可信的。

这正是：

进度估算难准确，变数太多无话说

昨日天气可借鉴，进度可信靠谱多

参考书目：项目百态：深入理解软件项目行为模式，作者：(美)Tom DeMarco等，译者：金明，出版社：人民邮电出版社