OOPAA

【注：本文是去年的舊文了，發表在《程序員》2009年2月期上。今日翻出來，炒炒現飯】

我們曾舉辦了一次為期三天的敏捷培訓，學員主要是一些知名軟件公司的項目經理和資深開發人員。培訓期間，我們帶領學員進行了豐富的游戲，通過寓教于樂的方式讓他們體驗了敏捷方法學的大部分知名實踐，并講解了敏捷方法學推崇的價值和原則。從學員的回顧以及意見表上可以看出培訓效果是顯著的，但是在培訓過程中學員也提到一些問題，主要是對敏捷方法學的實踐和價值比較疑惑。在回答問題的同時，我們能感覺到隨著敏捷方法學在國內被引入、被宣傳，很多軟件組織或人員對敏捷方法學都已經有了基本的了解，但是對敏捷方法學向軟件行業承諾的價值還存在不同程度的顧慮。

作為以“交付更多客戶價值”為核心原則之一的方法學，敏捷方法學向軟件行業承諾：敏捷方法學能提升軟件團隊交付能力，給客戶交付更多商業價值。為什么敏捷方法能做到這兩點承諾？軟件組織如果沒有實施過敏捷方法學，或者實施方法不得當，通常會對這兩點產生懷疑，從而對是否決心在組織內部實施敏捷產生猶豫和觀望情緒。那我們就來分析敏捷方法學是怎么做到的。

敏捷方法學提升交付能力

提升軟件團隊的交付能力，其實最好的辦法就是釋放團隊的軟件生產力，而不是試圖去規范它、約束它。這里，我們用“軟件生產力”來定義軟件團隊開發軟件的能力，包括軟件團隊在軟件開發過程中為了解決各種各樣的問題而使用的開發語言、開發工具以及開發實踐。

軟件生產力是不斷發展的。為了解決軟件開發過程中的問題，方法學才被提出來。從某種意義上講，只有方法學積極采納并改造新的軟件生產力，而不是因循守舊地墨守成規，才能真正釋放軟件團隊的軟件生產力。

那么問題就變成：敏捷方法學如何采納并改造現在的軟件生產力？

現在的軟件生產力

在開發語言方面，現在JVM/C#.NET是轉為平臺語言，支持在其基礎上多語言開發，比如Jruby，groovy，jython等語言就能在JVM上運行。原來不受重視的腳本語言，像ruby、python等也是重登大雅之堂，給軟件團體提供了更多的選擇。

IDE：現代IDE不只是集成了編碼、運行和調試功能的工具，而且是把應用程序開發的整個生命周期都納入管理，從分析建模、代碼編寫、配置管理、構建管理，再到測試的集成，突破了原來軟件過程里定義的各個環節的邊界。一些大受好評的IDE無不是內建了ALM的支持，并集成了軟件開發的大部分最佳實踐，如Intellij IDEA。

Build tool：自動構建越來越受到開發團隊的歡迎，Ant、nant、rake、gant……各種平臺各種語言的build工具不僅提供了豐富的build task，而且給開發人員進行擴展提供了足夠的自由度。至于maven，更是希望充當項目底層設施的角色，成為管理項目不可或缺的一部分。

Revision management tool：在項目開發過程中，版本管理是非常重要的一個部分。隨著技術的發展，VSS這種笨重的工具早已被沖進歷史的車輪。而且除了CVS、SVN這些central server的版本管理工具，分布式版本管理工具，如git、mercurial也是日益成熟。

前面只是簡單列舉了現在軟件開發過程會用到的一些工具，其實，現在的軟件開發實踐也有非常鮮明的特征。很多在日常開發中涌現出來的開發實踐，并不專屬于特定的軟件方法，卻早已得到業界的認可。

Developer unit test：自Kent Beck的junit框架發布以來，人們才意識到開發人員寫unit test也是如此的輕巧和方便。在其他語言方面，testNG、nunit、runit等測試框架也極大地推廣了單元測試的編寫。

Refactoring：重構是優化代碼設計的重要手段之一，在Martin Fowler出版Refactoring之后，才真正被大家所關注。up-front design就逐漸被日常開發中的incremental design所取代。而隨著對重構的研究，越來越多的相關書籍給開發人員提供了更多的實踐指導，比如Refactoring to Pattern等。

Periodic auto build：因為SCM工具和integration tools出現，自動構建越來越受到開發團隊的歡迎：一方面提高了軟件產品的質量，減少了產品對特定環境的依賴；另一方面減少了重復乏味的工作，也給開發團隊節省了時間和精力。像Cruisecontrol這樣的開源工具出現之后，自動構建就時時刻刻都在進行，并能及時給開發團隊提供反饋。
敏捷方法學釋放現在生產力

那么，敏捷方法學里面是如何對待這些軟件生產力呢？是不聞不問，還是積極采納它們，按照自己的價值觀和理念改造它們，進一步提供更有效的開發實踐呢？我們以一些知名敏捷實踐為例，看看這些實踐與當前軟件生產力之間是什么關系。

Test-Driven Development

