Scrum 和最佳做法

發行項
03/25/2024

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

短期衝刺規劃會議

大部分短期衝刺規劃都牽涉到產品擁有者和團隊之間的談判，以決定即將短期衝刺中的重點和工作。對規劃會議進行計時，將會議限製為4小時或更少，這非常有用。

在會議的第一個部分中，您的產品擁有者會與您的小組會面，討論可能包含在短期衝刺中的用戶劇本。您的產品擁有者會分享資訊，並回答小組對於這些故事的任何問題。此交談可能會顯示詳細數據，例如數據源和使用者介面配置。或者，它可能會顯示回應時間預期，以及安全性和可用性的考慮。您的小組應該在待辦項目窗體中擷取這些詳細數據。在會議的這個部分中，您的小組會瞭解其必須建置的內容。

當您規劃短期衝刺時，可能會發現擷取並新增至待辦專案的其他需求。請確定其已妥善定義且依優先順序排列。

此外，將短期衝刺目標設定為規劃工作的一部分，可協助小組專注於每個短期衝刺最重要的專案。

規劃短期衝刺之後，您可能會想要與重要專案關係人共享計劃。

您可以從這些資源深入瞭解：

設定短期衝刺目標

Scrum 小組會使用短期衝刺目標來集中其短期衝刺活動。他們通常會在短期衝刺規劃會議期間設定此目標。目標摘要說明小組要在短期衝刺結束時完成的工作。藉由明確說明目標，您可以在核心用途的小組內建立共享瞭解。短期衝刺目標也可協助在優先順序發生衝突時引導小組。

從戰溝提示：定義短期衝刺目標

短期衝刺目標會定義產品擁有者和小組視為達成該短期衝刺的最終目標。這不是沒有關聯性的待辦專案隨機選取專案，而是一段簡短的文字，可擷取小組應該嘗試完成的工作。通常，產品擁有者會先取得短期衝刺目標，再選取下一個短期衝刺的許多專案。該短期衝刺的專案應全部符合該通用目標。

短期衝刺目標可以是功能導向，但也可能有大型程式元件，例如部署自動化或測試自動化。

例如：

此短期衝刺我們將著重於簡單的用戶劇本。我們將使用它來證明建議的解決方案可運作。
此短期衝刺會圍繞實作適當保護網站管理區段的安全性功能。
此短期衝刺是整合最重要的付款網關，以便我們可以開始收集資金。

設定短期衝刺目標可協助小組保持專注。它可讓您更輕鬆地在短期衝刺中定義工作的優先順序，而且可能有助於限制涉及項目關係人和終端用戶的數目。

在短期衝刺檢閱期間，您應該問自己最重要的問題是您是否設法達到短期衝刺目標。你完成的故事數第二。如果目標完成，短期衝刺就會成功，即使並非所有的故事都已完成。

由 Jesse Houwing、Visual Studio devops Ranger 和一位為荷蘭 Avanade 荷蘭工作的資深顧問貢獻。

成功分級會議的提示

修正 Bug 代表與其他工作的取捨。使用您的分級會議來判斷修正每個錯誤與符合專案範圍、預算和排程相關的其他優先順序有多重要。

建立小組的準則，以評估要修正的 Bug，以及如何指派優先順序和嚴重性。與重大價值功能相關的 Bug（或延遲的重大商機成本），或其他項目風險，應獲指派較高的優先順序和嚴重性。使用其他小組檔儲存您的分級準則，並視需要更新。
使用分級準則來判斷要修正的 Bug，以及如何設定其狀態、優先順序、嚴重性和其他欄位。
根據您的開發週期所在位置調整分級準則。在早期，您可能會決定修正您分級的大部分錯誤。不過，在稍後的迴圈中，您可能會引發分級準則，以減少您需要修正的錯誤數目。
將 Bug 分級之後，請將其指派給開發人員。然後，開發人員可以調查並判斷如何實作修正程式。

管理您的技術債務

請考慮管理 Bug 列和技術債務，作為小組整體改進活動的一部分。您可能會發現這些感興趣的資源：

從溝渠提示：Bug 管理

敏捷式 Bug 管理：不是 Oxymoron
由 Microsoft 的首席程序經理 Gregg Boer、Visual Studio 雲端服務

解決每個短期衝刺的任何已知 Bug 債務

