ScrumMaster的能力（上）

Nov. 03 21:33~22:13

 

談到ScrumMaster，除了「誰適合當ScrumMaster？」這個問題以外，另一個經常被問到的問題就是「ScrumMaster要做什麼事？」從Scrum的官方文件來看，ScrumMaster的責任之一，就是確保團隊有依循Scrum所建議的方式開發軟體，同時扮演流程改善的推手。也就是說，ScrumMaster必須：

• 對Scrum框架很了解
• 對軟體開發流程很了解

缺乏以上能力的ScrumMaster經常會對團隊所遭遇的問題視而不見。如果團隊中有比較資深的成員，還有可能透過retrospective meeting由團隊成員自主提出改善建議。但如果團隊成員也不知道現行開發流程有什麼可以改善的地方，而ScrumMaster也沒有能力觀察到這樣的現象，團隊就可能會一直停留在現況上停滯不前。

Teddy曾經遇過有團隊採用三周的sprint長度，前兩周開發，最後一周拿來做測試。這個團隊很明顯將iteration（sprint）當成mini waterfall使用（請參考〈蝦米，每個Iteration都是Mini Waterfall？！〉），但是他們自己本身並無覺得不妥，也認為他們採用Scrum開發，而且成效良好。和傳統waterfall緩慢的回饋周期相比，mini waterfall也是一種改善，但如果只停留在此，團隊的靈活度與真正的敏捷團隊相比，還是有一大段可改善空間。

***

為了負擔上述兩項責任，ScrumMaster首先要對Scrum框架很了解。當遇到問題時，看看這個問題在Scrum框架中有沒有提到要怎麼處理。例如，sprint進行中有緊急的工作該怎麼辦？PO沒空參加sprint planning meeting怎麼辦？不同專長的團隊成員彼此專業知識無法交流該怎麼辦？

遇到問題如果Scrum框架無法回答，往上詢問這個問題在敏捷與精實方法（Agile and Lean）中應該採用何種態度來面對它？例如，能否用可執行的測試文件來取代傳統以Word撰寫的規格文件？團隊所做的每件事，是在提高客戶的價值，還是在累積庫存？

如果還是沒有得到可接受的答案，最後就回到軟體工程的基本原則來判斷。例如，因為工作有相依性妨礙依據需求優先順序來施工該怎麼辦？如何隔離與降低改變對於系統的影響？

***

ScrumMaster不一定要對所有問題都有答案，但至少要具備看出問題的靈敏嗅覺。

***

友藏內心獨白：就說ScrumMaster是牧羊犬啊。