返回目錄 下一章·Scrum 中的基本角色和職責

我們發現，許多項目成員對敏捷開發中的一些基本名詞概念模糊，造成了項目管理過程和內部交流上的一些困難。在此對一些容易混淆的基本概念做解釋。

1.1 Agile——敏捷

在軟件工業界，敏捷開發已成為眾多高效開發團隊的制勝之道。它不僅被許多中小公司青睞，在全球一百強的企業中，敏捷開發也已大行其道，受到許多資深項目管理者和開發人員的推崇。例如，騰訊內部幾乎所有的開發團隊都在實施敏捷。
????敏捷不是指某一種具體的方法論、過程或框架，而是一組價值觀和原則。符合敏捷價值觀和原則的開發方法包括：極限編程（XP），Scrum，精益軟件開發（Lean Software Development），動態系統開發方法（DSDM），特征驅動開發（Feature Driver Development），水晶開發（Crystal Clear）等等。所有這些方法都具有以下共同特征：

1. 迭代式開發。即整個開發過程被分為幾個迭代周期，每個迭代周期是一個定長或不定長的時間塊，持續的時間較短，通常為一到四周。
2. 增量交付。產品是在每個迭代周期結束時被逐步交付使用，而不是在整個開發過程結束的時候一次性交付使用。每次交付的都是可以被部署到用戶應用環境中被用戶使用的、能給用戶帶來即時效益和價值的產品。
3. 開發團隊和用戶反饋推動產品開發。敏捷開發方法主張用戶能夠全程參與到整個開發過程中。這使需求變化和用戶反饋能被動態管理并及時集成到產品中。同時，團隊對于用戶的需求也能及時提供反饋意見。
4. 持續集成。新的功能或需求變化總是盡可能頻繁地被整合到產品中。一些項目是在每個迭代周期結束的時候集成， 有些項目則每天都在這么做。
5. 開發團隊自我管理。擁有一個積極的、自我管理的、具備自由交流風格的開發團隊，是每個敏捷項目必不可少的條件。人是敏捷開發的核心。敏捷開發總是以人為中心建立開發的過程和機制，而非把過程和機制強加給人。

1.2 Scrum——橄欖球式開發模式

Scrum 是一個用于開發和維持復雜產品的框架，是一個增量的、迭代的開發過程，是敏捷開發的一種實現機制。Scrum以經驗性過程控制理論（經驗主義）為理論基礎，主張知識源于經驗, 以及基于已知的東西做決定。Scrum 采用迭代、增量的方法來優化可預見性并控制風險。在這個框架中，整個開發過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個沖刺（Sprint）。
????在Scrum中，使用產品Backlog來管理產品需求和開發任務。產品backlog是一個按照商業價值（或實現優先級）排序的事項列表，列表條目的體現形式通常為用戶故事。在規劃Sprint時，Scrum團隊從產品Backlog中挑選最高優先級的需求，在Sprint計劃會議上經過討論、分析和估算得到相應的任務，并分配給具體的成員去實現。
????當前Sprint需要完成的任務會展現在特別設計的面板上，清晰地展示每個任務的負責人、當前狀態、實現過程中的問題和變更等等信息。項目團隊和各利益攸關方能清晰地把握每個任務的開發進度和遇到的問題，并以此分析、控制項目的進度、成本和風險。
????Scrum以站立會作為項目規劃、過程控制和資源分配的內部交流協商機制。
????在每個迭代結束時，Scrum團隊將遞交潛在可交付的產品增量。

????作為敏捷開發的實現機制，Scrum擁有以下重要特征：

1. 迭代開發。在Scrum的開發模式下，我們將開發周期分成多個1-4周的迭代，每個迭代都交付一些增量的可工作的功能。迭代的長度是固定的，如果我們選擇了1周的迭代，那么保持它的長度不要發生變化，在整個產品開發周期內每個迭代都是1周的長度。這里需要強調的是在每個迭代必須產出可工作的增量功能，而不是第一個迭代做需求、第二個迭代做設計、第三個迭代做代碼。
2. 增量交付。增量是一個 Sprint 及以前所有 Sprint 中完成的所有產品待辦事項列表條目的總和。在 Sprint 的結尾，新的增量必須“完成”，這意味著它必須可用并且達到了 Scrum 團隊 “完成”的定義的標準。無論產品負責人是否決定真正發布它，增量必須可用。增量是從用戶的角度來描述的，它意味著從用戶的角度可工作。
3. 自組織團隊。Scrum團隊是一個自組織的團隊，傳統的命令與控制式的團隊只有執行任務的權利，而自組織團隊有權進行設計、計劃和執行任務，自組織團隊還需要自己監督和管理他們的工程過程和進度，自組織團隊自己決定團隊內如何開展工作，決定誰來做什么，即分工協作的方式。
4. 高優先級的需求驅動。在Scrum中，我們使用Product Backlog來管理需求，Product Backlog是一個需求的清單，其中的需求是漸進明細的、經過優先級排序的。Scrum團隊從Backlog最上層的高優先級的需求開始開發。在Scrum中，只要有足夠1-2個Sprint開發的細化了的高優先級需求就可以啟動Sprint了，而不必等到所有的需求都細化之后。我們可以在開發期間通過Backlog的梳理來逐步的細化需求。

