标签：style http color os io ar 2014 cti
译至：http://d.hatena.ne.jp/hyoshiok/20140813/p1
虽然摩尔法则比较有名（18个月半导体的性能翻番），但与之相比布鲁克斯法则大家对之知之甚少。
http://commons.wikimedia.org/wiki/File%3AFred_Brooks.jpg *1
布鲁克斯是上世纪60年代IBM System/360的操作系统OS/360的开发负责人，这之后基于当时的经验写了人月神話
这是描述大规模软件开发难度的一本划时代的书。如果是IT从业人员是必读的一本书。软件开发人员或是项目管理者的话，听我一句话，读一读比较好。我的日记里也介绍了好几次。
先不谈人月神话的第二章，看下面的示例。有这样一个项目需要12个人月，这样3个人4个月就能完成该任务。然后，每个月设定观测点A/B/C/D。
但是一个月就要结束的A结果花了两个月完成。这相比于预估时已经是两个月之后了。这怎么办？管理者有下面的对策。
那么，应该采用什么方法呢。最开始的二个方法，不修改工作目标和工作进度表的话最初４个月完成目标的期望就破灭了。
假如追加２个人，这两人的培训成本，３人完成的工作用５个来做，就需要重新安排工作，这些成本没有被追加到估算中，结果的话最终期限无法完成。追加６个人的情况，这种成本加的更多。
这就是布鲁克斯法则。「追加人员到延迟的项目更会影响项目的进度」
如布鲁克斯所写的那样，无法按进度完成工作的话，只能降低工作目标作業。
这是软件产品开发中５０年前发现的法则现在也是正确的。但是，几乎所有的开发者都不了解布鲁克斯法则，就算知道也不会去实践。
给延迟的项目加了就像是火上浇油。不理解这个法则的各位要好好的读一下人月神话。不管如何听我一句好好读读。作为项目管理在做决定前的共识，大家都要好好读读。推荐在此之上根据每个项目的特殊性来调整作业。
你的上司读过人月神话吗？试着问一下看看。
标签：style http color os io ar 2014 cti
原文地址：http://blog.csdn.net/robertsong2004/article/details/38558405
