有哪些方法可以减轻“神话人月”的影响？

布鲁克斯定律： 为一个较晚的软件项目增加人力会使它变得更晚。

弗雷德里克·布鲁克斯（Frederick Brooks）在他的书《无银弹-软件工程的本质与事故》中定义了“ 神话人月”的概念：

Brooks的假设是，复杂的程序设计项目无法完美地划分为离散的任务，而这些任务无需工人之间的沟通，也无法在任务与执行它们的工人之间建立一套复杂的相互关系。

自1982年以来，我们无疑已取得了进步，并在减轻这一问题方面积累了更多经验。您在工作中成功应用了哪些解决方案以在不增加更多问题的情况下将资源添加到项目中？

什么是MMM

首先，我想解释布鲁克定律的背景。是什么让他在1975年创建的？

人工月是假设的工作单位，代表一个人在一个月内完成的工作；布鲁克斯定律说，不可能以人工作月来衡量有用的工作。

^{来源：https : //zh.wikipedia.org/wiki/The_Mythical_Man-Month}

过去，复杂的编程项目将意味着庞大的整体系统。Brooks声称，如果没有开发人员之间的交流，也没有在任务和执行任务的人员之间建立一套复杂的相互关系，就无法将这些任务完美地划分为多个任务。

在高度凝聚力的软件整体中，这是非常正确的。无论完成多少解耦，大型整体仍然需要新程序员学习该整体所需的时间。以及增加的通信开销，这将消耗越来越多的可用时间。

但是真的必须这样吗？我们是否必须编写巨著并将通讯渠道保持n(n − 1) / 2在n开发人员数量在哪里？

我们知道有一些公司，成千上万的开发人员正在从事大型项目……而且它确实有效。因此，自1975年以来，一定有一些变化。

减轻MMM的可能性

2015年，PuppetLabs和IT Revolution发布了2015年DevOps状态报告的结果。在该报告中，他们集中于高绩效组织与非高绩效组织之间的区别。

高绩效组织显示出一些意外的属性。例如，它们在开发中具有最佳的项目截止日期性能。最佳的操作稳定性和可靠性。以及最佳的安全性和合规性记录。

报告中突出显示的令人惊讶的事情之一是“每日部署”指标。他们不仅测量了每天的部署量，还测量了每天的部署量/开发人员数量，以及在高性能组织中增加更多开发人员与非高性能组织中的开发人员的影响。

这是该报告中的图表-

而绩效低下的组织则符合“神话人月”的假设。高性能组织可以根据开发人员的数量线性扩展部署/日/开发的数量。

Gene Kim 在2016年伦敦DevOpsDays的精彩演讲中谈到了这些发现。

怎么做

首先，如何成为一个高绩效的组织？有几本关于这个问题的书，在这个答案中没有足够的空间，所以我只链接到它们。

• 从优秀到卓越：为什么有些公司的飞跃......和别人不一样的吉姆·柯林斯
• 该高速边缘：如何市场领导者充分利用卓越运营打败竞争对手由史蒂芬矛
• 工业，政府，教育的新经济学 W. Edwards Deming

对于软件和IT组织而言，成为高性能组织的关键因素之一是：注重质量和速度。

例如，沃德·坎宁安（Ward Cunningham）将技术债务解释为我们允许未解决的所有问题。这是管理层所接受的，因为它总是带有在有时间时将其修复的承诺。

没有足够的时间，技术债务只会变得越来越糟。

这些是什么导致技术债务增加的？

• 遗留代码
• 手动配置环境
• 手动测试
• 手动部署

遗留代码正如Michael Feathers 在《有效使用遗留代码》中所定义的那样，它是没有自动测试的任何代码。

任何时候都使用快捷方式将代码投入生产；运营负担将永远维持下去。然后，部署过程变得越来越长。

吉恩在演讲中讲述了一个有关公司部署了六周时间的故事。涉及成千上万个极易出错的繁琐步骤，绑架了400人，他们每年将这样做四次。

DevOps的宗旨之一是可靠性来自更频繁地进行较小的部署。

例

• 乔恩·詹金斯（Jon Jenkins）在Velocity 2011上：亚马逊每天要进行1万5 千次部署
• Ken Exner在2015年AWS峰会上：亚马逊每天要完成13.6万次部署

这两个演示展示了亚马逊为减少将代码部署到生产所需的时间而做的所有事情。

根据Gene的说法，在这些高绩效组织中，唯一会随着时间变化的是开发人员的数量。因此，以亚马逊为例，您可以说他们在四年中仅通过增加人员就将部署增加了十倍。

这意味着在一定条件下，采用正确的体系结构，正确的技术实践，正确的文化规范，开发人员的生产力可以随着开发人员数量的增加而扩展。DevOps绝对处于所有这些中间。

我所做的（仅是主观的）如下：

当考虑到到期日的经理希望将更多的人员加入我的团队以减少所需的时间并且似乎在MMM的领导下，我首先与他或她讨论为什么这可能很糟糕。我对此的最喜欢的比喻是提醒他们，如果一个女人可以在九个月内生一个孩​​子，那么九个女人在一个月内就不会生一个孩子，但是他们在九个月内将有九个孩子。时间没有减少，只有并行处理更好。

当决定被强加给我们的团队时，我们通常尝试要么进一步划分一些任务，而在不可能做到这一点时，我们通常依赖于结对编程，其中一个程序员负责打字，另一个由程序员决定代码（并定期切换） ）。

代码编写本身较慢，但是由于编写时不可避免地需要进行审查，因此测试时的错字/掉毛和错误更少。我觉得整体代码质量也要好一些，但是我没有度量标准来支持这种说法。

仅从CI的角度来说，增加从事项目工作的开发人员的数量通常会转化为在同一分支机构工作的人员更多。

传统的CI系统在这方面存在可伸缩性问题：破损/回归/阻塞的可能性增加，会降低集成速度，并邀请较小的团队脱离并转移到子分支（即进一步减慢）。请参阅如何对大型项目/团队进行持续集成？。这沿《神话人月》的概念进行。

我在回答该问题时建议的解决方案是，高度可扩展的 CI系统将使向真正的CI的迁移成为可能-整个更大团队（即使规模庞大）的基于单个分支/主干的集成。

使用同一页面的每个人，使用相同的自动化工具/流程以及CI系统本身内部自动进行的大多数QA验证，在团队成员之间切换角色和集中精力变得更加容易。整个开发过程变得更加平滑，更可预测，更轻松​​。

因此，在这样的环境中带上新的员工，只需从经验丰富的团队成员中分出难度较低的任务，然后再承担更多困难的任务，就可以轻松地提高他们的生产力。

我相信，所有这些都可以看作是对《人月神话》概念效果的缓解。