3 敏捷管理模式在軟件開發(fā)項目中的應(yīng)用
　　敏捷最早出現(xiàn)于1995年,相比于“分析—設(shè)計—實現(xiàn)”這種“重量級”(heavyweight)瀑布式軟件開發(fā)方法,敏捷提倡“輕量級”(lightweight)的開發(fā)模式。“輕”與“重”的差異不是說敏捷丟棄分析、設(shè)計這些過程,敏捷要求分析和設(shè)計要適度而不是過度,而且敏捷更強(qiáng)調(diào)迭代,要求迭代的周期不要太長,通常是2~4周,這樣軟件產(chǎn)品是通過一次一次的較短周期迭代而成,每次迭代都有交付成果,而不是經(jīng)歷漫長的過程等待,等待軟件最終的“破繭成蝶”。敏捷歷史上最為重大的事件是“敏捷軟件開發(fā)宣言”(Manifesto for Agile Software Development)的發(fā)表,宣言制定了4個核心價值觀:
　　“我們正在通過實踐和幫助其他人實踐,揭示更好的開發(fā)軟件的方法。我們的價值觀是:
　?、偃撕拖嗷ソ涣鲃儆谶^程和工具;
　?、诳梢怨ぷ鞯能浖儆谇笕?zé)備的文檔;
　?、叟c客戶協(xié)作勝于合同談判;
　?、茈S時應(yīng)對變化勝于按部就班。也就是說,雖然右邊的條目有價值,但我們更看重左邊的條目。”
　　正如敏捷所提倡的,它的宣言也異常“輕量”。敏捷宣言強(qiáng)調(diào)在實踐中揭示好的方法,并且認(rèn)為人(開發(fā)者與客戶)、可交付成果(軟件)、適應(yīng)變化這三者在軟件開發(fā)中更為重要,它的核心是“變革”,也就是從“重量級”的過程式開發(fā)變革到“輕量級”的敏捷開發(fā),對過程式開發(fā)過度倚重的過程、文檔、計劃進(jìn)行精簡,一個組織、一個團(tuán)隊、一個項目是否敏捷,判斷的唯一依據(jù)　就是是否遵循這四條原則,敏捷的項目管理同樣需要遵循這四條原則。
　　在軟件開發(fā)項目中引入敏捷之后,將會引發(fā)管理上的一系列變革。首先,關(guān)注重點由過程轉(zhuǎn)向人,過程是死的,人是活的,敏捷管理將充分調(diào)動人的自主能動性,對于依靠人這一最主要生產(chǎn)要素才得以實現(xiàn)的軟件產(chǎn)品來說,敏捷管理的這一做法真正回歸到了前面分析的“管理的本質(zhì)”,即充分發(fā)揮各個組織以及成員的潛能,敏捷管理將關(guān)注客戶與開發(fā)人員間的協(xié)作和交流,以及開發(fā)人員之間的協(xié)作和交流;其次,它將管理控制對象由項目計劃轉(zhuǎn)向項目的交付成果———軟件,這一轉(zhuǎn)變統(tǒng)一了客戶方與開發(fā)方的期待,而不是象過程管理強(qiáng)調(diào)了計劃卻忽略了客戶的期待和項目的最終目標(biāo),這種統(tǒng)一消除了雙方內(nèi)在隱含的“此消彼長”邏輯關(guān)系,成為促進(jìn)項目成功的“共同動力”;再次,敏捷要求在軟件開發(fā)過程中隨時可以適應(yīng)變化,甚至在項目快要結(jié)束的時候也能夠接受變更,這種能力解決了軟件產(chǎn)品由于“漸進(jìn)認(rèn)知”特點進(jìn)而引發(fā)需求變更的難題,而且除了流程、技術(shù)具備這種適應(yīng)能力之外,敏捷更要求開發(fā)人員擁有適應(yīng)變化的正確態(tài)度,擁抱變化而不是拒絕變化,這種態(tài)度轉(zhuǎn)變消除了客戶方和開發(fā)方之間關(guān)于“變更”存在的矛盾,進(jìn)一步掃清了項目成功道路上的“人為”障礙;最后,敏捷鼓勵創(chuàng)新,創(chuàng)新不是去創(chuàng)造一件前所未有的產(chǎn)品,而是為客戶“挖掘”新的價值,敏捷鼓勵新思維、使用新技術(shù),只有這樣才能適應(yīng)變化的環(huán)境,為客戶帶來價值,另一方面敏捷要求消除浪費(fèi),凡是不能為客戶提供價值的合規(guī)活動———比如冗余的開發(fā)文檔,這些活動就應(yīng)該堅決擯除,消除浪費(fèi)可以把更多開發(fā)重心放在為客戶創(chuàng)造價值的活動上,這是一個“反向增值”的舉措。
　　因此,敏捷4個核心價值觀的核心就是一個詞:變革。敏捷宣言發(fā)起人之一的Jim Highsmith在《敏捷項目管理》中提出了幾個重要觀點:
　?、倜艚菔谴龠M(jìn)變革并響應(yīng)變化以便在動蕩的商業(yè)環(huán)境中創(chuàng)造利潤的能力;
　?、诿艚菔瞧胶忪`活性和穩(wěn)定性的能力;③敏捷更多的是一種態(tài)度而不是一個流程,是一種氛圍而不是方法。這幾個觀點給敏捷管理指出了方向:敏捷管理應(yīng)該轉(zhuǎn)變?nèi)说乃季S和態(tài)度,應(yīng)該營造敏捷的團(tuán)隊氛圍,應(yīng)該培養(yǎng)敏捷的應(yīng)變能力,最終在多變的環(huán)境下創(chuàng)造利潤,而轉(zhuǎn)變的關(guān)鍵在于對靈活性和平衡性的把握。在軟件項目開發(fā)中,敏捷的范圍管理首先要做的是轉(zhuǎn)變態(tài)度,去適應(yīng)范圍的變化,而不是去控制;對于變更,應(yīng)該是樂于接受,而不是盲目排斥。
　　除了價值觀作為指導(dǎo),敏捷同時提供最佳的實踐做法,比如測試驅(qū)動開發(fā)(TDD)、特征驅(qū)動開發(fā)(FDD),結(jié)對編程(Paring Coding)等,并且提供給軟件開發(fā)組織各種敏捷的開發(fā)和管理框架,其中應(yīng)用最為廣泛的是SCRUM。
　　SCRUM的英文意思是英式橄欖球隊,SCRUM這個開發(fā)框架將軟件團(tuán)隊比作橄欖球隊,有明確的最高目標(biāo),熟悉開發(fā)流程中所應(yīng)具備的最佳典范和技術(shù),擁有高度自主權(quán),緊密溝通與協(xié)作,高適應(yīng)性地迎接各種挑戰(zhàn),確保每天、每個階段都明確地朝目標(biāo)推進(jìn)。SCRUM的實施過程是:
　　(1)制定產(chǎn)品Backlog,Backlog是軟件產(chǎn)品的一個需求列表。
　　(2)將整個產(chǎn)品的Backlog分解成Sprint Backlog,這個Sprint Backlog是按照目前的人力物力條件可以完成的。Sprint意思是沖刺,代表一次迭代周期(通常為30天),開發(fā)團(tuán)隊需要完成一個制定的Spring Back-log,并且最終成果是一個增量的、可以交付的產(chǎn)品。
　　(3)召開Sprint Planning Meeting,確定這個Sprint內(nèi)需要完成的任務(wù),標(biāo)注任務(wù)的優(yōu)先級并分配給每個成員。
　　(4)進(jìn)入Sprint開發(fā)周期,在這個周期內(nèi),每天需要召開Daily Scrum Meeting(站立式會議)。
　　(5)整個Sprint周期結(jié)束,召開Sprint ReviewMeeting,將成果演示給Product Owner。
　　(6)團(tuán)隊成員最后召開Sprint Retrospective Meet-ing,總結(jié)問題和經(jīng)驗。
　　(7)這樣周而復(fù)始,按照同樣的步驟進(jìn)行下一次Sprint。
　　從SCRUM實施過程可以看出,產(chǎn)品Backlog的制定對應(yīng)于傳統(tǒng)過程管理的范圍定義(Scope Defining),產(chǎn)品Backlog是客戶期待包含進(jìn)項目的軟件特征列表,在制定這個特征列表的時候,最需要注意的是確保這些特征能夠彼此獨立,這樣的劃分使得隨時做優(yōu)先排序或者進(jìn)行變更成為可能。
　　作為項目管理者,有幾點是在制定產(chǎn)品Backlog中要明確的:第一,產(chǎn)品Backlog　SCRUM實施過程允許隨著項目進(jìn)展而進(jìn)行變更,或者增加,或者修改,或者刪減其中的一些特征;第二,產(chǎn)品Backlog的制定需要客戶參與,并且由客戶做出選擇;第三,產(chǎn)品Back-log有一個擁有者,即Product Backlog Owner,這個擁有者可以是開發(fā)方的產(chǎn)品經(jīng)理,或者直接來自客戶,他擁有該特征列表的最終決定權(quán);第四,產(chǎn)品Backlog的優(yōu)先排序原則將取決于特征的價值,也就是說,如果不是現(xiàn)在就實現(xiàn)這個功能,會存在哪些風(fēng)險,或者要丟失什么樣市場機(jī)遇,應(yīng)該根據(jù)價值原則做出決定;
　　第五,需要對產(chǎn)品Backlog的各特征項進(jìn)行大小和復(fù)雜程度進(jìn)行估計。
　　傳統(tǒng)過程管理通過范圍分解(WBS)來建立工作分解結(jié)構(gòu)詞匯表,獲得范圍基準(zhǔn),并且為制訂項目進(jìn)度計劃提供輸入,這在敏捷開發(fā)當(dāng)中沒有專門對應(yīng)的技術(shù)和方法。在實際操作中,SCRUM將一個完整項目劃分為若干個小項目,每個小項目稱為一個發(fā)布(Re-lease),然后一個發(fā)布又分為多個Sprint,Sprint有自己的Sprint Backlog,每個Sprint Backlog包含完成任務(wù)所需的Backlog Item,這個過程有些類似于任務(wù)分解,但是分解的目的并不是為了接下去做一個“龐大而務(wù)求精準(zhǔn)”的項目計劃,而是在一個Sprint當(dāng)中具體地細(xì)分任務(wù),實現(xiàn)任務(wù)并且交付成果。敏捷的做法其實是將分解的任務(wù)以及能力轉(zhuǎn)移到敏捷的團(tuán)隊開發(fā)當(dāng)中,這種轉(zhuǎn)移化解了信息輸入不夠而可能造成的計劃不當(dāng)風(fēng)險,并且由開發(fā)團(tuán)隊的成員協(xié)作完成,使開發(fā)人員更明確各自的任務(wù)和交付成果,增強(qiáng)了自主性。
　　基于這種增量和迭代的方法,采用敏捷方法的項目經(jīng)理可以制訂更高層次的計劃來控制項目范圍和進(jìn)度。當(dāng)一次迭代完成后,客戶可以立即參與到交付成果評估當(dāng)中,客戶評估的對象是可用的功能,而不是一個空泛的文件說明,客戶要么接受這一迭代的成果,要么提出改進(jìn)意見,要么可以拒絕這個成果。這種驗收方式,即范圍核實(Scope Verification)較傳統(tǒng)的“一次性驗收”顯得更為具體和可行,它及時獲得客戶的反饋,而吸納反饋后改進(jìn)的軟件功能才有可能為客戶提供更多價值。
　　在范圍控制上,實施敏捷的項目團(tuán)隊更有信心面對變更,因為適應(yīng)性已經(jīng)成為團(tuán)隊最為突出的能力,提供客戶價值、正確的態(tài)度、迭代、協(xié)作、創(chuàng)新是這種信心的有力保障,項目經(jīng)理面對變更需要把握的處理原則就是:客戶價值在什么地方,應(yīng)該在可獲得的時間與資源中,交付什么樣的成果從而為客戶帶來最大的價值?！∽兏慕Y(jié)果有可能是為了增加更高價值的功能,而另一些則需要拋棄,這就是Jim Highsmith提到的敏捷的“平衡能力”。
　　4 結(jié)語
　　最后再將目光重新投向“項目三角形”,在引入敏捷之后,或許不能再這么簡單地利用三個因素去考慮和衡量一個項目,美國項目管理專家Johanna Rothman提出了這么一個“項目新三角”。
　　在這個新三角形當(dāng)中,由成本(cost)、工作環(huán)境(work environment)、人以及人的能力(People and theirCapabilities)三條邊決定三角形的大小,從三角形內(nèi)部的一個點向三角形的頂點各引一條線,分別是范圍(Feature Set)、時間(Time to Market)、質(zhì)量(Low De-fects),很明顯內(nèi)部的這三條線受到雙重約束,第一重約束是由外部三條邊所構(gòu)成的這個三角形,第二重約束就是內(nèi)部的三條線之間的制約:如果拽住這三條線的聯(lián)結(jié)點進(jìn)行拉伸,任何一條線的長短變化都會引起其他兩條線的變化。
　　這個新“項目三角形”帶來很大的啟發(fā),假如能夠擴(kuò)大整個三角形,那么范圍、時間、質(zhì)量這三個因素間的矛盾就將從根本上得以緩解甚至消除!這是一個嶄新的視角,該如何去擴(kuò)大這個“三角形”,答案在哪里?
　　當(dāng)一個軟件項目引入敏捷之后,就能找到這個答案,因為正如Jim Highsmith的精辟見解一樣———“敏捷更多是一種‘態(tài)度’,是一種‘氛圍’”,而態(tài)度足以改變一個人,足以改變整個團(tuán)隊,足以改變客
　　戶方與開發(fā)方的關(guān)系,氛圍則是敏捷所創(chuàng)造的平等、自主、協(xié)作、適應(yīng)和創(chuàng)新的工作環(huán)境,這不正是新三角形中People and their Capabilities與Work Environment這兩條邊嗎?
　　最后,幾乎可以很肯定地說,擁有敏捷團(tuán)隊的項目經(jīng)理將是一個非常幸運(yùn)的人。