Scrum 開發方法的實施

Scrum是基于過程控制理論的經驗方法，倡導自組織團隊；其運作架構核心是疊代增量型并行開發，也是“适應性”的軟體開發方法。Scrum提供了高度可視化的用于管理軟體開發複雜性管理的靈活項目管理的實踐架構或靈活過程，可以用于對現存軟體工程實踐的包裝，提高軟體生産率，改善溝通和合作的方法，使人們協作并注重業務目标。現在Scrum已被衆多的軟體企業使用，其中不乏有業界知名企業，如Microsoft 、IBM、Google和Nokia等。

作為一名Scrum教練，筆者經常被問到有關Scrum實施以及靈活開發方面的各類問題，現總結如下，供對此方法有興趣和有疑問的讀者參考。

一問：Scrum的核心特征是什麼？

一答：基于功能開發而組成的多功能、自組織團隊；高度柔性的可視化靈活項目管理自适應架構；以及支援增量并行開發的30天時間盒疊代。

二問：哪類項目可以使用Scrum?

二答：最初Scrum使用于需求難以預測的複雜商務應用産品的開發，但經過10多年的發展，它被應用于所有領域的軟體中，從生命攸關的軟體到更為随意的軟體，都可以使用Scrum。在使用Scrum時，無需讨論工件是什麼以及它們的數量，而是讨論需要嚴謹到什麼程度。作為一個指導原則，由整個Scrum團隊來決定正規性的程度，并盡可能地低。當然，這需要有豐富的實踐經驗來判斷。

三問：Scrum團隊一定是7個人嗎？

三答：在Scrum中有3個基本的角色：産品所有者Product Owner、開發團隊Development Team和ScrumMaster。Scrum團隊通常有5～9個成員，典型一個Scrum團隊應當有7個成員。但可以由多個團隊完成一個項目，即使用Scrum of Scrums實踐規則進行拓展項目團隊規模：每一個Scrum Team同樣有一個代表，通常是Scrum Master，參與Scrum of Scrums會議協調多個Scrum Teams的工作，這些會議類似于Daily Scrum Meeting，但每周召開一次。

四問：看上去Scrum非常簡單，可以給我們更簡化地總結一下嗎？

四答：是的，Scrum看上去确實很簡單，可以把Scrum總結得非常簡單：

團隊和項目出資人建立一個團隊需要做的所有事情的清單。這可以是一個任務的清單或者特性的清單。這就是Product Backlog。

每個月，團隊都努力實作清單最頂端的任務，這一部分是他們估計需要一個月完成的工作。他們把它展開成一個詳細的任務清單，叫做Sprint Backlog。這個團隊承諾在月底向出資人示範或傳遞結果。

每天，團隊都面對面地開5～10分鐘的會，彼此更新各自的狀态和排除使他們減慢的路障。這個叫Daily stand-up meeting。

指定一個特别的人擔任Scrum Master，這個人的任務是排除或安排别人排除在例會上這個團隊提到的任何路障。

但是它的實踐執行并不簡單，需要獲得關鍵的自适應和堅持Scrum核心價值觀——承諾、專注、公開、敬重和勇氣。

五問：我們認為，堅守一定的Scrum Meeting模式是必要的；但是執行一段時間後覺得很困難，有些人甚至覺得“惡心”，你對此怎麼看？

五答：每天舉行15～20分鐘左右的Scrum meeting是Scrum和項目的心髒。如果出現這一問題，我估計是軟體團隊傾向于在現有的項目管理方法下诠釋Scrum，沒有充分了解自我管理、湧現機制、可視性和評估/适應循環的根本原則。

按照“定義的”參考架構去執行Scrum的實踐，忽視了從控制轉向授權、從指令轉向協作，Scrum Master很可能将“自上次Scrum Meeting會後的一天裡我做了什麼？”了解為“檢查團隊成員是否完成上次Scrum Meeting中他所布置的任務”，将“從現在到下次Scrum Meeting的一天我将做什麼”了解為“告訴團隊人員從現在到下次Scrum Meeting的一天應做什麼”，将“在工作中遇到了哪些障礙”了解為“他将稽核是否能幫助團隊完成目标”。而團隊成員把Scrum Meeting了解為按順序報告工作情況的會議。

