Scrum

發行項
08/12/2011

Scrum 是一套用於執行以 Agile 原則和價值為基礎之專案的架構。它會定義一組活動，可協助您的小組更速快地為客戶提供更多價值。這些活動可讓您的客戶有機會在小組工作進展時加以檢閱、指引和影響。這種方法不會嘗試在專案一開始就定義所有項目。而是，您的小組會在簡短的反覆項目 (也稱為期程 (Sprint)) 中工作，並且隨著小組的進展調整計劃。如需 Scrum 所依據之 Agile 原則和價值的詳細資訊，請參閱 Agile 原則和價值，作者：Jeff Sutherland。

MSF for Agile Software Development v5.0 是以 Scrum 為基礎。因此，您的小組可以使用與核心開發活動整合的工具，藉以採用 Scrum。

本主題內容

準備專案
規劃專案
規劃期程
執行期程
追蹤專案

準備專案

開始進行專案之前，請先執行下列工作：

建立商務案例
召集小組
設定小組的基礎結構

若要建立商務案例，請識別商務需求和理由、定義願景，並取得資金。 Geoffrey Moore 所著的《Crossing the Chasm》一書就提供了建立願景的絕佳指引。如需詳細資訊，請參閱下列 Web 資源：Crossing the Chasm (英文)。

建立商務案例之後，您必須召集小組並識別 Scrum 主管和產品擁有者。如需詳細資訊，請參閱角色。

最後，您的小組必須設定基礎結構。例如，您可以安裝 Visual Studio Team Foundation Server 和 Visual Studio Application Lifecycle Management (ALM)、建立並 (可能) 自訂 Team 專案，以及設定工程做法。如需詳細資訊，請參閱 Visual Studio Application Lifecycle Management 使用者入門、自訂 Team 專案和工程作法。

規劃專案

在 Scrum 專案中，您的小組將花費大部分時間在一連串的期程中開發產品。不過，您的小組必須先建立專案的高階計劃。這個計劃是引導小組在專案進行期間所做之更詳細決策的藍圖。當您的小組實作計劃時，計劃將會變更。當您的小組完成專案規劃之後，小組就會建立產品待處理項目以及發行計劃 (如果需要的話)。

建置產品待處理項目

產品待處理項目是指描述使用者所需和重視之項目的使用者本文清單。這些使用者本文會依照商務價值和風險排定優先權，而且小組會使用稱為本文點的抽象單位來估計使用者本文。

建立使用者本文、設定使用者本文的順位以及評估使用者本文

建立使用者本文：在 Mike Cohn 所著的《User Stories Applied》一書中，他以這種方式定義使用者本文：「使用者本文會描述對於系統或軟體使用者或購買者而言很重要的功能」。使用者本文是從使用者的觀點所撰寫的。例如：

「身為老客戶，我想要尋找之前訂購過的餐點」。

如需詳細資訊，請參閱建立絕佳的產品待處理項目。

排定使用者本文的優先權：您的產品擁有者會與客戶一起了解他們重視的項目並與小組一起了解風險和相依性，藉以在產品待處理項目中排定使用者本文的優先權。您的產品擁有者會透過指派順位給每個使用者本文來指定優先權，以便指出小組應該實作它們的順序。

您的產品擁有者可以使用許多技術來分析並比較使用者本文的價值。如果您的小組已經有適用的優先權排定方法，請使用該方法。

少數優先權排定技術與 Agile 社群密切相關，例如客戶滿意度的 Kano 模型以及 Karl Wiegers 提出的相對加權。 (如需相對加權的詳細資訊，請參閱下列網頁：首要事項優先：排定需求的優先權 (英文))。其他優先權排定技術 (例如成本優先權、淨現值、投資回收期和實質報酬率) 則與 Agile 社群無關。這些技術也是合格技術，適合針對 Scrum 專案排定產品待處理項目的優先權。如需詳細資訊，請參閱下列 Web 資源所識別之書籍中的＜Part II: Estimating Size＞：Agile Estimation and Planning (英文)。

估計使用者本文：您的小組會共同使用本文點來估計每個使用者本文。在 Mike Cohn 所著的《Agile Estimation and Planning》一書中，他以這種方式定義本文點：「本文點是一種測量單位，用於表示使用者本文、功能或其他工作的整體大小」。本文點是不會直接轉換成特定時數的相對數值。不過，本文點可協助小組量化使用者本文的一般大小。這些相對估計值較不精確，所以比較容易判斷，而且經過一段時間仍然有效。透過使用本文點估計，當小組成員即將實作使用者本文時，您的小組可立即提供使用者本文的一般大小，然後再開發更詳細的工作時數估計。

