軟件項(xiàng)目管理中的“敏捷流程”

1991年秋，在美國勒海大學(xué)亞科卡學(xué)院的一份研究報(bào)告《21世紀(jì)美國制造業(yè)的戰(zhàn)略：一個(gè)工業(yè)主導(dǎo)的觀點(diǎn)》中，首次提出了敏捷競爭的概念。何謂敏捷（Agility）？對于企業(yè)而言，敏捷意味著企業(yè)能夠在顧客機(jī)會(huì)不斷變化、難以預(yù)測的競爭環(huán)境中贏利運(yùn)營；對于個(gè)人而言，敏捷指在企業(yè)對難以預(yù)測的顧客機(jī)會(huì)做出反應(yīng)，不斷重組其人力和技術(shù)資源的過程中，個(gè)人能夠?qū)A利底線做出貢獻(xiàn)，提高企業(yè)的凈收入。因此，敏捷可以看作是對變化和不確定的全面反應(yīng)。

變化和不確定，對于軟件業(yè)來說，是多么熟悉而又讓人煩惱的名詞。軟件工程自誕生以來，一直試圖通過技術(shù)和管理的手段來降低軟件項(xiàng)目的不確定性。在這個(gè)美好的愿景指導(dǎo)下，專家們發(fā)明了結(jié)構(gòu)化、發(fā)明了面向?qū)ο?、發(fā)明了CMM，這些新的技術(shù)和方法的確有助于“軟件危機(jī)”的解決，促進(jìn)了軟件業(yè)的發(fā)展；然而，超支、超時(shí)、低質(zhì)量的老問題并未得到根本解決。為了對抗不確定，軟件開發(fā)越來越復(fù)雜，越來越龐大，傳統(tǒng)的重量級（Heavy Weight）方法的副作用也越來越明顯——組織臃腫、辦事低效、官僚主義...

相對于重量級方法，軟件業(yè)一直有另一種聲音在，那就是輕量級方法（Light Weight），其目標(biāo)是以較小的代價(jià)獲得重量級相當(dāng)?shù)男Ч?/P>

最負(fù)盛名的輕量級方法是XP。XP是Extreme Programming的縮寫，從字面上可以譯為極端編程。但是，XP并不僅僅是一種編程方法，也不是中文中理解的那種不可理喻的“極端”化做法。實(shí)際上，XP是一種審慎的（deliberate）、有紀(jì)律（disciplined）的軟件生產(chǎn)方法。XP（Extreme Programming）植根于上個(gè)世紀(jì)80年代后期的Smalltalk社區(qū)。90年代，Kent Beck和Ward Cunningham把他們使用Smalltalk開發(fā)軟件的項(xiàng)目經(jīng)驗(yàn)總結(jié)和擴(kuò)展，逐步形成了一種強(qiáng)調(diào)適應(yīng)和以人為導(dǎo)向的軟件開發(fā)方法。

XP的核心是四大價(jià)值，即改善溝通（communication），尋求簡單（simplicity），獲得反饋（feedback）和富有勇氣（courage）。在此基礎(chǔ)上，XP總結(jié)出了軟件生產(chǎn)的十余條做法（practice），涉及軟件設(shè)計(jì)、測試、編碼、發(fā)布等各個(gè)環(huán)節(jié)。與其它輕量級方法相比，XP獨(dú)一無二的突出了測試的重要性，甚至將測試作為整個(gè)開發(fā)的基礎(chǔ)，每個(gè)開發(fā)人員不僅要書寫軟件產(chǎn)品的代碼，同時(shí)也必須書寫相應(yīng)的測試代碼；所有這些代碼通過持續(xù)構(gòu)建和集成（Continuous Build & Integration）為下一步的開發(fā)打定了一個(gè)高度穩(wěn)定的基礎(chǔ)平臺。有了這樣的基礎(chǔ)平臺的保證，XP就可以實(shí)施軟件設(shè)計(jì)的再造（Refactoring）。XP的設(shè)計(jì)理念是，在每次迭代周期僅僅設(shè)計(jì)這次迭代所要求的產(chǎn)品功能，上次迭代周期中的設(shè)計(jì)通過Refactoring形成此次的設(shè)計(jì)。

2001年2月，在美國猶他州的一個(gè)滑雪場，17位輕量級軟件開發(fā)方法的創(chuàng)始人和專家，包括Kent Beck（Extreme Programming）、Alistair Cockburn（Crystal Methodologies）、Jim Highsmith（Adaptive Software Development）等等，共同發(fā)布了“The Manifesto for Agile Software Development”（敏捷軟件開發(fā)宣言）。這表明，在軟業(yè)經(jīng)歷了無數(shù)次的項(xiàng)目失敗之后，人們開始反思軟件開發(fā)的工程特性，反思計(jì)劃和控制的有效性，反思過去對于不確定性的態(tài)度和反應(yīng)。敏捷終于為這個(gè)行業(yè)，以及這個(gè)行業(yè)中的一些人所認(rèn)識、理解和推崇。

與會(huì)者之一Martine Fowler在其后來的文章“The New Methodology”中這樣解釋重量級、輕量級和敏捷：

輕量級與重量級的差異來自于人們對兩種方法的文檔數(shù)量的直觀感受，即輕量級方法較少產(chǎn)生和依賴于龐大的文檔，但這只是一個(gè)表面現(xiàn)象；在諸多的輕量級方法之間存在著很多相通的地方，敏捷更恰當(dāng)?shù)谋磉_(dá)了這些輕量級方法的最根本之處。

