中國軟件呼喚敏捷過程

發展現狀

國際軟件過程領域的敏捷運動源于 2001 年敏捷聯盟在美國成立和《敏捷宣言》的正式發表。敏捷軟件運動代表了 21 世紀互聯網時代軟件開發模式的一種先進理念和價值觀，相比傳統過程，敏捷更強調快速靈活反應，主動迎接和適應變化，主張更緊密的客戶與開發商協作和以人為本的企業可持續發展。典型的敏捷過程模型有 XP（極限編程）、FDD（特性驅動開發）、Scrum 以及敏捷的統一過程（AUP）等。

我國軟件人員了解、嘗試敏捷大概始于 2002 年前后一批 XP 敏捷系列圖書在國內的引進出版以及早期相關文章的探討和報道�？傮w上敏捷過程在我國發展得還比較緩慢，可以說是剛剛起步。當前采用敏捷方法的企業以外資、成熟、領導型企業居多，大部分國內企業目前可能還處在了解、觀望的階段，對敏捷過程、方法的認知接受程度也偏低。這種媒體熱、企業冷的猶豫現象一方面可能與五年來的 CMM 考級熱有關，另一方面也可能與市場上某些對 XP 極端做法、敏捷功效神乎其神的夸大宣傳有關。

軟件過程改進是我國軟件企業提升競爭力、獲得可持續發展的一條重要途徑。一方面，大多數以快速短迭代為特征的敏捷過程有助于消除錯誤實施 ISO、CMM 帶來的官僚主義、形式主義等消極后果。另一方面，許多軟件客戶和技術主管們對有些 XP 擁護者鼓吹幾乎不留設計文檔、主要依賴源代碼說明的做法存有很大的疑慮，這種工作方式與強調過程文檔化、數字化的 ISO 9000、CMM 理念有著顯著差別，卻得到了我國許多本來就不善于抽象表達設計的程序員們的熱烈“擁戴”。

關于國內企業具體采用的典型過程種類，雖然偶爾有零星的 XP 案例報道，但我們發現實際采用類 RUP/UP 過程的遠比 XP 多，FDD 偶爾有聽說，Scrum 則很少。有一種比較流行、可能比較接近現實的說法是：70% 甚至更多的國內軟件企業實際上采用的既不是 RUP、XP，也不是 TSP、PSP，而是一種“什么都像、什么也都不像”的自釀過程。

據說目前國內已有 500 多家軟件企業通過了各級 CMM 評估，而 2005 年標志著 CMM 時代的結束，取而代之的是 CMMI（集成的過程能力成熟度模型）。 CMMI 框架相比 CMM 更加成熟、更加健全，也更加靈活和敏捷。 CMMI 的敏捷化以及原本實施 CMM、CMMI 的軟件企業過程的敏捷化是一個值得我們關注的方向。

在看到 CMM 由熱趨冷、敏捷由冷轉熱的同時，我們還應看到以 RUP 為代表的統一軟件過程（UP）家族的興起。 RUP 的獨特之處在于它采用 OO 技術對軟件開發過程本身進行業務建模，在一個成熟靈活的抽象框架之內統一、集成了迭代開發、用例驅動、UML 可視化建模、OOAD、架構設計、變更配置管理、質量管理、項目管理等許多主流先進的當代軟件工藝。在統一過程基礎上結合敏捷實踐的敏捷統一過程（AUP，Agile UP）也成為很多企業的現實選擇。

問題與挑戰

在學習、傳播和實踐敏捷的過程中，我們發現國內對敏捷過程存在著以下一些誤區。有不少人誤認為“敏捷就是 XP ”。事實上，敏捷并不等于“極限”。 Kent Beck 等人發明的 XP 只是眾多敏捷方法中的一種，國際上除 XP 外還有 Agile UP、Scrum、FDD、DSDM 等許多成熟的、著名的敏捷過程和方法。 XP 獲得了更多的媒體曝光度和影響力，可能與其推廣者的積極努力，有關機構投入了更多的媒體公關、市場資源有關。 “敏捷”代表了一整套價值觀、原則和實踐方法，把敏捷宣傳簡單狹隘地等同于推廣 XP 將會阻礙敏捷在我國得到更為廣泛的認同和應用。

