OOPAA

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

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

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

敏捷方法學(xué)提升交付能力

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

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

那么問題就變成：敏捷方法學(xué)如何采納并改造現(xiàn)在的軟件生產(chǎn)力？

現(xiàn)在的軟件生產(chǎn)力

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

IDE：現(xiàn)代IDE不只是集成了編碼、運(yùn)行和調(diào)試功能的工具，而且是把應(yīng)用程序開發(fā)的整個生命周期都納入管理，從分析建模、代碼編寫、配置管理、構(gòu)建管理，再到測試的集成，突破了原來軟件過程里定義的各個環(huán)節(jié)的邊界。一些大受好評的IDE無不是內(nèi)建了ALM的支持，并集成了軟件開發(fā)的大部分最佳實(shí)踐，如Intellij IDEA。

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

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

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

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

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

Periodic auto build：因?yàn)镾CM工具和integration tools出現(xiàn)，自動構(gòu)建越來越受到開發(fā)團(tuán)隊(duì)的歡迎：一方面提高了軟件產(chǎn)品的質(zhì)量，減少了產(chǎn)品對特定環(huán)境的依賴；另一方面減少了重復(fù)乏味的工作，也給開發(fā)團(tuán)隊(duì)節(jié)省了時間和精力。像Cruisecontrol這樣的開源工具出現(xiàn)之后，自動構(gòu)建就時時刻刻都在進(jìn)行，并能及時給開發(fā)團(tuán)隊(duì)提供反饋。
敏捷方法學(xué)釋放現(xiàn)在生產(chǎn)力

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

Test-Driven Development

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

TDD = TFD + Refactoring

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

Pairing

Pairing 要求兩個人在一起結(jié)對工作，結(jié)對的雙方不要求都是開發(fā)人員，可以是開發(fā)人員與商務(wù)分析人員，或者開發(fā)人員與質(zhì)量分析人員，又或者是商務(wù)分析人員與質(zhì)量分析人員，甚至是團(tuán)隊(duì)成員與客戶。

堅(jiān)持代碼評審以及保持團(tuán)隊(duì)概念一致性是兩項(xiàng)被很多經(jīng)驗(yàn)證明能提高生產(chǎn)率和交付質(zhì)量的實(shí)踐。Pairing就把這兩者做到了極致：編碼設(shè)計(jì)的時候，始終有另外一個人在評審你的代碼，從一開始就杜絕了不良設(shè)計(jì)和代碼的引入；工作的時候，始終有另外一個人和你保持對概念理解的一致性，便于團(tuán)隊(duì)保持概念一致性。

Continuous integration

有了持續(xù)集成服務(wù)器Cruisecontrol或者Cruise、自動構(gòu)建工具ant等等、版本管理工具，以及其他代碼分析工具，比如測試覆蓋率工具、checkstyle工具，持續(xù)集成涉及的功能越來越強(qiáng)大，不僅能自動快捷地給開發(fā)團(tuán)隊(duì)提供構(gòu)建結(jié)果，而且能提供其他更多的分析結(jié)果以幫組開發(fā)團(tuán)隊(duì)改進(jìn)軟件質(zhì)量。這樣，開發(fā)團(tuán)隊(duì)通過快速得到構(gòu)建反饋而提升了生產(chǎn)率，也可以憑借分析結(jié)果驗(yàn)證交付軟件的質(zhì)量。

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

從敏捷方法學(xué)對待現(xiàn)在軟件生產(chǎn)力的態(tài)度，我們可以說敏捷方法學(xué)面對新興軟件生產(chǎn)力是積極采納的，釋放了軟件團(tuán)隊(duì)最大的軟件生產(chǎn)力，從而促進(jìn)了軟件團(tuán)隊(duì)交付能力的提升。

敏捷方法學(xué)給客戶交付更多價(jià)值

不管軟件開發(fā)中使用什么樣的開發(fā)方法學(xué)，最終交付的軟件是只有給客戶產(chǎn)生盡可能多的商業(yè)價(jià)值，軟件項(xiàng)目才能說是成功的。

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

