跳转到内容

布鲁克斯法则

维基百科，自由的百科全书

布鲁克斯法则（英语：Brooks's law）是人们关于软件项目管理的一种观点。根据这个观点，“在一个已经进度落后的软件项目上再增加人手只会使这个软件项目进度更加落后”[1][2]。这一观点是由佛瑞德·布鲁克斯在他1975年出版的《人月神话》一书中首先提出。根据佛瑞德·布鲁克斯的说法，在某些情况下，增加一个软件项目的人手只会花费更多的开发时间。

说明

布鲁克斯本人认为此法则“过于简化”[1]，但可以说明一些大致的情形。布鲁克斯认为布鲁克斯法则的原因是因为以下三点：

  1. 加入专案的人员需要一段时间后才会有生产力。布鲁克斯称此为ramp-up（英语：ramp-up）时间。软体计画是复杂的工程产物，在专案中的新成员需要接受训练，了解之前专案进行的情形，而训练就会分散可用在专案上的人力，在新成员还没有产出时，会暂时让专案的生产力下降。新成员除了会需要资深工程师花时间训练，减少其生产力外，还可能因不熟悉而增加程式的错误，让专案的进度后退。
  2. 随著人员增加，两两交流的数量也会快速增加（组合爆炸），沟通的成本也会增加[3]。进行相同工作的人员需要维持讯息同步，若越多人加入，维持讯息同步花的时间也会更多。
  3. 若是高度可分割的工作（像是清理旅馆客房），多加人力可以减少整体进行的时间。但软体专案中许多工作不容易分割，布鲁克斯用一个例子来来说明：一个孕妇九个月可以生下小孩，“但九个孕妇无法在一个月内生下一个小孩”。

例外以及可能的处理方式

在布鲁克斯法则中有些例外的部份，这也可能是可以避免布鲁克斯法则的处理方式[4][5]

第一点要注意到布鲁克斯法则是针对已经落后的专案[6]。若在专案开发的较早阶段加入人力，可能就可以让专案维持在时程内（或至少赶上时程）[7]。很重要是要确定专案是否真的落后了，或者只是专案一开始过于乐观所造成的。时间落后的专案时，大部份都是排程错误所导致的。若要让专案在一个有意义并且可靠的时间内完成，修正排程是最好的作法[8]

加入专案中人员的数量、品质以及其担任角色也是需要考虑的。若要避免落后的专案出现布鲁克斯法则，最简单的方式是加上够多的人，让增加的生产力可以补足训练以及沟通造成的生产力下降[9]。可以加入优良的程式设计者或是专家，以减少训练的时间[10]。也可以让加入的人员参与专案的其他工作，例如品质保证或是撰写文件，只要任务够明确，ramp up时间就可以减短[11]。

良好的分割也可以让团队成员为了沟通花的心力降到最低。较小的团队可以处理较小的子问题，再由最上层团队负责系统整合。若要以这种方式工作，一开始就要将问题以正确的方式进行分割，若分割的不正确，会让问题更恶化。会阻碍二个在不同团队，但其任务紧密耦合成员之间的沟通，就算在专案计划中这二个任务不是紧密耦合的，也是一样。

分割的例子就是设计模式，可以简化工作分散的情形，因为整个团队可以在设计模式的架构下，进行各自的工作。设计模式定义了程式设计者需要依循的规则，用标准语言简化沟通，并且提供一致性以及可扩展性。

“百慕达计划”（Bermuda plan）是指移除专案中大部份的开发者（送到百慕达），让剩下来的开发者完成软体，曾有人提出以此方式来避免布鲁克斯法则[12][13]。

相关条目

参考文献

  1. ^ 1.0 1.1 Frederick P. Brooks, Jr. 《人月神话》. 1995 [1975]. Addison-Wesley.
  2. ^ Maggie Fox NBC News, October 21, 2013, Better use the phone: Why Obamacare website is such a fail （页面存档备份，存于互联网档案馆）. Accessed Oct 21, 2013. "And sending in too many of the "best and the brightest’ might not be the right fix, either, software experts note. They often cite Brooks’s Law, which holds that adding people to a project slows it down."
  3. ^ James Taylor, "A Survival Guide for Project Managers", 2nd edition, AMACOM [需要解释], 2006, ISBN 978-0814408773, p. 21.
  4. ^ "In spite of Brooks's law, adding people to a late project remains commonplace" ... "I have evangelized this well-worn software engineering chestnut many times myself, but I no longer think it's true". (McConnell, 1999)
  5. ^ "The trouble is that there are important exceptions that many people do not take the time to consider when using Brooks's law to justify something". (Berkun, 2006)
  6. ^ "Implicit in those projects is that it applies only to the final phases of a project. The question is, How do you know whether you're in a project's final phases?" (McConnell, 1999)
  7. ^ "We have found that adding people to a late project will always increase its cost, but the project may not always be late since there may be sufficient schedule to absorb them and the project may not be at maximum staffing. Only under certain degree of sequential constraints among project tasks will the project be delayed." (Hsia, Hsu, Kung, 1999)
  8. ^ Late chaotic projects are likely to be much later than the project manager thinks – project completion isn't three weeks away, it's six months away. Go ahead and add staff. You'll have time for them to become productive. Your project will still be later than your plan, but that's not a result of Brooks's law. It's a result of underestimating the project in the first place." (McConnell, 1999)
  9. ^ "Gordon and Lamb studied Brooks's law and suggested that the best way to recover from a slipping schedule is to add more people than might be expected to be necessary, and to add them early." (Hsia, Hsu, Kung, 1999)
  10. ^ "The law assumes that all added labour is equal, which is not true. Given the choice of adding a good programmer, who knows the code base and is friends with half the team, I'd consider it." (Berkun, 2006)
  11. ^ "The sad but popular approach is to throw people in without much explanation and let everyone figure it out for themselves. But if the manager clarifies why Sally and Rupert are joining, and defines good roles for them, with input from the team, they'll be set up to make a smooth transition." (Berkun, 2006)
  12. ^ Shea, Tom. Developers Unveil 'Vaporware'. InfoWorld (InfoWorld Media Group). 7 May 1984, 6 (19): 48 [2010-04-13]. ISSN 0199-6649. 
  13. ^ Bruno, Eric J. Curly Braces #9: Was Fred Brooks wrong about late software projects?. Java Magazine. Oracle Corporation. 2023-02-06 [2024-03-18]. （原始内容存档于2024-01-19）. 
检索自“https://zh.wikipedia.org/w/index.php?title=布鲁克斯法则&oldid=83903410”