1、Scrum為項(xiàng)目執(zhí)行提供了可靠的、已被證實(shí)的基礎(chǔ)。但是，在每個(gè)項(xiàng)目中，Scrum都必須根據(jù)具體需求和環(huán)境進(jìn)行調(diào)整，這是項(xiàng)目成敗的決定性因素。在這篇文章中，我們將會(huì)介紹我們?nèi)绾纬晒Φ赝瓿闪艘粋€(gè)大型的（20人年，超過十萬(wàn)行代碼）、分布式（開發(fā)人員位于印度和荷蘭）Scrum項(xiàng)目，而這個(gè)項(xiàng)目曾經(jīng)在傳統(tǒng)開發(fā)方式下被廢棄過 。為了幫助讀者順利運(yùn)作大規(guī)模項(xiàng)目，在這里我也會(huì)歷數(shù)我們的經(jīng)驗(yàn)教訓(xùn)，包括：項(xiàng)目啟動(dòng)、找到合適的產(chǎn)品負(fù)責(zé)人、估算的重要性、有效溝通、測(cè)試、文檔。背景荷蘭鐵路可以躋身于世界上使用量最大的鐵路系統(tǒng)之列，每天要運(yùn)送120萬(wàn)乘客。該部門打造了一套全新的信息系統(tǒng)，為乘客提供更準(zhǔn)確的列車信息，減少人為

2、干預(yù)。作為該系統(tǒng)的一部分，我們做了這個(gè)PUB發(fā)布系統(tǒng)，對(duì)所有車站中的信息顯示和音頻廣播做集中控制。有人之前試過完成這個(gè)PUB系統(tǒng)，但是他們當(dāng)時(shí)用的是傳統(tǒng)的瀑布方法?？蛻舭言敿?xì)的需求文檔規(guī)范交給了開發(fā)商，然后放任自流，等著完整的系統(tǒng)成形交付。三年之后，這個(gè)項(xiàng)目被取消掉了，因?yàn)殚_發(fā)商沒能開發(fā)出一個(gè)可以工作的系統(tǒng)來(lái)。然后客戶雇傭了我們公司從頭做起，我們引入了敏捷開發(fā)方式，用上了Scrum，跟客戶緊密協(xié)作，開放交流，小步前進(jìn)。起步項(xiàng)目開始的時(shí)候，我們?cè)诘谝粋€(gè)sprint開始前安排了一個(gè)啟動(dòng)階段，耗時(shí)三周，準(zhǔn)備好了sprint中所需的一切。這個(gè)啟動(dòng)階段由一個(gè)項(xiàng)目經(jīng)理，一個(gè)架構(gòu)師和一個(gè)Scrum Mast

3、er參與完成。選擇產(chǎn)品負(fù)責(zé)人是個(gè)很有難度的事情，我們找不到一個(gè)人能夠有時(shí)間、具備領(lǐng)域知識(shí)、而且有權(quán)利設(shè)置需求優(yōu)先級(jí)。我們提名了兩個(gè)業(yè)務(wù)分析師來(lái)一起承擔(dān)產(chǎn)品負(fù)責(zé)人的職責(zé)。他們能抽出時(shí)間來(lái)，而且他們從前也參與過構(gòu)建PUB的工作，所以業(yè)務(wù)知識(shí)很豐富，足以擔(dān)當(dāng)起產(chǎn)品負(fù)責(zé)人的角色，為多組客戶充當(dāng)優(yōu)秀的代理。有關(guān)優(yōu)先級(jí)的和范圍的高級(jí)決策，是由客戶委任的項(xiàng)目經(jīng)理負(fù)責(zé)，但是他時(shí)間不夠用，對(duì)于需求的理解也有所欠缺。一般情況下大家的配合還可以，但偶爾項(xiàng)目經(jīng)理也會(huì)對(duì)（他所缺席的）計(jì)劃會(huì)議上制定的優(yōu)先級(jí)進(jìn)行調(diào)整，于是這個(gè)會(huì)議就得重新來(lái)過。在理想狀態(tài)中，對(duì)優(yōu)先級(jí)有最終決策權(quán)的人應(yīng)當(dāng)每次都參加sprint計(jì)劃會(huì)議。因?yàn)橄?/p>

