项目完成时间与开发人员数量之间反向关系的具体替代方案？

Question

背景

现在人们很清楚(如果不是总是很好地沟通)，以下逻辑不适用于软件开发项目估计数：

A project that would take 1 developer 12 days,
               would take 2 developers 6 days,
               would take 3 developers 4 days,
               etc.

或者像弗雷德·布鲁克斯在“神秘的男人月”中雄辩地说的那样，

九个人一个月不能生一个孩子。

当然，造成这种情况的因素有几个，包括必然的顺序性任务、更困难的沟通等等。

从数学上讲，该模型等价于表示项目完成时间T与指定开发人员N的数量有关。

T = E/N

其中，E是一个单独开发人员完成项目所需的时间。

问题

在项目完成时间T与指定开发人员N的数量之间是否还有其他建议的关系

1. 可以用一个相当简洁的数学方程来表示；
2. 与来自实际软件项目的数据相比(或者至少比T = E/N更有利)吗？

引用支持的答案优先考虑。谢谢!

Answer 1

你说的是软件评估。

在软件评估方面有开创性的典型参考文献是Barry的“软件工程经济学”和Tom的“控制软件项目”。

博姆的书是你开始的地方，即使它有35年的历史。他最大的贡献是：(1)认识到估计方程本身是非线性的；(2)使用大量项目的实际数据来校准估算方法；(3)认识到某些因素，如工具、团队能力和进度压缩或扩展，将改变估计的工作量。)压缩时间表，总工时就会增加。扩大日程，总工时就会增加。

第一步是估计工作量，比如工时或工作日。第二步是将工时估计转化为名义的估计时间表，通常以天、周或月为单位，并以名义的团队规模为单位。第三步是修改工时估计，使用一些人所称的高效率蝙蝠(又称高级管理人员，或销售或市场营销)所规定的实际时间表。

德马尔科最大的贡献是一个“不可能的区域”的想法:有些日程根本是不可能实现的，不管你向他们扔了多少具身体，不管他们有多好。

在Boehm的书出版后不久，通用动力堡沃斯分部采用了他的方法，并根据自己的实际数据为F-16软件开发校准了自己的估值器。然后，每次他们估计F-16软件修改任务时，他们都会押注公司的底线。

我与COCOMO的第一次接触是在我在那里的时候:在一个内部项目中，我发现Boehm的“数字中的一击”方法得出了一个与我的直觉相当接近的估计值，我对此感到非常惊讶。

当我看到人们使用线性估计器(“每人每天10行”，或类似的)时，我感到非常沮丧，甚至在Boehm的书出版35年后的今天也是如此。

一旦浏览了Boehm的书，就可以查看更新：COCOMO II软件成本估算。最初的COCOMO，从1981年左右开始，并没有扩展到“更现代化”(翻译为:很多倍大)项目。

在你消化了以上三本书之后，你就可以看看史蒂夫·麦康奈尔的软件评估:黑色艺术的神秘化了。不要直接跳过麦康奈尔的书。

Answer 2

我认为你的假设有点错误。

我相信，人们普遍认为，增加新的开发人员确实加快了开发速度，但这只是在一定程度上。这一点通常被认为大约有5个开发人员。在此之后，正如您所假设的那样，通信开销和缺少可并行的任务要么不会缩短时间，要么甚至会增加时间。

如果我像你一样引用一个“神秘的男人月”，布鲁克斯建议一个开发模型，其中团队由5-7个开发人员组成，然后这些团队是“更大的团队”的一部分，其中只有来自每个团队的选定代表相互交流。这使通信开销保持在较低的水平，同时允许大量开发人员从事项目工作。