人月神话札记：时间和人力

- 日理万妓 2021-09-10 11:46 296阅读 0赞

**前言**：美食的烹饪需要时间，那么稍等片刻，你将享用更多的美味。缺乏合理的进度安排是造成项目滞后的重要原因，因素有以下内容：  
\- **对估算技术缺乏有效的研究**  
\- **进度和工作量混淆，就是说人员和时间可以转换**  
\- **对自己的估算缺乏信心**  
\- **缺乏信心**  
\- **对进度缺少跟踪和监督，所以站立会和燃尽图至关重要**  
\- **意识到进度偏移时，第一个反应是增加人力，而这时大多数情况如同火上浇油，火越来越大，需要的汽油却越来越多**

--------------------

## 乐观主义 ##

书中说，编程人员都是乐观主义者，我想，在国内，需求者比编程人员更“乐观”，他们引导设计者和架构师走上极端的左倾主义。我存有一种愿景就是，希望未来需求者能够考虑足够的风险，树立一种观念就是每一项任务不仅仅是花费它“应该”花费的时间。  
对于创造者来说，只有在实现的过程中，才能发现构思的不完整性和不一致性。也就是说，我们去做1.0版，意义重大，1.0版能够帮助我们更好的去反思我们的设计。  
作为我们程序员来说，“一切都会完美的运行”几乎是不可能的，从我们自身来说，当我们写完代码后，必须要抱着怀疑的态度，去检查我们创造的代码，减少bug。

## 人月 ##

人员和时间不能在所有场所内进行替换。

*  对于像割小麦的任务中，人员和时间可以相互转换，增加人手，必定能减少割麦子的时间。
 *  对于像母亲孕育孩子的过程中，必须要经历10月怀胎，这是无法进行分解的。
 *  对于需要沟通可以分解的任务，其人员和时间的关系图，在人员增加到一定程度上时，需要的时间不会再减少
 *  对于关系错综复杂的任务，其人员的增加在一定程度上还会增加时间的投入，这个是最可怕的。

从实际的开发经验中，可以得出，软件开发是错综复杂的过程，那么没有弄清楚效率降低、进度延迟的真正原因时，盲目的追求人员的增加会让事情更糟。

## 系统测试 ##

系统测试的时间在大多数的软件开发中，系统测试被开发团队忽略，往往很多时候，开发人员做完自己的代码后，就将测试工作丢给测试人员，这种现象我之前有所描述，见[小型团队的测试该何去何从][Link 1]这篇文章中，我介绍了这个可怕的现象，而其解决办法竟然是增加人员。  
没有合理的规划系统测试时间的话，就会带来可怕的后果，因为系统测试往往是在产品发布之前，这个时候再出现延误，代价太高。

## 空泛的估算 ##

大多数情况下，产品经理或者项目经理和客户的关系就如同蛋糕师和顾客的关系，蛋糕的烹制过程会受到顾客紧迫程度的影响。假如顾客催促蛋糕师，那么蛋糕师可能做出两种选择，第一个就是继续按照自己的进度，让顾客等待，这样可能失去顾客；第二个是加大火力，这样蛋糕就可能出现问题。

## 重复产生的进度灾难 ##

当任务没有按照原定计划执行时，就出现延期，假如出现在项目进展的第一个阶段，项目经理发现了进度延缓的问题，那么假如说他盲目的增加人手来试图缩短产品研发时间的话，就必然会重复进入到灾难的陷阱中。  
增加人手会带来严重的问题，原来的开发人员需要拿掉开发的时间来培训**新的人员，这样同时又将原来的进度延缓，假如再增加人手，就会进入到万劫不复的灾难中**。

> 作者有如下结论“**Adding manpower to a late sofeware project makes it latter**.”

那么我们该如何正确做出改变呢？

*  重新安排进度，也就是说分配充足的时间，来确保完整的解决项目。
 *  削减任务，如果项目延期导致的二次开发成本非常高，那么这是必要的。
 *  然而增加人手，这个决策是可怕的。

**总结**：项目的时间依赖于顺序上的限制，而人员的最大数量依赖于独立子任务的数量。如何把握人员数量和进度之间的关系是至关重要的。

[Link 1]: http://blog.csdn.net/qing_gee/article/details/43634971%20%E5%B0%8F%E5%9E%8B%E5%9B%A2%E9%98%9F%E7%9A%84%E6%B5%8B%E8%AF%95%E8%AF%A5%E4%BD%95%E5%8E%BB%E4%BD%95%E4%BB%8E