4、前有人試著構(gòu)建過PUB系統(tǒng)，所以有些部分的詳細(xì)需求文檔已經(jīng)是現(xiàn)成的了。它們遵守了MIL標(biāo)準(zhǔn)1，不過其形式不適于敏捷計(jì)劃和估算2，因?yàn)樵诿艚蓍_發(fā)中，需求應(yīng)當(dāng)被組織成小塊的段落，每一塊都可以在一個(gè)sprint中進(jìn)行實(shí)現(xiàn)、測(cè)試和演示，但是現(xiàn)有的文檔與此要求不符。產(chǎn)品負(fù)責(zé)人也沒有多少編寫用戶故事的經(jīng)驗(yàn)，為了解決這個(gè)問題，Scrum Master幫他們弄出了最原始的產(chǎn)品backlog，里面放著一些細(xì)粒度的、經(jīng)過估算的用戶故事，供前幾個(gè)迭代使用。我們所構(gòu)建的軟件只是某個(gè)大型軟件系統(tǒng)的一部分，它還包括很多相關(guān)的軟件系統(tǒng)，那些系統(tǒng)負(fù)責(zé)顯示信息，還要在車站內(nèi)安裝相關(guān)顯示設(shè)備。我們得保證每件事情都可以按時(shí)完成，才

5、能把復(fù)雜的系統(tǒng)理順。所以需要有一個(gè)整體的計(jì)劃方案。經(jīng)歷了幾次迭代，我們對(duì)系統(tǒng)的各個(gè)功能都按照自己的最大能力做出估算，這個(gè)問題也解決掉了，而且也有了一個(gè)比較靠譜的生產(chǎn)率。于是就可以用發(fā)布版本燃盡圖來(lái)記錄和溝通進(jìn)度了。這里我們學(xué)到的東西就是，即使是信息量很少的情況下，有估算也比沒估算好。擴(kuò)展到分布式團(tuán)隊(duì)項(xiàng)目啟動(dòng)以后，一開始只有7個(gè)人，兩星期一迭代。項(xiàng)目從一開始就計(jì)劃著要用到印度的一些人力，所以從第一個(gè)sprint開始就有兩個(gè)印度開發(fā)人員進(jìn)入了團(tuán)隊(duì)。他們來(lái)到客戶現(xiàn)場(chǎng)參與開發(fā)，用了六周時(shí)間熟悉領(lǐng)域知識(shí)、用戶代表和團(tuán)隊(duì)其他成員。建立團(tuán)隊(duì)伊始，就要決定如何協(xié)作。我們跟所有團(tuán)隊(duì)成員一起也包括印度同事組織了一

6、個(gè)“規(guī)范和章程 3 ”活動(dòng)。我們定下來(lái)一些實(shí)踐方式，如怎樣做結(jié)對(duì)、用哪些工具、質(zhì)量目標(biāo)、每天的核心工作時(shí)間等等。然后在Wiki上記錄下來(lái)。整個(gè)團(tuán)隊(duì)有了共識(shí)，事情就好辦多了。一旦這些共識(shí)需要修改，比如在回顧會(huì)議上提出改進(jìn)，這些實(shí)踐就要在wiki上更新，這樣有新人加入的時(shí)候，他們看到的總是最新內(nèi)容。在前幾個(gè)迭代里面，團(tuán)隊(duì)成功地構(gòu)建、測(cè)試、驗(yàn)證了組成系統(tǒng)核心的用戶故事。這讓客戶很滿意，尤其是跟過去相比，我們的進(jìn)度更快，而且客戶對(duì)項(xiàng)目的方向也有掌控權(quán)。幾個(gè)迭代以后，我們就擴(kuò)展了項(xiàng)目：印度的開發(fā)人員返回本國(guó)，然后我們?cè)谟《群秃商m都增加了資源，這樣變成了兩個(gè)Scrum團(tuán)隊(duì)，每個(gè)團(tuán)隊(duì)5個(gè)開發(fā)人員，共享同一個(gè)