堅持以下7個基本原則，将有利于有效執行Scrum Meeting：

1 團隊信仰自我管理和支援自我管理。

2 他們作為團隊共同承諾Sprint目标。

3 他們認識到溝通的重要性，并且通過Daily Scrum Meeting推動溝通。

4 他們了解和擁抱貫穿整個Sprint周期的必要的日常任務變更，互相依賴的會議規則，每日會議允許團隊成員管理和響應變化。

5 團隊有一位卓有成效的Scrum Master或得到他們授權的上司來決策和問責。

6 團隊認為工作可視化很重要，透明改進團隊群組織其他團隊之間的關系，進而得到更高層次的信任和協作。

7 團隊将Daily Scrum Meeting回顧與其他裡程碑相聯系使會議盡可能有效。

六問：用什麼來判斷軟體團隊在真正實施Scrum?

六答：對這一問題，Scrum創始人之一Jeff Sutherland用諾基亞測試的8個判斷條件來判定是否在真正執行Scrum。這8個判斷條件是：

1 你們有固定的疊代周期麼？你們的疊代周期是否以某個特定的時間開始并以某個固定的時間結束，且疊代周期必須少于6周？（回答否定的則不符合疊代開發原則）

2 在每個疊代周期結束時，你們能提供可以工作的軟體麼？（回答否定的則不符合疊代開發原則）

3 在疊代開始之前，你們是否需要必須有一個完整細緻的需求說明？（回答肯定的則不符合疊代開發原則）

4 是否将測試作為疊代增量開發的一部分，在開發過程中進行測試？（回答否定的則不符合疊代開發原則）

接下來，用4個附加的Scrum規則來判斷是否實作了Scrum：

1 你們是否有産品所有者？是不是有人可以代表客戶和你們一起工作？

2 如果有産品所有者的話，他們是否能提供待開發的産品Backlog？且此産品Backlog是否按照優先級來排序的？是否估算過開發這些功能的所需時間？

3 團隊在開發過程中是否使用了Burndown圖來展示工作量變化、跟蹤進度、推算團隊開發速度？

4 在疊代過程中，是否能保證項目經理不幹涉團隊工作？

通過以上8點基本上就可以确定，團隊是否真正地實作了Scrum。

七問：在Scrum中我怎樣去度量團隊績效？

七答：你可以通過速度去度量團隊績效，即在一個Sprint中将需求轉化為軟體功能的能力。可以是一個Sprint中完成多少Product Backlog Item（包括功能和非功能需求及其他議題），或者轉化為1個合适機關貨币如10000完成多少Product Backlog Item。

八問：在Scrum中我怎樣去度量個人績效？

八答：你不能度量個人績效，隻能度量整個Scrum團隊的績效。Scrum是自我管理的團隊，而不是個人組成的組。當然，可能你的軟體組織要求這麼做，這确實是個棘手的問題，我也沒有好的解決方案。對于軟體組織這一層面，我建議你首先把度量的焦點聚焦于你生産的軟體、真正的開發功能和軟體組織用于改進基準和市場價值的能力。而項目這一級别，我建議将完整的個人檢查過程簡化為3個問題：你對增加組織的價值有什麼幫助？你做了什麼使客戶高興？你的同僚怎麼看待你？可以請同僚來評估個人貢獻，并列出1～10的等級。在Daily Scrum Meeting上，你可以看到誰有貢獻，誰沒有。

九問：在Sprint期間，如何去修改一個缺陷？

九答：Scrum團隊的目标之一是在發現缺陷的Sprint中就修複它們。在他們逐漸精通采用30天疊代周期以後，尤其是通過對自動化測試的利用，他們能夠達到這個目标。當Scrumt團隊成員做出對某項編碼任務的估計時，這個估計值就包含了用于修複在實作過程中發現的缺陷的時間，否則就應該确定和估計一個獨立的任務（“修複缺陷”）即缺陷作為Product Backlog Item處理。我的偏好是隻确定一項任務，但是在它通過所有的測試之前不認為已經完成。

