本文是 Quora 上的一篇回答，作者是一名前谷歌工程總監，他認爲敏捷宣言從較高層次而言，與谷歌工程師對軟件開發的看法是很接近的。但如果落實到細節，比如敏捷宣言背後的某些原則，其所代表的主張短迭代和低文檔的 Scrum 流程，過於集中於短期思維，不適用於谷歌這樣革命性的工程項目。
在 Quora 上有人提出了"爲什麼像谷歌這種公司的開發人員認爲敏捷開發是無稽之談？"的問題，關於此，作爲一名前谷歌工程總監，David Jeske 提供了一些個人見解，以下是 David Jeske 的回答。
對很多人來說，敏捷意味着很多事情。我認爲敏捷宣言從較高層次而言，與谷歌工程師對軟件開發的看法是很接近的。
- 個體和互動高於流程和工具
- 工作的軟件高於詳盡的文檔
- 客戶合作高於合同談判
- 響應變化高於遵循計劃
然而，一旦把這些高層次的觀點落實到細節，這些協定就開始褪色。敏捷有一些很好的想法，但它也存在一些問題元素，即過於集中在短期思維，對於像谷歌這樣的公司進行革命性工程項目並不太適用。在不深入細節的情況下，讓我們來看看 敏捷宣言背後的原則。
讓我們從共通點談起。谷歌的發展風格是敏捷宣言背後的原則中所提到的 激勵賦能個體 的例證。在這些原則中，最符合硅谷風格，可能本身就是受到硅谷啓發的幾條原則包括：
- 激發個體的鬥志，以他們爲核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。
- 最好的架構、需求和設計出於自組織的團隊。
- 團隊定期反思如何能提高成效，並依此調整自身的行爲。
- 堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。
- 以簡潔爲本，它是極力減少不必要工作量的藝術。
這些原則對於聰明的工程師來說幾乎是常識。我認爲，硅谷打造了一種以賦能和信任個人爲中心的文化。
然而，這些原則的其他部分卻並不符合谷歌的開發文化。而這些部分實質上造就了短期迭代的 Scrum 流程。它們似乎更適用於特定類型的開發，最顯著的是面向諮詢或合同的軟件編程，在這種情況下，客戶是組織的外部人員，因爲他們爲開發付費，所以客戶占主導地位操縱局勢，可以在任何時候改變主意：
- 我們的首要任務是通過持續不斷地及早交付有價值的軟件來滿足客戶。
- 在整個項目中，業務人員和開發人員必須每天一起工作。
- 不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面交談。
- 欣然面對需求變化，即使在開發後期也一樣。爲了客戶的競爭優勢，敏捷過程對變化進行掌控。
- 頻繁地交付可工作的軟件，從幾周到幾個月不等，傾向於採取較短的週期。
這種短期規劃、直接與客戶接觸和持續迭代的風格，非常適合具有簡單核心和大量客戶可見特性的軟件，這些特性的可用性可以增量方式上升，不太適用於那些只有非常簡單的用戶接口和大量隱藏的內部複雜性軟件，這些軟件可能直到相當完整時才具有可用性，或實現客戶無法想象的飛躍式解決方案。
像谷歌這樣的公司一直在編寫革命性軟件，這些產品以前從未有人編寫，在複雜的子組件編寫完成之前，軟件是無法工作的。這讓我立刻想到了 Bigtable 和 Borg 項目。Bigtable 是一種廣泛複製的分佈式數據庫設計，而 Borg 是最早出現的超大規模集羣 / 雲管理器之一。這種類型的顛覆性創新需要大量的預先設計時間，並且需要在超過一週的迭代中爲編寫組件而工作。由於項目的外部接口如此簡單，以及內部複雜性如此之高，以至於許多工作對“客戶”甚至無法可見的，因此沒有辦法編撰客戶可見的相關用戶故事。這種類型的軟件需要 8-20 個月的時間向客戶交付第一個工作版本。
像 Bigtable 和 Borg 這樣的項目是反 scrum 的。它們代表了技術領導者非常長遠的考慮。在單獨一週的時間裏，他們並沒有做一些可以滿足少量需求的事情，而是爲集羣軟件開發方式的根本性轉變打下了基礎。這項投資不僅在谷歌獲得了令人難以置信的回報，而且影響了整個行業。
其他行業也有類似的情況。從稅務會計軟件到電腦遊戲，有些軟件在部分完成後並不適宜交付給終端客戶。
如果我被要求重寫上面的敏捷原則，使之更符合谷歌風格的開發，它們可能會是下面這個樣子：
- 我們的首要任務是提高客戶（和程序員）的生產力和對信息的訪問。處理你能找到的最迫切、最常見的問題，併產生最大的網絡影響。不要僅僅滿足客戶的要求，要去深入瞭解客戶，並徹底改變他們的世界。
- 開發人員應該創建一個谷歌設計文檔（一個相當小型的，但是結構化的設計文檔），對項目做出解釋，這個項目希望實現什麼目標，以及爲什麼不能用其他方法來完成目標。此文檔應該分發給所有項目干係人，以便在項目開始之前獲得早期反饋。書面記錄是必不可少的，因爲它確保對項目何時抵達成功以及如何達到目標有一個清晰和一致的理解。
- 在項目的所有階段，大型組件的關鍵設計元素應該在設計文檔中得到簡明的解釋和記錄。
- 飛躍式創新。完成並部署一個飛躍式創新比追求完美更重要。不可能做到完美無暇。相反，要靈活，並計劃在技術棧的每一層不斷地重新創造和改造。
- 在合理的情況下，儘可能快地交付工作軟件，並非一味地追求儘快交付。在對外交付之前先在內部使用自己的產品。確保產品在交付前達到高質量標準。產品的質量比交付產品所花費的時間更重要。
雖然敏捷宣言從高層次而言有足夠的靈活性，可以和以上這些原則配合應用，但是我認爲這些重寫的原則與主張短迭代和低文檔的敏捷 /Scrum 流程還是有很大區別的，而這些主張短迭代的低文檔敏捷 /Scrum 流程如今幾乎已經成爲敏捷開發的同義詞。
作者介紹：
David Jeske，計算機工程師，前谷歌工程總監。