7、測(cè)試人員。過后又變成了三個(gè)團(tuán)隊(duì)，一共三個(gè)測(cè)試人員。每個(gè)團(tuán)隊(duì)都既有印度員工，又有荷蘭員工。這種方式讓項(xiàng)目保持了很高的生產(chǎn)率和工作質(zhì)量 4。那我們是怎樣異地協(xié)同工作的呢？首先，我們頻繁使用Skype。我們都有網(wǎng)絡(luò)攝像頭、耳機(jī)、麥克風(fēng)，還有個(gè)大屏幕。所以我們既能一對(duì)一開會(huì)，也能全體參會(huì)。這些都用的是現(xiàn)成的東西和免費(fèi)軟件。沒多花多少錢，只是用UPS保證斷電的時(shí)候也能繼續(xù)開Skype會(huì)議，這樣提高了印度那邊的網(wǎng)絡(luò)聯(lián)系能力。其次，只有在同一個(gè)地方的人才做結(jié)對(duì)。也就是說印度的人跟印度的人結(jié)對(duì)，荷蘭的人跟荷蘭的人結(jié)對(duì)。經(jīng)驗(yàn)告訴我們，不管現(xiàn)在有了哪些工具，結(jié)對(duì)編程所需的交互協(xié)作還是需要兩個(gè)人坐在一起的。最后，我

8、們用ScrumWorks記錄誰(shuí)在做什么事情，記錄Sprint的進(jìn)度。因?yàn)槲覀兪欠植际綀F(tuán)隊(duì)，所以這個(gè)比白板要好得多。在跟產(chǎn)品負(fù)責(zé)人討論產(chǎn)品backlog的時(shí)候，ScrumWorks也起了很大作用。在實(shí)施這種分布式模型的時(shí)候，我們也戰(zhàn)勝了很多困難。例如，產(chǎn)品負(fù)責(zé)人不習(xí)慣說英語(yǔ)。按照Scrum的說法，計(jì)劃會(huì)議分成兩部分，在第一部分中，產(chǎn)品負(fù)責(zé)人給團(tuán)隊(duì)講述用戶故事，并且設(shè)置優(yōu)先級(jí)。因?yàn)檫@種語(yǔ)言障礙的存在，這一部分的會(huì)就只讓荷蘭團(tuán)隊(duì)參加了。第二部分通常是大家討論具體任務(wù)，做估算。這部分是跟印度團(tuán)隊(duì)一起用Skype來(lái)完成的，說的是英語(yǔ)，產(chǎn)品負(fù)責(zé)人不參加。我們還多花一些時(shí)間來(lái)溝通第一部分會(huì)議的內(nèi)容。Spri

9、nt演示也只在荷蘭進(jìn)行。完成以后，荷蘭團(tuán)隊(duì)再寫封內(nèi)部簡(jiǎn)報(bào)，告知印度團(tuán)隊(duì)也包括公司其他人演示的結(jié)果。事實(shí)證明，這個(gè)內(nèi)部簡(jiǎn)報(bào)深受歡迎。拆出一個(gè)只關(guān)注架構(gòu)的團(tuán)隊(duì)我們的項(xiàng)目只是整個(gè)應(yīng)用鏈條中的一部分，必須要跟客戶現(xiàn)有的IT基礎(chǔ)架構(gòu)無(wú)縫掛接。雖然我們的產(chǎn)品負(fù)責(zé)人對(duì)核心功能需求非常熟悉，但是在安全、日志、可用性、性能等方面就所知甚少了。要從客戶的組織中了解這些需求難度很大，因?yàn)檫@得跟不同部門中的許多人溝通討論。這種調(diào)查工作給Scrum的迭代節(jié)奏拖了后腿。為了解決這個(gè)問題，我們創(chuàng)建了一個(gè)獨(dú)立團(tuán)隊(duì)，他們只關(guān)注架構(gòu)方面的內(nèi)容。他們的工作就是弄清楚非功能性需求，好讓我們把它們轉(zhuǎn)換成backlog中的用戶故事。我們