1.3 Sprint——沖刺

組成整個開發過程的一個短的迭代周期成為一次沖刺。一個Sprint是指一個1周－4周的、有明確生產計劃和產出的迭代周期，由Sprint 計劃會議、每日站會、開發工作、Sprint 評審會議和 Sprint 回顧會議構成，并產出可交付的產品增量。也就是說，每個Sprint結束即可向需求方提交一次版本更新。
????Scrum采用迭代增量的方式，是因為需求是涌現的，我們對產品和需求的理解是漸進式的，Sprint長度越長，我們需要預測的越多，復雜度會提升、風險也會增加，所以Sprint的長度最多不超過4周。越來越多的團隊使用2周的Sprint，很多市場變化快、競爭激烈的領域，比如互聯網和移動互聯網產品開發團隊也會使用1周的迭代。
????每次沖刺可在超前完成工作計劃時提前結束，但必須在到期時結束。關閉沖刺時，已完成的任務需要評審以確定是否真的完成，未完成的任務則須退回到待辦事項列表中。

1.4 Backlog——待辦事項列表

Scrum軟件開發是一個循序漸進的過程，而用戶需求和技術實現通常具有相當的不確定性。項目團隊通常需要反復對需求進行識別分析，創建工作分解結構，估算工作量，并及時響應需求和技術的不確定性。Scrum利用Backlog來管理用戶需求和任務，并通過及時梳理來響應需求變更。
????Scrum的產品Backlog是一個按照商業價值（或實現優先級）排序的事項（需求）列表，記錄經過識別、分解和估算的用戶需求和任務。Jira系統提供的Backlog如下圖所示。

1.5 Issue——事項

在Scrum中，經過識別解析得到的用戶故事、開發任務、測試得到的BUG等等統稱為事項（Issue）。

2.5.1 Story——用戶故事

用戶故事是從用戶的角度來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素：

1. 角色：誰要使用這個功能。
2. 活動：需要完成什么樣的功能。
3. 商業價值：為什么需要這個功能，這個功能帶來什么樣的價值。

用戶故事以故事點（Story point）作為其相對大小的衡量單位。故事點一般是指相對于某個標準故事而言，當前故事所需付出的努力。由于故事點往往由相對比較法估算得出，因此其大小只有比較意義沒有絕對意義，也并不對應具體工時。

1.5.2 Epic——史詩

在Scrum項目中，Epic是指從用戶需求中識別出來的在一定程度上相互獨立、而內部則相對聯系的需求集合，例如系統管理模塊、用戶認證模塊等等。
????也就是說，一篇史詩是由一系列用戶故事組成的故事集。通常用Epic大致描述系統模塊的功能概要或需求范圍，但不應描述細節。

1.5.3 Task——任務

Task是明確定義了輸入輸出、技術指標和其他具體要求的任務說明。對于從Story中具現的任務，一般直接從Story中開出Sub-task。如果Story足夠小，則不必再開出Sub-task，可直接將Story作為任務交給具體人員去完成。

1.5.4 Improvement——改進

Improvement指改善性的微小需求變更，是對已完成的用戶故事的細微優化調整。這些調整一般不涉及具體功能的變更，而是基于用戶體驗的細節優化，不足以形成新的用戶故事。

1.5.5 New feature——新特性

新增的用戶需求。并非對已有用戶故事的細化或者完善，而是指新的用戶故事。盡量杜絕在一次沖刺中間插入新特性，應當把他作為用戶故事規劃到Backlog里，再根據其優先級安排到以后的沖刺中。所以在JIRA中，盡量不要創建New feature。

1.5.6 Bug——缺陷

測試人員在項目測試過程中發現的任何缺陷，都需要在JIRA系統中開設BUG，詳細說明缺陷細節，確定其優先級和負責人。由于公司的JIRA與測試管理系統TestLink相關聯，測試人員可以利用TestLink自動創建Bug并生成缺陷說明。

2.6 Priority——事項優先級

事項優先級定義事項基于用戶需求、技術實現或其他利益攸關方的要求所確定的實現先后順序。包括：

1. Blocker：最優先實現。在Bug中指阻礙開發或測試工作，無法繼續運行，需要立即修復并且部署。
2. Critical：重要。在Bug中指崩潰、數據丟失、嚴重的內存泄漏。
3. Major：主要。在Bug中指主要的功能喪失。
4. Minor：次要。在Bug中次要功能喪失，或其他問題，即存在簡單問題。
5. Trivial：不重要。在Bug中指如單詞拼寫錯誤或文字對齊美觀問題等。

1.7 Burn-down Chart——燃盡圖

燃盡圖（burn down chart）是在項目完成之前，對需要完成的工作的一種可視化表示，向項目組成員和相關方提供工作進展的一個公共視圖。

1.7.1 沖刺燃盡圖

