分配给项目的人员数量与缺陷数量之间确实存在关系吗？

12

这是一本关于SLIM和软件评估的培训手册的引文：

还要注意，工作量和缺陷之间存在关联。这意味着，给定规模的项目分配给的人越多，缺陷就会越多。

工作量是项目的人事时间（人年，人月）。缺陷数是在生命周期中任何时候检测到的缺陷数。大小定义为组成项目的用例，功能点或SLOC。

假定过程良好且有能力的工程师，这似乎违反直觉。例如，拥有更多的人意味着更多地关注所有工件（需求规格，设计，代码，测试）。除了拥有更多的眼睛之外，我的直觉还表明，在使用适当质量技术的项目中，努力与缺陷之间几乎没有关系。

除了关于Putnam模型的文件（SLIM使用该文件）之外，我找不到任何文档，这些文档表明缺陷与工作量或缺陷与项目人数之间的任何已知关系。这是已知的关系吗？“更多的人=更多的缺陷”这一说法是否成立？

— 托马斯·欧文斯
source

10

“为一个较晚的软件项目增加人力将使其变得更晚”-Fred Brooks

— Oded

2

@Oded根本没有提到加人。同样，布鲁克斯法则对缺陷一无所知，而只是增加了沟通渠道，以制定决策并使人们了解情况。我会怀疑，就像卡尔·比勒费尔德（Karl Bielefeldt）所建议的那样，沟通困难可能导致缺陷。

— Thomas Owens

@ThomasOwens-是的，引用的确确实是关于沟通渠道的增加（以及由此带来的困难），并假设这会导致缺陷。

— Oded

我仍然要说，当大量开发人员投入到一个项目上时，它通常表示死亡的征兆。

— Morgan Herlocker 2011年

@ironcode项目的开发人员数量应由项目的大小和范围以及其组织方式决定。过多的开发人员或以后增加过多的开发人员是管理不善的征兆，也许是走向死亡的征兆。

— Thomas Owens

14

我的直觉是这样的：

分配给给定规模的项目的人员越多，沟通开销越大
=>误会和各种沟通问题的机会就越大
=>产生的缺陷数量也就越大。

和

优秀的开发人员比平庸/劣质的开发人员稀有，因此更难找到和雇用
=> 分配给给定规模项目的人员越多，他们的平均能力越低
=>产生的缺陷数量就越大。

但是这些可能只是我的推理，我没有任何支持证据。

顺便提一句，考虑到我们的职业状况，以下强调的假设非常强烈（恕我直言）：

假定过程良好且有能力的工程师，这似乎违反直觉。我的直觉表明，在采用适当质量技术的项目中，努力与缺陷之间几乎没有关系。

— 佩特·托克（PéterTörök）
source

我将麦康奈尔的“ Thrashing / Process / Productivity”图归因于此。如果您不介绍新朋友，您会早日习惯于项目中涉及的沟通开销，并且保持适当的沟通变得更加容易和自然。根据布鲁克斯定律，当您将人员延迟添加到项目中时，这种情况就分解了，这与项目后期引入流程相同–沟通渠道的增加意味着th动的增加和沟通的失败导致缺陷。不过，我可能对此不满意。您的推理可能是有效的。

— 托马斯·欧文斯

但是，随着人的减少，您不太可能让他们坚持自己的优势。雇用一些优秀的开发人员，如果他们可以专注于某个领域，而不只是一个可以做所有事情的专家，是否会更容易些？

— JeffO 2011年

@Jeff O，你有意思。OTOH如果每个开发人员只专注于自己的强项，那么他们之间的沟通可能会变得更加麻烦。

— 彼得Török

1

通讯是否更麻烦或只是必需？

— JeffO 2011年

@Jeff O，IMO，他们对彼此的领域了解得越少，就需要进行更多的交流，并且产生误解和错误假设的机会也就越大。

— 彼得Török

5

这可能只是一种关联。管理层倾向于分配更多的人来帮助他们认为将变得更加复杂的项目，或者由于大量不可逾越的错误而落后的项目，或者需要在各个组件之间进行大量耦合的项目。如果您不考虑管理决策，我怀疑这种关联至少会减少，甚至不会逆转。

— 卡尔·比勒费尔特
source

唯一的问题是没有提及人员配置随时间的变化（特别是增加）。它只是说如果您有一个n人的项目，那么您将有m个缺陷。增加人员确实会带来通信开销和问题，但是（据我所知）这超出了人与缺陷之间简单关系的范围。我确实同意，增加人员迟到的副作用不仅是沟通渠道的增加以及对人员的培训和使他们快速发展的需要（布鲁克斯定律），而且还可能增加缺陷。但这超出了范围。

— Thomas Owens

我提到的只是延迟添加人员的一个因素。管理仍具有分配更多的人倾向于前面到他们预期更加危险或复杂的项目。

— Karl Bielefeldt

SLIM（和其他评估工具，如果使用得当）的目的是帮助估计所需的人员，项目成本，所需的时间等。但是，这确实需要正确理解和使用该工具。

— Thomas Owens

3

鉴于最近更新的规模和工作量定义，我认为结果可能是由于以下事实：工作量（总工时）实际上是对实际项目规模的更好估算，而不是数据来源正在使用的量度（工作量为如果所有团队和团队的资源都相等，则是一个完美的衡量标准）。