10、用“Scrum of Scrum”會(huì)議來(lái)跟特征團(tuán)隊(duì)溝通。我們都喜歡這種方式，因?yàn)樘卣鲌F(tuán)隊(duì)可以全速前進(jìn)。而且有些員工也喜歡在“架構(gòu)團(tuán)隊(duì)”中工作。文檔客戶要求大量的文檔，而且還要符合MIL文檔規(guī)范。還要用荷蘭語(yǔ)寫。很明顯，這項(xiàng)工作只能由荷蘭人來(lái)干。而且開發(fā)跟測(cè)試都不熟悉MIL規(guī)范，寫用戶手冊(cè)這樣的文檔也不是他們所擅長(zhǎng)的。所以我們決定雇一個(gè)曾經(jīng)寫過MIL文檔的技術(shù)文案。開發(fā)跟測(cè)試可以繼續(xù)關(guān)注于各自職責(zé)。這個(gè)做法也很成功，不過我們發(fā)現(xiàn)這也要求技術(shù)文案和其他團(tuán)隊(duì)成員之間也要有大量的溝通交流，這是需要引起注意的，因?yàn)殚_發(fā)人員只想“做他們?cè)撟龅氖虑椤薄Ｐ枨笪覀兊漠a(chǎn)品負(fù)責(zé)人是一些業(yè)務(wù)分析師，他們習(xí)慣于用荷蘭語(yǔ)

11、寫出大量的需求文檔。而在我們的過程中，只要backlog中有用戶故事，產(chǎn)品負(fù)責(zé)人也能在計(jì)劃會(huì)議上做解釋，這就足夠了。但是客戶又要求有很多文檔。所以我們打算和產(chǎn)品負(fù)責(zé)人一起把需求翻譯成用戶故事。結(jié)果就是需求被放在了兩個(gè)地方：需求文檔和 backlog。當(dāng)需求發(fā)生變化的時(shí)候就會(huì)導(dǎo)致問題。我們做了大量的輔導(dǎo)工作，確保產(chǎn)品負(fù)責(zé)人不僅僅是關(guān)注需求文檔，也要負(fù)責(zé)backlog。有了一行文字表達(dá)的用戶故事，再加上產(chǎn)品負(fù)責(zé)人的解釋，我們的Scrum團(tuán)隊(duì)就可以構(gòu)建和測(cè)試軟件了。不過需求文檔對(duì)外部的測(cè)試團(tuán)隊(duì)做測(cè)試還是很有價(jià)值的，雖然在好些迭代里面，我們很難把實(shí)現(xiàn)的用戶故事跟需求文檔中的某些部分“映射”起來(lái)。回顧從

12、前，我們其實(shí)一直都沒有一個(gè)理想的需求管理過程。我們只是盡了最大努力，來(lái)應(yīng)對(duì)這相互沖突的需求：我們需要用戶故事，客戶需要詳細(xì)的需求文檔。測(cè)試我們?cè)陧?xiàng)目中做了自動(dòng)化測(cè)試，保證在每個(gè)Sprint結(jié)尾的時(shí)候都可以交付經(jīng)過測(cè)試的軟件，不帶有回歸的bug。即使隨著系統(tǒng)擴(kuò)展，我們還是做到了在8人的Scrum團(tuán)隊(duì)中只安排一個(gè)測(cè)試人員，而且保證了高質(zhì)量：外部測(cè)試團(tuán)隊(duì)最多也就是能在每千行代碼中發(fā)現(xiàn)一個(gè)缺陷。我們的自動(dòng)化測(cè)試包括兩部分：?jiǎn)卧獪y(cè)試和驗(yàn)收測(cè)試。在前者中，我們用的是JUnit，用Clover度量測(cè)試覆蓋率，我們的目標(biāo)是服務(wù)器端代碼的測(cè)試覆蓋率達(dá)到80%。驗(yàn)收測(cè)試用FitNesse作自動(dòng)化。每個(gè)完成的用戶故

13、事，都會(huì)在FitNesse上有一套驗(yàn)收測(cè)試。有了龐大的測(cè)試套件，就能在 Sprint中找到并修復(fù)回歸的bug。這種做法還有另外一個(gè)好處，就是測(cè)試人員從一開始就可以積極參與，在用戶故事實(shí)現(xiàn)之前編寫測(cè)試用例。有一個(gè)地方讓我們苦惱了很久。這個(gè)系統(tǒng)有一部分是一個(gè)用戶界面很復(fù)雜的富客戶端。對(duì)這東西做自動(dòng)化測(cè)試要比對(duì)服務(wù)端做測(cè)試難得多。所以在UI方面的功能我們大部分還是依靠手工操作。隨著系統(tǒng)的增長(zhǎng)，回顧測(cè)試所花的時(shí)間就越來(lái)越長(zhǎng)，更糟的是，外部團(tuán)隊(duì)只在這部分系統(tǒng)中會(huì)發(fā)現(xiàn)回歸bug。如果有了自動(dòng)化測(cè)試就能防止這一點(diǎn)。我們由此學(xué)到了一點(diǎn)，即便是自動(dòng)化測(cè)試很困難，為它付出些努力，遲早會(huì)獲得回報(bào)，尤其是在項(xiàng)目晚期。