判斷小組的速度

建立發行計劃和規劃每次期程之前，您的小組必須判斷其速度。小組的速度是指它可以在一次期程內完成的本文點數目。

如果您的小組已經透過收集資料來測量其速度，而該項資料顯示小組在給定時間內完成的使用者本文數目，請使用該項資料。它可讓您有效深入探索小組的速度。如果您現在沒有該項資料，但是即將開始使用 Visual Studio ALM 和 MSF for Agile Software Development v5.0 來執行專案，系統將在專案進行期間收集該項資料。如需詳細資訊，請參閱所有反覆項目的狀態報表。

如果沒有歷程資料可用，您的小組可以針對它在第一次期程內可完成的本文點數目進行概略估計。請查看位於優先權堆疊頂端的估計使用者本文，然後針對它在一次期程內可完成的本文數目進行快速評估。請將每個使用者本文的本文點相加，以便取得初始估計值。第一次期程之後，您就可以使用歷程資料來判斷小組的速度。在前幾次期程中，您應該會在小組學習如何以一致的方式估計時發現相當的差距。經過許多次期程之後，小組的測量速度應該會比較穩定。當小組的測量速度穩定時，請重新評估發行計劃。

小組速度的估計值會提供一個起點，可讓您用來判斷要在期程中實作的使用者本文數目，但是此估計值並非小組承諾的基礎。小組的承諾是建立在完成使用者本文所需之工作的更詳細估計上。如需詳細資訊，請參閱產品計劃活頁簿。

建立發行計劃

在每次期程中，您的小組將完成可出貨之產品的增量。雖然小組所實作的使用者本文在期程結束時已經準備好出貨，不過它們可能無法提供足夠的商務價值來闡述實際發行產品的理由。規劃發行時請將發行指派給反覆項目：

識別可一起提供足夠商務價值以發行給客戶的使用者本文群組。
判斷小組應該在哪些期程內完成這些使用者本文群組。

當您的小組進展時，使用者本文會加入至產品待處理項目，而且可能會移除使用者本文。此外，某些使用者本文的優先權會變更，而某些使用者本文可能會比原本預期更早或更晚實作。您的產品擁有者會在專案進行期間維護發行計劃以及產品待處理項目。

如需詳細資訊，請參閱產品計劃活頁簿。

準備第一次期程

期程是指時間框限的開發反覆項目，通常為期一至四週，而且它會產生小組可出貨之產品的增量。在小組開始進行第一次期程之前，您的產品擁有者會準備產品待處理項目。優先權夠高足以考慮納入第一次期程的使用者本文必須備妥，以便讓小組實作。您的產品擁有者必須執行下列工作，以準備產品待處理項目：

將使用者本文細分為較小的本文。
提供小組將使用者本文細分為工作時所需之使用者本文的相關詳細資料。

如果某個使用者本文代表小組整體速度的主要數量，您的產品擁有者就會知道該使用者本文太大。例如，如果小組的速度是 30 個本文點，則 15 個本文點的使用者本文就太大，無法納入期程計劃會議。此時，小組將採用一半期程，以便完成該使用者本文。

您的小組也會要求使用者本文的相關詳細資料，以便將它們細分為工作和估計這些工作。例如，當您的小組檢查「身為客戶，我想要能夠搜尋某種類型的餐點」使用者本文時，可能會提出下列類型的問題：

「這必須設計成任意文字搜尋，還是可用類型清單的選項？」
「如果多個廠商提供符合搜尋的餐點，應該如何排序這些結果？」

如需詳細資訊，請參閱準備進行下一次期程。

規劃期程

當小組已經開發出產品待處理項目並且建立發行計劃時，就可以開始進行期程的工作。您的小組會進行期程計劃會議來開始期程，讓小組承諾完成產品待處理項目中的一組使用者本文。該組使用者本文以及支援的工作就是期程待處理項目。如需詳細資訊，請參閱比較產品與衝刺待處理項目。

期程開始之後，期程待處理項目中的使用者本文就不會變更。因此，計劃必須夠詳細，才能讓小組有信心地提出該項承諾。