Sprint燃盡圖用于展示沖刺周期內故事點的變動情況，理想情況下，該圖表是一個向下的曲線，隨著剩余工作的完成，Sprint故事點“燒盡”至零。然而實際上，每個迭代都有很多待開發的Story，在敏捷開發中，工作量的評估是以Story為單位的，一個迭代Story的數量會影響到燃盡圖的Y軸。如果Story的數量過少，繪制出來的燃盡圖就會呈明顯的折線形狀，也會對速度和風險的判斷帶來影響。所以，曲線未必能真的代表剩余的工作數量，也不能完美地作為管理層進行項目可視化管理和績效管理的工具。但它可以反映出項目沖刺規劃、管理和進度控制上的一些問題。
????以下是某項目某個沖刺周期的燃盡圖：

1.png

????圖中曲線在第二周時有三個時間段比較集中地下降，說明團隊在這三個時間段比較集中地確認任務已完成；圖中沒有比較大的向上的突起，說明沖刺策劃工作還算不錯，Scrum Master對沖刺有較強的控制力，沒有在沖刺周期內引入過多的新特性；最終曲線沒有到達零點，說明沖刺周期內有任務未完成，需要反思是否存在一個沖刺內工作量過多還是、引入了新特性還是存在別的工作效率或團隊協作的問題。
????而下面這張圖反映了項目團隊對沖刺的策劃和控制可能存在更多的問題：

1.7.2 交付燃盡圖

對于PMO而言，交付燃盡圖可能比沖刺燃盡圖更具有實際意義。
????沖刺燃盡圖反映了一個Sprint內工作的“燃盡”情況，而交付燃盡圖則展示了在更長的、可能跨越很多個Sprint周期的情況下，軟件是否能如期交付某個版本或某個模塊。以下是某項目的某個版本的交付燃盡圖。

交付燃盡圖中，淺綠色的柱狀代表這個Sprint完成了的故事點數，所以前面加了個減號；
????淺藍色的柱狀代表，在這個Sprint開啟之前就存在的故事點數，在這個Sprint結束時還剩下多少；
????深藍色的柱狀代表，在這個Sprint開啟后到下個Sprint開啟前這段時間，版本中增加了多少故事點數，所以用加號。
以下通過2個圖例說明如何解讀交付燃盡圖。

1. 較正常的交付燃盡圖，可以預測這個版本可以在什么時候交付

   
   
   
   

   兩條預測線，上面那條的由來是，淺藍色柱狀的頂部中點，用最小二乘法計算的擬合直線；下面那條則是深藍色柱狀的底部中點，用最小二乘法計算的擬合直線。兩條線斜率的意義是，每個Sprint故事點數完成的速率和故事點數新增的速率。兩條預測線的交點對應的橫坐標代表這個版本預計會在哪個沖刺內完成。

2. 存在較大的無法按時交付甚至永遠無法交付的風險

   
   
   
   

   上圖兩條預測線，縱坐標軸的右側沒有交點，代表這個版本恐怕存在較大的交付風險，需要注意。如果發現版本無法可能無法交付的時候可以選擇的策略，一般是增加開發的速率，或者是減少一些當前版本的故事點數，放到下一個版本中去。

1.8 Fist-of-five——舉手表決

舉手表決（Fist to five，fist of five）是敏捷軟件開發團隊用于調查團隊成員并幫助達成一致意見的一種技術。使用舉手表決技術，Scrum Master或PO重申該團隊也許會采取的行為，并要求團隊成員展示他們的支持級別。每個團隊成員通過舉起緊握的拳頭或豎起對應支持級別的手指數來回應。如果一個團隊成員舉起的手指少于3，他有機會陳述其反對意見，團隊會給出回應。Scrum Master或PO繼續舉手表決過程直到達成一致意見（每個人都舉起的手指都不小于3）或同意轉移到下一話題。

• 緊握拳頭：不，我完全不同意。
• 1根手指：我非常擔心。
• 2根手指：我想討論一些小問題。
• 3根手指：我不完全同意但我可以接受意見通過而不須進一步討論。
• 4根手指：我認為想法不錯且愿意為其工作。
• 5根手指：想法棒極了，執行時我愿意帶頭。

1.9 需求空間、開發空間和測試空間

通常，一個項目的開發過程，可以通過3個空間來進行表達：需求空間、開發空間和QA測試空間。3個空間相互間應當是完全整合的，使得整個團隊的不同職能能夠相互協作。其中：

1. 需求空間：存放、描述項目所有待實現的需求，表現為Product Backlog，由PO主導并管理，所有團隊成員可以參與梳理。
2. 開發空間：包含項目正在開發實現的所有事項，表現為Sprint Backlog和Scrum Board，在Scrum Master 指導下由開發團隊共同管理。
3. 測試空間：管理項目的測試計劃和測試用例，是項目的一系列質量目標和驗收標準，由QA主導管理。當Sprint開始后，QA根據User Story編寫對應的測試用例，加入QA空間；當開發人員提交到To QA后，QA根據測試用例執行測試，反饋測試結果。此外，還包括其他不同級別的測試計劃和用例。