摘要：衆所周知，ScrumMaster是服務型上司——其本身不參與日常的研發工作，寫代碼、改Bug的工作都讓團隊幹了，Scrum Master到底幹了啥？ScrumMaster工作的好壞應該如何衡量？
本文分享自華為雲社群《Scrum Master們每天都在摸魚麼？》，作者：靈活的小智 。
衆所周知，ScrumMaster是服務型上司——其本身不參與日常的研發工作，寫代碼、改Bug的工作都讓團隊幹了，Scrum Master到底幹了啥？ScrumMaster工作的好壞應該如何衡量？
衡量ScrumMaster工作的好壞，首先應該了解Scrum Master平時都幹什麼。
全職的ScrumMaster需要觀察、輔導并引導團隊按照Scrum架構進行日常的産品傳遞工作，作為Scrum Master，往往有如下職責：
教練：Scrum Master本身也是一種靈活教練，需要觀察團隊的日常工作，并且對開發團隊和産品負責人（Product Owner）進行輔導，確定整個團隊能夠按照Scrum流程開展各項活動。
服務型上司：Scrum Master不同于職能經理或者項目經理，不會去指令團隊做什麼任務或者怎麼做，也不掌握團隊成員的“生殺大權”，Scrum Master為Scrum團隊提供服務，確定團隊産品傳遞中的必要需求得到滿足。
過程權威：Scrum Master要確定團隊了解靈活的價值，同時確定團隊在此基礎上遵循Scrum的原則，幫助團隊定義自己的靈活流程并進行實踐；并且在後續幫助團隊持續改進，實作傳遞業務價值最大化。
“保護傘”：Scrum Master應該保護團隊免受外部幹擾，讓團隊集中精力在價值傳遞上。比如：産品經理想在疊代中插入新的需求，Scrum Master需要衡量需求是否應該插入，插入後哪些需求應該置換等等，而不是坐視不管。
“清道夫”：Scrum Master要幫助團隊掃清傳遞過程中遇到的障礙，比如團隊新的開發環境要一組叢集，而團隊本身對資源沒有建立權限，可由Scrum Master拉通相關人員，進行叢集的建立。
“變革代言人”：Scrum Master要積極推動靈活，盡管這可能會很困難，但作為Scrum Master應該讓團隊乃至組織意識到轉型的重要性和必要性，并需要讓團隊看到Scrum 為團隊帶來的收益。
通過上文對ScrumMaster職責的描述，不難看出，Scrum Master主要工作就是推動靈活在團隊中的進行，其本身不寫代碼，也不寫項目所需的各種文檔——沒有什麼輸出。
看過足球的應該都知道，哪怕教練有能力、有權力，也很難保證帶隊出成績，教練取得的成績通常和球員分不開。再看看Scrum Master，其本身是服務型上司——沒權力，Scrum的具體實踐者是團隊，是以要做到“指哪打哪”就更難了。
以上因素會導緻ScrumMaster工作的好壞很難衡量，甚至會讓人産生一種ScrumMaster每天啥也不幹的錯覺。那Scrum Master工作的好壞到底如何衡量呢？
衡量ScrumMaster工作好壞的方法還是有的，雖然并不能衡量的那麼準确，本文介紹的方法主要有三種：通過工具衡量、通過改善效果衡量、通過團隊主觀評價衡量
有句話叫：“度量什麼，就一定會得到什麼”，那為什麼還要用工具去衡量？
其實這裡說的并不是用一個工具去記錄、管理Scrum Master的日常工作，所謂工具是指團隊日常工作使用的各項工件，比如看闆、使用者故事、燃盡圖等，通過團隊對各項工具的使用情況，來側面反映出Scrum Master對團隊的輔導效果。
比如，正常情況下，Scrum Master會主持團隊的站立會議，會上團隊成員互相分享項目進展及阻礙。往往在會議前或會議中，看闆上的工作項會有價值流動，比如某些工作項進入開發、某些工作項進入測試、某些工作項進入評審等，工作項狀态更新的同時，還會伴随着消耗工時的更新，以便于後續類似任務的估算。如果Scrum Master很好的引導團隊，讓團隊嚴格按照Scrum流程來開展日常工作，那一個工作項往往會經曆頻繁的狀态變更，以華為雲DevCloud的工作項為例，工作項的操作曆史中可以看到工作項狀态、處理人以及工時等字段的變更，如下圖：
而如果Scrum對平時的工作敷衍了事，或者很難推動團隊踐行Scrum，工作項的價值流動往往會很有跳躍性，如下圖：
再比如，ScrumMaster需要去輔導産品負責人如何編寫使用者故事承載需求，并且按照價值優先級對需求進行排序，我們可以通過使用者故事的好壞，比如是否滿足三段式，故事粒度拆分是否合理等，來衡量Scrum Master的工作效果（華為雲DevCloud專家服務平台提供了“使用者故事 ”能力評估功能，可線上對使用者故事編寫水準進行自動評估，有興趣的讀者可以來評估一下）。
除了工具外，還可以通過團隊傳遞情況來判斷Scrum Master工作的好壞。這裡說的傳遞情況不是指人均産出代碼行、千行代碼Bug率等名額，用這些名額衡量的話，往往還是之前提到的——“度量什麼，就一定會得到什麼”，起不到啥衡量作用。
靈活的本質是通過疊代的方式，小步快跑同時對産品進行及時的調整，以提高産品研發效率和品質。是以筆者認為可以從使用者故事傳遞周期、項目整體按時傳遞率、産品使用者滿意度等改善效果來從側面衡量Scrum Master的工作的好壞。
靈活轉型初期可能很難看到明顯的進展，在這個過程中Scrum Master要幫助團隊發現問題，比如為什麼項目上線後會有很多Bug，什麼原因造成的，後續應該如何改進，跟蹤改進狀況等。走過幾個疊代後，如果Scrum Master對團隊引導是有效的話，産品的使用者滿意度應該是有所提升的；同時各方面的傳遞周期也會逐漸縮短且有一個相對穩定的速率。
如果團隊經曆幾個疊代，一直很掙紮——加班加點、項目按時上線後一直有一堆改不完的Bug，那ScrumMaster的工作多半是失敗的。
Scrum Master輔導過的團隊通常會有很好的團隊氛圍，Scrum Master輔導的如何可以通過訪談或者問卷的形式，讓被輔導的團隊評價ScrumMaster的工作，往往也會得到答案。
靈活不是短期内就完成的工作，更不是銀彈，靈活轉型是一個漫長且複雜的過程，在這個過程中，Scrum Master需要觀察團隊，引導團隊去實踐靈活方法，思考怎麼解決實踐中遇到的問題，最後總結經驗。當一個團隊趨于高度靈活的狀态，Scrum Master的工作可能會輕松，否則Scrum Master要做的事情還是很多的。
點選關注，第一時間了解華為雲新鮮技術~