還有一種常見的偏見認為 XP（極限編程）帶了“編程”二字，表明它是“咱們”程序員自己提出來的“草根”方法，具備此般的親和力自然極容易自下而上地引起程序員的共鳴，而其他各種所謂的“傳統”過程統統是管理者、“外行人”自上而下提出來的，離“咱們”程序員的實際很遠。這種看法顯然是幼稚和片面的。實際上，像 TSP、UP、XP 等等各類著名的過程方法均是由世界上開發不同應用的各類優秀程序員在軟件工程歷史上的不同發展階段分別提出來的。這些過程方法各有各的適用性，無絕對的好壞之分，只有根據自己項目和團隊的實際情況選擇適用的方法才是明智之舉。

我們還發現國內不少公開報道的 XP、UP 應用案例實際上采用的并不是真正意義上的 XP 或 UP。一方面許多自詡的敏捷實施者并沒有真正理解 XP、UP 這些經典過程方法的含義，另一方面許多“軟件原教旨主義者”又滿腔熱情地打著大師崇拜的旗號追求純而又純的 XP、UP 或 CMM 過程，認為它們都是鋼板一塊，斷不可以修改定制。我們知道越是極限、極端的東西，其適用面往往也就越小。還有些人總是把 CMM、ISO 與敏捷對立起來，可為什么我們不能學習 Kent Beck，在實際過程中吸收 XP 的 TDD、重構、結對編程、持續集成等聰明的做法？當然可以。而且，說不定這種混合集成的、符合中國企業自身特點的敏捷統一過程比“純潔、標準、絕對”的 XP、RUP 或 TSP 風險更小、收效更大。

在我國推廣和實施敏捷面臨著一些重要挑戰。敏捷化進程是我國軟件企業管理從過去的粗放模式轉變為現代化精細模式的一個提升過程和發展契機，而軟件開發的敏捷性也并不是任何人可以輕易獲得的。敏捷的基礎包括迭代遞增式開發（IID）、面向對象的分析設計（OOAD）等核心技能，國際軟件的領導企業 15 年來早已完成了相應的工藝升級和變革，而據我們觀察，國內的軟件開發目前仍然是以陳舊的類瀑布式過程為主，高于具體編程語言的 OO 技術也未得到深入、廣泛和扎實的運用。所以敏捷企業要成功，能否很好地實施迭代過程、提升 OO 技能是關鍵。

此外，軟件工程、過程的敏捷化也不僅僅是軟件開發人員單方面的事情，敏捷過程實施的成功在很大程度上依賴于客戶的支持與配合。國內不成熟的行業客戶往往習慣于“瀑布”思維，在招投標階段既固定項目的費用和工期，又固定項目的功能范圍（筆者戲稱其為“三固定”），結果往往導致項目質量的損失，而許多項目最終的真實狀況往往是既延期又超支，費用、工期、范圍實際上一個也確保不了。這種盲目的客戶合同與合作方式不但明顯違背科學規律，也給軟件企業、行業的健康發展帶來了嚴重障礙。

趨勢與機會

假如問軟件產品、系統的客戶、軟件企業的老總們，您欣賞什么樣的軟件開發過程？成熟、集成、敏捷、統一、先進 …… 可能沒有人會拒絕這些美麗的話語，如此過程必然也是所有人（包括廣大程序員在內）的追求。然而何謂“成熟”的軟件過程？不同行業、不同領域的軟件開發可能有各自不同的定義和評判標準。我們認為，軟件過程的敏捷化、統一化（含集成化）是必然的趨勢， 21 世紀的軟件過程沒有敏捷、統一的要素又怎能稱之為“成熟”？

我國軟件要不要走規�；�的產業之路？沒有規�；�，中國軟件就沒有出路。規�；�并不會必然導致官僚、臃腫、遲鈍等大企業病。15 年來 CMM/CMMI、RUP、XP 等等經典過程模型方法的出現標志著國際軟件工程、工藝的空前發展和高度成熟，遺憾的是我國民用軟件工程在開發過程、工藝標準等方面似乎一直是乏善可成、鮮有成就，造成這一差距的原因可能就在于我們過去始終樂于忙忙碌碌，卻沒能及時很好地總結自己的經驗教訓。敏捷、統一是當代成熟軟件過程發展的主旋律，我們認為參考 CMMI 框架、結合 RUP、XP、Scrum 等最佳實踐的敏捷、統一、集成的過程之路更適合以中小企業居多的中國軟件行業的現狀，我國軟件企業和產業迫切需要建立屬于自己國家和地域的“審美標準”，應該而且有條件提出有中國特色的軟件過程評價標準和參考模型。