问题描述
在1975年，弗雷德里克·布鲁克斯提出了“神话般的人月”（Mythical Man Month）的概念。他认为，复杂的编程项目无法完美地划分为可以在没有开发者之间的沟通和建立复杂的任务和执行任务的人之间建立复杂的相互关系的离散任务。然而，随着时间的推移，我们积累了一些经验来减轻这个问题。你在工作中成功应用了一些解决方案，以在项目中增加资源而不会引发更多问题。那么，你是如何做到的呢？
解决方案
了解“神话般的人月”
首先，我们需要了解“神话般的人月”的背景和含义。根据布鲁克斯的定义，一个“人月”是指一个人在一个月内完成的工作量。然而，布鲁克斯认为，无法用“人月”来衡量有用的工作量。他认为，复杂的编程项目无法完美地划分为可以在没有开发者之间的沟通和建立复杂的任务和执行任务的人之间建立复杂的相互关系的离散任务。这在高度内聚的软件单体中尤为明显。无论进行多少解耦，大型单体仍然需要新的程序员花费时间来了解它，并且沟通开销会占用越来越多的时间。
然而，我们是否真的需要这样呢？我们是否必须编写单体应用程序并保持n(n-1)/2个开发者之间的沟通渠道呢？事实上，我们知道有一些公司正在进行大型项目的开发，并且这种方式是可行的。所以，自1975年以来，一定有一些改变。
减轻“神话般的人月”的可能性
在2015年，PuppetLabs和IT Revolution发布了《2015年DevOps状况报告》的结果。在该报告中，他们关注了高绩效组织与非高绩效组织之间的区别。
高绩效组织表现出一些意想不到的特点。例如，他们在开发中具有最佳的项目截止日期性能，在运营中具有最佳的操作稳定性和可靠性，以及最佳的安全性和合规性记录。
报告中突出的一个令人惊讶的事实是每天部署次数的指标。但不仅仅是每天部署次数，他们还测量了每天每个开发者的部署次数以及在高绩效组织和非高绩效组织中增加更多开发者的效果。
以下是报告中的图表：
低绩效组织符合“神话般的人月”的假设。而高绩效组织可以将每天每个开发者的部署次数与开发者人数成线性关系。
在Gene Kim在2016年的DevOpsDays伦敦演讲中，他详细讲解了这些发现。
如何做到
首先，如何成为一个高绩效组织？有一些书籍讨论了这个问题，这里只提供链接。
- 《从优秀到卓越：为什么有些公司能够成功而其他公司不能》 – Jim Collins
- 《高速边缘：如何利用运营卓越击败竞争对手》 – Steven Spear
- 《工业、政府、教育的新经济学》 – W. Edwards Deming
对于软件和IT组织来说，成为高绩效组织的关键因素之一是：专注于质量和速度。
例如，Ward Cunningham在他的演讲中解释了技术债务，即我们允许未修复的所有事情。这被管理层接受，因为总是伴随着一个承诺，即在有时间的时候会修复它。
然而，时间永远不够，技术债务只会越来越严重。导致技术债务增长的原因有很多，比如遗留代码、手动配置环境、手动测试和手动部署。
遗留代码是指没有自动化测试的代码。每当使用快捷方式将代码部署到生产环境时，运维团队就会负担起维护这些技术债务的责任。然后，部署过程变得越来越长。
Gene在他的演讲中讲述了一个公司的故事，该公司的部署过程需要六周时间，涉及数万个极易出错的繁琐步骤，耗费了400人的时间，每年要重复四次。
DevOps的一个原则是，可靠性来自于更频繁地进行较小的部署。
示例
以下是一些示例，展示了一些公司如何减少将代码部署到生产环境所需的时间。
- Jon Jenkins在Velocity 2011上的演讲：亚马逊每天进行15,000次部署。
- Ken Exner在AWS Summit 2015上的演讲：亚马逊每天进行136,000次部署。
这两个演讲展示了亚马逊为减少将代码部署到生产环境所需的时间所做的一切努力。
根据Gene的说法，这些高绩效组织在这段时间内唯一改变的是开发者的数量。因此，从亚马逊的例子中可以看出，他们在四年内通过增加人数将部署次数增加了十倍。
这意味着，在特定条件下，通过正确的架构、正确的技术实践和正确的文化规范，开发者的生产力可以随着开发者数量的增加而增加。而DevOps正处于这一切的中心。
以上是一些减轻“神话般的人月”效应的方法和实例。希望对你有所帮助！