001-敏捷方法與大型互聯網系統開發-前沿

【導讀】這是阿里技術嘉年華髮表於segmentfault的第一篇文章，感謝高陽給了測試資格。接下來阿里技術嘉年華將在segmentfault圍繞項目管理、敏捷實踐、淘寶搜索算法、個性化推薦、導航、反做弊等方面發表若干原創技術幹活。本帳號由阿里巴巴集團-技術發展部-新媒體相關的同窗在負責維護，有任何問題請經過campus#alibaba-inc.com(請將#替換成@)與咱們取得聯繫，謝謝：）

文/一玄

目前，我國的互聯網商業發展十分迅速，許多公司將其商業模型和業務系統基於互聯網進行構建，掀起了互聯網系統開發的又一波熱潮。

穩定、可用性高、質量好的互聯網應用，對於在商業上取得成功具有極其重要的意義。同時，可以以最快的速度、最高的效率和最低的成本響應用戶需求、根據商業運營狀況進行快速的適應調整，對於在競爭激烈的互聯網行業中立於不敗之地，具備極其關鍵的做用。而興起於20世紀末、流行於本世紀的敏捷軟件開發方法，被認爲是應對複雜軟件系統開發的有效途徑。

基於此，本文將把敏捷軟件方法學中的核心原則和實踐，與面向公衆的大型互聯網系統的開發結合起來，研究如何在大型互聯網系統的開發中吸取採納敏捷軟件開發方法的精髓，以更快速度、更好質量和更低成本，進行互聯網軟件的開發。

互聯網開發的一些現狀

隨着互聯網的普及、計算機相關技術書籍和期刊的廣爲發行，以及大量相關的專題網站和技術社區的推廣，敏捷思想和敏捷軟件開發方法已經爲國內的IT界所瞭解。敏捷軟件開發的內容也已經逐漸走入正統的軟件工程教材，走入大專院校的課堂。許多軟件開發組織也正在接觸和實踐敏捷軟件開發方法。

但從總體宏觀上看，敏捷軟件方法在中國還處於剛剛開始被瞭解、逐步被採納的階段。

中國已經有一些軟件開發組織在近幾年開始使用敏捷方法，雖然目前數量還較少，並且大部分使用敏捷方法的公司都集中在外資的跨國企業如IBM、SUN等在中國的研發團隊，以及一些外資軟件外包和專業的敏捷開發諮詢服務公司如ThoughtWorks公司等。同時有一些比較前沿的國內公司也在率先學習、採納和實踐、推廣敏捷軟件開發方法。從宏觀總體而言，能夠說當前中國國內的敏捷軟件開發方法，仍然處於技術採納生命週期的初期試用階段。

互聯網是一個「快魚吃慢魚」的行業，也是競爭最爲激烈、變化最爲迅猛的行業。如何在競爭激烈、變化迅猛的互聯網行業中脫穎而出，並長期立於不敗之地？敏捷軟件開發方法的理念和實踐，讓互聯網行業中的許多公司看到了新的方向。敏捷軟件開發開始在國際國內的許多互聯網公司中掀起了革命。

一些著名的國際互聯網公司如Google,Microsoft和Yahoo!以及衆多的新興Web 2.0互聯網公司已經開始轉向全面採用敏捷開發，其中Scrum和XP被使用的最多。並且其中很多已經有了較長時間的實踐經驗。

好比，Yahoo！公司在2002年時，最初使用的是公司內部定義的一個相似瀑布模型的PDP方法。但是，到2005年時，它發現須要新的方法來應對互聯網產品的複雜性和多變性，而PDP在應對快速的市場變化方面根本沒法與敏捷方法相提並論。所以，在2005年Yahoo！在美國、歐洲和亞太地區開始選擇實施敏捷方法學中的Scrum方法，進行互聯網軟件產品的開發。最初僅選擇了四個團隊進行嘗試。到2008爲止，已有近200個團隊在不一樣程度上使用了Scrum。雖然在實施過程當中，也出現過很多問題，但平均而言，全部參與敏捷實施的這些團隊，其生產效率提升了30~40%。對於一個企業來講，這並非一個小數目。

在Google公司中，敏捷軟件開發的理念和應用則更爲明顯。Google的許多產品都打上Beta的標籤，也就是在告訴用戶，Google的產品一直在根據用戶的反饋進行不斷的演化發展中，Google的開發團隊會根據用戶反饋來及時調整產品的方法，是一種典型的敏捷開發方法。另外，Google的軟件開發團隊具有使人矚目的創新能力，而其由軟件開發精英人才組成的敏捷產品開發小組做戰模式，是Google可以持續創新的關鍵因素之一。這些都具備敏捷軟件開發理念的深入痕跡。

中國許多互聯網公司的開發團隊，在這幾年中也在逐漸接受並應用相似的敏捷軟件開發模式。許多公司正在不斷學習、引入和實踐敏捷軟件開發模式，並逐步造成各自的實踐框架。其餘國內很多新興的Web 2.0互聯網公司，在吸納敏捷方法上，也有活躍的表現。

