chapter 2 人月神话

乐观主义
所有的编程人员都是乐观主义者。…
“这次她肯定会运行的”
“我刚刚找到了最后一个错误”
人月
第二个谬误是在估计和进度安排中使用的工作单位﹣人月。暗示着时间和人员可以相互替换。
在对于任务分解上，看似越多的人会减少个人工作的时间，实则不然，人员的增多会导致其他方面诸如培训和交流之间的开销的增加，导致很快会消耗掉任务分解所节省下来的时间，有时未必会减少时间。不要妄图以减少时间为目的进行相关的人员方面的变动，或是项目上的调整，提速是可以的，但是首先不要贪心，其次记住欲速则不达。不是人越多效率越高。
系统开发的时间安排
1／3 计划
1／6 编码
1／4 构件测试和早期系统测试
1／4 系统测试，所有构件已完成
需要特别指出的是，不为系统测试安排足够的时间简直就是一场灾难
虽然从理论上来说，在系统开发的过程中错误的数量的确应该为0，事实上我们永远都不可能做到，甚至尽量减少到最低也是很难的，在测试的时候就需要花上更多的时间，虽然未必会找到最后一个bug，但是总比花的时间少要来的好得多…
当项目进度落后之后你会怎么做？作为项目经理，亚力山大啊…如果增加人手，可能造成的风险会滚雪球一样增长，通常项目管理会因为人的因素而增加太多的不确定性，这个是特别难估计的部分，或许这就是为什么项目经理也是越老越吃香的原因，可以通过经验来进行项目初期的预算估计以及项目计划的制定，但是，当有新的技术手段出现时，使用经验进行估算显然是不是用的，那么有没有一个优秀的估算模型进行计划的制定呢？？？
简化Brooks的法则：向进度落后的团队增加人手，只会让进度更加落后。