如需詳細資訊，請參閱衝刺計劃會議。

選擇使用者本文

您的小組會選擇要在期程中實作之候選的使用者本文。您的小組會識別具有最高優先權而且其本文點不超過其估計速度的使用者本文。例如，具有最高優先權的四個使用者本文可能有 8、3、7、6 和 2 個本文點。如果小組的每次期程具有 25 個本文點的容量，您的小組就會在期程待處理項目中加入前四個本文。

如需詳細資訊，請參閱反覆項目中的待處理項目活頁簿。

識別工作

您的小組會評估每個使用者本文來判斷它必須完成才能實作該本文的工作。您的小組會將使用者本文細分為工作來協助它充分了解使用者本文，以便提出有信心在期程中實作它們的承諾。

[反覆項目中的待處理項目] 工作表

在 Scrum 方面非常有經驗的小組可能不需要將使用者本文細分為工作，就能夠提出這項承諾。

估計工作

識別工作之後，您的小組會估計每項工作將花費的時間長度 (以小時為單位)。小組經常會使用規劃撲克牌 (Planning Poker) 技術來估計工作。這項技術有助於避免小組嘗試估計不必要的精確度。

承諾完成使用者本文

您的小組會使用 [反覆項目中的待處理項目] 活頁簿來確定小組有足夠的工作時數能完成所有工作。如果期程的工作超過小組在期程中可用的工作，您就必須移除最低順位的使用者本文，直到工作能夠納入小組的期程容量為止。您可以針對無法容納期程的大型本文，交換優先權較低的小型本文。

容量工作表

您的小組會承諾完成它已經判斷出能夠完成的使用者本文。它會提出這項承諾是因為，它了解您的產品擁有者不會嘗試引入額外工作，或變更正在期程中實作之使用者本文的優先權。

執行期程

在期程期間，您的小組會完成實作期程待處理項目中之使用者本文所需的工作。完成每次期程之前，您的小組可以追蹤其進度，並確定它符合客戶的驗收準則和小組的完成軟體準則。

完成使用者本文

在您的小組規劃期程之後，它會有一份承諾在期程期間完成的使用者本文清單。這些使用者本文已經細分為工作。當期程開始時，每位小組成員都會註冊工作。完成該項工作之後，小組成員就會更新其狀態並註冊另一項工作。您的小組會以這種方式逐一處理工作清單，並完成期程待處理項目中的使用者本文。小組成員可以指出哪些工作在簽入程式碼時已完成。如需詳細資訊，請參閱使工作項目與變更集產生關聯。

如需指派工作和更新其狀態的詳細資訊，請參閱工作 (Agile)。

相較於正式流程，Scrum 更仰賴人員彼此交談，以便確定他們了解相依性、共用專業知識，並且有效率地進行計劃中的變更。請每天召開簡短的 Scrum 會議，讓每位小組成員共用有關下列項目的詳細資料，包括：他們在前一天所完成的工作、他們計劃於當日完成的工作，以及任何可能會影響或需要其他小組成員提供協助的問題或阻礙。如需詳細資訊，請參閱每日 Scrum 會議。

在 Kent Beck 所著的《Extreme Programming Explained》一書中，他就指出越早修正 Bug 的成本越低。在這項事實的前提之下，您的小組必須了解哪些事項對於客戶而言很重要。也許客戶重視的是品質，而不是更多功能。您的產品擁有者必須知道這種資訊，因為客戶會控制小組的工作流程。

Scrum 小組所產生的軟體應該是沒有任何錯誤的軟體。不過，您的小組可能會在專案中遇到錯誤。此時，請處理 Bug，因為小組了解一發現 Bug 便加以修正會比日後修正的成本更低而且更快速。當您的小組發現 Bug 時，請立即修正它們。如果您的小組無法在發現 Bug 的同一天修正 Bug，請在 Visual Studio ALM 中建立 Bug 工作項目，並於期程結束之前修正它。

如需詳細資訊，請參閱 Bug (Agile)。

追蹤期程進度

您的小組可以追蹤期程進度，以便確定工作如預期般完成，而且它符合驗收準則。 Scrum 小組最常使用 [待執行工作] 報表來追蹤其期程進度。 MSF for Agile Software Development v5.0 提供了一組報表，可讓小組用來追蹤期程進度。