因此，实际上发生的是大型项目具有更多缺陷，这一点也不奇怪。

— psr
source

2

假定过程良好且有能力的工程师，这似乎违反直觉。

我认为您无法在现实世界中假设其中任何一个。一个项目上的人越多，您就越有可能遇到不良苹果，这些苹果无法跟上，并会拖慢最好的开发人员。即使您遵循这些假设，但随着人数的增加，还有一些其他因素会使项目变慢并导致更多缺陷：

通讯开销
代码读取开销（通过这种方式，我的意思是，即使是最好的开发人员，也比他们自己花费更多的时间阅读和使用其他人的代码）
测试必须更彻底（我们全都争取100％的测试覆盖率，但这在现实世界中很少发生。您投入的项目越多，无需极其彻底的自动化测试，重构就越可怕，因为您只是希望自己所做的更改不会有副作用。并非所有测试都可以任何合理的方式进行自动化，这会花费更多时间。

以我的经验，当项目非常模块化且每个层只有1或2个人时，由开发人员加载的项目的负面影响就会大大降低。我不在乎您使用的是哪个版本控制系统，让4个开发人员一次将签入自动合并到同一文件中可能不是一个好主意。

— 摩根·赫洛克
source

如果阻止4个开发人员使用同一文件的唯一方法是将团队规模限制为3个，那么您会遇到更大的问题。

— JeffO 2011年

2

相关性和因果关系之间存在差异。引用似乎是说，对于分配了更多工程师的项目，缺陷总数往往会更高。这对我来说非常有意义，我确信MS Windows比我创建的应用程序具有更多的缺陷，但这并不意味着我的应用程序具有卓越的质量。

再举一个更抽象的例子-如果我们将每个国家的死亡总数与该国的医生总数相关联，我相信我们可以说“拥有更多医生的国家死亡人数更多”。这不是因为医生造成了死亡，而是因为大量的医生表明人口众多。

— 丹尼尔·B
source

对于Windows的示例，我确信Windows也会因为更大而有更多的缺陷机会。如果一个开发人员编写了一个系统，该系统是10 SLOC，一个系统是10000 SLOC，那么具有10000 SLOC的系统就有更大的机会出现缺陷（包括防止编译的错别字，分号丢失，逻辑错误等）。。通常，较大的项目将拥有更多的工程师，但关系不是人数和缺陷之间的关系，而是规模和缺陷之间的关系。

— Thomas Owens

@ThomasOwens-是的，这正是我的意思。

— Daniel B

为什么不将错误与项目的规模和复杂性进行比较？

— JeffO 2011年

@JeffO-相对地测量它是绝对不容易的（您到底是怎么做到的？）。也许最初的陈述是脱离上下文的，但是作者很少将复杂的，经过计算的结果简单地称为“缺陷”。在这种情况下，我会期望另一个词，例如“质量”（表示已进行了一些计算），或者更长的短语，例如“每个指派工程师的缺陷”。也许我对这里的作者有些愤世嫉俗:)

— Daniel B

@Jeff他们会的。但是，您可以将缺陷与规模和复杂性进行比较，而不是将人员数量进行比较。随着尺寸和复杂性的增加，缺陷也会增加，人数也会增加。所以是的，尽管人数确实增加了，但人数的增加并没有增加缺陷的数量。

— Thomas Owens

1

让我们暂时取消有关人数的主张。

只要您认为增加的工作量必然需要增加大小，就可以将注入的缺陷数作为工作量的函数来看是有意义的，因为缺陷数和软件大小之间存在很强的相关性。

因此，如果您假设投入到项目中的工作量越多，编写的代码行就越多，那么您就可以使用工作量作为规模的代理，以预测缺陷的数量。沃茨·汉弗莱（Watts Humphrey），Capers Jones等人的工作一次又一次地证明了尺寸（例如LOC）与缺陷数量之间的相关性。

我看不到人数多少，只是更多的人意味着更多的努力。

附带说明一下，不要将关联与因果关系混为一谈。尽管尺寸和注入缺陷的数量之间存在相关性，但尺寸不是原因。如您所指出的，原因通常来自人员和流程问题。也就是说，缺陷与尺寸的关系是了解是否存在问题以及衡量变更有效性的重要指标。

— 麦可
source

0

我假设这仅限于核心编程团队的成员，而不是诸如UI，UX，DBA等专家的情况。

我认为需要妥善管理，但这并不容易。由优质开发人员组成的小型团队可以自行管理。更有可能避免大段代码创建的人才较少。

拥有更多的团队成员可以使职责划分更加容易。将更好或更有经验的开发者放在困难地区。从您的优秀开发人员那里夺走一些平凡的或非编程任务，让初级开发人员处理中断。这将需要更多的计划和思考，但是提供了一个机会来利用您的才能。

有一种观点认为，有一个优秀的开发人员需要掌握新技能要比一个已经知道的低于平均水平的开发人员更好。如果您有时间，那太好了。可能将更多的开发人员分配给一个项目的原因可能是由于所需的工作量和时间限制。您可能会有可以专注于特定领域并变得更加熟练的人。拥有如此全面的知识非常棒，但是有时在没有太多指导的情况下，较少的开发人员可以接受一些指导并使用它。

现实情况是，没有多少人曾经在一个成功的项目中管理过一个大型团队。即使他们都很有才华，大型团队也很难自我管理。自我阻碍了吗？

— 杰夫
source