人月神话札记之人月神话

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

乐观主义

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

人月

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

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

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

系统测试

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

空泛的估算

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

重复产生的进度灾难

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

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

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

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

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