Scrum是近年軟體開發方法最熱門的關鍵字,說得像是可以返老還童、起死回生的仙丹妙藥。但台灣真正導入的團隊又沒多少,聲稱導入的團隊又充滿著在地文化的台灣式手法。那麼,到底應不應該導入Scrum呢?
關於
Scrum的模式和方法,在《
Scrum Primer》這份文件(連結為簡體中文PDF版)已經解釋得很清楚;如果英文沒問題,還可以看看更原汁原味的
英文版。所以本文就來純粹談談導入一段時間之後,最深刻的經驗和感想。
Scrum跟其他Agile方法最大的差異,在於把人(Team、Product Owner、Scrum Master),事(Sprint Planning、Sprint Retro等等),物(Product backlog)很明確的定義處理。
其他敏捷方法如XP,是著墨在技術方法上;而Kanban則著重在流程上的處理。所以相對而言,Scrum可以馬上就照表操課,而且還可以跑得有模有樣。那麼,到底有什麼難度呢?
Scrum的缺點
Scrum難在它他並不是設計來「做出產品」的,而是將全部開發流程透明化、讓優點和缺點明顯暴露出來的「擴大器」。
怎麼說呢?比如說Team自己決定這Sprint要拿多少工作,通常
Product Owner就會哀嚎「怎麼產出比之前降那麼多」,因為之前高產出是用PM的鞭子與愛心、主管的壓力關懷、以及工程師的偷工減料創意堆疊出來的。
所謂出來混遲早要還,之後就會反映在高離職率上、修不完的bug、或是完成99%的系統就是差1%而永遠無法結案。
那暴露出來的弱點怎麼辦?
就是改善啊!假設每次Sprint會有1%的改善,50次Sprint就增加64%;等於是在1-2年的時間中,5人Team的能力會擁有8人的戰力,聽起來很不錯吧?
你接下來一定會問,如果不改善呢?
第一個是要靠
Scrum Master的功力,讓
團隊認知到這些問題;第二,如果團隊認知了、而且有意願改善,就盡力協助。如果是一個團隊認知問題,但又沒意願改善,那怎麼辦呢?在現在超級競爭的環境中,還願意待在一個不求進步團隊中的義士,再過幾年變烈士的幾率是很高的。
Scrum的優點
講完缺點,當然也要談談Scrum的優點。同樣的,想要進步、自動自發的Team,在Scrum的框架下會得到尊重和授權;在一個正面循環之下,會不斷增加自己的能力和產品品質。
能在這種團隊和環境工作,成就感和滿意度都會遠超過由PM主導的傳統開發模式;至於個中滋味,就只能靠自己體會了。
因為Scrum是擴大器(或者說是
照妖鏡),第一個導入的前提就是「心臟夠大顆」。察覺到團隊可以自我管理時,絕對會讓人雀躍不已;而在沒有外在壓力時,卻發現團隊產能直落谷底、或是不願意改善,用「傷心」也不足以形容這種失望。
所以,如果要導入Scrum,你心臟夠大顆嗎?
發源於矽谷的敏捷式開發,在軟體產業如 Google、Facebook 臉書實證成功後,敏捷管理也開始影響各個不同的產業。
透過書中的實例和做法,無論老闆、主管或員工,科技業、服務業、傳產、學界或政府,都能運用敏捷讓自身工作更順心,團隊合作更順暢,企業成長更順利。