但因爲傳統的瀑布式軟件開發模型在中國具備較長時期的影響，許多軟件公司都先入爲主的採用瀑布式方法，互聯網公司中也有不少人員是從傳統的軟件開發組織轉入互聯網系統開發，對瀑布方法已經有了根深蒂固的思惟定勢。加之，敏捷軟件方法在中國互聯網公司內的採納和實施也不多是垂手可得的，目前整體上看，即便那些在採用敏捷方法上起步較早的互聯網公司，也仍是處於「起步」階段向「探索」階段過渡的時期。在這些公司中，也還須要對敏捷軟件開發進行大量的學習、研究、實踐、適配和整合。

在闡述敏捷軟件開發方法以前，有必要首先來分析總結廣爲流傳和使用的瀑布式開發模型的簡陋和嚴重弊端。

瀑布式開發模型的弊端

重量型的軟件開發方法學，其基礎模型是所謂的「瀑布式開發模型(Waterfall Model)」。軟件開發的瀑布模型，將整個軟件過程分解爲按照固定順序完成的一系列單獨階段：整個過程，從需求、設計、實現、測試、部署到維護，按順序進行。整個開發過程看起來就像是瀑布同樣，逐次通過這些階段。開發過程當中的每一個階段，都有明確的起始點和結束點。若是上一個階段的結束點沒有完成，則不能進入到下一階段的活動中；而一旦已經進入到下一階段中，就沒法再回到上一個階段的活動。

這種模型的概念看起來很是簡單，易於理解和掌握；加之，在軟件開發組織中的許多管理者，通常而言，他們也都很喜歡可以有一系列固定的里程碑，以可以很方便地對開發過程的進度進行跟蹤。瀑布式模型乍看之下很是符合這種須要。可是，因爲瀑布模型是一個僵硬固化、不容許在過程當中發生變化的模型，忽略了軟件開發活動複雜現實，是一個過於簡陋的模型，因此事實上很難得到理想中的可管理性。

事實上，軟件開發活動是一個高度動態、須要很是強的適應性、須要不斷根據反饋進行調整的過程。在這個過程當中，十分容易發生各類各樣的變化和調整，好比需求的變動、投資計劃的變動、進度計劃的變動等，這些變化通常而言是不可避免的；即便到了實現階段，也可能會發現最初的設計存有問題，必須進行調整修正等；並且，因爲軟件開發通常而言都有一個比較長的週期，使用瀑布模型時，因爲客戶沒法提早確切知道他們所想要的一切東西，需求變動的問題尤爲沒法避免。並且，客戶只有在最終階段，纔可以看到和使用真實的項目成果，這時若是發現實際產物和本身所需差異很大，則可能帶來巨大的商業損失。

對許多軟件項目的跟蹤研究結果代表，開發組織的生產力降低、軟件缺陷率攀升和項目的失敗，都和採用瀑布方法呈正相關性。

1970年，Winston Royce在《Proceedings of the IEEEWestcon》上發表了一篇題爲《管理大型軟件系統的開發》的論文。在這篇論文中，Royce首次描述了瀑布方法，但他其實是要推薦一種與流行的瀑布模型不一樣的方法，羅伊斯提到瀑布方法是「風險重重和易於招致失敗」的，瀑布模型是最簡單一種過程描述，毫不是放之四海皆準的法寶，事實上它只適用於最簡單的項目。這篇論文傾向提倡使用迭代式開發模型來改進和替代瀑布方法。

美國國防部在20世紀八十年代，針對軟件開發頒佈了標準DOD-STD-2167，這是一個基於瀑布模型與文檔驅動的方法。以後，美國國防部發現遵循瀑布方法和2167標準給他們在軟件開發上帶來了許多失敗的項目，栽了不少跟斗。以後，美國國防部通過研究，決定廢棄DOD-STD-2167和它的改良標準DOD-STD-2167A，在1994年以MIL-STD-498取代。

可是，因爲長期的傳播，瀑布式開發模型在許多軟件開發組織和軟件工程教科書中先入爲主的危害已經造成。縱觀科學史，簡單的思想每每在一開始會佔據主要的位置。軟件開發是一個全新的領域，所以，在開始階段遵循「需求、設計、編碼、測試」的簡單公式來試圖建立技能化的開發過程也就不足爲奇。不少軟件採購組織、軟件開發從業人員對此已經造成根深蒂固的強烈思惟定式。

好比，DOD-STD-2167影響了美國外的許多國家的標準定義。這些國家尚未了解到美國國防部後來摒棄了2167標準和瀑布方法；這些國家的標準體系中有至關一部分仍然強調瀑布式的文檔驅動的開發過程。

再好比，20世紀80年代後期和90年代期間，軟件工程學院(SEI)的軟件成熟度模型(CMM)在業界頗具影響，它也仍是倡導文檔驅動、計劃驅動、面向階段和預見性計劃，其指導思想仍是基於瀑布模型的實踐和指令型過程。早期的項目管理學會(PMI)和項目管理知識體系(PMBOK)，也是鼓吹「計劃工做，而後按計劃工做」、分階段的預見性計劃，在本質上其思惟範式也是瀑布模型。

萌芽於20世紀80年代、興起於20世紀90年代的輕量型方法和本世紀初的敏捷軟件開發方法(Agile Software Development, ASD)，開始試圖改變和扭轉這種局面。

下期我們來聊聊互聯網學習型敏捷研發組織的構建及策略，請繼續關注。