共计 2901 个字符，预计需要花费 8 分钟才能阅读完成。
雖然這篇文章討論了 Scrum 中的一些常見指导原则，但重要的是要記住這些指南是靈活的，應根據您團隊的需求進行塑造。
當我提到規則時，我指的是那些無法修補以適應特定背景的方面。例如，沒有產品負責人，開發團隊和 Scrum Master，您就無法做 Scrum。
當我提到指南時，我指的是那些可能被改變以適應特定背景的方面; 但是，影響只能在實施後進行驗證。然後我們相應地檢查和調整。
例如，Product Backlog 細化消耗不超過團隊容量的 10%。容量是小時數，故事點數還是天數？嗯，沒有規則。Scrum 團隊自我組織並選擇最適合他們背景的東西; 遵循我們消耗的指導方針，不超過團隊容量的 10%。
在這篇文章中，我將探討一些將 11 個要素綁定在一起的指南，並讓 Scrum 團隊靈活地將這些方面融入其背景中。
#1。開發團隊規模
建議開發團隊的規模為 3 - 9 名成員。根據具體情況，可能會有更多人或更少。它的影響因團隊環境而異。不到三個開發團隊成員減少了交互，導致生產率降低。較小的開發團隊可能會在 Sprint 期間遇到技能限制，導致開發團隊無法提供可能可釋放的增量。擁有超過九名成員需要太多的協調。大型開發團隊為實證過程提供了太多的複雜性。
#2。開發團隊的標題 / 角色
Scrum 無法識別開發團隊中的任何標題 / 角色。在開發團隊中，每個人都是開發團隊成員。雖然在組織內，團隊成員可能擁有頭銜 / 角色。根據我的經驗，我沒有遇到任何只有一個頭銜 / 角色的團隊。
#3。每日 Scrum 的三種問題格式
我使用過的大多數團隊都使用了每日 Scrum 的三個問題的格式：
昨天我做了什麼幫助開發團隊實現 Sprint 目標？
今天我將做些什麼來幫助開發團隊實現 Sprint 目標？
我是否看到任何妨礙我或開發團隊滿足 Sprint 目標的障礙？
這三個問題只是以 Scrum 開頭的團隊的模板。只要他們專注於 Sprint 目標的進展，開發團隊就可以按照他們認為合適的方式構建他們的 Daily Scrum。
#4。活動時間表
事件的時間框表示一個月 Sprint 事件允許的最長時間。指南是：對於較短的 Sprint，時間限制通常較短。
這是否意味著，對於為期兩週的 Sprint，Sprint Planning 的時間限制為四小時，Sprint Review 為兩小時，Sprint 回顧為一個半小時？沒有。
只要滿足其目的，事件可以根據需要调整短 / 長，但它們不能超過最大分配時間。例如，Sprint 計劃為期兩週的 Sprint 計劃活動如果達到目的可能會在兩小時內結束，如果不滿足，則可能會持續八個小時。
#5。進展趨勢
Scrum 指南建議使用燒毀圖表和累積流量等實踐來監控進度。但是，團隊可以完全自由選擇他們認為合適的任何練習。根據我的經驗，我見過團隊創建視覺路線圖，基於里程碑的進度，旅程線，釋放燃燒圖表等。我們還需要記住，在復雜的環境中，只有經驗數據才能幫助我們做出正確的決策。
#6。估計
在 Scrum 的指南介紹了需要積壓的產品項目來進行估計。如何估算它們完全取決於 Scrum 團隊。故事點，理想日，T 卹尺碼，狗尺碼是一些方法。
Scrum 團隊可以做“沒有估計”嗎？當然，只要 Scrum 團隊能夠起草支持經驗主義的計劃，創建透明度，並幫助團隊在 Sprint 結束時創建可能可釋放的“完成”增量。Scrum 團隊自行組織選擇適合其背景的內容。
#7。工作分解
在“選擇的工作將如何完成？”部分下。對於 Sprint 計劃，Scrum 指南提到：
開發團隊在 Sprint 的頭幾天計劃的工作在本次會議結束時進行分解，通常分為一天或更短時間。
然而，這通常有助於發展團隊這樣做。根據我的經驗，我看到幾個團隊沒有將他們的工作項目細分到如此細緻的水平。他們了解如何將功能轉換為“完成”增量。
#8。Sprint 評論
這是一項重要的檢查和調整活動，Scrum 團隊與主要利益相關方就 Sprint 期間取得的成果進行合作，以及在下一個 Sprint 中可以做些什麼來優化產品的價值。
Scrum 指南還描述了 Sprint Review 中的元素：
與會者包括 Scrum 團隊和產品負責人邀請的主要利益相關者。
產品負責人解釋了產品待辦事項項目已“完成”且未完成的內容。
開發團隊討論 Sprint 期間的情況，遇到的問題以及這些問題是如何解決的。
開發團隊演示了它“完成”的工作，並回答了有關增量的問題。
產品負責人會討論產品 Backlog。他或她根據迄今為止的進展（如果需要）預測可能的目標和交付日期。
整個小組就下一步做什麼進行合作，以便 Sprint Review 為後續的 Sprint Planning 提供有價值的信息。
回顧市場或產品的潛在用途如何改變下一步最有價值的事情。
審查下一個預期的產品功能或功能發布的時間表，預算，潛在功能和市場。
對於已經獲得資助一年的 Scrum 團隊來說，在每兩週一次的 Sprint 評審中審查其預算是否有意義？也許不吧。
並非所有上面提到的元素都適用於所有 Scrum 團隊。它們作為指導提供，以便 Scrum 團隊可以選擇在 Sprint 審核期間討論和触及產品交付的各個方面，因為他們認為適合他們的上下文。
#9。發佈到生產
每個 Sprint 的目的是創建一個可能可釋放的“完成”增量。這意味著增量需要處於可用狀態並滿足 Scrum 團隊的完成定義（DoD）。
然而，將增量釋放到生產中的選擇由產品負責人決定。根據團隊的上下文及其創建的增量，Scrum 團隊可能決定每個 Sprint 執行多個版本，每個 Sprint 發布一個版本，或者累積發布多個 Sprint; 無論如何優化產品的價值。
#10。完成的定義
“完成”的定義有助於提高透明度，並對完成工作的含義達成共識。根據 Scrum 指南，Scrum 團隊有望擴大他們的國防部並使其更高質量的更嚴格。
同樣，這不是一個規則。取決於團隊的背景; Scrum 團隊可能會在每次回顧中重新審視它的國防部，或者可能繼續使用相同的國防部，除非它學會了新的東西以提高產品的質量。
結論
這些只是 Scrum 指南中的一些指導原則。我想提出這種區別，因為我經常發現 Scrum 團隊與 Scrum 規則和指南混淆。幾乎沒有什麼是常見的 – 將 Sprint 計劃的時間安排為兩個星期的 Sprint 或開發團隊花費太多時間和精力將 PBI 分解為“任務”– 其他人並不常見。我相信這篇文章將幫助團隊確定 Scrum 的一些方面，他們可以修改這些方面以適應他們的背景。
Scrum 参考
What are the Scrum Events?
What are Scrum Ceremonies?
What is Product Backlog Grooming?
What are the 3 Important Questions in Daily Scrum?
Scrum Sprint Cycle in 8 Steps
What is a Sprint in Scrum?
Heartbeat of Scrum – The Daily Standup
Daily Scrum Meeting – A Quick Guide
Why Fixed Length Sprints in Scrum?
What is Scrum Release Planning?
What is Sprint Planning?
What is Sprint Review?
