chapter 2 人月神话
在对于任务分解上,看似越多的人会减少个人工作的时间,实则不然,人员的增多会导致其他方面诸如培训和交流之间的开销的增加,导致很快会消耗掉任务分解所节省下来的时间,有时未必会减少时间。不要妄图以减少时间为目的进行相关的人员方面的变动,或是项目上的调整,提速是可以的,但是首先不要贪心,其次记住欲速则不达。不是人越多效率越高。乐观主义 所有的编程人员都是乐观主义者。… “这次她肯定会运行的” “我刚刚找到了最后一个错误” 人月 第二个谬误是在估计和进度安排中使用的工作单位﹣人月。暗示着时间和人员可以相互替换。虽然从理论上来说,在系统开发的过程中错误的数量的确应该为0,事实上我们永远都不可能做到,甚至尽量减少到最低也是很难的,在测试的时候就需要花上更多的时间,虽然未必会找到最后一个bug,但是总比花的时间少要来的好得多… 当项目进度落后之后你会怎么做?作为项目经理,亚力山大啊…如果增加人手,可能造成的风险会滚雪球一样增长,通常项目管理会因为人的因素而增加太多的不确定性,这个是特别难估计的部分,或许这就是为什么项目经理也是越老越吃香的原因,可以通过经验来进行项目初期的预算估计以及项目计划的制定,但是,当有新的技术手段出现时,使用经验进行估算显然是不是用的,那么有没有一个优秀的估算模型进行计划的制定呢???系统开发的时间安排 1/3 计划 1/6 编码 1/4 构件测试和早期系统测试 1/4 系统测试,所有构件已完成 需要特别指出的是,不为系统测试安排足够的时间简直就是一场灾难简化Brooks的法则:向进度落后的团队增加人手,只会让进度更加落后。
思考,”The Cathdral and the Bazaar”一文中提到的关于开源软件的管理方式是违背了Brooks法则的,但是仍旧能够成功,为什么????
chapter 3 外科手术队伍
其实现在的大多数团队都是采用了这种开发方式进行开发,但是正如作者所提出的问题一样,如何组建一个大规模的团队是最重要的事情,并且,如果逐层按照小型队伍的组建方式进行大型队伍的建立,那么在决策阶段不可避免会产生冲突,如何解决此种冲突矛盾?如何协调各个小型团队之间的工作进度以及团队交流?这些研究表明,效率高和效率低者之间个体差异非常大,经常能够达到数量级的水平。 Mills的建议 大型项目的每一个部分有一个团队来解决,但是该队伍以类似外科手术的方式组建,并非一拥而上 10人程序开发队伍的沟通模式