後來發現的（或者在發現它的疊代中沒有修複 的）缺陷應該按照與Product Backlog一樣的方法來對待。應該按照與Product Backlog一樣的方法确定缺陷修複工作的優先級，配置設定到後續的某次疊代中。隻要超出一次疊代的範圍，就不再有什麼缺陷的概念。修複一個缺陷和增加一個功能隻是一件事的兩種說法。另外，如果現有團隊還需要維護現有産品時，則需要提醒軟體團隊在做計劃時拿出專門的時間處理那種需要馬上響應的缺陷修改任務。

十問：Scrum的局限性是什麼，實施中需要注意什麼？

十答：我們都知道Scrum隻是一種靈活管理的一種實踐架構（Framework），任何方法都有其邊界和局限性，套用業界流行的一個說法就是“沒有銀彈”。Scrum為軟體開發管理隻定義了一個高層次的、易于操作與遵循的非常小的實踐集，Scrum避免了說軟體團隊應該如何開發軟體，它堅持認為：人們在自己的工作中和處理問題時，應該像一個成熟的成年人一樣，是以它并不涉及具體的軟體開發技術和人員溝通、期望管理、問題沖突等管理技能，這些都需要其他相關理論和技能來補充，另外，如同其他項目一樣，需要軟體團隊在其業務領域的專業能力來確定軟體項目的成功。

Scrum源于美國軟體界，對國内實施強調自組織管理的Scrum需要破除可能習慣于聽命行事的組織環境，建立自我限制、自我組織和實作的工作管理方式群組織環境，同時根據Scrum背後的科學原理則可以根據特定的情形進行調整。建議最初時，按Scrum提供的實踐架構執行，然後，當積累了豐富實踐經驗後再根據Scrum提供的避免做什麼的說明視實際情形進行調整，到最後，不要在乎自己是否執行Scrum或是其他什麼靈活方法，也就是達到從心所欲不逾矩。

十一問：Scrum中如何看待文檔，或是對待寫文檔的問題有何建議？

十一答：這一問題屢屢被提及的是有着非常現實背景，軟體組織或軟體項目都需要一些軟體文檔，而在Scrum中沒有規定具體的做法。我認為軟體文檔主要的作用在于了解、溝通和管理要建構的軟體，需要傳遞給使用者和軟體組織為了友善維護軟體和知識産權方面考慮用作儲存和傳遞知識的作用，特殊軟體需要滿足法律法規的要求。

是以，第一、是否需要文檔，标準是該文檔是否增值，堅持精益原則，消除不必要的浪費，比如如果設計人員和專家坐在一起，就可以免去設計文檔，而是在白闆上粗略地勾勒草圖，然後用照片記錄白闆上的圖或用可列印的白闆将其列印出來。第二，假設該文檔隻是符合規定（法律、審計或是客戶等其他原因的強制需求）的需要，則可以考慮安排部分項目時間交給非核心人員編寫文檔，避免影響軟體開發核心工作的開展。第三，對于了解和溝通所要建構軟體的關鍵文檔，原則上用自動化的代碼文檔工具如Doxygen、JavaDoc或NDoc等，在必要時産生符合代碼标準的自解釋的源代碼文檔，并建立自文檔化的軟體UML圖模型。另外，用簡明扼要的1～2頁的軟體架構文檔，描述軟體的架構，為新來的開發者表示出關鍵構件和接口。第四，不要奢求需求是完美的，設計文檔能夠與代碼同步更新，或項目計劃與項目狀态完全比對，需求文檔能夠滿足後續開發需要即可，總之，軟體文檔符合精益（Lean）、易了解（Mean）和足夠（Enough）的要求，确信在目前環境能夠嚴格地保證溝通需要。還有一個有趣的現象是技術人員基本上都讨厭寫文檔，但需要指出的是編寫精益易了解足夠的文檔也是職業軟體開發者的一項基本功，當然同時，也要避免為了文檔而文檔，它意味着用于項目的每個文檔都應該證明是對項目有意義的。

