作者：David Jeske，計(jì)算機(jī)工程師，前谷歌工程總監(jiān)。

本文是 Quora 上的一篇回答，作者是一名前谷歌工程總監(jiān)，他認(rèn)為敏捷宣言從較高層次而言，與谷歌工程師對(duì)軟件開發(fā)的看法是很接近的。但如果落實(shí)到細(xì)節(jié)，比如敏捷宣言背后的某些原則，其所代表的主張短迭代和低文檔的 Scrum 流程，過于集中于短期思維，不適用于谷歌這樣革命性的工程項(xiàng)目。

在 Quora 上有人提出了 ' 為什么像谷歌這種公司的開發(fā)人員認(rèn)為敏捷開發(fā)是無稽之談？' 的問題，關(guān)于此，作為一名前谷歌工程總監(jiān)，David Jeske 提供了一些個(gè)人見解，以下是 David Jeske 的回答。

對(duì)很多人來說，敏捷意味著很多事情。我認(rèn)為敏捷宣言從較高層次而言，與谷歌工程師對(duì)軟件開發(fā)的看法是很接近的。

• 個(gè)體和互動(dòng)高于流程和工具
• 工作的軟件高于詳盡的文檔
• 客戶合作高于合同談判
• 響應(yīng)變化高于遵循計(jì)劃

然而，一旦把這些高層次的觀點(diǎn)落實(shí)到細(xì)節(jié)，這些協(xié)定就開始褪色。敏捷有一些很好的想法，但它也存在一些問題元素，即過于集中在短期思維，對(duì)于像谷歌這樣的公司進(jìn)行革命性工程項(xiàng)目并不太適用。在不深入細(xì)節(jié)的情況下，讓我們來看看敏捷宣言背后的原則。

讓我們從共通點(diǎn)談起。谷歌的發(fā)展風(fēng)格是敏捷宣言背后的原則中所提到的激勵(lì)賦能個(gè)體的例證。在這些原則中，最符合硅谷風(fēng)格，可能本身就是受到硅谷啟發(fā)的幾條原則包括：

• 激發(fā)個(gè)體的斗志，以他們?yōu)楹诵拇罱?xiàng)目。提供所需的環(huán)境和支援，輔以信任，從而達(dá)成目標(biāo)。
• 最好的架構(gòu)、需求和設(shè)計(jì)出于自組織的團(tuán)隊(duì)。
• 團(tuán)隊(duì)定期反思如何能提高成效，并依此調(diào)整自身的行為。
• 堅(jiān)持不懈地追求技術(shù)卓越和良好設(shè)計(jì)，敏捷能力由此增強(qiáng)。
• 以簡潔為本，它是極力減少不必要工作量的藝術(shù)。

這些原則對(duì)于聰明的工程師來說幾乎是常識(shí)。我認(rèn)為，硅谷打造了一種以賦能和信任個(gè)人為中心的文化。

然而，這些原則的其他部分卻并不符合谷歌的開發(fā)文化。而這些部分實(shí)質(zhì)上造就了短期迭代的 Scrum 流程。它們似乎更適用于特定類型的開發(fā)，最顯著的是面向咨詢或合同的軟件編程，在這種情況下，客戶是組織的外部人員，因?yàn)樗麄優(yōu)殚_發(fā)付費(fèi)，所以客戶占主導(dǎo)地位操縱局勢(shì)，可以在任何時(shí)候改變主意：

• 我們的首要任務(wù)是通過持續(xù)不斷地及早交付有價(jià)值的軟件來滿足客戶。
• 在整個(gè)項(xiàng)目中，業(yè)務(wù)人員和開發(fā)人員必須每天一起工作。
• 不論團(tuán)隊(duì)內(nèi)外，傳遞信息效果最好效率也最高的方式是面對(duì)面交談。
• 欣然面對(duì)需求變化，即使在開發(fā)后期也一樣。為了客戶的競(jìng)爭優(yōu)勢(shì)，敏捷過程對(duì)變化進(jìn)行掌控。
• 頻繁地交付可工作的軟件，從幾周到幾個(gè)月不等，傾向于采取較短的周期。

這種短期規(guī)劃、直接與客戶接觸和持續(xù)迭代的風(fēng)格，非常適合具有簡單核心和大量客戶可見特性的軟件，這些特性的可用性可以增量方式上升，不太適用于那些只有非常簡單的用戶接口和大量隱藏的內(nèi)部復(fù)雜性軟件，這些軟件可能直到相當(dāng)完整時(shí)才具有可用性，或?qū)崿F(xiàn)客戶無法想象的飛躍式解決方案。