與這些“重”方法不同，敏捷方法學(xué)就是以“給客戶交付價(jià)值”為核心原則之一，而不是強(qiáng)調(diào)對過程的過度嚴(yán)格的管理。不僅在敏捷價(jià)值和原則里面緊扣“客戶價(jià)值”，而且其所有實(shí)踐都是客戶價(jià)值驅(qū)動的。

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

   1.  短的軟件交付周期
   2.  及時的響應(yīng)用戶反饋
   3.  高的軟件質(zhì)量
   4.  軟件的靈活性
   5.  項(xiàng)目團(tuán)隊(duì)的透明性
   6.  低的軟件成本
   7.  高的投資回報(bào)率（ROI）

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

   1.短的軟件交付周期

軟件交付得越早，交付周期越短，客戶就能越早通過使用軟件產(chǎn)品來創(chuàng)造自己的價(jià)值，特別是商業(yè)軟件：這是很顯然的。即使你交付的軟件只包括了完整功能列表里的一部分，但因?yàn)槟菍蛻舳允莾r(jià)值最高的部分，而且軟件是可以運(yùn)轉(zhuǎn)的，客戶也就得到了更多的價(jià)值。不僅僅是完整周期的縮短，更頻繁的交付、增進(jìn)的發(fā)布也能給客戶帶來商業(yè)價(jià)值。

在傳統(tǒng)軟件方法學(xué)里面，只有到軟件交付期限才能交付給客戶可用的軟件版本。整個軟件開發(fā)過程里面，客戶得不到一個可運(yùn)行的版本來使用。這樣，就嚴(yán)重?fù)p害了客戶的價(jià)值。

在敏捷方法學(xué)里面，項(xiàng)目團(tuán)隊(duì)通過INVEST的user story劃分，保證了客戶價(jià)值的周期性交付；通過簡單設(shè)計(jì)來保持關(guān)注對客戶而言優(yōu)先級最高的user story，避免了對低價(jià)值的其他方面的付出；而通過持續(xù)集成來保證每個構(gòu)建出來的版本都是客戶可用的候選發(fā)布版本……這樣，通過多種緊湊的實(shí)踐，敏捷方法學(xué)保證了項(xiàng)目團(tuán)隊(duì)對客戶價(jià)值的關(guān)注和盡早實(shí)現(xiàn)，并隨時提供能滿足一定客戶價(jià)值的可用的軟件版本。

   2.高的軟件質(zhì)量

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

在傳統(tǒng)軟件方法學(xué)里面，也有通過詳盡的user case設(shè)計(jì)、代碼評審、QA測試用例等方式來減少軟件可能出現(xiàn)的缺陷。但因?yàn)榉治觥⒃O(shè)計(jì)、開發(fā)和測試等環(huán)節(jié)的脫節(jié)，不同環(huán)節(jié)之見的理解不同，溝通不暢，很難挖掘客戶真正的需求和適應(yīng)需求變化，從而導(dǎo)致大部分最后的軟件要么是缺陷多多，要么是功能不能滿足客戶需求，只能留到二期三期來解決。

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

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

   3.高的投資回報(bào)率（ROI）

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

在傳統(tǒng)軟件開發(fā)學(xué)里面，基本上只有靠一開始的軟件設(shè)計(jì)來提供軟件的靈活性。雖然開發(fā)過程上游的軟件設(shè)計(jì)的設(shè)計(jì)方案可能非常優(yōu)雅，但由于中間過程沒有足夠的驗(yàn)證和約束，等到軟件交付的時候，軟件最后實(shí)現(xiàn)的可維護(hù)性和靈活性完全不能保證。這樣，客戶就只能祈禱軟件的生命周期不要那么短了。

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

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

敏捷實(shí)施調(diào)查

2008年2月，Dr. Dobb's發(fā)起了一次有關(guān)敏捷開發(fā)技術(shù)實(shí)施情況的調(diào)查，共收到642份數(shù)據(jù)2。調(diào)查結(jié)果表明，實(shí)施敏捷的風(fēng)險(xiǎn)很低，并且調(diào)查結(jié)果顯示：實(shí)施敏捷方法之后，開發(fā)生產(chǎn)率得到提高的占82％，軟件交付質(zhì)量得到提升的占77％，而客戶滿意度得到提升的則占78％。

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

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

結(jié)論

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

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