14、產(chǎn)出成果客戶對(duì)我們的工作很滿意。說點(diǎn)馬后炮的話，跟大多數(shù)項(xiàng)目一樣，功能、時(shí)間、預(yù)算都會(huì)隨著項(xiàng)目進(jìn)度發(fā)生變化，所以“按時(shí)按預(yù)算”完成只是個(gè)很模糊的完成標(biāo)準(zhǔn)而已。更為重要的是，我們?cè)陧?xiàng)目進(jìn)程中常常跟客戶討論怎樣把項(xiàng)目做好，他們都很滿意。不幸的是，因?yàn)槠渌到y(tǒng)中的問題，產(chǎn)品在全國(guó)范圍內(nèi)部署的時(shí)候出了麻煩?？蛻粽伊送獠康膶徍斯緛?lái)審核這個(gè)軟件。他們的結(jié)論是：· 系統(tǒng)的可維護(hù)性非常好。 · 源碼質(zhì)量非常高。 在審核公司的報(bào)告中，他們說他們從來(lái)沒有給過一個(gè)項(xiàng)目這么多正面評(píng)價(jià)。總結(jié)下面是我們從這個(gè)項(xiàng)目中學(xué)到的最重要的幾點(diǎn)：· 很難找到一個(gè)既有豐富的需求知識(shí)、又有權(quán)利設(shè)置優(yōu)先級(jí)的

15、產(chǎn)品負(fù)責(zé)人。所以人們往往都要用幾個(gè)人一起扮演產(chǎn)品負(fù)責(zé)人的角色，尤其是在大型項(xiàng)目里面。 · 如果一定要按期完成工作，那就得保證產(chǎn)品backlog的完整，也要做好估算。對(duì)需求而言，即便信息量很小，有估算也比沒估算的好。把估算跟團(tuán)隊(duì)生產(chǎn)率合并以后，發(fā)布計(jì)劃就有了必要的信息。 · Scrum對(duì)多個(gè)分布式團(tuán)隊(duì)很適用。我們每個(gè)Scrum團(tuán)隊(duì)都既有荷蘭人又有印度人，這很好地發(fā)揮了團(tuán)隊(duì)精神，讓我們注重有效溝通。在溝通中，利用現(xiàn)成的硬件和免費(fèi)軟件能節(jié)省成本。 · 在啟動(dòng)分布式項(xiàng)目的時(shí)候，先把大家都聚到同一個(gè)地方，讓大家對(duì)團(tuán)隊(duì)實(shí)踐達(dá)成一致，這點(diǎn)效果很好。 · 對(duì)于不適合放到

16、Scrum Sprint中的工作（比如尋找關(guān)鍵人員，跟其他客戶部門交流），可以讓一個(gè)單獨(dú)的團(tuán)隊(duì)去做，這樣效率更高。特性團(tuán)隊(duì)可以集中精力開發(fā)軟件。有一個(gè)專職的技術(shù)文案也很好，即便這會(huì)增加溝通成本。 · 雖然軟件開發(fā)過程不需要大量的需求文檔，但客戶可能需要。不過在Scrum項(xiàng)目中，需求文檔代替不了用戶故事。如果既有需求文檔，又有用戶故事，那就得在做計(jì)劃的時(shí)候，就要考慮到在兩個(gè)地方協(xié)調(diào)需求的額外開銷。 · 在增量式交付軟件的過程中，自動(dòng)化測(cè)試發(fā)揮著關(guān)鍵性作用，它可以排除回歸bug的干擾。在項(xiàng)目結(jié)束之前，投資回報(bào)會(huì)高過成本的。 參考文獻(xiàn)1 MIL-STD-498 , The Standard2 敏捷估計(jì)與規(guī)劃, Mike Cohn, 20053 Team norming and chartering, Martin van Vliet,4 Fully Distributed Scrum: The Secret Sauce