【審視】Scrum Master的檢查清單

一般情況下，一個Scrum Master如果更多的是做組織會議、確保時間盒以及對流程中的障礙快速響應等事項的話，可以同時引導2-3個團隊。在這種情況下，團隊會在降低問題發生率的基礎上提高一定的績效。

但如果Scrum Master想要將一個團隊打造成讓所有人都眼前一亮的敏捷團隊，那就需要考慮如何成為優秀的Scrum Master，以及如何更好地引導團隊。這時的Scrum Master最好是成為某一團隊（尤其是在團隊初創階段）的全職引導者。

接下來是一個Scrum Master的檢查清單，來看看Scrum Master要從哪些方面入手引導團隊吧：

一、產品負責人做得如何？

一般情況下，一個Scrum Master如果更多的是做組織會議、確保時間盒以及對流程中的障礙快速響應等事項的話，可以同時引導2-3個團隊。在這種情況下，團隊會在降低問題發生率的基礎上提高一定的績效。

但如果Scrum Master想要將一個團隊打造成讓所有人都眼前一亮的敏捷團隊，那就需要考慮如何成為優秀的Scrum Master，以及如何更好地引導團隊。這時的Scrum Master最好是成為某一團隊（尤其是在團隊初創階段）的全職引導者。

一、產品負責人做得如何？

Scrum Master可以在很多方面提高產品負責人的效率：

不論有幾個團隊，一個產品是否只有一個產品負責人？

產品待辦事項列表是否根據產品負責人最新想法進行優先級排序的？

待辦事項列表是不斷更新的，新反饋的需求是否已經放入產品待辦事項列表？

產品待辦事項列表的數量是否可管理？為了維護可管理的待辦事項數量，需要將高優先級待辦事項的顆粒度細化，低優先級的事項可以保持一個粗顆粒度的狀態。過度分析優先級不高的待辦事項會適得其反，因為需求是在不斷變化的。

需求（特別是處在高優先級的）是否能表述為獨立的、可磋商的、有價值的、可估計的、小的和可測試的用戶故事？

產品負責人是否在關注并避免技術債務的問題？比如在待辦事項的“完成”定義中加入自動化測試和重構。

待辦列表是否對所有利益相關人可見？

團隊成員是否都了解如何使用自動化工具來管理待辦列表？因為自動化工具的不正確引入往往不利于協作。

是否能夠通過更為宏觀的可視化方式來促進信息傳播？

有沒有幫助產品負責人梳理待辦事項的優先級？

所有的利益相關人（包括團隊）是否知道發布計劃與團隊現有速率的符合情況？可以嘗試在每個Sprint回顧會議上，確認項目已經“完成”后演示產品或發布燃盡圖。這會讓我們更及時地發現范圍和時間的偏差。

產品負責人是否會在Sprint評審后調整發布計劃？一些產品負責人會在Sprint交付后，及時調整發布計劃。因為在這一過程中會不斷地發現其他重要工作，一些原有工作會被推遲發布。

二、團隊做得如何？

團隊的狀態是否流暢？一般流暢的團隊會呈現以下特征：

明確的目標（期望和規則清晰可見，目標可以實現，且與個人的技能和能力適當匹配）；

全神貫注并全力以赴；

在下意識狀態中，行動和認知相統一；

直接及時的反饋（行為可以隨反饋不斷地進行調整）；

在能力與挑戰尋求平衡（不要太容易也不要太難）；

控制力：對形勢和任務的控制力；

存在內在激勵，因此工作起來很輕松。

團隊成員是否相互合作、相互理解，并經常一起慶祝項目成功？

團隊成員是否相互以高標準監督、相互挑戰以促進成長？

有沒有一些話題因為大家感覺難受，所以在團隊里沒有進行討論的？

是否嘗試過通過不同的形式和地點做Sprint回顧？

團隊是否在Sprint中一直關注驗收標準？考慮一次在Sprint中期檢查來重新評估Sprint計劃。

Sprint任務是否反映出團隊實際在做的事情？與Sprint無關的工作是Sprint的障礙。

團隊是否由5－9個跨職能人員組成？能否來構建潛在的可交付的產品增量？

團隊的任務板是否包含最新信息？

團隊用于自管理的工件（任務板、Sprint燃盡圖等等）是否對團隊可見？方便使用嗎？

這些工件是否受到充分保護，不受外界干涉？團隊外部的人對團隊日常活動的過度審視可能會阻礙團隊內部的透明化和自我管理。

團隊成員是否會自愿領取任務？在Scrum團隊中，應該感覺自己就像得到了報酬的志愿者。如果沒有這種感覺，那一定是哪里出問題了。

償還技術債務的需要有沒有放在待辦列表里？如果沒有的話，團隊有沒有和產品負責人溝通？

團隊成員能否拋開各自的崗位定義，對約定工作的所有方面（測試、用戶文檔等）集體負責？

管理層是否以集體的成功來衡量團隊？

三、工程實踐做得如何？

團隊開發中的系統是否有一個“按下測試”的按鈕，讓每個人（同一團隊或不同團隊的）都能方便地檢測到系統被破壞了？通常可以使用XUnit框架（JUnit等）來實現。

是否自動化的端到端系統測試（或功能測試）與自動化的單元測試之間尋求適當的平衡？

團隊是否用開發系統的同種語言來寫系統功能測試和單元測試（而不是用只有部分團隊知道如何維護的專用腳本語言或捕捉回放工具）？

團隊是否發現在系統測試和單元測試之間存在有用的灰色區域嗎？

當有人引起回歸失敗時，是否有個持續集成服務器會在一小時甚至幾分鐘內自動發出警報？

是否將所有測試匯總到持續集成服務器的結果中？

團隊成員們是否發現了持續設計和不斷重構的樂趣？重構有一個嚴格的定義：改變系統的內部結構而不改變其外部行為，且在存在重復的代碼、復雜的條件邏輯、糟糕的命名標識符、對象之間的過度耦合等情況下進行。重構應該連續進行，至少每小時進行幾次。只有在自動化測試覆蓋的情況下，才可能有信心地進行重構。

產品待辦事項列表的“完成”的定義是否包括完整的自動化測試覆蓋和重構？測試驅動開發（TDD）可以增加實現此目標的可能性。

團隊成員是否大多數時間來結對編程？結對編程可以顯著地增加代碼的可維護性，并減少Bug率。

四、團隊/組織做得如何？

團隊之間是否有充分溝通？Scrum of Scrums是實現溝通的一種方式。

團隊在需要跨越架構邊界的情況下是否能夠獨立交付工作？

是否在組織內進行全面回顧以解決跨團隊、系統的問題？

在適當的時候，是否有將團隊障礙有貼在研發主管的辦公室墻上嗎？這些障礙帶來的浪費是否能被量化為失去的錢、投入市場的時間、質量或者客戶線索？

團隊或組織是否是為數不多的能提供和團隊集體目標一致的職業道路的組織？如果是以犧牲測試、自動化測試或用戶文檔為代價來做編程或架構工作，請回答“否”。

團隊或組織是否被專業刊物或其他獨立來源公認為最佳組織或行業引領者？

是否在創建學習型組織？

像Scrum Master一類的創造性的工作沒有一個標準實踐，上面列出的點可能會幫到Scrum Master，也有可能幫不到。不過，一旦Scrum Master開始意識到自己可以做些什么來改變現狀，盡管可能不敢去做。但沒關系，你已經走上了一條成為優秀Scrum Master的道路。

敏捷開發 軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。