谷歌的开发人员认为敏捷开发是无稽之谈？
极客时间编辑部
讲述：子阳大小：2.32M时长：05:05
近日，在 Quora 上有人提出了“为什么像谷歌这种公司的开发人员认为敏捷开发是无稽之谈？”的问题，对此，作为一名前谷歌工程总监，大卫·杰斯克（David Jeske）提供了一些个人见解，以下是他的回答。
对很多人来说，敏捷意味着很多事情。我认为敏捷宣言从较高层次而言，与谷歌工程师对软件开发的看法是很接近的。
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
先从共通点谈起。谷歌的发展风格是敏捷宣言背后的原则中所提到的激励赋能个体的例证。在这些原则中，最符合硅谷风格，可能本身就是受到硅谷启发的几条原则包括：
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
最好的架构、需求和设计出于自组织的团队。
团队定期反思如何能提高成效，并依此调整自身的行为。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
这些原则对于聪明的工程师来说几乎是常识。然而，这些原则的其他部分却并不符合谷歌的开发文化，并造就了短期迭代的 Scrum 流程。它们似乎更适用于特定类型的开发，最显著的是面向咨询或合同的软件编程，在这种情况下，客户是组织的外部人员，因为他们为开发付费，所以客户占主导地位操纵局势，可以在任何时候改变主意。
所以，我们的首要任务是通过持续不断地及早交付有价值的软件来满足客户；在整个项目中，业务人员和开发人员必须每天一起工作；不论团队内外，传递信息效果最好效率也最高的方式是面对面交谈；欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程对变化进行掌控；频繁地交付可工作的软件，从几周到几个月不等，倾向于采取较短的周期。
这种短期规划、直接与客户接触和持续迭代的风格，非常适合具有简单核心和大量客户可见特性的软件，这些特性的可用性可以增量方式上升，不太适用于那些只有非常简单的用户接口和大量隐藏的内部复杂性软件，这些软件可能直到相当完整时才具有可用性，或实现客户无法想象的飞跃式解决方案。
像谷歌这样的公司一直在编写革命性软件，这些产品以前从未有人编写，在复杂的子组件编写完成之前，软件是无法工作的。所以这在一定程度上是反 Scrum 的。
如果我被要求重写上面的敏捷原则，使之更符合谷歌风格的开发，它们可能会是下面这个样子：
首要任务是提高客户（和程序员）的生产力和对信息的访问。处理你能找到的最迫切、最常见的问题，并产生最大的网络影响。要去深入了解客户，并彻底改变他们的世界。
开发人员应该创建一个小型且结构化的谷歌设计文档，对项目做出解释，此文档应该分发给所有项目干系人，以便在项目开始之前获得早期反馈。书面记录是必不可少的，确保对项目何时抵达成功以及如何达到目标有一个清晰且一致的理解。
在项目的所有阶段，大型组件的关键设计元素应该在设计文档中得到简明的解释和记录。
飞跃式创新。完成并部署一个飞跃式创新比追求完美更重要。不可能做到完美无暇。相反，要灵活，并计划在技术栈的每一层不断地重新创造和改造。
在合理的情况下，尽可能快地交付工作软件，并非一味地追求尽快交付。在对外交付之前先在内部使用自己的产品。确保产品在交付前达到高质量标准。产品的质量比交付产品所花费的时间更重要。
虽然敏捷宣言从高层次而言有足够的灵活性，可以和以上这些原则配合应用，但是我认为这些重写的原则与主张短迭代和低文档的敏捷 /Scrum 流程还是有很大区别的，而这些主张短迭代的低文档敏捷 /Scrum 流程如今几乎已经成为敏捷开发的同义词。
原文链接：Why do some developers at strong companies like Google consider Agile development to be nonsense?
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(3)
- 最新
- 精选
秋水东行敏捷开发给人的感觉就是高中生参加中考。否则，很可能会死的很难看。
李孟我一直这样认为，自由意志，探索灵魂本质，才能做出些有用的东西。
悟敏捷用不好就是灾难大片
收起评论