当前位置: 首页 > 科技观察

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

时间:2023-03-12 21:22:59 科技观察

这篇文章是Quora上的一个回答。作者是前谷歌工程总监。他认为AgileManifesto在高层次上非常接近Google工程师对软件开发的看法。但如果你实施细节,比如敏捷宣言背后的某些原则,提倡短迭代和低文档的Scrum过程过于注重短期思维,不适合像谷歌这样的革命性工程项目。在Quora上,有人提出了“为什么像Google这样的公司的开发人员认为敏捷开发是无稽之谈?”的问题。对此,前谷歌工程总监DavidJeske提供了一些个人见解。以下是DavidJeske的回答。对于很多人来说,敏捷意味着很多事情。我认为敏捷宣言在高层次上非常接近谷歌工程师对软件开发的看法。个人和交互胜过流程和工具工作软件胜过详细文档客户协作胜过合同谈判响应变化胜过遵循计划然而,一旦这些高层次的观点深入到细节,这些协议就会开始消失。敏捷有一些好的想法,但也有一些问题,就是过于专注于短期思维,不太适合像谷歌这样的公司来承担革命性的工程项目。不深入细节,让我们看一下敏捷宣言背后的原则。让我们从共同点开始。Google的开发风格是敏捷宣言背后的原则中提到的激励和授权个人的一个例子。在这些原则中,最符合硅谷风格、可能受到硅谷启发的有:激发个人的斗志,以个人为核心建设项目。以信任为后盾,提供实现目标所需的环境和支持。最好的架构、需求和设计来自自组织团队。团队定期反思如何提高效率并相应地调整其行为。对卓越技术和良好设计的不懈追求会增强敏捷性。考虑到简单性,这是尽量减少不必要的努力的艺术。这些原则对聪明的工程师来说几乎是常识。我认为硅谷创造了一种以赋予个人权力和信任个人为中心的文化。然而,这些原则的其他部分不符合谷歌的开发文化。这些部分实质上创建了短期迭代Scrum流程。它们似乎更适用于特定类型的开发,最显着的是咨询或面向合同的软件编程,其中客户在组织外部并且由于他们为开发付费,因此客户主导了情况并且可以随时改变您的想法:我们的首要任务是通过一致的早期交付有价值的软件来满足我们的客户。在整个项目中,业务人员和开发人员必须每天一起工作。在团队内部和外部传达信息的最有效和高效的方式是通过面对面的对话。对需求的变化持开放态度,即使是在开发后期。敏捷流程为客户的竞争优势管理变更。频繁交付工作软件(从几周到几个月不等)往往需要更短的周期。这种短期计划、直接客户参与和持续迭代的风格非常适合具有简单核心和大量客户可见功能且可用性可以逐步提高的软件,不太适合具有非常简单用户界面的软件许多隐藏的内部复杂性软件可能在相当完整之前无法使用,或者启用客户无法想象的跨越式解决方案。像谷歌这样的公司一直在编写革命性的软件,这些软件以前从未被编写过,并且在编写复杂的子组件之前无法运行。这让我立刻想到了Bigtable和Borg项目。Bigtable是一种广泛复制的分布式数据库设计,而Borg是最早出现的超大规模集群/云管理器之一。这种类型的颠覆性创新需要大量的前期设计时间和一周以上的迭代工作来编写组件。由于项目的外部接口如此简单,而内部复杂度如此之高,以至于很多工作甚至对“客户”来说都是不可见的,因此没有办法编写对客户可见的相关用户故事。此类软件需要8-20个月才能将第一个工作版本交付给客户。像Bigtable和Borg这样的项目是反scrum的。它们代表了技术领导者非常长远的想法。在一个星期内,他们并没有做一些满足少量需求的事情,而是为集群软件开发方式的根本转变奠定了基础。这项投资不仅在谷歌,而且在整个行业都取得了令人难以置信的回报。其他行业也有类似情况。从税务会计软件到电脑游戏,有些软件不适合在部分完成时交付给最终客户。如果我被要求重写上面的敏捷原则以更符合Google风格的开发,它们可能看起来像这样:我们的首要任务是提高客户(和程序员)的生产力和信息访问。解决您能找到的最紧迫、最常见的问题,并对网络产生最大的影响。不要只是满足您的客户,了解他们并永远改变他们的世界。开发人员应该创建一个Google设计文档(一个相当小但结构化的设计文档)来解释项目、项目希望实现的目标以及无法通过其他方式实现的原因。该文档应分发给所有项目利益相关者,以便在项目开始之前获得早期反馈。书面记录是必不可少的,因为它可以确保清楚一致地了解项目何时取得成功以及如何取得成功。在项目的所有阶段,大型组件的关键设计元素都应在设计文件中进行简明解释和记录。创新的飞跃。完成和部署跨越式创新比精益求精更重要。不可能完美。相反,要灵活并计划在技术堆栈的每一层不断地重新发明和重新发明。尽可能快地交付工作软件并不是盲目地追求尽快交付它。在外部交付之前,先在内部使用您自己的产品。确保产品在交付前符合高质量标准。产品质量比交付时间更重要。虽然敏捷宣言在高层次上足够灵活,可以与上述原则结合应用,但我认为这些重写的原则与提倡短迭代和低文档的敏捷/Scrum流程有很大不同,而这些低文档敏捷/支持短迭代的Scrum流程几乎已成为当今敏捷开发的代名词。关于作者:DavidJeske,计算机工程师,谷歌前工程总监。