Brooks法则就是一种实践，应用很全面、严密的方法来描述组织之流程、信息系统、人员和组织子单元的当前或未来结构，方便其与组织的核心目标和战略方向保持一致性。
中国的故事三个和尚没水吃,厨师太多做坏汤。同样,软件程序员太多也会产生更多问题,这些问题超出了程序员的解决能力。
Brooks是北罗莱纳大学计算机科学教授,他阐述了所谓的Brooks法则：为推迟的软件增加人力将使得软件时间发布更晚。
Brools教授解释说,这是因为后来者需要加快速度,同时还要与前任进行沟通,从而使得开发团队增加了更多的开发时间,这个时间超过了新增程序员所做的贡献。
从理论上说,软件发展陷入僵局是可能的,此时开发团队极其庞大,以致所有时间都来互相沟通和重新决定,这样项目永远也不会完成。
另一方面,Brooks教授写道,灾难来源于漏洞。
温馨提示：答案为网友推荐，仅供参考
第1个回答 2009-07-13
首先简单给您介绍一下Brooks法则。
brooks法则：它是一种实践，应用全面、严密的方法来描述组织之流程、信息系统、人员和组织子单元的当前或未来结构，以便其与组织的核心目标和战略方向保持一致。
正如“三个和尚没水吃，厨师太多做坏汤。”同样，软件程序员太多也会产生更多问题，这些问题超出了程序员的解决能力。
Brooks是北罗莱纳大学计算机科学教授，他阐述了所谓的Brooks法则：为推迟的软件增加人力将使得软件时间发布更晚。 这是因为后来者需要加快速度，同时还要与前任进行沟通，从而使得开发团队增加了更多的开发时间，这个时间超过了新增程序员所做的贡献。从理论上说，软件发展陷入僵局是可能的，此时开发团队极其庞大，以致所有时间都来互相沟通和重新决定，这样项目永远也不会完成。
下面再详细说明一下这个法则的应用：
Frederick P. Brooks，Jr.是北卡罗来纳大学Kenan-Flagler商学院的计算机科学教授。Brooks被认为是“IBM 360系统之父”，他担任了360系统的项目经理，以及360操作系统项目设计阶段的经理。凭借在上述项目的杰出贡献，他、Bob Evans和Erich Bloch在1985年荣获了美国国家技术奖（National Medal of Techology）。早期，Brooks曾担任IBM Stretch和Harvest计算机的体系结构师。
在查布尔希尔，Brooks博士创立了计算机科学系，并在1964至1984年期间担任主席。他曾任职于美国国家科技局和国防科学技术委员会。Brooks目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境。
导致项目滞后的原因：
首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设——一切都将运作良好。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。
第二点中提到的关于人月不可互换。举个例子就是说：有一个10人月工作量的项目不能单纯的分配个5个人用2个月的时间来完成。因为程序员在工作当中还需要交流的时间，各子项目间还可能会有依赖关系，因此本来10人月的项目分配给5个人之后，它的实际成本就提升了。
有人可能会说一个人做就可以了，但为了节省时间，在规定的时间里完成项目，还是需要团队合作的。
第三点：为了更有效的实施这一点，我们需要使用一个版本控制工具，比如说：SVN。还需要设置检查点，里程碑，以及基线，从而准确的跟踪项目进度。
第五点：当项目延后而增加人手，导致的结果却是负面的。为了按期完成任务而增加新人，你需要从原来的项目组中调配人员来培训新人，而且根据第二点，人员的增多，无形中也加大了任务开销，最后导致项目难以控制。
项目开发中可能有的问题：
• 系统测试时间分配不够
• 空泛的估算
• 重复产生的进度灾难
(1) 对于软件任务的进度安排，以下是brooks使用了很多年的经验法则：
1/3计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试，所有的构件已完成
在许多重要的方面，它与传统的进度安排方法不同：
1. 分配给计划的时间比寻常的多。即便如此，仍不足以产生详细和稳定的计划规格说明，也不足以容纳对全新技术的研究和摸索。
2. 对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。
3. 容易估计的部分，即编码，仅仅分配了六分之一的时间。
特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生在项目快完成的时候。直到项目的发布日期，才有人发现进度上的问题。因此，坏消息没有任何预兆，很晚才出现在客户和项目经理面前。
另外，此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。在此之前，项目已经配置了充足的人员，每天的人力成本也已经达到了最大的限度。更重要的是，当软件用来支持其他的商业活动（计算机硬件到货，新设备、服务上线等等）时，这些活动延误出现即将发布前，那么将付出相当高的商业代价。
（2）为了在客户期望的日期内完成项目，项目经理会进行一些不合理的安排非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的直觉，这样的方式很难生产出健壮可靠和规避风险的估计，从而导致广泛估计这个错误。
解决的方法有：
1. 开发生产率图表，缺陷率，估计规则等，也就是在项目开始之前做一比较详细的项目评测和项目计划，应该就是软件工程的需求阶段所要做的事情。
2. 在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，确信自己的经验和直觉总比从期望派生出的结果要强得多
（3）重复产生的进度灾难其实就是上一章中的第五点，当项目进度落后时向项目组增加人手。
当项目落后时，项目经理可以选择的方案有哪些捏，下面细细道来：
1. 添加人手。这种方法是不可取的。现在举一个例子，比如一个12人月的项目，分配给3个人在4个月内去完成,但实际上在第二个月末才完成3人月的工作量。因此还剩下9人月的项目，也就是每个月要完成4.5人月的工作。此时项目经理可能会增加2个新人来完成。但实际上需要原项目组的人员来培训新人，现在假设需要一个月的时间。因此在第三个月末，还剩下7人月的工作量，而实际可以投入工作的只有5人月。因此在不考虑交流成本扩大的情况下，至少需要增加4个人，那么就是一个7+的团队。并且小组的组织和任务的划分在类型上都不尽相同，这已经不是程度上的差异问题。由此可见在项目前期有充足的人手分配，以及详细的项目计划是多么的重要。（当然在中国的软件公司中还是会要求员工靠加班来加快进度，呵呵，这里不加考虑。）
2. 重新安排进度，在新的进度安排中分配充分的时间，以确保工作能仔细、彻底地完成，从而无需重新确定时间进度表。
3. 削减任务。在现实情况中，一旦开发团队观察到进度的偏差，总是倾向于对任务进行削减。当项目延期所导致的后续成本非常高时，这常常是唯一可行的方法。项目经理的相应措施是仔细、正式地调整项目，重新安排进度；或者是默默地注视着任务项由于轻率的设计和不完整的测试而被剪除。
简单、武断地重复一下Brooks法则：
向进度落后的项目中增加人手，只会使进度更加落后（Adding manpower to a late software project makes it later）。
项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能会过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
希望上述回答对您有所帮助！
brooks法则：它是一种实践，应用全面、严密的方法来描述组织之流程、信息系统、人员和组织子单元的当前或未来结构，以便其与组织的核心目标和战略方向保持一致。
正如“三个和尚没水吃，厨师太多做坏汤。”同样，软件程序员太多也会产生更多问题，这些问题超出了程序员的解决能力。
Brooks是北罗莱纳大学计算机科学教授，他阐述了所谓的Brooks法则：为推迟的软件增加人力将使得软件时间发布更晚。 这是因为后来者需要加快速度，同时还要与前任进行沟通，从而使得开发团队增加了更多的开发时间，这个时间超过了新增程序员所做的贡献。从理论上说，软件发展陷入僵局是可能的，此时开发团队极其庞大，以致所有时间都来互相沟通和重新决定，这样项目永远也不会完成。
下面再详细说明一下这个法则的应用：
Frederick P. Brooks，Jr.是北卡罗来纳大学Kenan-Flagler商学院的计算机科学教授。Brooks被认为是“IBM 360系统之父”，他担任了360系统的项目经理，以及360操作系统项目设计阶段的经理。凭借在上述项目的杰出贡献，他、Bob Evans和Erich Bloch在1985年荣获了美国国家技术奖（National Medal of Techology）。早期，Brooks曾担任IBM Stretch和Harvest计算机的体系结构师。
在查布尔希尔，Brooks博士创立了计算机科学系，并在1964至1984年期间担任主席。他曾任职于美国国家科技局和国防科学技术委员会。Brooks目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境。
导致项目滞后的原因：
首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设——一切都将运作良好。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。
第二点中提到的关于人月不可互换。举个例子就是说：有一个10人月工作量的项目不能单纯的分配个5个人用2个月的时间来完成。因为程序员在工作当中还需要交流的时间，各子项目间还可能会有依赖关系，因此本来10人月的项目分配给5个人之后，它的实际成本就提升了。
有人可能会说一个人做就可以了，但为了节省时间，在规定的时间里完成项目，还是需要团队合作的。
第三点：为了更有效的实施这一点，我们需要使用一个版本控制工具，比如说：SVN。还需要设置检查点，里程碑，以及基线，从而准确的跟踪项目进度。
第五点：当项目延后而增加人手，导致的结果却是负面的。为了按期完成任务而增加新人，你需要从原来的项目组中调配人员来培训新人，而且根据第二点，人员的增多，无形中也加大了任务开销，最后导致项目难以控制。
项目开发中可能有的问题：
• 系统测试时间分配不够
• 空泛的估算
• 重复产生的进度灾难
(1) 对于软件任务的进度安排，以下是brooks使用了很多年的经验法则：
1/3计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试，所有的构件已完成
在许多重要的方面，它与传统的进度安排方法不同：
1. 分配给计划的时间比寻常的多。即便如此，仍不足以产生详细和稳定的计划规格说明，也不足以容纳对全新技术的研究和摸索。
2. 对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。
3. 容易估计的部分，即编码，仅仅分配了六分之一的时间。
特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生在项目快完成的时候。直到项目的发布日期，才有人发现进度上的问题。因此，坏消息没有任何预兆，很晚才出现在客户和项目经理面前。
另外，此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。在此之前，项目已经配置了充足的人员，每天的人力成本也已经达到了最大的限度。更重要的是，当软件用来支持其他的商业活动（计算机硬件到货，新设备、服务上线等等）时，这些活动延误出现即将发布前，那么将付出相当高的商业代价。
（2）为了在客户期望的日期内完成项目，项目经理会进行一些不合理的安排非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的直觉，这样的方式很难生产出健壮可靠和规避风险的估计，从而导致广泛估计这个错误。
解决的方法有：
1. 开发生产率图表，缺陷率，估计规则等，也就是在项目开始之前做一比较详细的项目评测和项目计划，应该就是软件工程的需求阶段所要做的事情。
2. 在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，确信自己的经验和直觉总比从期望派生出的结果要强得多
（3）重复产生的进度灾难其实就是上一章中的第五点，当项目进度落后时向项目组增加人手。
当项目落后时，项目经理可以选择的方案有哪些捏，下面细细道来：
1. 添加人手。这种方法是不可取的。现在举一个例子，比如一个12人月的项目，分配给3个人在4个月内去完成,但实际上在第二个月末才完成3人月的工作量。因此还剩下9人月的项目，也就是每个月要完成4.5人月的工作。此时项目经理可能会增加2个新人来完成。但实际上需要原项目组的人员来培训新人，现在假设需要一个月的时间。因此在第三个月末，还剩下7人月的工作量，而实际可以投入工作的只有5人月。因此在不考虑交流成本扩大的情况下，至少需要增加4个人，那么就是一个7+的团队。并且小组的组织和任务的划分在类型上都不尽相同，这已经不是程度上的差异问题。由此可见在项目前期有充足的人手分配，以及详细的项目计划是多么的重要。（当然在中国的软件公司中还是会要求员工靠加班来加快进度，呵呵，这里不加考虑。）
2. 重新安排进度，在新的进度安排中分配充分的时间，以确保工作能仔细、彻底地完成，从而无需重新确定时间进度表。
3. 削减任务。在现实情况中，一旦开发团队观察到进度的偏差，总是倾向于对任务进行削减。当项目延期所导致的后续成本非常高时，这常常是唯一可行的方法。项目经理的相应措施是仔细、正式地调整项目，重新安排进度；或者是默默地注视着任务项由于轻率的设计和不完整的测试而被剪除。
简单、武断地重复一下Brooks法则：
向进度落后的项目中增加人手，只会使进度更加落后（Adding manpower to a late software project makes it later）。
项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能会过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
希望上述回答对您有所帮助！
第2个回答 推荐于2016-01-29
首先简单给您介绍一下Brooks法则。
brooks法则:它是一种实践，应用全面、严密的方法来描述组织之流程、信息系统、人员和组织子单元的当前或未来结构，以便其与组织的核心目标和战略方向保持一致。
正如“三个和尚没水吃，厨师太多做坏汤。”同样，软件程序员太多也会产生更多问题，这些问题超出了程序员的解决能力。
Brooks是北罗莱纳大学计算机科学教授，他阐述了所谓的Brooks法则:为推迟的软件增加人力将使得软件时间发布更晚。 这是因为后来者需要加快速度，同时还要与前任进行沟通，从而使得开发团队增加了更多的开发时间，这个时间超过了新增程序员所做的贡献。从理论上说，软件发展陷入僵局是可能的，此时开发团队极其庞大，以致所有时间都来互相沟通和重新决定，这样项目永远也不会完成。
下面再详细说明一下这个法则的应用:
Frederick P. Brooks，Jr.是北卡罗来纳大学Kenan-Flagler商学院的计算机科学教授。Brooks被认为是“IBM 360系统之父”，他担任了360系统的项目经理，以及360操作系统项目设计阶段的经理。凭借在上述项目的杰出贡献，他、Bob Evans和Erich Bloch在1985年荣获了美国国家技术奖（National Medal of Techology）。早期，Brooks曾担任IBM Stretch和Harvest计算机的体系结构师。
在查布尔希尔，Brooks博士创立了计算机科学系，并在1964至1984年期间担任主席。他曾任职于美国国家科技局和国防科学技术委员会。Brooks目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境。
导致项目滞后的原因:
首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设——一切都将运作良好。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。
第二点中提到的关于人月不可互换。举个例子就是说:有一个10人月工作量的项目不能单纯的分配个5个人用2个月的时间来完成。因为程序员在工作当中还需要交流的时间，各子项目间还可能会有依赖关系，因此本来10人月的项目分配给5个人之后，它的实际成本就提升了。
有人可能会说一个人做就可以了，但为了节省时间，在规定的时间里完成项目，还是需要团队合作的。
第三点:为了更有效的实施这一点，我们需要使用一个版本控制工具，比如说:SVN。还需要设置检查点，里程碑，以及基线，从而准确的跟踪项目进度。
第五点:当项目延后而增加人手，导致的结果却是负面的。为了按期完成任务而增加新人，你需要从原来的项目组中调配人员来培训新人，而且根据第二点，人员的增多，无形中也加大了任务开销，最后导致项目难以控制。
项目开发中可能有的问题:
• 系统测试时间分配不够
• 空泛的估算
• 重复产生的进度灾难
(1) 对于软件任务的进度安排，以下是brooks使用了很多年的经验法则:
1/3计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试，所有的构件已完成
在许多重要的方面，它与传统的进度安排方法不同:
1. 分配给计划的时间比寻常的多。即便如此，仍不足以产生详细和稳定的计划规格说明，也不足以容纳对全新技术的研究和摸索。
2. 对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。
3. 容易估计的部分，即编码，仅仅分配了六分之一的时间。
特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生在项目快完成的时候。直到项目的发布日期，才有人发现进度上的问题。因此，坏消息没有任何预兆，很晚才出现在客户和项目经理面前。
另外，此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。在此之前，项目已经配置了充足的人员，每天的人力成本也已经达到了最大的限度。更重要的是，当软件用来支持其他的商业活动（计算机硬件到货，新设备、服务上线等等）时，这些活动延误出现即将发布前，那么将付出相当高的商业代价。
（2）为了在客户期望的日期内完成项目，项目经理会进行一些不合理的安排非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的直觉，这样的方式很难生产出健壮可靠和规避风险的估计，从而导致广泛估计这个错误。
解决的方法有:
1. 开发生产率图表，缺陷率，估计规则等，也就是在项目开始之前做一比较详细的项目评测和项目计划，应该就是软件工程的需求阶段所要做的事情。
2. 在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，确信自己的经验和直觉总比从期望派生出的结果要强得多
（3）重复产生的进度灾难其实就是上一章中的第五点，当项目进度落后时向项目组增加人手。
当项目落后时，项目经理可以选择的方案有哪些捏，下面细细道来:
1. 添加人手。这种方法是不可取的。现在举一个例子，比如一个12人月的项目，分配给3个人在4个月内去完成，但实际上在第二个月末才完成3人月的工作量。因此还剩下9人月的项目，也就是每个月要完成4.5人月的工作。此时项目经理可能会增加2个新人来完成。但实际上需要原项目组的人员来培训新人，现在假设需要一个月的时间。因此在第三个月末，还剩下7人月的工作量，而实际可以投入工作的只有5人月。因此在不考虑交流成本扩大的情况下，至少需要增加4个人，那么就是一个7+的团队。并且小组的组织和任务的划分在类型上都不尽相同，这已经不是程度上的差异问题。由此可见在项目前期有充足的人手分配，以及详细的项目计划是多么的重要。（当然在中国的软件公司中还是会要求员工靠加班来加快进度，呵呵，这里不加考虑。）
2. 重新安排进度，在新的进度安排中分配充分的时间，以确保工作能仔细、彻底地完成，从而无需重新确定时间进度表。
3. 削减任务。在现实情况中，一旦开发团队观察到进度的偏差，总是倾向于对任务进行削减。当项目延期所导致的后续成本非常高时，这常常是唯一可行的方法。项目经理的相应措施是仔细、正式地调整项目，重新安排进度；或者是默默地注视着任务项由于轻率的设计和不完整的测试而被剪除。
简单、武断地重复一下Brooks法则:
向进度落后的项目中增加人手，只会使进度更加落后（Adding manpower to a late software project makes it later）。
项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能会过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
brooks法则:它是一种实践，应用全面、严密的方法来描述组织之流程、信息系统、人员和组织子单元的当前或未来结构，以便其与组织的核心目标和战略方向保持一致。
正如“三个和尚没水吃，厨师太多做坏汤。”同样，软件程序员太多也会产生更多问题，这些问题超出了程序员的解决能力。
Brooks是北罗莱纳大学计算机科学教授，他阐述了所谓的Brooks法则:为推迟的软件增加人力将使得软件时间发布更晚。 这是因为后来者需要加快速度，同时还要与前任进行沟通，从而使得开发团队增加了更多的开发时间，这个时间超过了新增程序员所做的贡献。从理论上说，软件发展陷入僵局是可能的，此时开发团队极其庞大，以致所有时间都来互相沟通和重新决定，这样项目永远也不会完成。
下面再详细说明一下这个法则的应用:
Frederick P. Brooks，Jr.是北卡罗来纳大学Kenan-Flagler商学院的计算机科学教授。Brooks被认为是“IBM 360系统之父”，他担任了360系统的项目经理，以及360操作系统项目设计阶段的经理。凭借在上述项目的杰出贡献，他、Bob Evans和Erich Bloch在1985年荣获了美国国家技术奖（National Medal of Techology）。早期，Brooks曾担任IBM Stretch和Harvest计算机的体系结构师。
在查布尔希尔，Brooks博士创立了计算机科学系，并在1964至1984年期间担任主席。他曾任职于美国国家科技局和国防科学技术委员会。Brooks目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境。
导致项目滞后的原因:
首先，我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设——一切都将运作良好。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆。
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。
第四，对进度缺少跟踪和监督。其他工程领域中，经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓的举动。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。
第二点中提到的关于人月不可互换。举个例子就是说:有一个10人月工作量的项目不能单纯的分配个5个人用2个月的时间来完成。因为程序员在工作当中还需要交流的时间，各子项目间还可能会有依赖关系，因此本来10人月的项目分配给5个人之后，它的实际成本就提升了。
有人可能会说一个人做就可以了，但为了节省时间，在规定的时间里完成项目，还是需要团队合作的。
第三点:为了更有效的实施这一点，我们需要使用一个版本控制工具，比如说:SVN。还需要设置检查点，里程碑，以及基线，从而准确的跟踪项目进度。
第五点:当项目延后而增加人手，导致的结果却是负面的。为了按期完成任务而增加新人，你需要从原来的项目组中调配人员来培训新人，而且根据第二点，人员的增多，无形中也加大了任务开销，最后导致项目难以控制。
项目开发中可能有的问题:
• 系统测试时间分配不够
• 空泛的估算
• 重复产生的进度灾难
(1) 对于软件任务的进度安排，以下是brooks使用了很多年的经验法则:
1/3计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试，所有的构件已完成
在许多重要的方面，它与传统的进度安排方法不同:
1. 分配给计划的时间比寻常的多。即便如此，仍不足以产生详细和稳定的计划规格说明，也不足以容纳对全新技术的研究和摸索。
2. 对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。
3. 容易估计的部分，即编码，仅仅分配了六分之一的时间。
特别需要指出的是，不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生在项目快完成的时候。直到项目的发布日期，才有人发现进度上的问题。因此，坏消息没有任何预兆，很晚才出现在客户和项目经理面前。
另外，此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。在此之前，项目已经配置了充足的人员，每天的人力成本也已经达到了最大的限度。更重要的是，当软件用来支持其他的商业活动（计算机硬件到货，新设备、服务上线等等）时，这些活动延误出现即将发布前，那么将付出相当高的商业代价。
（2）为了在客户期望的日期内完成项目，项目经理会进行一些不合理的安排非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的直觉，这样的方式很难生产出健壮可靠和规避风险的估计，从而导致广泛估计这个错误。
解决的方法有:
1. 开发生产率图表，缺陷率，估计规则等，也就是在项目开始之前做一比较详细的项目评测和项目计划，应该就是软件工程的需求阶段所要做的事情。
2. 在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，确信自己的经验和直觉总比从期望派生出的结果要强得多
（3）重复产生的进度灾难其实就是上一章中的第五点，当项目进度落后时向项目组增加人手。
当项目落后时，项目经理可以选择的方案有哪些捏，下面细细道来:
1. 添加人手。这种方法是不可取的。现在举一个例子，比如一个12人月的项目，分配给3个人在4个月内去完成，但实际上在第二个月末才完成3人月的工作量。因此还剩下9人月的项目，也就是每个月要完成4.5人月的工作。此时项目经理可能会增加2个新人来完成。但实际上需要原项目组的人员来培训新人，现在假设需要一个月的时间。因此在第三个月末，还剩下7人月的工作量，而实际可以投入工作的只有5人月。因此在不考虑交流成本扩大的情况下，至少需要增加4个人，那么就是一个7+的团队。并且小组的组织和任务的划分在类型上都不尽相同，这已经不是程度上的差异问题。由此可见在项目前期有充足的人手分配，以及详细的项目计划是多么的重要。（当然在中国的软件公司中还是会要求员工靠加班来加快进度，呵呵，这里不加考虑。）
2. 重新安排进度，在新的进度安排中分配充分的时间，以确保工作能仔细、彻底地完成，从而无需重新确定时间进度表。
3. 削减任务。在现实情况中，一旦开发团队观察到进度的偏差，总是倾向于对任务进行削减。当项目延期所导致的后续成本非常高时，这常常是唯一可行的方法。项目经理的相应措施是仔细、正式地调整项目，重新安排进度；或者是默默地注视着任务项由于轻率的设计和不完整的测试而被剪除。
简单、武断地重复一下Brooks法则:
向进度落后的项目中增加人手，只会使进度更加落后（Adding manpower to a late software project makes it later）。
项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能会过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
相似回答