狀況良好的待執行工作報表版本

小組通常會發現他們完成某項工作所需的時間比期程計劃會議期間估計的時間更長或更短。這種變化是典型的變化。您可以藉由指定小組在工作中花費的實際時間，記錄這項資訊。

當期程進行時，您的小組可能會識別非預期卻是完成使用者本文所必要的工作。在這種情況下，請建立工作、估計工作，然後判斷小組是否能在期程的剩餘時數中完成工作。如果您的小組可以完成此工作，請繼續進行期程。如果您的小組無法在期程中完成此工作，請會同產品擁有者一起討論如何繼續進行。產品擁有者和您的小組可以進行下列類型的變更來解決問題：

降低使用者本文的驗收準則，讓此工作成為不必要的工作。
從期程待處理項目中移除使用者本文。
取消期程。

完成期程

在期程即將結束時，請確定小組正在完成所有使用者本文或需求。例如，請確定接受度測試已成功，而且每個使用者本文都符合小組所定義的準則。如需完成定義的詳細資訊，請參閱下列網頁：Mitch Lacey & Associates, Inc. (英文)。

Bug 狀態報表

Bug 趨勢報表

在期程的最後一天，您的小組將會為產品擁有者和客戶 (可能) 示範它已完成的使用者本文。您的產品擁有者和客戶會判斷他們是否接受每個使用者本文。如需詳細資訊，請參閱衝刺檢閱會議。

在客戶檢閱之後，您的小組將召開追溯性會議。如需詳細資訊，請參閱追溯性會議。

追蹤專案

當您的小組在期程中工作以提供專案的增量時，客戶會逐漸對其餘需求有較佳了解，而且您必須考慮商務環境中的變更。您的產品擁有者會與客戶一起了解這些變更。您的產品擁有者會維護產品待處理項目和發行計劃，以便反映這些變更，並確定您的小組在每次期程開始時就擁有所需的項目。您的小組會追蹤產品的整體進度，以便確定它正在朝完成專案的進度順利邁進。

準備進行下一次期程

產品待處理項目的有效期限與專案的整體品質和完整性有直接關聯性。待處理項目必須定期更新、變更和重新考慮，以便確定待處理項目在每次小組即將開始期程時準備就緒。

您的產品擁有者會執行下列工作，以準備產品待處理項目來進行下一次期程：

隨著客戶需求變更，更新使用者本文及其優先權。
細分可能會在下一次期程中實作的使用者本文。

產品待處理項目

當您的小組完成一次期程時，其他使用者本文就會更接近產品待處理項目的頂端。您的產品擁有者必須分析並細分這些位於頂端的本文，讓小組能夠在即將進行的期程中實作它們 (如需詳細資訊，請參閱本主題前面的準備第一次期程)。Mike Cohn 通常將此流程稱為產品待處理項目冰山。當小組處理一組功能時，此冰山就會融化、新的工作會浮出表面，而且冰山會變得更小。在此流程中，其他出現的詳細資料剛好足夠而且及時。

既然您的小組正忙於執行期程，產品擁有者就無法預期小組投入維護產品待處理項目的程度與準備第一次期程時所投入的程度相同。為了在對期程造成最小中斷的情況下協助產品擁有者準備產品待處理項目，您的小組和產品擁有者將在進行期程期間討論產品待處理項目的相關開啟問題。

追蹤發行進度

當專案依序進行期程時，您的小組會追蹤下一次發行的整體進度。您的小組也將追蹤其進度來評估並改善其速度。當您的小組追蹤其進度時，它應該嘗試回答下列類型的問題：

我們是否正在處理最適當的使用者本文？您的產品待處理項目將會隨著專案進行，使用新的使用者本文加以調整。不過，如果待處理項目中的本文總數沒有降低，即使您在每次期程中完成本文，小組仍然應該要調查原因。正在完成的本文可能不是最佳選擇。小組應該針對每次發行設有一個願景和目標，並且確定這些本文直接與客戶要求的項目繫結。
我們是否承擔技術負債？即使修正 Bug 之類的工作尚未完成，某些小組仍然會將使用者本文視為已完成。這些小組就會承擔日後必須償還的技術負債，而且成本通常更高。

Visual Studio ALM 提供了許多報告來協助您的小組追蹤許多期程的進度。

所有反覆項目的狀態報表

狀況良好的所有反覆項目的狀態