自1982年以来，我们无疑已经取得了进步，并在缓解此问题方面积累了更多经验。您在工作中成功应用了哪些解决方案，以在不增加更多问题的情况下为项目添加资源。
#1 楼
什么是MMM首先，我要解释布鲁克定律的上下文。是什么让他在1975年创建的？
人月是一个假设的工作单位，代表一个人在一个月内完成的工作；布鲁克斯定律说，不可能用人工来衡量有用的工作。
资料来源：https://en.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上的精彩演讲谈到了这些发现。
如何做
首先，如何成为一个高绩效的组织？有几本关于这个问题的书，在这个答案中没有足够的空间，所以我只链接到它们。
从优秀到优秀：为什么有些公司成功飞跃...吉姆•柯林斯（Jim Collins）所不具备的其他优势
高端优势：市场领导者如何利用卓越运营来击败竞争对手史蒂芬•斯皮尔
W. Edwards Deming的《工业，政府，教育经济学》
对于软件和IT组织而言，成为高效组织的关键因素之一是：关注质量和速度。
例如，沃德·坎宁安（Ward Cunningham）解释了技术债务，因为我们允许所有未解决的问题。这是管理层所接受的，因为它总是承诺在有时间的时候将其解决。
没有足够的时间，技术债务变得越来越差。
这些是什么导致技术负担增加的？
旧版代码
环境的手动配置
旧版代码Michael Feathers在有效地使用旧版代码中定义的任何代码都没有自动测试。
任何时候都使用快捷方式将代码投入生产；运营负担将永远维持下去。然后部署的过程变得越来越长。
Gene在他的演讲中讲述了一个有关公司部署了六周时间的故事。 DevOps涉及成千上万个极易出错的繁琐步骤，最多可容纳400人，而他们每年都会这样做四次。
DevOps的宗旨之一是可靠性来自于更频繁地进行较小的部署。
示例
乔恩·詹金斯（Jon Jenkins）在Velocity 2011上：亚马逊每天要进行15,000次部署
Ken Exner在2015年AWS峰会上：亚马逊每天要完成13.6万次部署
这两个演示文稿展示了亚马逊为减少部署时间所进行的所有工作从代码到生产。
根据Gene，在这些高性能组织中，唯一随时间变化的是开发人员的数量。因此，以亚马逊为例，您可以说他们在四年中仅通过增加人员就将部署增加了十倍。
这意味着在特定条件下，采用正确的架构，正确的技术实践，正确的文化规范，开发人员的生产力可以随着开发人员数量的增加而扩展。而且DevOps绝对是这一切的中间。
#2 楼
我所做的事情（仅是主观的）如下：当经理在考虑到期日时希望增加人员加入我的团队以减少所需的时间并且看来在MMM的领导下，与他或她讨论为什么这可能不好。我对此的最喜欢的比喻是提醒他们，如果一个女人可以在九个月内生一个孩子，那么九个女人在一个月内就不会生一个孩子，但是他们在九个月内将有九个孩子。时间没有时间，只有并行处理更好。
当决定权决定在我们的团队中时，我们通常尝试进一步划分一些任务，而当这不可能时，我们通常依靠在结对编程中，一个程序员负责打字，而另一个程序员则负责编码（并定期切换）。
代码编写速度较慢，但由于测试时错字/掉毛和错误较少，因为写作时不可避免的审查。我觉得整体代码质量也好一点，但是我没有度量标准来支持这种说法。
评论
我喜欢结对编程的想法。这实际上可以有所帮助。我也许能够根据后来的理论来解释为什么以后要这么做。
–吉里·克劳达（Jiri Klouda）
17 Mar 4 '17 5:31
请做，等待！
– Peter Muryshkin
17年6月8日在10:58
#3 楼
完全从CI的角度来说，增加项目开发人员的数量通常会转化为在同一分支机构工作的人更多。传统的CI系统在这方面存在可伸缩性问题：破损的可能性/ regressions / blockages增加会减慢集成速度，并邀请较小的团队休息并转到子分支（即，进一步减速）。请参阅如何对大型项目/团队进行持续集成？这与《神话人月》的概念完全吻合。团队（即使规模巨大）。
在同一页面上的每个人，使用相同的自动化工具/过程以及CI系统本身内部自动进行的大多数QA验证，在团队成员之间切换角色和集中精力变得更加容易。整个开发过程变得更加顺畅，更可预测，更轻松。因此，更困难的事情也变得更容易。
我认为所有这些都可以缓解“人月神话”概念的影响。
评论
在高性能组织中，增加更多的开发人员通常意味着创建更多独立的团队来编写解耦的软件。这样可以使更多的人实现更多更快的成就。让它们都通过单个集成分支进行通信是一种反模式，并且很可能会大大降低速度。
– Evgeny Zislis
17 Mar 4 '17 at 10:05
让他们都通过单个集成分支进行通信是一种反模式-为什么？如果在不再需要集成工作的意义上解耦，那么他们将以一种不重叠/不冲突的方式接触分支。如果仍然需要整合他们的工作，那么通过偏离CI方法并失去其所有优势，其他分支机构将延迟整合并使整合复杂化。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 5 '17 at 6:44
我认为我们不同意“分支”的含义。拥有一个带有单个分支（git或svn）的大型存储库是很好的，并且会承担每个人在同一存储库上工作的开销。也可以有多个存储库，其中每个存储库都有一个分支来跟踪特定的解耦服务。取决于工具，它增加了提交和签出代码的开销。
– Evgeny Zislis
17 Mar 5 '17 at 7:05
啊，对不起，是的-我已经习惯了，并一直忘记别人不是。通过分支，我指的是SCM分支的高级通用表示形式，只要以整体方式一起管理实际的基础SCM系统的特殊性，实际上并不重要。从CI预期来看，一个具有主分支的大型仓库或10个并排的仓库（git模块？）每个都具有一个主分支应该与CI预期值相当。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 5 '17 at 7:42
然后，我的第一个评论中的说法成立。独立不可能在通天塔中完成，当您拥有整体时，每个人的开销都很高-因此每个人都负担沉重。最好将解耦的项目表示为要管理的解耦的小型VCS系统。如果您还记不清的话，有些公司正在使用ClearCase和其他VCS来管理所有公司代码-开销太可怕了。
– Evgeny Zislis
17 Mar 5 '17 at 7:44
评论
我投票结束这个问题是因为离题，因为它更适合Software Engg。 SE（softwareengineering.stackexchange.com），并且还导致它并非严格地特定于Devops。这是一个严格的DevOps特定问题。它直接与围绕软件交付的过程有关。您确定您确实了解DevOps的含义吗？
你一直在说DevOps，我不认为这意味着你的意思。
@ Dawny33：请阅读DevOps的基础书籍之一-Phoenix Project。您将仅提及AWS，Docker，Jenkins或任何其他工具。整本书涉及过程，组织层次结构和结构以及团队合作的方式。 DevOps是一种将改善日本和后来的美国制造业的科学思想带入软件开发过程的方式。想法基于Edward W. Deming和Eliyahu M. Goldratt的作品。您所看到的DevOps仅仅是表面，工具和结果。它的多余部分。
@ Dawny33这个问题不适合软件工程。尽管这个总的话题是，但是这个问题太过广泛了。它寻求意见，而不是试图解决问题。如果您不了解其他社区接受的问题类型，请不要建议其他社区。如果将这个问题发布在软件工程上，它将被否决，关闭并可能很快删除。这会导致糟糕的用户体验。