Scrum架構及其背後的原則（轉）

第一部分：Scrum 的架構

Scrum并不是一個特定産品開發的流程或技術，而是一個容納其它流程和技術的架構。作為一個疊代和增量的産品開發架構，Scrum本身十分簡單和明确。

void run_scrum() {
    const int 	Sprint_Length = 10;    
    int 		velocity = get_past_performance();  		

    // Scrum 中的三個角色
    Role team, product_owner, ScrumMaster;

    // Scrum 中的制品
    Product_Backlog 	product_backlog;
    Sprint_Backlog 	sprint_backlog;
    Burndown_Chart	sprint_burndown_chart, release_burndown_chart;

    Product_Increment 	product_increment;

    //開始項目的三個準備條件
    setup_team(team);
    define_Definition_of_Done(team, product_owner);
    initial_project(&product_backlog );  //标紅的為輸出參數，将帶回值，下同

    //每一次while 循環為一次疊代
    while (!is_empty(product_backlog)) {
        run_sprint_planning_meeting(product_backlog, velocity, &sprint_backlog);

    	//每一次for循環為一個工作日
        for(num_of_day = 1; num_of_day <=  Sprint_Length; num_of_day ++){
            run_daily_scrum_meeting(&sprint_burndown_chart);
            do_development_activity(sprint_backlog, &product_increment);
        }

        run_sprint_review_meeting(product_backlog, product_increment);
        run_retrospective_meeting();

        update_product_backlog(&product_backlog, &release_burndown_chart);
        update_velocity(&velocity);
    }  
}           

這就是Scrum的完整架構，隻有這些，很簡單，我們下面将逐行解釋。

const int 	Sprint_Length = 10;    
int 	velocity = get_past_performance();            

Scrum是一個疊代開發模型。每一

Role team, product_owner, ScrumMaster;           

個疊代周期，團隊完成一部分産品需求，傳遞可工作的軟體。在Scrum中，疊代被稱為sprint (本意為沖刺跑，一般不作翻譯)，典型的sprint長度是1到4周。值得強調的是，對于同一團隊，sprint的長度是固定不變的。

Sprint_Length -- Sprint長度：這裡以10個工作日（兩周）為例，const常量修飾符，強調了其不可變性。

Velocity -- 團隊開發速率： 也即每個sprint 團隊能完成多少量的使用者需求，它是Scrum中計劃和承諾的最重要依據。開發速率來源自過去實際産出結果，并在産品開發過程中不斷修正。

Role team, product_owner, ScrumMaster;           

以上的實體定義是Scrum 中的三個關鍵角色，在Scrum架構中也僅僅定義了這三個角色。

Team -- 團隊：團隊負責産品傳遞，規模一般為 5～9人，Scrum強調團隊的多功能（cross functional）和自組織。多功能指的是，團隊應該整體具備各個職能所需的技能，如系統，開發和測試技能，同時也具備各個元件的技能如資料庫設計、協定開發和UI設計等。團隊的多功能是短疊代開發的基礎，隻有做到這一點，獨立的團隊才可能在一個sprint 中傳遞對使用者有意義的産品增量。自組織指，在目标清晰的前提下由團隊自主決定完成目标的具體方法。

Product Owner – 産品負責人: 多直接稱為PO。PO 負責把握産品的方向，包括需求的收集、定義，優先級設定等。PO通過這些活動以及和團隊的合作，最終確定産品ROI（return of investment, 投資回報）的最大化。

ScrumMaster: 一般不作中文翻譯，ScrumMaster并不直接負責産品傳遞，它向團隊負責，確定團隊按照Scrum的架構工作，具備良好的外部和内部工作環境，順暢地傳遞産品，并不斷的改進，提升傳遞的效率和品質。與傳統意義上的管理者不同，ScrumMaster更多是起服務、協調和引領的作用。如果注意觀察會發現，在這段程式中，ScrumMaster 是一個定義，但從未使用的變量，這也正反映了ScrumMaster的協調和支援的作用。

Product_Backlog 	product_backlog;
Sprint_Backlog 		sprint_backlog;
Burndown_Chart		sprint_burndown_chart, release_burndown_chart;

Product_Increment 	product_increment;           

上面的結構變量是Scrum 中的核心制品，它們貫穿整個Scrum 操作過程，分别是：

Product backlog -- 産品待辦事項：很多時候直接用英文表示，簡稱PB，是一份使用者需求清單。其中的每一項都是一個具體的端到端的使用者需求，如“使用者可以完成登入”等等。Scrum 産品開發過程就是，通過一系列的sprint，每個sprint完成一部分“産品待辦事項”，傳遞包含這些需求實作的産品增量，直至完成所有“産品待辦事項”。Product backlog 的責任人是Product Owner，它在産品開發的初期生成，并在開發過程中不斷更新完善。