TDD的實踐形式可以簡單地歸納成：添加足夠簡單使得失敗的測試，盡可能簡單地修改功能代碼使測試通過，重復這個過程；如果功能代碼產生了bad smell，你需要重構來消除。用簡單的方程式來描述，就是：

TDD = TFD + Refactoring

很明顯，這個最有名的實踐脫胎于unit test，又融合了重構的優點。“通過unit test可以改善代碼質量”、“持續重構可以改善程序設計”，這些觀點已經得到廣泛認可。敏捷方法把developer unit test和重構吸收進來又加以改造，使得開發人員通過小步前進的方式獲得更高的生產率，并交付更高質量的軟件。而IDE集成ALM工具，更是讓普通開發人員在應用TDD的開發過程中如虎添翼。

Pairing

Pairing 要求兩個人在一起結對工作，結對的雙方不要求都是開發人員，可以是開發人員與商務分析人員，或者開發人員與質量分析人員，又或者是商務分析人員與質量分析人員，甚至是團隊成員與客戶。

堅持代碼評審以及保持團隊概念一致性是兩項被很多經驗證明能提高生產率和交付質量的實踐。Pairing就把這兩者做到了極致：編碼設計的時候，始終有另外一個人在評審你的代碼，從一開始就杜絕了不良設計和代碼的引入；工作的時候，始終有另外一個人和你保持對概念理解的一致性，便于團隊保持概念一致性。

Continuous integration

有了持續集成服務器Cruisecontrol或者Cruise、自動構建工具ant等等、版本管理工具，以及其他代碼分析工具，比如測試覆蓋率工具、checkstyle工具，持續集成涉及的功能越來越強大，不僅能自動快捷地給開發團隊提供構建結果，而且能提供其他更多的分析結果以幫組開發團隊改進軟件質量。這樣，開發團隊通過快速得到構建反饋而提升了生產率，也可以憑借分析結果驗證交付軟件的質量。

敏捷方法實踐還有很多，比如Stories、story wall、stand up、retrospective等等。不管這些實踐形式如何，其實我們都能從它們身上看到已經存在并被證明能提升生產率的開發實踐。也就是說，敏捷方法學充分利用了已有的軟件開發工具和開發語言的威力，極大地采納了被證明了的軟件開發實踐，再按照一定的價值觀和理念進一步改進這些開發實踐。

從敏捷方法學對待現在軟件生產力的態度，我們可以說敏捷方法學面對新興軟件生產力是積極采納的，釋放了軟件團隊最大的軟件生產力，從而促進了軟件團隊交付能力的提升。

敏捷方法學給客戶交付更多價值

不管軟件開發中使用什么樣的開發方法學，最終交付的軟件是只有給客戶產生盡可能多的商業價值，軟件項目才能說是成功的。

對于傳統的形式化的、戒律森嚴的軟件工程方法學，不僅其要求生成的文檔數目和種類，而且需要的管理資源投入、QA評審的程度和開發人員被要求遵守的嚴格流程1，都極大地偏離了“給客戶交付價值”這個核心目標。因此，國際上一些著名的軟件工程專家將傳統的這些軟件方法稱之為“重（heavy）”方法，強調方法學對過程的極度嚴格要求。

與這些“重”方法不同，敏捷方法學就是以“給客戶交付價值”為核心原則之一，而不是強調對過程的過度嚴格的管理。不僅在敏捷價值和原則里面緊扣“客戶價值”，而且其所有實踐都是客戶價值驅動的。

對于軟件開發來講，客戶關心的價值在哪些方面呢？在Amr Elssamadisy的Agile Adoption Patterns一書中，定義了如下的客戶價值：

   1.  短的軟件交付周期
   2.  及時的響應用戶反饋
   3.  高的軟件質量
   4.  軟件的靈活性
   5.  項目團隊的透明性
   6.  低的軟件成本
   7.  高的投資回報率（ROI）

這些客戶價值都是緊密聯系在一起的，這里我們就只針對第1、3、7等三個方面來做一些相關的闡述。

   1.短的軟件交付周期

軟件交付得越早，交付周期越短，客戶就能越早通過使用軟件產品來創造自己的價值，特別是商業軟件：這是很顯然的。即使你交付的軟件只包括了完整功能列表里的一部分，但因為那對客戶而言是價值最高的部分，而且軟件是可以運轉的，客戶也就得到了更多的價值。不僅僅是完整周期的縮短，更頻繁的交付、增進的發布也能給客戶帶來商業價值。

在傳統軟件方法學里面，只有到軟件交付期限才能交付給客戶可用的軟件版本。整個軟件開發過程里面，客戶得不到一個可運行的版本來使用。這樣，就嚴重損害了客戶的價值。

在敏捷方法學里面，項目團隊通過INVEST的user story劃分，保證了客戶價值的周期性交付；通過簡單設計來保持關注對客戶而言優先級最高的user story，避免了對低價值的其他方面的付出；而通過持續集成來保證每個構建出來的版本都是客戶可用的候選發布版本……這樣，通過多種緊湊的實踐，敏捷方法學保證了項目團隊對客戶價值的關注和盡早實現，并隨時提供能滿足一定客戶價值的可用的軟件版本。

   2.高的軟件質量

