ACM通信
最短时间表定理:是的，你可以在软件的截止日期上砸钱
一些流传在软件工程领域的民间智慧，常常被愚蠢地重复了几十年，是错误的。当它影响到软件开发的关键方面并且与可靠的科学证据相矛盾时，它可能具有特别的破坏性。目前的讨论涵盖了一个满足这两个条件的问题:向项目中增加人员以缩短交付时间是否有意义。
我的目标是推广一个在软件工程文献中广为人知的结果，可以追溯到Barry Boehm[1]的早期工作，Steve McConnell在他2006年出版的关于软件成本估算[2]的书中以“最短可能的时间表”的名字进行了非常清晰的解释。虽然这是一个经验而非逻辑的结果，但我相信它值得被称为一个定理(McConnell回避使用这个术语)，因为它是我们在软件工程管理领域中最接近于一个普遍属性的东西，这已经被大量的实验研究证实了。
这篇文章没有提供新的概念，因为麦康奈尔的第20章已经说明了所有关于这个主题的内容;我的目的很简单，就是让最短可能时间表定理更广为人知，特别是对从业者来说。
关于缩短项目时间的神话始于一个明显正确的观察，至少在极端情况下是正确的。每个人都知道，如果我们的项目已经通过公认的成本估算技术进行了评估，那么一年需要三个开发人员，我们不可能神奇地雇佣36个人在一个月内完成它。生产力并不总是会扩大。
但常识也是如此。从之前的琐碎观察中得出的结论往往采用了“布鲁克斯定律”的形式:在一个较晚的项目中增加人员会进一步拖延它。原因是，新员工的沟通费用比实际贡献要高。布鲁克斯的其他一些语录人月神话尽管经受住了时间的考验，但我一直认为，这条法律描述的是糟糕管理的定义，而不是任何实际的法律。当然，如果你一直把人们扔在截止日期前，你只会增加沟通问题，让事情变得更糟。但是如果你是一个有能力的经理，扩大团队规模是你可以使用的工具之一，可以用来改善项目的状态，剥夺你自己的能力是愚蠢的。20年前，麦康奈尔也发表了一篇对这一假想法律的明确驳斥。
尽管布鲁克斯的声明受到了应有的批评，但它至少在范围上是有限的:它针对的是为一个已经延迟的项目增加人员。在软件项目的任何阶段，将它应用到更普遍的成本估计和人员配置问题上甚至是错误的。40年的陈词滥调在这里的份量更小。正如麦康奈尔的书所显示的，成本估算不再是一种魔法。它也不是一门精确的科学，但是存在产生可靠估计的技术。
最短可能时间表定理是最有趣的结果之一。比布鲁克斯所谓的定律有趣得多，因为它是有实证研究支持的(而不是要求我们相信一个人的精辟论断)，它提供了一个积极的结果，而不是一个普遍的负面观点，并对该结果进行了限制;两者都是定量表达的。
图1给出了SPS定理的一般思想。大意;图2将提供一个更精确的视图。
图1:最短可能时间表定理的一般视图。
“名义项目”是产生最优点的成本和进度估算的结果。这个图和这个定理给项目经理提供了一个高兴的理由和一个绝望的理由:
- 庆幸的是:通过投入更多的钱，即更多的人(在软件工程中，项目成本本质上是人员成本[4])，你可以更快地实现代码。
- 绝望:无论你做什么，你能获得的时间都有一个明确的限制:25%。它似乎是软件工程的一种通用常数。
“绝望”部分通常在一开始最受关注，因为它为钱能买多少软件(可以说)设定了一个绝对值:无论你怎么努力，你永远不会得到低于名义(最优)价值的75%的结果。图1中的“不可能区域”表达了基本的限制。这种消极的结果就是对古老的民间“法”的理性而精确的现代替代。
然而，积极的一面也同样重要。75%空的杯子也有25%满。如果项目经理意识到，再多的额外人力也不能保证更高的管理层在时间上减少25%以上，那么他可能会感到失望。但同样重要的是要知道，只要有适当的资金、适当的人员、适当的工具和适当的管理技能，这种并非微不足道的削减实际上是可以实现的。最后一点很关键:光有钱是不够的，你需要管理;如前所述，布鲁克斯定律主要是对……效应的观察坏管理。
图1只包含了基本思想，并不是为了提供精确的数值。图2是McConnell书中的原始图。它绘制了时间与工作量的关系，而不是相反，但更重要的是，它显示了几条曲线，每条曲线都对应于书中调查的一项已发表的实证研究或成本模型。
图2:最短时间表的原始插图
([3]图2-20，经作者许可转载)
在标称点的左边，曲线显示，根据每项研究，成本的增加如何导致时间的减少。他们在细节上有所不同:项目需要花多少钱，可以最大限度地减少多少。但他们都同意“最短可能时间表”的基本结果:支出可以减少时间，最大减少不超过25%。
这个数字也为另一个自然产生的问题提供了一个答案，尽管这个答案令人失望。到目前为止，我们的讨论假设时间是关键资源，我们准备花更多的钱来更快地推出产品。但有时情况恰恰相反:关键资源是成本，或者具体地说，是开发人员的数量。假设名义分析告诉我们，该项目将需要4名开发人员投入1年时间，并相应地花费60万美元(选择你的货币)。我们只有40万的预算。我们是否可以通过雇佣更少的开发者而减少花费，并接受这将需要更长的时间?
在这方面，在图2中名义点的右侧，McConnell的调查显示没有达成共识。一些研究和模型确实导致了成本的降低，另一些研究表明，随着时间的增加，成本实际上也会增加。(以下是我的解释，基于我的经验而不是任何系统的研究:你确实可以用一个较小的团队在较长的时间内实现最初的目标;但对最终成本的影响可能有所不同。如果新的时间为t'= t + t，新的团队规模为s'= s - s, t和s为名义值，则成本差异与t - t' s成正比。它可以是积极的，也可以是消极的，这取决于原始t和s的值，以及团队规模减少对项目持续时间的精确影响。)
然而，确切的结果是图的左边部分。最短可能进度定理证实了优秀的项目经理所知道的:在有限的范围内，您可以通过召集所有人来缩短交付时间。准确的版本应该广为人知。
参考文献
[1] Barry W. Boehm:软件工程经济学，普伦蒂斯·霍尔，1981年。
[2]史蒂夫·麦康奈尔:软件评估揭秘黑艺术，微软出版社，2006。
[3]史蒂夫·麦康奈尔:布鲁克斯定律废除,在IEEE软件第16卷第1期。6，第6 - 8页，1999年11月至12月。
这是一个公认的观点，尽管有人可能希望这个行业除了人以外，更关注工具的投资。
Bertrand Meyer是瑞士苏黎世联邦理工学院(ETH Zurich)的软件工程(荣誉退休)教授，埃菲尔铁塔的软件(Goleta, CA)，米兰理工大学(意大利)教授，俄诺波利斯大学(俄罗斯)软件工程实验室负责人。
评论
钱德拉塞卡红桉
Bertrand Meyer关于最短时间表的文章是一篇有趣的文章。读起来又好又干脆。
我有几点看法，因此提出以下评论:
(1)通过将所提出的内容作为一个定理(在教育学的意义上)提出，就可以期望得到一个同样的证明。如果可能的话，请分享有助于证明所讨论观点的方向/指针
而且
(2)是否存在任何约束、项目类型或复杂性、标准化因素和无形实体——这些因素会影响在得出这一定理时所考虑的任何项目的“执行”部分?如果有，请分享。
通常，一个时间表是一个时间表——有一个确定的开始日期和一个确定的结束日期，由所有利益相关者事先商定。如果这个定理考虑了所有可能的时间表，并得出一个特定的时间表——通过逻辑演绎的方式，并证明一个特定的时间表是所有时间表中最短的(可以在这个和使用可用工具进行管理的项目的“关键路径”之间进行类比)——我认为这增加了强调要点的本质。
谢谢,
钱德拉红桉
迈克尔山药
我把布鲁克斯的神话人月理论放在所有管理时尚之上，但你的帖子让我查阅了麦康奈尔的《布鲁克斯定律被废除了吗?》: https://stevemcconnell.com/articles/brooks-law-repealed/
好吧，迈耶教授和麦康奈尔说服了我，布鲁克斯定律不是零阶逼近真理，但我不会说该定律被废除了。
以下是我对布鲁克斯和麦康奈尔对话的想象:
麦康奈尔:项目延期了，我们需要再增加两个人。
布鲁克斯:那没用的!
麦康奈尔:(耸耸肩)不会有什么坏处。
在当前项目中添加晚期人员的真正好处是，他们将在随后的“清理”版本中真正提供帮助，前提是您的公司不是那种一旦项目完成就会抛弃大部分员工的公司。
显示所有2评论