Sprint backlog -- sprint待辦事項：是一個sprint 中要完成的任務清單。其中的項目是為完成特定使用者需求而要進行的設計、開發、內建、測試等具體任務，如“為子產品A添加外部接口”等。完成sprint backlog中的所有任務，也意味着sprint 開發任務的完成，對應的使用者需求可以傳遞。Sprint backlog，在spirnt 計劃會議上生成，在開發過程中，可能會有所調整。

Sprint burndown chart – sprint 燃盡圖：以坐标圖表示團隊在一個sprint中工作進展情況，橫坐标是sprint 已進行的實際天數，縱坐标是還剩餘的任務需要的時間的總和。它直覺的反應了sprint 實際執行與計劃的比較，以及團隊離sprint 的目标完成的距離。

Release burndown chart – 釋出燃盡圖：以坐标圖表示目前版本的需求完成進展情況，橫坐标是已經進行的sprint 的個數，縱坐标是待完成的使用者需求的多少。它直覺的反應了産品需求的完成情況，以及團隊離完成版本完全釋出的距離。

-- 産品增量：Scrum 要求每一個sprint結束都産生使用者可用的軟體，也被稱着“潛在可傳遞的産品增量”（Potential shippable product increment, PSPI），事實上傳遞與否還要受使用者習慣的限制。能否每個sprint生成滿足品質定義的PSPI 是Scrum 執行效果的試金石。

setup_team(Team);
define_Definition_of_Done(team, product_owner);
initial_project(&product_backlog );             

上面代碼中的三步操作是Scrum 執行開始的準備條件。

Setup Team – 建立團隊：創立和建設适合的團隊是Scrum實施的第一步工作，團隊應該滿足上面定義的Scrum團隊的基本屬性，并形成自己的目标和願景，了解Scrum工作模式。

Define Definition of Done – 定義完成标準：完成标準，是指一個使用者需求完成應該滿足什麼樣的标準。它是Product Owner 和 團隊之間的一個約定，有了這個約定，當團隊說，這個需求完成了的時候，Product Owner 将明确知道這意味着什麼，比如是否包含了針對這個需求的性能測試，或是否包含相應的使用者使用手冊等。在實際運用中，由于條件限制，團隊在一開始可能無法做到sprint 結果可傳遞，而會剩餘一部分工作在傳遞前完成，如性能測試等，這一部分工作被稱為“undone”的工作。完成标準在特定時間是固定的，但随着團隊成熟度提高，團隊應逐漸擴充自己的完成标準，使其逼近向客戶傳遞的條件，undone的部分越來越少。

Initial Project – 啟動項目：項目啟動，是項目進入開發階段前的一系列準備工作，如：項目目标的設定，項目初始需求的定義和澄清，工作量的估計，風險的識别，關鍵設計決策的産生，開發基礎設施的選擇和建構等。一般由客戶（如果可能），PO，團隊以及相關幹系人共同參與項目啟動。項目啟動最重要的是輸出一個初始product backlog，它應該包含對其中條目的大小的估計和優先級别的設定。

上面三個操作的結果是，有了合适的Scrum團隊，團隊和PO之間就需求完成的标準達成一緻的定義，并生成了一份初始的product backlog。有了這三個條件便可以正式進入疊代開發了。

