l

2014年11月4日 星期二

ScrumMaster的能力(上)

Nov. 03 21:33~22:13

螢幕截圖 2014-11-03 21.35.00

 

談到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是牧羊犬啊。

1 則留言:

  1. 不知道有沒有研究針對所謂的"真正的敏捷團隊"與不是"真正的敏捷團隊"的比較? 開發速度快幾周? 客戶滿意度多幾%之類的研究? 另外有所謂的"真正的敏捷團隊"存在嗎?有實例嗎? 誰來認證它們是"真正的敏捷團隊"??

    回覆刪除