首先，敏捷強(qiáng)調(diào)適應(yīng)，而非預(yù)測。重量級方法花費(fèi)大量的人力物力，試圖制訂詳細(xì)的計(jì)劃來指導(dǎo)長期的工作，而一旦情況變化，那么計(jì)劃就不再適用。因此本質(zhì)上重量級方法是抵制變化的，而敏捷方法則強(qiáng)調(diào)適應(yīng)變化。其次，敏捷方法以人為中心，而非以流程為中心（即以事為中心）。敏捷方法強(qiáng)調(diào)軟件開發(fā)應(yīng)順乎本心（work with people's nature ），軟件開發(fā)應(yīng)帶來樂趣。

敏捷流程（Agile Process）汲取眾多輕量級方法的“精華”，更加強(qiáng)調(diào)對變化的適應(yīng)和對人性的關(guān)注。除了上面介紹的XP以外，其他知名的敏捷流程包括：

1.Crystal

Cystal事實(shí)上不是一種開發(fā)方法，而是一系列的方法。因?yàn)镃rystal的發(fā)明人Alistair Cockburn認(rèn)為，不同類型的項(xiàng)目需要采用不同的方法。Alistair Cockburn從兩個(gè)維度來劃分項(xiàng)目，一是項(xiàng)目規(guī)模，以人數(shù)計(jì)算；二是產(chǎn)品發(fā)生錯(cuò)誤的后果，以嚴(yán)重性計(jì)算。

Crystal方法集也形成于90年代，當(dāng)時(shí)，Cockburn接受了IBM的任務(wù)去寫一些關(guān)于開發(fā)方法的東西。相對而言，Crystal的個(gè)人色彩要淡些，因?yàn)樗粌H來源于Cockburn的個(gè)人經(jīng)驗(yàn)，而且也來源于Cockburn走訪的很多不同的項(xiàng)目；而Cockburn本人也較為思想開放，樂于接受“異見”。

在以人為導(dǎo)向上，Crystal和其他敏捷方法有些差異。在Cockburn看來，自由是人之本性，要人遵守紀(jì)律總是有難度的；因此，要在工作生產(chǎn)率和流程的紀(jì)律性之間作一權(quán)衡。流程要易于遵照執(zhí)行，而這是以犧牲生產(chǎn)率為代價(jià)的。Cockburn認(rèn)為，XP的流程規(guī)范仍太復(fù)雜和難于執(zhí)行，而采用Crystal雖然生產(chǎn)率不如XP，但開發(fā)人員更樂于采用。Cystal也強(qiáng)調(diào)在每個(gè)迭代后的Review，并以此進(jìn)行Cystal方法的自身改進(jìn)。

2. ASD

ASD（Adaptive Software Development）的發(fā)明人Jim Highsmith本來是一個(gè)傳統(tǒng)開發(fā)方法的工作者，他有多年的預(yù)測型方法的研究、教學(xué)和實(shí)施經(jīng)驗(yàn)，但后來，他發(fā)現(xiàn)這些預(yù)測型方法根本就存在很大缺陷，尤其不適合當(dāng)前的軟件業(yè)務(wù)。

ASD強(qiáng)調(diào)開發(fā)方法的適應(yīng)性（Adaptive），這一思想來源于復(fù)雜系統(tǒng)的混沌理論。ASD不象其他方法那樣有很多具體的實(shí)踐做法，它更側(cè)重為ASD的重要性提供最根本的基礎(chǔ)，并從更高的組織和管理層次來闡述開發(fā)方法為什么要具備適應(yīng)性。

3. SCRUM

SCRUM同樣也包括了很多具體做法，這些做法并無多少特別之處，但多數(shù)有一個(gè)“怪異”的名稱。比如，SCRUM將開發(fā)過程劃分為30天的迭代周期，每個(gè)迭代周期叫做一個(gè)Sprint；每天有一個(gè)15分鐘的短會(huì)，用來決定第二天的任務(wù)安排，這樣的短會(huì)就叫做scrum。

SCRUM較為有特色的，是它特別強(qiáng)調(diào)開發(fā)隊(duì)伍和管理層的交流協(xié)作。每天，開發(fā)隊(duì)伍都會(huì)向管理層匯報(bào)進(jìn)度，如果有問題，也會(huì)向管理層要求幫助解決。

4. FDD

FDD（Feature Driven Development）的發(fā)明人是Jeff De Luca和Peter Coad。FDD在OO社區(qū)較為人所知。FDD定義了5個(gè)流程，分別是Develop an Overall Model、Build a Features List、Plan by Feature、Design by Feature和Build by Feature。其中前3個(gè)流程是在項(xiàng)目開始就進(jìn)行的，而后兩個(gè)則出現(xiàn)在每次迭代周期中。FDD的迭代周期是兩周。每個(gè)流程被劃分為不同的任務(wù)和相應(yīng)的驗(yàn)證標(biāo)準(zhǔn)。

開發(fā)人員被歸為兩種，一種是主程序員，另一種是class所有者。主程序員不作具體的編程工作，但要負(fù)責(zé)將Feature和Class對應(yīng)起來，并充當(dāng)開發(fā)協(xié)調(diào)者、設(shè)計(jì)者、技術(shù)支持和指導(dǎo)者等；class所有者則進(jìn)行實(shí)際的編程。

在軟件業(yè)，敏捷流程還猶如星星之火，特別是在國內(nèi)，敏捷流程還鮮為人知。在即將到來的未來，敏捷流程將何去何從，中國的軟件從業(yè)者又將在其中扮演何種的角色，套用一句中國的古話，“路漫漫其修遠(yuǎn)兮，吾將上下而求索”。