软件工程管理——《人月神话的读书笔记》(chapter2~chapter10)

chapter 2 人月神话

 
 
 

  
  
  乐观主义
所有的编程人员都是乐观主义者。…
“这次她肯定会运行的”
“我刚刚找到了最后一个错误”
人月
第二个谬误是在估计和进度安排中使用的工作单位﹣人月。暗示着时间和人员可以相互替换。

 
 
 
在对于任务分解上，看似越多的人会减少个人工作的时间，实则不然，人员的增多会导致其他方面诸如培训和交流之间的开销的增加，导致很快会消耗掉任务分解所节省下来的时间，有时未必会减少时间。不要妄图以减少时间为目的进行相关的人员方面的变动，或是项目上的调整，提速是可以的，但是首先不要贪心，其次记住欲速则不达。不是人越多效率越高。

 
 
 

  
  
  
系统开发的时间安排
1／3 计划
1／6 编码
1／4 构件测试和早期系统测试
1／4 系统测试，所有构件已完成
需要特别指出的是，不为系统测试安排足够的时间简直就是一场灾难

 
 
 
虽然从理论上来说，在系统开发的过程中错误的数量的确应该为0，事实上我们永远都不可能做到，甚至尽量减少到最低也是很难的，在测试的时候就需要花上更多的时间，虽然未必会找到最后一个bug，但是总比花的时间少要来的好得多…
 
 
 
当项目进度落后之后你会怎么做？作为项目经理，亚力山大啊…如果增加人手，可能造成的风险会滚雪球一样增长，通常项目管理会因为人的因素而增加太多的不确定性，这个是特别难估计的部分，或许这就是为什么项目经理也是越老越吃香的原因，可以通过经验来进行项目初期的预算估计以及项目计划的制定，但是，当有新的技术手段出现时，使用经验进行估算显然是不是用的，那么有没有一个优秀的估算模型进行计划的制定呢？？？

 
 
 

  
  
  
简化Brooks的法则：向进度落后的团队增加人手，只会让进度更加落后。
 
 
 

思考，”The Cathdral and the Bazaar”一文中提到的关于开源软件的管理方式是违背了Brooks法则的，但是仍旧能够成功，为什么？？？？

chapter 3 外科手术队伍

 
 
 

  
  
  

这些研究表明，效率高和效率低者之间个体差异非常大，经常能够达到数量级的水平。
Mills的建议
大型项目的每一个部分有一个团队来解决，但是该队伍以类似外科手术的方式组建，并非一拥而上

10人程序开发队伍的沟通模式

 
 
 
其实现在的大多数团队都是采用了这种开发方式进行开发，但是正如作者所提出的问题一样，如何组建一个大规模的团队是最重要的事情，并且，如果逐层按照小型队伍的组建方式进行大型队伍的建立，那么在决策阶段不可避免会产生冲突，如何解决此种冲突矛盾？如何协调各个小型团队之间的工作进度以及团队交流？