August 20 11:40~14:00
(影像節錄自此)
最近幾天部落格上面都是設計模式的文章，今天換個口味，回頭談一下敏捷開發。Teddy前一陣子印了幾十篇論文（請參考《沒事多讀paper，多讀paper沒事》），今天介紹其中一篇文章，篇標題為《Combining Kanban and Scrum- lessons from a team of sysadmins》，發表於2012 Agile Conference。
作者Katarzyna Terlecka在2010年的時候協助一個五人的系統管理團隊導入Scrum，其中包含兩位Windows平台管理者，以及三位Linux平台管理者。這兩群人彼此都不知道彼此的工作內容，除了因為原本處裡的工作所需的知識就不一樣以外，還有一些安全性的考慮，導致彼此之間的工作無法互相支援。這五人管理團隊負責支援分散在三個地點的約1,700位使用者，並且要負責管理1,000平方公尺的電信實驗室。他們還需要管理分散在兩個不同地點的四個伺服器機房裡面的約100台不同的伺服器。
***
開始嘗試Scrum
作者一開始被要求幫這個團隊導入Scrum，因為系統管理團隊的工作比較動態，因此他們採用了為期一周的sprint。掙扎五個sprint之後，作者發現Scrum在這個團隊中運作得並不順利。例如，sprint planning meeting幾乎是一場無止境的戰鬥。可能是因為團隊所遇到的工作項目太小（可能只需要幾分鐘的系統設定）且突發性的工作的比例不少，因此要他們做sprint規劃，即使是一周的sprint，都很困難。
***
開始嘗試Kanban
後來作者請團隊改嘗試Kanban，由於Kanban關注的是團隊的工作流程（flow）是否順暢，拿掉了固定開發週期（iteration或是sprint）的要求，因此乍看之下應該比較適合系統管理團隊的需要。
經過五天的嘗試之後，團隊還是一團混亂。雖然之前五周的Scrum經驗並不順利，但是團隊覺得他們還是需要某種程度的計畫、評量、Product Owner的關注、一個類似ScrumMaster的角色來協助改善開發流程與排除阻礙、以及了解進度。
***
混在一起做撒尿牛丸
經過這兩次不同的經驗，團隊討論後決定要擷取Scrum與Kanban的部分方法，找出一個適合他們這種系統管理團隊的開發方式。以下是團隊的作法：
- Definition of Done（DoD）：針對一些工作項目定義完成的條件。
- Product Backlog：維持Scrum的Product Backlog，裡面的內容與優先順序交由Product Owner決定。
- 實體工作工作看板：團隊的實體看板如下圖所示（節錄自該論文）。
- 角色：文章提到了Product Owner與Kate（類似ScrumMaster）這兩個角色，沒有提到Team，不過看起來在角色方面應該是維持Scrum的作法。
- 事件：
- 每周一次：依據主題不同分兩次舉辦，但是作者沒有解釋這個會議是要做什麼
。會不會是product backlog refinement workshop？ - Technical grooming meeting
- Customer-oriented grooming meeting
- 每兩周一次：自省會議，基本上兩周舉辦一次，但也可能提早。
- Review meeting：由Product Owner發起，只要有功能完成便可舉辦。頻率不定，但最長不超過兩周。
- Daily planning meeting：結合Sprint Planning與Daily Scrum的半小時會議，決定今天要做什麼以及檢視之前完成的工作。
***
以下是作者在文章中提到的一些經驗：
- Product Owner：在以前的工作模式中，客戶（公司員工）一有問題通常是直接找系統管理人員處理，系統管理團隊並沒有人扮演PO的角色。這樣子會導致工作進度不透明，每個人都好像是一個小PO一樣。後來團隊協調出一個人來扮演PO的角色，所有客戶的需求一定要透過PO來處理，讓團隊成員可以不被中斷的完成工作。團隊花了一些時間讓客戶習慣這種改變，一旦習慣之後團隊的進度變得非常透明。
- 規劃：每天都花一點點時間做規劃，因此每一天就好像一個很小的sprint一樣。
- 救火的工作：很多瑣碎但卻很緊急的救火工作還是一個問題，因此團隊指派一個「消防隊員」（firefighter）的角色，針對緊急且簡短便可處理完畢的工作，客戶可以寄信到一個指定的電子郵件信箱，消防隊員將會負責處理這些工作。如果消防隊員發現客戶寄過來的工作太大，他會把這個工作交給PO來處理。
- 持續改善：日常的工作已經多到快把團隊成員給淹沒了，很難有時間來進行什麼持續改善。他們的做法是將所有持續改善的想法先放在Product Backlog的最下方，每隔一段時間他們檢視這些改善項目，並挑選合適的改向項目出來執行。
- 進度：作者提到Kanban有一個很大的問題就是團隊感受不到整體的進度，Teddy也曾經聽過，有人因為這個原因，從Kanban又改回Scrum。作者提到他們定期聚在一起檢視完成的工作項目，PO則是要確保Product Backlog保持最新的狀態。團隊則是藉由觀看完成的工作項目來了解進度。說實話關於這一點作者說明的不是很清楚，就算沒有混和Scrum的作法，團隊還是可以藉由觀看完成的工作項目來了解進度。
- 多個執行緒：一開始的時候Teddy有提到，這個團隊包含Windows與Linux的系統管理人員，而他們兩者的工作是無法互相幫忙。團隊在工作看板上把待辦事項分成Windows與Linux兩種，用以解決這個問題。
- 沒有Deadline：由於Kanban去除了固定長度開發周期的限制，因此並沒有像Scrum一樣，有一種工作必須在sprint完成的壓力。因此，有可能有些工作會一直拖下去。雖然Kanban可以藉由觀察與縮短lead time（交期）來避免這個問題，但對於剛導入Kanban的團隊，工作沒有deadline的確是可能造成一些困擾。文章中提到的作法是，針對關鍵的工作或是已經太久沒有完成的工作，團隊可以指定完工期限。不過作者並沒有提到，指定完工期限但是工作還是沒完成那該怎麼辦。
- 不再需要評估：因為系統管理的工作經常都很難評估，因此之前採用Scrum的時候，團隊在sprint planning meeting經常為了評估而吵翻天。現在團隊不再評估工作項目，PO單純計算完成的工作項目來得知團隊的速度（velocity）。
***
以上經驗，提供給鄉民們參考。
***
友藏內心獨白：各取所需變成Scrumban？
。
