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

 

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

 

· 個(gè)體和互動(dòng)高于流程和工具

 

· 工作的軟件高于詳盡的文檔

 

· 客戶合作高于合同談判

 

· 響應(yīng)變化高于遵循計(jì)劃

 

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

 

讓我們從共通點(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)。

 

· 以簡(jiǎn)潔為本，它是極力減少不必要工作量的藝術(shù)。

 

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

 

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

 

· 我們的首要任務(wù)是通過(guò)持續(xù)不斷地及早交付有價(jià)值的軟件來(lái)滿足客戶。

 

· 在整個(gè)項(xiàng)目中，業(yè)務(wù)人員和開(kāi)發(fā)人員必須每天一起工作。

 

· 不論團(tuán)隊(duì)內(nèi)外，傳遞信息效果最好效率也最高的方式是面對(duì)面交談。

 

· 欣然面對(duì)需求變化，即使在開(kāi)發(fā)后期也一樣。為了客戶的競(jìng)爭(zhēng)優(yōu)勢(shì)，敏捷過(guò)程對(duì)變化進(jìn)行掌控。

 

· 頻繁地交付可工作的軟件，從幾周到幾個(gè)月不等，傾向于采取較短的周期。

 

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

 

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

 

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

 

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

 

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

 

· 我們的首要任務(wù)是提高客戶(和程序員)的生產(chǎn)力和對(duì)信息的訪問(wèn)。處理你能找到的最迫切、最常見(jiàn)的問(wèn)題，并產(chǎn)生最大的網(wǎng)絡(luò)影響。不要僅僅滿足客戶的要求，要去深入了解客戶，并徹底改變他們的世界。

 

· 開(kāi)發(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)，以及為什么不能用其他方法來(lái)完成目標(biāo)。此文檔應(yīng)該分發(fā)給所有項(xiàng)目干系人，以便在項(xiàng)目開(kāi)始之前獲得早期反饋。書面記錄是必不可少的，因?yàn)樗_保對(duì)項(xiàng)目何時(shí)抵達(dá)成功以及如何達(dá)到目標(biāo)有一個(gè)清晰和一致的理解。

 

· 在項(xiàng)目的所有階段，大型組件的關(guān)鍵設(shè)計(jì)元素應(yīng)該在設(shè)計(jì)文檔中得到簡(jiǎn)明的解釋和記錄。

 

· 飛躍式創(chuàng)新。完成并部署一個(gè)飛躍式創(chuàng)新比追求完美更重要。不可能做到完美無(wú)暇。相反，要靈活，并計(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)成為敏捷開(kāi)發(fā)的同義詞。

 

作者介紹：

 

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