Scrum為項目執(zhí)行提供了可靠的

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

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

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

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

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

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

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

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

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

10、用“Scrum of Scrum”會議來跟特征團隊溝通。我們都喜歡這種方式，因為特征團隊可以全速前進。而且有些員工也喜歡在“架構團隊”中工作。文檔客戶要求大量的文檔，而且還要符合MIL文檔規(guī)范。還要用荷蘭語寫。很明顯，這項工作只能由荷蘭人來干。而且開發(fā)跟測試都不熟悉MIL規(guī)范，寫用戶手冊這樣的文檔也不是他們所擅長的。所以我們決定雇一個曾經寫過MIL文檔的技術文案。開發(fā)跟測試可以繼續(xù)關注于各自職責。這個做法也很成功，不過我們發(fā)現這也要求技術文案和其他團隊成員之間也要有大量的溝通交流，這是需要引起注意的，因為開發(fā)人員只想“做他們該做的事情”。需求我們的產品負責人是一些業(yè)務分析師，他們習慣于用荷蘭語

11、寫出大量的需求文檔。而在我們的過程中，只要backlog中有用戶故事，產品負責人也能在計劃會議上做解釋，這就足夠了。但是客戶又要求有很多文檔。所以我們打算和產品負責人一起把需求翻譯成用戶故事。結果就是需求被放在了兩個地方：需求文檔和 backlog。當需求發(fā)生變化的時候就會導致問題。我們做了大量的輔導工作，確保產品負責人不僅僅是關注需求文檔，也要負責backlog。有了一行文字表達的用戶故事，再加上產品負責人的解釋，我們的Scrum團隊就可以構建和測試軟件了。不過需求文檔對外部的測試團隊做測試還是很有價值的，雖然在好些迭代里面，我們很難把實現的用戶故事跟需求文檔中的某些部分“映射”起來?；仡檹?/p>

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

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

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

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

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