十二問：Scrum與流行的RUP有什麼異同？

十二答：這個問題網上好象有專文論述，這裡根據我的自己的實踐體會簡單地說一下，Scrum與RUP都強調需求導向、疊代增量開發和風險驅動，兩者可以結合使用。Scrum與RUP的側重點不同，其中一個表現Scrum反對預定義的過程和預見性的步驟，RUP會有一些可選的但又需要預先定義的活動，如與需求分析、測試等相關的活動，并有先後順序。需求管理方面Scrum由Product owner管理，RUP則由需求工程師管理；可視化模組化方面，scrum團隊自定，通常進行靈活模組化，RUP倡導可視化模組化；軟體體系結構方面，Scrum軟體組織或團隊自定，RUP則由軟體體系中心确定；疊代周期方面，Scrum疊代周期推薦30天，RUP推薦2～6周。

十三問：一提起靈活方法，為什麼通常将Scrum與XP一并談論？

十三答：這大概是XP與Scrum是靈活方法中被業界采用最為廣泛的原因吧。另外，一個值得注意的原因是兩者都聚焦于資訊價值流和資訊溝通，除了疊代長度稍有差别外，大多數Scrum實踐與XP是相容且互相補充，Scrum側重于項目管理和人，XP有許多工程技術實踐，兩者相得宜彰。Scrum這種強調項目管理價值與實踐而不在乎需求、實作等工程技術用作其他軟體開發方法包裝器的特征，具有高度适應性和柔性是其他靈活方法不具有的，是以，它很容易與其他方法進行組合，或者作為其他方法的補充，這一點不是它的弱點，而應當看作其長處。

十四問：我們公司采用CMM/CMMI進行軟體過程改進，是否适合實施Scrum？

十四答：CMM/CMMI與Scrum或靈活方法之間的關系是常常被人們關心或經常提起的一個有趣的話題。2002年Scrum創始人 各級ken Schwaber與美國卡内基。梅隆大學軟體工程研究所SEI的Paulk Mark曾經評估Scrum如何實作CMM的關鍵過程域，結論是Scrum實踐規則可以滿足CMM2級全部和CMM3即的大部分關鍵過程域。事實上，國内外都有利用Scrum通過CMM/CMMI評估的案例。

通常認為CMM/CMMI之間的差別在于：關注目标不同，CMM/CMMI關注組織級，Scrum關注項目級；基礎假設不同，CMM/CMMI假設軟體開發可預測與可重複，符合統計過程控制，優化放在最後，Scrum假設軟體開發是自适應，高度複雜，需要基于過程控制理論的經驗方法，優化一開始就進行。

業界有一個流行觀點是将Scrum納入到一個已經通過CMM/CMMI 3或更進階别評估的組織，看起來比将一個Scrum項目改為CMMI更簡單。同時，一些實施Scrum或其他靈活方法的軟體組織對CMMI評估沒有興趣，把CMMI評估看作浪費金錢，也就是說，他們不需要CMMI評估來獲得合同，但獲得這一評估卻需要耗費金錢和時間，我的看法是在現實商業環境中的軟體組織是否需要組合CMM/CMMI和Scrum主要不在于理論或其背後的軟體哲學理念，而在于業務運作環境所需考慮的優先級。假設您需要組合兩者并有通過CMMI評估需要，關鍵在于找到一個了解如何靈活使用CMMI模型又了解Scrum的CMMI主任評估師。

十五問：如何引入和執行Scrum?

十五答：對于第一個項目建議在一個有執行Scrum經驗豐富的專家指導下進行。在試點項目的選擇上Scrum的創始人鼓勵選擇最為困難和關鍵的項目，我個人建議是如果試點項目團隊有強烈意願并獲得高層支援是完全可以的。否則，試點項目應該是建構真實的、具有合理的、客觀的商業目标的軟體，團隊規模6～8人為宜，以避免一開始就使用Scrum of Scrums，項目長度通常2～6個月為宜。在項目啟動後，外部的項目管理者和潛在使用Scrum的可以邀請其觀摩Daily Scrum Meeting、Sprint Planning Meeting 、Sprint Review Meeting和Sprint Retrospective Meeting。最終，Scrum的實踐擴充至軟體組織的最高層，每一層都基于團隊，高層管理者每月組織一次Scrum meeting就可以了。