軟件質量越高，也就意味著軟件的缺陷越少，提供的功能更加符合客戶真正想要的要求。而且，即使商業需求上發生了變化，高質量的軟件也容易進行擴展和修改。

在傳統軟件方法學里面，也有通過詳盡的user case設計、代碼評審、QA測試用例等方式來減少軟件可能出現的缺陷。但因為分析、設計、開發和測試等環節的脫節，不同環節之見的理解不同，溝通不暢，很難挖掘客戶真正的需求和適應需求變化，從而導致大部分最后的軟件要么是缺陷多多，要么是功能不能滿足客戶需求，只能留到二期三期來解決。

在敏捷方法學里面，項目團隊通過co-location，打破不同部門之間的隔板，讓所有的項目成員坐在一起，減少了軟件需求在溝通過程中的失真。如果有現場客戶，就更是讓這種信息失真問題減到最低。

在開發過程中，敏捷團隊會使用TDD、簡單設計和持續集成等實踐來保證軟件的簡單，讓可能存在的問題盡早的暴露出來；再通過小型sign off，來保證開發人員做出的軟件是滿足分析人員和測試人員的要求。

   3.高的投資回報率（ROI）

作為投資方，客戶最關心的莫過于投資回報率(ROI)了。除了前面分析的軟件質量和軟件成本之外，對ROI有直接影響的因素就是軟件生命周期了。軟件生命周期是指軟件的產生直到報廢的整個生命周期。生存周期越長，說明軟件能滿足用戶要求、能被使用的時間周期越長。而軟件生命周期又與軟件的可維護性和靈活性息息相關。那么，如何保證軟件的可維護性和靈活性，就是影響到客戶的ROI的關鍵因素。

在傳統軟件開發學里面，基本上只有靠一開始的軟件設計來提供軟件的靈活性。雖然開發過程上游的軟件設計的設計方案可能非常優雅，但由于中間過程沒有足夠的驗證和約束，等到軟件交付的時候，軟件最后實現的可維護性和靈活性完全不能保證。這樣，客戶就只能祈禱軟件的生命周期不要那么短了。

而在敏捷方法學里面，很多的開發實踐可以提升軟件產品的可維護性和靈活性，比如前面分析的TDD、持續集成和增進設計等等，從而使軟件的生命周期得到了極大的延長。因此，這些影響產品生命周期的實踐對客戶的投資回報率都是有直接或間接的影響。

從上面對三個特定的客戶價值的分析可以看出，敏捷方法實踐就是以“交付更多客戶價值”為出發點提出來的，始終體現了敏捷方法學的價值觀：“個體和交互勝過流程和工具，可工作的軟件勝過面面俱到的文檔，客戶合作勝過合同談判，響應變化勝過遵循計劃”，和以 “盡早、持續的交付有價值的軟件來使客戶滿意”原則為首的敏捷原則。

敏捷實施調查

2008年2月，Dr. Dobb's發起了一次有關敏捷開發技術實施情況的調查，共收到642份數據2。調查結果表明，實施敏捷的風險很低，并且調查結果顯示：實施敏捷方法之后，開發生產率得到提高的占82％，軟件交付質量得到提升的占77％，而客戶滿意度得到提升的則占78％。

2008年6月，敏捷工具廠商Versionone也發起一次敏捷開發實施情況的調查3，共收到來自80個國家3061個參與者提交的結果。大部分參與者都是敏捷的技術帶頭人、教練或是咨詢師，他們所處公司中，絕大部分的開發隊伍少于100人。他們給出的數據是：實施敏捷方法之后，開發生產率得到提高的占84％，軟件交付質量得到提升的占68％，69％的軟件項目加快了上市時間，而另外有74％的人認為項目風險降低了。

從上面兩次調查報告來看，在實施了敏捷方法學的軟件組織里面，絕大部分的組織都認為實施敏捷方法學之后，組織的軟件交付能力得到了提升，而且客戶的滿意度也得到了提高。也就是說，在絕大部分實施敏捷方法學的軟件組織里面，敏捷方法學承諾的兩個愿景得到了充分的印證。

結論

敏捷方法學承諾的“提升團隊交付能力，給客戶交付更多商業價值”的確能給項目團隊和軟件客戶帶來實實在在的好處。不僅有充足的理由，而且有充足的案例數據來證明這一點。面對商業價值日新月異的經濟趨勢，傳統的軟件方法學顯得束手無策，既不能滿足目前對軟件交付商業價值的要求，也極大地扼殺了軟件團隊的生產力和創造力。與“重”方法學不同，敏捷方法學只是提供了很少的幾種推薦實踐，然后再提供了遵循的價值和原則。敏捷方法學更希望軟件團體在開發過程中，根據客觀的實際情況，按照敏捷價值和原則，進行裁剪出適合團隊的軟件方法。基于此，也是越來越多的軟件組織投入的實施敏捷方法學的潮流中來。

1 http://dev.csdn.net/article/12/12726.shtm
2 http://www.ambysoft.com/downloads/surveys/AgileAdoption2008.ppt
3 http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf