作者：David Jeske，計算機工程師，前谷歌工程總監(jiān)。
本文是 Quora 上的一篇回答，作者是一名前谷歌工程總監(jiān)，他認為敏捷宣言從較高層次而言，與谷歌工程師對軟件開發(fā)的看法是很接近的。但如果落實到細節(jié)，比如敏捷宣言背后的某些原則，其所代表的主張短迭代和低文檔的 Scrum 流程，過于集中于短期思維，不適用于谷歌這樣革命性的工程項目。
在 Quora 上有人提出了 ' 為什么像谷歌這種公司的開發(fā)人員認為敏捷開發(fā)是無稽之談？' 的問題，關于此，作為一名前谷歌工程總監(jiān)，David Jeske 提供了一些個人見解，以下是 David Jeske 的回答。
對很多人來說，敏捷意味著很多事情。我認為敏捷宣言從較高層次而言，與谷歌工程師對軟件開發(fā)的看法是很接近的。
然而，一旦把這些高層次的觀點落實到細節(jié)，這些協(xié)定就開始褪色。敏捷有一些很好的想法，但它也存在一些問題元素，即過于集中在短期思維，對于像谷歌這樣的公司進行革命性工程項目并不太適用。在不深入細節(jié)的情況下，讓我們來看看敏捷宣言背后的原則。
讓我們從共通點談起。谷歌的發(fā)展風格是敏捷宣言背后的原則中所提到的激勵賦能個體的例證。在這些原則中，最符合硅谷風格，可能本身就是受到硅谷啟發(fā)的幾條原則包括：
這些原則對于聰明的工程師來說幾乎是常識。我認為，硅谷打造了一種以賦能和信任個人為中心的文化。
然而，這些原則的其他部分卻并不符合谷歌的開發(fā)文化。而這些部分實質上造就了短期迭代的 Scrum 流程。它們似乎更適用于特定類型的開發(fā)，最顯著的是面向咨詢或合同的軟件編程，在這種情況下，客戶是組織的外部人員，因為他們?yōu)殚_發(fā)付費，所以客戶占主導地位操縱局勢，可以在任何時候改變主意：
這種短期規(guī)劃、直接與客戶接觸和持續(xù)迭代的風格，非常適合具有簡單核心和大量客戶可見特性的軟件，這些特性的可用性可以增量方式上升，不太適用于那些只有非常簡單的用戶接口和大量隱藏的內部復雜性軟件，這些軟件可能直到相當完整時才具有可用性，或實現(xiàn)客戶無法想象的飛躍式解決方案。
像谷歌這樣的公司一直在編寫革命性軟件，這些產品以前從未有人編寫，在復雜的子組件編寫完成之前，軟件是無法工作的。這讓我立刻想到了 Bigtable 和 Borg 項目。Bigtable 是一種廣泛復制的分布式數(shù)據(jù)庫設計，而 Borg 是最早出現(xiàn)的超大規(guī)模集群 / 云管理器之一。這種類型的顛覆性創(chuàng)新需要大量的預先設計時間，并且需要在超過一周的迭代中為編寫組件而工作。由于項目的外部接口如此簡單，以及內部復雜性如此之高，以至于許多工作對“客戶”甚至無法可見的，因此沒有辦法編撰客戶可見的相關用戶故事。這種類型的軟件需要 8-20 個月的時間向客戶交付第一個工作版本。
像 Bigtable 和 Borg 這樣的項目是反 scrum 的。它們代表了技術領導者非常長遠的考慮。在單獨一周的時間里，他們并沒有做一些可以滿足少量需求的事情，而是為集群軟件開發(fā)方式的根本性轉變打下了基礎。這項投資不僅在谷歌獲得了令人難以置信的回報，而且影響了整個行業(yè)。
其他行業(yè)也有類似的情況。從稅務會計軟件到電腦游戲，有些軟件在部分完成后并不適宜交付給終端客戶。
如果我被要求重寫上面的敏捷原則，使之更符合谷歌風格的開發(fā)，它們可能會是下面這個樣子：
雖然敏捷宣言從高層次而言有足夠的靈活性，可以和以上這些原則配合應用，但是我認為這些重寫的原則與主張短迭代和低文檔的敏捷 /Scrum 流程還是有很大區(qū)別的，而這些主張短迭代的低文檔敏捷 /Scrum 流程如今幾乎已經(jīng)成為敏捷開發(fā)的同義詞。
英文原文：
Why do some developers at strong companies like Google consider Agile development to be nonsense?