十六問：Scrum的疊代Sprint周期一定是30天嗎？

十六答：Scrum的目标是在一系列（3～8個）短期的時間框（time box）内傳遞盡可能多的優質軟體。其中時間框被（固定時間間隔）稱為Sprint，典型地，其将持續大約一個月30天的時間。但在許多公司已縮短至兩個2周或更短。我建議剛開始實施Scrum時Sprint周期最好固定為30天，随着經驗積累可以根據實際進行調整期Spint周期為2～4周。

十七問：Sprint的長度取決于哪些因素？

十七答：絕大多數的疊代增量開發方法推薦1～6周的長度。Scrum推薦其疊代Sprint的長度為30天。确實需要調整時，考慮釋出的總時間長度、不确定性的多少、獲得回報的難易、優先級可以保持多久不變時間長度、疊代系統開銷、緊迫感産生有多快等因素。這裡需要特别指出的是國内有企業一開始就執行2周為Sprint周期的企業，因為其執行短周期疊代開發的基礎設施（如軟體配置管理和自動化測試的基本實踐不紮實）不到位而導緻退化為瀑布開發的案例。

十八問：導緻Scrum項目失敗的主要原因是什麼？

十八答：導緻失敗的主要原因是軟體團隊不是自組織團隊，團隊由項目經理或Scrum Master進行指導群組織。其次，Product Owner或客戶不參與每次疊代，不進行需求優先級劃分，不參與每次示範，并且不為下一疊代選擇具有最高商業價值的項。另外，在疊代期内給團隊成員追加新的需求或額外的任務。

十九問：您如何看待Scrum Master認證教育訓練？

十九答：靈活聯盟推出Scrum Master認證教育訓練即Scrum Certified Master，事實上其靈活聯盟内部對此也有一些争論。我個人認為您如果有機會參加由那些真正了解Scrum的人負責的為期2天的教育訓練自然是件好事。但我認為把它叫做“認證”會帶來一些錯誤的認識，比如國内外都有參加了Scrum認證後就認為自己是Scrum Certified Master，然後在軟體組織内執行Scrum最後導緻失敗的案例。要真正達到通常意義上的認證，至少你必須進入軟體團隊，用Scrum工作方式幾個月的實踐才行，倘若沒有任何軟體開發經曆和了解Scrum背後的哲學體系，僅是接受2天的教育訓練而去推廣Scrum，後果不堪設想。另外，如果純粹為了就業或是獲得證書什麼的，我認為沒有必要參加目前還相對昂貴的認證教育訓練，看看類似的認證教育訓練效用就可以知道了。相信任何理性的軟體組織都更看重的是實踐能力而非僅僅通過2天教育訓練換來的一紙證書。在這裡我特别聲明我并不反對任何人任何時候參加任何機構舉辦的Scrum Master認證教育訓練。

二十問：對于剛剛學習和實施Scrum者有沒有可以推薦的讀物？

二十答：書籍方面目前主要有由Scrum創始人Ken Schwaber主筆的三本書：《Agile Software Development with Scrum》、《Agile Project Management with Scrum》和《The Enterprise and Scrum》。其中《Agile Software Development with Scrum》還得到了Beedle和Sutherland的協助，國内出了影印版中文名為《靈活軟體開發——使用Scrum過程》。《Agile Project Management with Scrum》出了中文版，中文名為《Scrum 靈活項目管理》，《The Enterprise and Scrum》也已引入英文版。另外著名技術網站infoQ有2本迷你書。我個人傾向推薦《Agile Software Development with Scrum》。

此外，我個人認為在精力和時間允許的情況下最好對Scrum産生重大影響的一些書籍和文章進行研讀，這樣可以更深入了解Scrum和領悟其自适應與自組織的精髓。

本文來自CSDN部落格，轉載請标明出處：http://blog.csdn.net/zhujjcn/archive/2009/06/10/4257253.aspx