每一個短期衝刺，小組都會查看 Bug 待辦項目中剩餘的任何 Bug，並指定容量，讓已知的一組 Bug 縮減為零或接近零。無論是一天、一周還是整個短期衝刺，它們會先修正 Bug。稍後在短期衝刺中發現的錯誤不會被視為該初始承諾的一部分。除非它們是高優先順序，否則會放在下一個短期衝刺的 Bug 待辦專案上。

許多小組在承諾式組織中工作。通常，管理對於小組履行承諾的能力具有很高的價值。針對一組已知 Bug 執行容量規劃，可讓短期衝刺規劃更具決定性，以增加其符合承諾的機會。在短期衝刺期間探索到的任何新錯誤都不屬於初始承諾的一部分，而且可以處理下一個短期衝刺。

管理整個企業的 Bug 債務

一個轉型為持續消除債務的文化的組織可能會處理下列問題：如何讓小組減少其 Bug 計數，而不需要確切地告訴他們該怎麼做？領導階層希望團隊能夠改變，但讓團隊自主性來決定他們如何改變。其中一個選項是使用錯誤上限。

例如，假設每個工程師有三個 Bug 的 Bug 上限。因此，10 人的小組在其 Bug 待辦專案中不應該有超過 30 個 Bug。如果小組超過上限，則預期會停止對新功能進行工作，並低於 Bug 上限。一個團隊應該永遠處於上限之下，但團隊決定該如何做到這一點。 Bug 上限可確保小組不會拖欠錯誤債務太久。小組可以從導致第一個位置插入 Bug 的錯誤中吸取教訓。

請記住，Bug 上限代表 Bug 待辦專案中的錯誤。它不包含在開發功能之短期衝刺中找到並修正的錯誤。這些錯誤被認為是復原的工作，而不是債務。

雖然錯誤會導致技術債務，但它們可能不代表所有債務。

軟體設計不佳、撰寫程序代碼不佳或短期修正都可能導致技術債務。技術債務反映了所有這些問題帶來的額外發展工作。

追蹤工作，以 PBIs、用戶劇本或 Bug 的形式解決技術債務。若要追蹤小組在產生和解決技術債務方面的進度，您會想要考慮如何分類工作專案和您想要追蹤的詳細數據。您可以將標籤新增至任何工作專案，將其分組為您選擇的類別。

Scrum 主機的角色

Scrum Masters 藉由採用 Scrum 程式來協助建置和維護狀況良好的小組。他們引導、指導、教導和協助 Scrum 團隊適當地使用 Scrum 方法。 Scrum Masters 也作為變更代理程式，協助小組克服障礙，並推動團隊大幅提高生產力。

Scrum Masters 的核心責任包括：

支援小組採用並遵循 Scrum 程式。例如，您不應該讓每日 Scrum 會議成為持續 45 分鐘的開放式討論。
防止產品擁有者或小組成員在短期衝刺開始后新增工作。
清除封鎖問題，以防止小組進行向前進度。這項工作可能需要您完成小型工作，例如核准新組建計算機的採購單，或解決小組內的衝突。
協助小組處理衝突和產生的問題，並從程序中學習。
詢問顯示隱藏問題的問題，並確認整個團隊都充分瞭解溝通內容。
找出並保護小組免於成為重大問題的潛在問題。就像在發現 Bug 後不久修正 Bug 更便宜一樣，當問題很小且易於管理時，修正小組問題也比較容易且更干擾。
防止小組在短期衝刺檢閱會議期間呈現不完整的用戶劇本。
向業務項目關係人收集、分析和呈現數據，以示範小組如何改善和成長。例如，如果您的小組在產生較少的 Bug 時增加了所傳遞的值量，請透過定期與業務專案關係人通訊來顯示此值。

良好的 Scrum 大師有或開發優秀的溝通、談判和衝突解決技能。他們積極傾聽人們說和寫的話。他們還聽他們如何傳遞他們的資訊，例如他們的身體語言，面部表情，聲樂節奏和其他非語言溝通。

就像在發現 Bug 後不久修正 Bug 更便宜一樣，在問題成長為主要問題之前，修正小組問題也比較容易且更不具干擾性。

每日 Scrum 會議

每日 Scrum 會議可協助讓小組專注於第二天需要做什麼。保持專注可協助小組發揮最大能力，以符合短期衝刺承諾。您的 Scrum Master 應強制執行會議的結構，並確保會議會在 15 分鐘內準時開始，並在 15 分鐘內完成。

成功的 Scrum 會議有三個層面：

