雪花新闻

为什么谷歌的开发人员认为敏捷开发是无稽之谈?

摘要:但如果落实到细节,比如敏捷宣言背后的某些原则,其所代表的主张短迭代和低文档的 Scrum 流程,过于集中于短期思维,不适用于谷歌这样革命性的工程项目。这种短期规划、直接与客户接触和持续迭代的风格,非常适合具有简单核心和大量客户可见特性的软件,这些特性的可用性可以增量方式上升,不太适用于那些只有非常简单的用户接口和大量隐藏的内部复杂性软件,这些软件可能直到相当完整时才具有可用性,或实现客户无法想象的飞跃式解决方案。

本文是 Quora 上的一篇回答,作者是一名前谷歌工程总监,他认为敏捷宣言从较高层次而言,与谷歌工程师对软件开发的看法是很接近的。但如果落实到细节,比如敏捷宣言背后的某些原则,其所代表的主张短迭代和低文档的 Scrum 流程,过于集中于短期思维,不适用于谷歌这样革命性的工程项目。

在 Quora 上有人提出了 " 为什么像谷歌这种公司的开发人员认为敏捷开发是无稽之谈?" 的问题,关于此,作为一名前谷歌工程总监,David Jeske 提供了一些个人见解,以下是 David Jeske 的回答。

对很多人来说,敏捷意味着很多事情。我认为敏捷宣言从较高层次而言,与谷歌工程师对软件开发的看法是很接近的。

然而,一旦把这些高层次的观点落实到细节,这些协定就开始褪色。敏捷有一些很好的想法,但它也存在一些问题元素,即过于集中在短期思维,对于像谷歌这样的公司进行革命性工程项目并不太适用。在不深入细节的情况下,让我们来看看 敏捷宣言背后的原则

让我们从共通点谈起。谷歌的发展风格是敏捷宣言背后的原则中所提到的 激励赋能个体 的例证。在这些原则中,最符合硅谷风格,可能本身就是受到硅谷启发的几条原则包括:

这些原则对于聪明的工程师来说几乎是常识。我认为,硅谷打造了一种以赋能和信任个人为中心的文化。

然而,这些原则的其他部分却并不符合谷歌的开发文化。而这些部分实质上造就了短期迭代的 Scrum 流程。它们似乎更适用于特定类型的开发,最显著的是面向咨询或合同的软件编程,在这种情况下,客户是组织的外部人员,因为他们为开发付费,所以客户占主导地位操纵局势,可以在任何时候改变主意:

这种短期规划、直接与客户接触和持续迭代的风格,非常适合具有简单核心和大量客户可见特性的软件,这些特性的可用性可以增量方式上升,不太适用于那些只有非常简单的用户接口和大量隐藏的内部复杂性软件,这些软件可能直到相当完整时才具有可用性,或实现客户无法想象的飞跃式解决方案。

像谷歌这样的公司一直在编写革命性软件,这些产品以前从未有人编写,在复杂的子组件编写完成之前,软件是无法工作的。这让我立刻想到了 Bigtable 和 Borg 项目。Bigtable 是一种广泛复制的分布式数据库设计,而 Borg 是最早出现的超大规模集群 / 云管理器之一。这种类型的颠覆性创新需要大量的预先设计时间,并且需要在超过一周的迭代中为编写组件而工作。由于项目的外部接口如此简单,以及内部复杂性如此之高,以至于许多工作对“客户”甚至无法可见的,因此没有办法编撰客户可见的相关用户故事。这种类型的软件需要 8-20 个月的时间向客户交付第一个工作版本。

像 Bigtable 和 Borg 这样的项目是反 scrum 的。它们代表了技术领导者非常长远的考虑。在单独一周的时间里,他们并没有做一些可以满足少量需求的事情,而是为集群软件开发方式的根本性转变打下了基础。这项投资不仅在谷歌获得了令人难以置信的回报,而且影响了整个行业。

其他行业也有类似的情况。从税务会计软件到电脑游戏,有些软件在部分完成后并不适宜交付给终端客户。

如果我被要求重写上面的敏捷原则,使之更符合谷歌风格的开发,它们可能会是下面这个样子:

虽然敏捷宣言从高层次而言有足够的灵活性,可以和以上这些原则配合应用,但是我认为这些重写的原则与主张短迭代和低文档的敏捷 /Scrum 流程还是有很大区别的,而这些主张短迭代的低文档敏捷 /Scrum 流程如今几乎已经成为敏捷开发的同义词。

作者介绍:

David Jeske,计算机工程师,前谷歌工程师总监。

英文原文:

Why do some developers at strong companies like Google consider Agile development to be nonsense?
相关文章