l

2013年8月29日 星期四

從Scrum到Scrumban的經驗

August 28 16:00~18:52

螢幕快照 2013-08-28 下午6.55.19


繼《系統管理團隊結合Kanban與Scrum的經驗》以及《遊戲團隊結合Agile與Kanban的經驗》之後,今天要介紹一篇發表在Software and System Process (ICSSP), 2012研討會的論文,名為:《From Scrum to Scrumban: A Case Study of a Process Transition》。

不了解Scrumban的鄉民們可以參考《What is Scrumban?》這篇文章。如果要更深入學習Scrumban,則可以參考Corey Ladas所寫的《Scrumban: Essays on Kanban Systems for Lean Software Development》這本書。

***

背景介紹

這篇論文介紹一間代號為CMSiPro的瑞典公司從Scrum過渡到Scrumban的歷程以及從中學習到的經驗。這家公司在全球十個國家設有行銷與業務辦公室,在瑞典的斯德哥爾摩有一個開發團隊,越南的河內則有另一個開發團隊與一個測試團隊;每個工程團隊有15~20位工程師。Product Owner團隊則是分散在瑞典和丹麥

螢幕快照 2013-08-28 下午6.12.59

***

遇到的問題

CMSiPro公司的開發團隊遇以下這些問題:

  1. 跨國團隊溝通不良
  2. 分散式團隊工作協調不順
  3. 沒有做好需求變動追朔(requirements change traceability)
  4. 沒有定義DoD(Definition of Done)
  5. 急就章的短期解決方案:這一點很重要,Teddy遇到的很多團隊也都有這樣的問題,所以要特別解釋一下。因為Scrum團隊成員會有一種想要在sprint結束前完成所有sprint planning meeting所挑選出來的story的傾向(怕沒做完會被以為工作成效不彰),因此經常會採取急就章的解決方法,甚至是犧牲程式碼的品質,讓story「看起來好像完成了」。這個問題的原因,部分與團隊沒有定義明確的DoD也有關係。
  6. 程式碼被合併之後就沒什麼人敢修改:只有在每個sprint結束的時候才會合併(merge)程式碼並且開始整合。一旦合併的過程結束之後,就算是覺得現有的程式碼有可以改進之處,但是因為怕麻煩與出錯,所以大家就不想去動合併後的程式。久而久之,累積的技術債就越來越多。
  7. 管理階層對於問題的回饋反應很慢:這一點…不用解釋了,大部分的公司都一樣挑眉質疑
  8. 對於流程的知識與承諾不足:這一點用Teddy的話來說,就是「他們以為自己在實施Scrum,其實他們是在run…(自己接)」。
  9. 不夠開誠布公:根據作者的說法,因為越南團隊(儒家文化?!)比較害羞跟謙虛,所以有些問題會放在心裡不敢直接表達出來。
  10. 技術債不斷的增加:反正程式可以動就好了啊不要告訴別人
  11. 流程改善相關的活動優先權都很低:這一點也是很常見的問題,PO總是想要多做一點功能,持續改善是什麼,可以吃嗎?挑眉質疑
  12. 沒有效率的開發流程:綜合以上這麼多問題,開發流程當然不可能有效率。

以上這些問題,Teddy在帶領Scrum團隊的時候也經常遇到,算是很典型的問題。

***

Scrum到Scrumban的過程

這篇論文花了很多篇幅在敘述從Scrum改用Scruban的過程,看完這些過程之後,Teddy只想說:「瑞典人做事,真的很嚴謹」挑眉質疑。這些細節就容Teddy跳過不表,引用論文裡面的一張圖來蒙混過去XD。

螢幕快照 2013-08-28 下午6.22.03

***

經驗分享

對於之前提到的12點問題,作者談到改善後的結果:

  • 完全解決:2.分散式團隊工作協調不順、3.沒有做好需求變動追朔(requirements change traceability)、4.沒有定義DoD(Definition of Done)、6.程式碼被合併之後就沒什麼人敢修改、11.流程改善相關的活動優先權都很低
  • 部份解決:1.跨國團隊溝通不良、5.急就章的短期解決方案、8.對於流程的知識與承諾不足、9.不夠開誠布公、沒有效率的開發流程。
  • 沒有解決:7.管理階層對於問題的回饋反應很慢。
  • 正在解決中:10.技術債不斷的增加。

以上,嚴格講起來,都不是重點不要告訴別人。因為作者最後提到他們學到最重要的一件事,就是:

剛開始採用Scrum的時候所遭遇的問題,其實不是Scrum本身的問題,而是CMSiPro公司的Scrum實踐的很爛(the poor implementation of Scrum)。

類似的看法Henrik Kniberg也曾經提過,許多Kanban團隊是經由改用Kanban的過程而重新學習與了解Scrum。

總之,作者最後建議兩點:

  • 建立流程持續改善的機制。
  • 找到訓練良好並且願意投入承諾的員工。

這兩點基礎建設如果能夠做得到,很多問題都可以逐步被解決。

***

因為作者提到Scrum的教育訓練很重要,Teddy順勢再補充一點:「Scrum敏捷方法實作班」招生中,準備或已經導入Scrum/Kanban但卻問題重重的鄉民們請多加利用熱戀

***

友藏內心獨白:整篇文章和Scrumban好像沒什麼關係。

3 則留言: