为什么谷歌开发人员认为敏捷开发是无稽之谈？x.docx

为什么谷歌开发人员认为敏捷开发是无稽之谈？x为什么谷歌的开发人员认为灵敏开发是无稽之谈？ 在 Quora 上有人提出了 为什么像谷歌这种公司的开发人员认为灵敏开发是无稽之谈？ 的问题，关于此，作为一名前谷歌工程总监，David Jeske 供应了一些个人见解，以下是 David Jeske 的回答。对许多人来说，灵敏意味着许多事情。我认为灵敏宣言从较高层次而言，与谷歌工程师对软件开发的看法是很接近的。个体和互动流程和工具 工作的软件高于详尽的文档 客户合作合同谈判 • 响应改变高于遵循安排 然而，一旦把这些高层次的观点落实到细微环节，这些协定就起先褪色。灵敏有一些很好的想法，但它也存在一些问题元素，即过于集中在短期思维，对于像谷歌这样的公司进行革命性工程项目并不太适用。在不深化细微环节的状况下，让我们来看看灵敏宣言背后的原则。让我们从共通点谈起。谷歌的发展风格是灵敏宣言背后的原则中所提到的 激励赋能个体的例证。在这些原则中，最符合硅谷风格，可能本身就是受到硅谷启发的几条原则包括：• 激发个体的斗志，以他们为核心搭建项目。供应所需的环境和支援，辅以信任，从而达成目标。最好的架构、需求和设计出于自组织的团队。团队定期反思如何能提高成效，并依此调整自身的行为。坚持不懈地追求技术卓越和良好设计，灵敏实力由此增加。• 以简洁为本，它是极力削减不必要工作量的艺术。这些原则对于聪慧的工程师来说几乎是常识。我认为，硅谷打造了一种以赋能和信任个人为中心的文化。然而，这些原则的其他部分却并不符合谷歌的开发文化。而这些部分实质上造就了短期迭代的 Scrum 流程。它们好像更适用于特定类型的开发，最显著的是面对询问或合同的软件编程，在这种状况下，客户是组织的外部人员，因为他们为开发付费，所以客户占主导地位操纵局势，可以在任何时候变更办法：我们的首要任务是通过持续不断地及早交付有价值的软件来满意客户。在整个项目中，业务人员和开发人员必需每天一起工作。• 不论团队内外，传递信息效果最好效率也最高的方式是面对面交谈。• 欣然面对需求改变，即使在开发后期也一样。为了客户的竞争优势，灵敏过程对改变进行掌控。• 频繁地交付可工作的软件，从几周到几个月不等，倾向于实行较短的周期。这种短期规划、干脆与客户接触和持续迭代的风格，特别适合具有简洁核心和大量客户可见特性的软件，这些特性的可用性可以增量方式上升，不太适用于那些只有特别简洁的用户接口和大量隐藏的内部困难性软件，这些软件可能直到相当完整时才具有可用性，或实现客户无法想象的飞跃式解决方案。像谷歌这样的公司始终在编写革命性软件，这些产品以前从未有人编写，在困难的子组件编写完成之前，软件是无法工作的。这让我立即想到了 Bigtable 和 Borg 项目。Bigtable 是一种广泛复制的分布式数据库设计，而 Borg 是最早出现的超大规模集群 / 云管理器之一。这种类型的颠覆性创新须要大量的预先设计时间，并且须要在超过一周的迭代中为编写组件而工作。由于项目的外部接口如此简洁，以及内部困难性如此之高，以至于很多工作对客户甚至无法可见的，因此没有方法编撰客户可见的相关用户故事。这种类型的软件须要 8-20 个月的时间向客户交付第一个工作版本。像 Bigtable 和 Borg 这样的项目是反 scrum 的。它们代表了技术领导者特别长远的考虑。在单独一周的时间里，他们并没有做一些可以满意少量需求的事情，而是为集群软件开发方式的根本性转变打下了基础。这项投资不仅在谷歌获得了令人难以置信的回报，而且影响了整个行业。其他行业也有类似的状况。从税务会计软件到电脑嬉戏，有些软件在部分完成后并不相宜交付给终端客户。假如我被要求重写上面的灵敏原则，使之更符合谷歌风格的开发，它们可能会是下面这个样子：• 我们的首要任务是提高客户（和程序员）的生产力和对信息的访问。处理你能找到的最迫切、最常见的问题，并产生最大的网络影响。不要仅仅满意客户的要求，要去深化了解客户，并彻底变更他们的世界。• 开发人员应当创建一个谷歌设计文档（一个相当小型的，但是结构化的设计文档），对项目做出说明，这个项目希望实现什么目标，以及为什么不能用其他方法来完成目标。此文档应当分发给全部项目干系人，以便在项目起先之前获得早期反馈。书面记录是必不行少的，因为它确保对项目何时抵达胜利以及如何达到目标有一个清楚和一样的理解。• 在项目的全部阶段，大型组件的关键设计元素应当在设计文档中得到简明的说明和记录。• 飞跃式创新。完成并部署一个飞跃式创新比追求完备更重要。不行能做到完备无暇。相反，要敏捷，并安排在技术栈的每一层不断地重新创建和改造。• 在合理的状况下，尽可能快地交付工作软件，并非一味地追求尽快交付。在对外交付之前先在内部运用自己的产品。确保产品在交付前达到高质量标准。产品的质量比交付产品所花费的时间更重要。虽然灵敏宣言从高层次而言有足够的敏捷性，可以和以上这些原则协作应用，但是我认为重写的原则与主见短迭代和低文档的灵敏 /Scrum 流程还是有很大区分的，而这些主见短迭代的低文档灵敏 /Scrum 流程如今几乎已经成为灵敏开发的同义词。