While (!is_empty(product_backlog)) {
    run_sprint_planning_meeting(product_backlog, velocity, &sprint_backlog);
    ……           

每一次while循環代表一個sprint周期，直至product backlog中所有的需求被開發完成。

Run sprint planning meeting – 進行sprint計劃會議： sprint 規劃會議規劃這個sprint 目标和具體任務安排，它标志着一個sprint 的開始。在sprint計劃會議上要依次完成以下的内容：

1. 團隊決定在接下來的的sprint 中要完成的使用者需求，如過對需求存在疑問，團隊應和PO進行澄清和确認。團隊必須按照PO設定的product backlog的優先級别，從高到低選擇，如因實作上的依賴關系，要調整需求選擇的順序，也需要和PO進行确認，以確定團隊始終工作在最有價值的需求上。關于承諾多少需求，也并非取決于團隊或專家的主觀判斷，而是根據product backlog中對每一個需求的大小估計，以及團隊過去的實際開發速率（velocity），承諾相比對數量的需求。
2. 針對所選擇需求的實作，進行簡單和必要的溝通、分析。以確定第三步可以順利的進行。
3. 分别将每一個需求，分解成設計、開發和測試等任務。并估計每一個任務所需的工作量（通常以小時計）。

Sprint 計劃會議由團隊主導，但需要PO的貢獻，特别是上面的第一條，需要PO的現場參與。其它條目，即使PO不在場，也應該随時可以提供遠端的咨詢。

作為sprint 計劃會議的結果，團隊選擇并承諾了接下來sprint 中要完成的product backlog中的使用者需求，并且，将每一個需求分解成具體的多個開發任務。這些開發任務的清單被稱為sprint backlog，它是sprint 計劃會議的最重要輸出，接下來的工作，就是完成這些開發任務，傳遞對應的使用者需求。

for(num_of_day = 1; num_of_day <=  Sprint_Length; num_of_day ++){
    run_daily_scrum_meeting();
    update_burndown_chart();
    do_development_activity(sprint_backlog, &product_increment);
}           

在這裡，每一次for循環代表一個工作日，循環的次數也即sprint 的時間長度。

Run daily scrum meeting – 進行每日Scrum 會議： Scrum 團隊每天都會進行一次同步 -- Scrum 會議。Scrum 會議被限定在15分鐘之内結束，每一天在同樣的時間，同樣的地點舉行，旨在溝通同步項目開發狀态，建立團隊對項目的整體認識，并發現項目中的問題。會議上，每一個人都向團隊回答三個問題：我昨天做了什麼？我今天計劃做什麼？在前進的道路上有什麼障礙? Scrum 會議結束後，要更新sprint燃盡圖以反映團隊的工作進度，和離sprint目标的距離。

Do development activity – 進行開發工作：Scrum強調團隊成員間的緊密協作，原則上任務應該由團隊成員主動認領，而非被配置設定。為此，團隊需要形成相應的規則，如：在同一時刻，不應該并行開始過多使用者需求開發，這樣可以確定團隊有明确的工作重點，也可以避免在sprint 結束時所有的需求都隻是部分完成，而傳遞不了任何有價值的軟體增量。随着開發程序的不斷進展，軟體增量得以生成、擴充和驗證。

run_sprint_review_meeting(product_backlog, product_increment);
run_retrospective_meeting();           

Run sprint review meeting – 進行sprint評審會議：Sprint評審會議又稱為sprint示範會議，一個sprint結束，團隊建構了包含新的使用者需求的産品增量，團隊在這個會議上展示過去的一個sprint所建構的産品。sprint評審會議是開放的，應盡可能邀請相關人員參加，ScrumMaster、團隊、PO、市場人員、客戶、管理人員、維護人員、領域專家以及關聯團隊等。在會議上團隊對照product backlog依次示範剛剛建構的使用者需求，擷取參與者的回報，這些回報将成為未來的産品設計和規劃調整的依據，以使産品更好的滿足客戶的需求，更好的服務于組織的業務目标。

Run retrospective meeting – 進行sprint團隊回顧會議：在評審會議之後，團隊進行回顧會議，評審會議是對産品的檢查和調整，而回顧會議是團隊對自身的檢查和調整。Scrum 強調通過經驗性的過程，逐漸檢查和調整團隊的協作和工作模式，持續改善。回顧會議是Scrum 運作的十分重要的一環，其有效性是Scrum實施成功的保障。除非團隊決定邀請額外人員，回顧會議一般隻有團隊參加，在回顧會議上，團隊回顧剛剛過去的一個sprint，團隊在哪些方面做得好，應該堅持；哪些方面有待改進，并挖掘其本質原因，定義具體的改進計劃，以在下一個sprint去切實實施。為保證回顧會議的有效，組織和團隊都應該承諾願意做出适應性的改變。

update_product_backlog(&product_backlog, &release_burndown_chart);
update_velocity(&velocity);            

Update product backlog -- 更新産品待辦事項：sprint 結束，産品待辦事項内的一部分需求被傳遞，應該更新其狀态。此外，由于PO和團隊擷取了更準确和詳細的産品資訊，product backlog 也應該相應更新，例如在sprint 回顧會議激發了使用者對優先級新的認識，在同PO确認後，product backlog 的優先級定義就需要做出相應的調整。更新産品待辦事項的同時，釋出燃盡圖也需要相應更改，以反映最新的需求完成情況。

Update velocity – 更新團隊開發速率：前面提到，團隊承諾多少需求的依據是團隊過去的開發速率。每個sprint結束，團隊的參考發速率都需要根據實際情況做修正，這将有助于更好地把握開發節奏，合理地計劃未來的工作。