每個人都站起來。站起來有助於保持會議專注和簡短。
它們會依時間開始和結束，並每天在同一個位置同時發生
每個人都參與，每個小組成員都會回答三個 Scrum 問題：
- 自從最近的 Scrum 以來，我已完成哪些工作？
- 我可以在下一個 Scrum 之前完成哪些工作？
- 哪些封鎖問題或障礙可能會影響我的工作？

注意

scrum 會議的重點在於工作狀態，需要從某個小組成員傳遞至另一個小組成員。

小組成員應努力快速且簡潔地回答問題。例如：

「昨天，我更新了類別，以反映我們從資料庫提取的新數據元素，並讓它出現在介面中。這項工作已完成。今天，我確保新的數據元素會正確地使用預存程式和數據表中的其他數據元素進行計算。我相信我今天能完成這項工作。我需要有人來檢閱我的計算。我沒有障礙或阻止問題。

此回應會傳達小組成員完成的工作、小組成員計劃完成的工作，以及小組成員想要一些協助查看程序代碼。

與下一個範例形成對比：

“昨天，我上課了，它工作了。今天，我處理介面。沒有封鎖問題。

小組成員無法提供他們所處理之類別的足夠詳細數據，也無法提供其完成之介面元件的相關詳細數據。事實上，這句話從未出現過。

重要的是，沒有人在報告期間中斷。每個人必須有足夠的時間回答這三個問題。

會議後應該進行更深入和後續的討論，因為人們回到辦公桌前，或者，如果需要大量的對話，請在後續會議上進行。

許多小組會使用「虛擬停車場」方法來延遲討論。當主題發現，團隊成員認為需要進一步的討論，他們可以悄悄地走到白板或翻頁圖，並在停車場列出主題。在會議結束時，小組會決定他們將如何處理列出的專案。

短期衝刺檢閱會議

在短期衝刺的最後一天進行短期衝刺檢閱會議。您的小組會示範在短期衝刺中完成的每個產品待辦專案。產品擁有者、客戶和項目關係人接受符合其期望並識別任何新需求的使用者案例。客戶在看到示範之後，通常會更充分地瞭解其需求，並可能識別想要查看的變更。

根據此會議，某些用戶劇本會接受為完成。不完整的用戶劇本會保留在產品待辦專案中。新的使用者劇本會新增至待辦專案。這兩組故事都會在下一次短期衝刺規劃會議上排名和估計或重新估計。

在此會議和回顧會議之後，您的小組會規劃下一個短期衝刺。由於業務需求會快速變更，因此您可以利用此會議與您的產品擁有者、客戶和項目關係人，再次檢閱產品待辦專案優先順序。

短期衝刺回顧會議

回顧，當進行良好和定期時，支持持續改善。

短期衝刺回顧會議通常發生在短期衝刺檢閱會議的最後一天。在此會議中，您的小組會探索其 Scrum 的執行，以及可能需要調整的內容。

根據討論，您的小組可能會變更一或多個程式，以改善自己的效率、生產力、品質和滿意度。此會議和產生的改進對於自我組織敏捷原則至關重要。

注意

若要支援小組的回顧，請考慮安裝 Marketplace 回顧延伸模組。此延伸模組支援收集專案里程碑的意見反應、組織並排定意見反應的優先順序，以及建立和追蹤可採取動作的工作，以協助小組隨著時間改善。

請在小組短期衝刺回顧期間尋找這些區域：

影響小組一般有效性、生產力和質量的問題。
影響小組整體滿意度和專案流程的專案。
造成未完成的待辦項目會發生什麼事？小組未來可以採取哪些動作來防止這些問題？

例如，假設小組有數個工作，而小組中只有一個人可以執行。孤立的專業知識創造了一條威脅衝刺成功的重要路徑。個別的隊員加時，而其他隊員則感到沮喪，他們無法做更多的説明。接下來，小組決定練習 eXtreme 程式設計，以協助在一段時間內修正此問題。

以小組身分，努力判斷是否要調整一或多個程式，以將短期衝刺期間發生的問題降到最低。

您的小組可能需要執行一些工作來實作改進。例如，發現自己受到太多失敗組建造成負面影響的小組決定實作持續整合。因為他們不想中斷程式，所以在生產組建中開啟試用組建之前，他們花了幾個小時才設定試用組建。為了代表這項工作，他們建立了尖峰，並組織了該工作與產品待辦項目的其餘部分。