「译」大规模敏捷

原文地址： https://blog.cleancoder.com/uncle-bob/2018/04/02/InTheLarge.html

原作者：Robert C. Martin (Uncle Bob)

自敏捷之开端始，我们就思考大规模敏捷的问题。我们是否能够把轻量级，迭代，增量，快速反馈等软件开发的原理应用于规模巨大的项目呢？

最初我们想到的答案是Scrum of Scrums之类的东西。这个想法是在更高的层次上递归地应用敏捷开发的原理。如果一个项目需要超过5-12个开发人员，那么可以组织两个这样的团队，以及一个更高级别的团队来“监督？”他们。

请注意上面的问号。当我们开始考虑大型项目时，我们不可避免地要谈及层级化的组织。但是敏捷似乎是厌恶组织层级的。毕竟，敏捷就是关于平等主义的。敏捷是拒绝命令和控制的。敏捷是拒绝计划和时间表的，还有…

无稽之谈！并不是这样的！

敏捷其实是一场“风水轮流转”的革命。在软件行业的早期，我们原本就以敏捷的方式编写代码。我们写小块代码片段，对其进行了测试，将它们构建为更大的块，如此循环往复。如果您回到1960年代后期，并观察当时人们编写代码的方式，您会发现敏捷的小荷尖尖角正在显露出来。

当然，当时我们在硬件方面受到了很大的限制。编译要跑好几个小时。代码编辑要用电传打字机。那时，大多数程序员根本不会使用键盘。因此他们让按键操作员替他们输入代码。在这种环境下，很难实现快速反馈机制。

即便如此，我们仍竭尽所能去缩短反馈周期。我们使用汇编器编写程序，坐在控制台前通过用八进制或十六进制打补丁的方式来进行调试。我们可以通过在调试器中执行代码，甚至通过单步执行来测试代码。经年累月，熟能生巧。这是在合理的时间内完成工作的唯一方法。

但是“风水轮流转”了。我们开始使用在控制台上不容易调试的语言。我们开始编写越来越大的程序。为了在反馈周期如此长的环境中工作，我们需要制定计划。

瀑布就在这样的环境中诞生了出来。当编辑,编译,测试的循环周期需要一整天的时候，我们需要进行大量的计划和检查。在24小时的循环周期内做TDD和重构是不现实的！

但是“风水”一直在转动。今天的大多数程序员都没有深切体会到摩尔定律的指数发展。我们从1970年的24小时循环周期，到1980年的60分钟循环周期，到1990年的十分钟循环周期，再到2000年的10秒循环周期。到2005年，大多数程序员的循环周期不到1秒。

敏捷就在这样的环境中诞生了出来。敏捷是对1960年代快速周转，高频反馈开发策略的一种历史回归，不过这次我们有了更强大的机器，更强大的语言和工具以及更大规模的项目。

敏捷也可以说是从历史的灰烬中浴火重生而来的。瀑布虽然在70年代和80年代是很有必要的，但却令人非常痛苦。在那几十年中，我们学会了哪些事情是不该做的。因此，当敏捷在90年代末出现时，它也承载着之前那段黑暗时期所积累的教训。

敏捷却也不仅仅是对短反馈周期的历史回归。敏捷在短反馈周期的基础之上增强了纪律。诸如测试，重构，结对编程和高度自动化之类的实践。敏捷确实让我们从六十年代的策略中前进了。

不过前进的方向是什么？敏捷革命改进了什么？

敏捷革命关注的是相对较小的团队如何开发相对较小的软件项目。请注意，我强调了“小”这个字。

敏捷团队擅长于创建十万行左右的软件系统。十万行已经可以做很多事情了。对于许多公司而言，一两个敏捷团队足以满足他们。

另一方面，如果您需要创建一个千万行代码的系统，那么一个敏捷团队就不够了。您需要大约一百个团队来构建千万代码行级别的系统。

但是，您如何管理一百个敏捷团队？您如何给他们提供用户故事？您如何协调它们之间的接口？您如何在那千万行代码中创造边界而让团队可以彼此独立工作？

以及您如何以“敏捷”的方式做到这一点？ （这才是真正的问题）

答案是：你不能！

我们人类非常擅长于建设大型项目。长久以来我们就知道如何做这件事。

想想我们人类完成过的真正巨大的项目吧。

• 阿波罗登月：我们把人送到月球上！
• 诺曼底战役：我们在50英里坚固的防线上，以156000名士兵入侵了诺曼底。
• 我们拥有支持80亿人口的世界经济。
• 全球各地都有庞大的网络，您可以在树林里徒步时在手机上读这篇文章！
• 你要买东西吗？按几下手机，明天甚至今天就会有人来送快递。
• 我们将红色跑车驶入了太阳轨道。

应该不用说更多例子了。我们人类确实非常擅长做大事。

那为什么我们对大型软件会有所忧虑呢？我们已经知道如何构建大型软件了。我们已经这样做了50多年或更久了。“大”的部分实际上从来不是问题所在。我们用敏捷解决的问题是关于“小”的那部分。我们之前不知道如何搞定的，是做小型项目。

我们一直都知道如何做大型项目。那就是分而治之。敏捷解决了其中“小”的那一部分。敏捷与“大”的部分无关。

但是，但是，但是，但是……平等主义！拒绝计划和命令与控制！敏捷！

无稽之谈！

敏捷不是平等主义。敏捷不是拒绝计划，也不是拒绝命令和控制。事实上，敏捷是命令和控制体系中最小单元的体现：战术小队。

是的，在层级结构的末端，命令和控制不再有效。一小组人可以通过大量反馈和激烈的沟通在较短的周期内工作，以实现目标。这就是一支敏捷的团队。在这个级别上，严格的命令和控制是极为有害的。但是在此级别之上，命令和控制就变得有必要了。在层级上越往上走，这种效应就越明显。没有大量的命令和控制，就无法设计，建造，生产和销售数以亿部的iPhone。

市场上有很多种大规模敏捷的玩法。有关该主题的书籍和博客也有很多。也有人成立了咨询公司，专门为大公司做大规模敏捷的转型。这没有什么不好的。

这些大规模敏捷方法所讲的策略和技术都没有错。只不过，它们不是敏捷的。它们与敏捷无关。它们是在人类几千年来用于完成重大工作的策略和技术的基础上加了点敏捷的“味道”。

这点味道来自敏捷使用的词汇和概念。增添些口味没有错–没问题。如果您喜欢使用敏捷中的词语和概念，那就尽管去用。但是不要过分关注它的“敏捷性”。一旦你要做大规模的事情，就离开了敏捷的领域。希望您的各个开发小组正在使用敏捷；但是整个大规模项目并不是敏捷的。

因为敏捷是专注于做”小“事情的。