像谷歌這樣的公司一直在編寫革命性軟件，這些產(chǎn)品以前從未有人編寫，在復(fù)雜的子組件編寫完成之前，軟件是無法工作的。這讓我立刻想到了 Bigtable 和 Borg 項(xiàng)目。Bigtable 是一種廣泛復(fù)制的分布式數(shù)據(jù)庫設(shè)計(jì)，而 Borg 是最早出現(xiàn)的超大規(guī)模集群 / 云管理器之一。這種類型的顛覆性創(chuàng)新需要大量的預(yù)先設(shè)計(jì)時(shí)間，并且需要在超過一周的迭代中為編寫組件而工作。由于項(xiàng)目的外部接口如此簡單，以及內(nèi)部復(fù)雜性如此之高，以至于許多工作對(duì)“客戶”甚至無法可見的，因此沒有辦法編撰客戶可見的相關(guān)用戶故事。這種類型的軟件需要 8-20 個(gè)月的時(shí)間向客戶交付第一個(gè)工作版本。

像 Bigtable 和 Borg 這樣的項(xiàng)目是反 scrum 的。它們代表了技術(shù)領(lǐng)導(dǎo)者非常長遠(yuǎn)的考慮。在單獨(dú)一周的時(shí)間里，他們并沒有做一些可以滿足少量需求的事情，而是為集群軟件開發(fā)方式的根本性轉(zhuǎn)變打下了基礎(chǔ)。這項(xiàng)投資不僅在谷歌獲得了令人難以置信的回報(bào)，而且影響了整個(gè)行業(yè)。

其他行業(yè)也有類似的情況。從稅務(wù)會(huì)計(jì)軟件到電腦游戲，有些軟件在部分完成后并不適宜交付給終端客戶。

如果我被要求重寫上面的敏捷原則，使之更符合谷歌風(fēng)格的開發(fā)，它們可能會(huì)是下面這個(gè)樣子：

• 我們的首要任務(wù)是提高客戶（和程序員）的生產(chǎn)力和對(duì)信息的訪問。處理你能找到的最迫切、最常見的問題，并產(chǎn)生最大的網(wǎng)絡(luò)影響。不要僅僅滿足客戶的要求，要去深入了解客戶，并徹底改變他們的世界。
• 開發(fā)人員應(yīng)該創(chuàng)建一個(gè)谷歌設(shè)計(jì)文檔（一個(gè)相當(dāng)小型的，但是結(jié)構(gòu)化的設(shè)計(jì)文檔），對(duì)項(xiàng)目做出解釋，這個(gè)項(xiàng)目希望實(shí)現(xiàn)什么目標(biāo)，以及為什么不能用其他方法來完成目標(biāo)。此文檔應(yīng)該分發(fā)給所有項(xiàng)目干系人，以便在項(xiàng)目開始之前獲得早期反饋。書面記錄是必不可少的，因?yàn)樗_保對(duì)項(xiàng)目何時(shí)抵達(dá)成功以及如何達(dá)到目標(biāo)有一個(gè)清晰和一致的理解。
• 在項(xiàng)目的所有階段，大型組件的關(guān)鍵設(shè)計(jì)元素應(yīng)該在設(shè)計(jì)文檔中得到簡明的解釋和記錄。
• 飛躍式創(chuàng)新。完成并部署一個(gè)飛躍式創(chuàng)新比追求完美更重要。不可能做到完美無暇。相反，要靈活，并計(jì)劃在技術(shù)棧的每一層不斷地重新創(chuàng)造和改造。
• 在合理的情況下，盡可能快地交付工作軟件，并非一味地追求盡快交付。在對(duì)外交付之前先在內(nèi)部使用自己的產(chǎn)品。確保產(chǎn)品在交付前達(dá)到高質(zhì)量標(biāo)準(zhǔn)。產(chǎn)品的質(zhì)量比交付產(chǎn)品所花費(fèi)的時(shí)間更重要。

雖然敏捷宣言從高層次而言有足夠的靈活性，可以和以上這些原則配合應(yīng)用，但是我認(rèn)為這些重寫的原則與主張短迭代和低文檔的敏捷 /Scrum 流程還是有很大區(qū)別的，而這些主張短迭代的低文檔敏捷 /Scrum 流程如今幾乎已經(jīng)成為敏捷開發(fā)的同義詞。

英文原文：

Why do some developers at strong companies like Google consider Agile development to be nonsense?