這是我在 qCon 上海 2013 所發表演講的摘要 (http://www.qconshanghai.com/node/403), 描述在專案中使用 Kanban 的經驗. 歡迎大家多多指教.
專案背景
首先先介紹專案的背景. 這部分其實很重要, 因為我的解藥可能會是你的毒藥. 你必須要先了解的背景和來龍去脈, 這樣你便可以判斷是否可以套用在你的專案中. 因為沒有所謂的銀製子彈, 只有較合適的做法.
這個產品是沙盒分析的產品, 公司希望它可以成為下一代主要的金牛. 因此老闆便會盯得很緊, 你隨時隨地需要有進度報告. 此外, 世界上一定也不可能只有你在做這類產品, 已經有領先者佔據這個市場. 你必須要推出一些版本出來, 看看市場反應, 然後適時地作出調整. 所以快速因應和交付是我們的重點.
在組織方面, 我們分工十分細緻, 有開發人員, 測試人員, UI 設計人員, 此外還有一些出一張嘴的經理們. 這些不同角色各自有各自的專業, 負責不同領域的事情, 不容易互相支援彼此的事情. 此外, 因為產品才剛剛開始, 因此老闆覺得開發, 維護和支援pre-sales的事情, 最好一手包辦, 這樣才可以快速反應, 避免中間層層溝通, 錯失先機. 但是這也代表我們工程師一方面要開發, 另一方面也要直接面對客戶, 工作的種類便會繁雜.
這產品一路做來, 我們大約每 2 個月出一個版本. 幸運地是每個版本都有找到一些客戶, 不幸地是你每個版本都要持續維護 XD. 此外, 我們也無法只單單有英文版, 對於日本客戶, 我們需要做一些日文化的支援, 因此多語言也是要照顧一下. 今年老闆覺得我們產品中某些功能是另外客戶需要的, 教我們要去支援. 等到支援完後, 老闆覺得這部們似乎可以變成另一個產品, 因此我們今年就開始要支援多產品的團隊.
採用 Scrum 所遭遇的問題
我們專案是採用 Scrum 為主的開發方式, sprint 的長度是 2 周, 發行週期大約是 1.5 - 2月. 在這個過程中, 我們遭遇了以下問題:
1. 多個專案, 多種不同性質的工作
Scrum 比較著重在單一專案上面, 若是要支援多個專案, task board 上便會太多東西擠在 in prog 上面.
此外, 對於客戶來的 bug, 你很難估計多久能解完, 因為你需要和外面客戶來來回回討論, 客戶並不會隨傳隨到. 此外這些 bug 何時會來, 會來多少也是無法控制.
對於 POC case 更是麻煩, 大多是有時效性, 你必須在一段時間處理完. 如果你不能及時解完, 那客戶就不會買你的產品了.
2. Task board 上資訊不足
使用過 scrum 都知道, 每次工作都累積在 “In prog” 中, 可是不確定到底完成到哪裡. 雖然每日立會會提到, 但是無法記下這麼多資訊. 如果幸運點, 可能最後在 iteration 結束前會移到 done. 但是若是沒有移過去時, 就太晚去幫助他們了.
3. 人數太多不易使用
我們專案開發人員加起來有 25 位左右, 進行每日例會時要花很多時間. 就算每個人講一分鐘也要半個鐘頭. 如果是每天開, 工程師會受不了. 此外 task board 上的內容也是一樣, 如果每個人有 2-3 個工作要做, 上面就會有 50-75 個便利貼在上面, 看到眼睛都花了.
4. Retrospective 效果不彰
我們 sprint 的長度是兩周, 因此會每兩周進行一次 retrospective, 來收集大家對整個專案的問題. 可是你應該知道, 會提出來的問題大都不是那麼容易處理, 需要常點時間才可能處理掉. 可是每兩周就請 engineer 再提出相同的事情, 工程師會覺得很無趣. 他認為重點是要知道之前提出的問題被處理的進度, 而不是叫他在提出相同的問題.
用 Kanban 來改善專案的進行
為了處理以上狀況, 我們試圖使用 Kanban 來補足. 因此我們採取了以下做法:
1. 資訊視覺化
唯有知道目前的狀況, 你才能知道發生什麼事情, 然後才可以提出解法. 所以第一步便是將目前的所有工作狀況給視覺化
(1) 測試人員
測試人員要處理的事情很多, 主要可分成這幾類
a. 測試新的開發功能: Clarify Spec -> (Test Case Creation)TCC -> (Test Execution Preparation)TEP -> (Test Case Review)TCR -> (Test Case Execution)TCE -> Bug Verification -> Done
b. 效能測試: Plan -> Review -> Execution -> Check -> Done
c. 測試自動化: Analyze -> Design -> Coding -> Testing -> Production -> Done
d. 非預期或是維護的 case: ToDo -> In Prog -> Done
我們企圖講所有事情顯示出來, 這樣才知道大家在忙什麼, 目前做到哪個階段了, 哪些人是瓶頸. 讓我們可以及時處理所遭遇的問題.
(2) 開發人員
開發人員要做的事情不外乎設計, 寫程式, 以及改 bug. 當這些事情做完後, 需要做些檢視 (review), 以確保其品質(design review, code review, fixed code review), 所以我們將其流程定義如下:
流程: Backlog -> Doing -> Check -> Done
(3) 專案階層
RD 和 QA 有各自的看版, 可是資訊太過詳盡, 無法快速對整個專案狀況有個快速的了解. 因此我們在建立一個專案階層的 task board, 上面的便利貼是對應到的是這個 iteration 要交付的功能, 因此我們就能知道每個功能進行到哪個階段了.
2. 利用目視管裡找出壞味道
當工作狀況的資訊視覺化後, 我們觀察到有些現象出現了, 就可能是有問題發生. 因此我們整理出了一些壞味道, 可用來幫助我們能快速找出問題點:
(1) 不需要或是少列步驟
當你發現工作流程步驟中, 有些步驟是不需要的(沒有人在做這件事情), 或者是缺少某些步驟(或是有做某些事情可是卻不在看版上面), 這時候便需要修改看板的流程.
(2) 流程過度一般化
流程過於簡化時, 會讓我們無法清楚知道目前的狀態是什麼. 就像 Scrum 預設的步驟是: ToDo, InProg, Done. 這就是太過簡化, 必須要再展開, 我們才能掌握更多資訊.
(3) 同時處理不同性質的東西
若你是處理太多不同性質的東西, 會讓你花很多時間在切換上面. 像是同時進行開發和維護的工作. 你便很難安排工作計劃. 最好是能專心在同一類型的工作, 做到告一段落後, 再切換會比較有效率.
(4) 檯面下的多工
有些人雖然沒有做很多事情, 卻是進度緩慢, 並且這些人通常是比較資深的員工. 這通常代表他可能做了很多非檯面上的工作. 像是指導其他員工工作, 或是回答其他人有關於某些舊系統的問題. 這些事情很容易被忽略, 必須將他們檯面上的工作減少, 讓他們能兼顧被指派的工作以及指導他人.
(5) 有些步驟做太快
如果你發現某個步驟做得很快, 或是直接跳過, 那可能代表成員並沒有好好執行這件事. 因此你需要發現背後的原因是什麼, 可能需要訂定 policy 去說明在這步驟做完的標準是什麼, 或是看看是否沒有時間做或是遇到困難.
(6) 有些步驟做太慢
如果你發現某些步驟要做很久, 或是不知道何時會完成, 通常你會需要先將此步驟再做拆解, 讓我們可以知道更細步的進度. 接著要有改進方法來實施, 讓它可以儘快完成.
(7) 有些步驟重複發生
當你發現有些事情一直重複發生, 代表他可能一直在 rework, 因此你需要去查出遇到什麼困難, 並且找出解決或是改進方法.
3. 漸進式改進
這裡我們使用了 improvement kata, 來逐步改進, 而不是一直做retrospective 來叫大家提出問題.
http://www-personal.umich.edu/~mrother/The_Improvement_Kata.html
這裡是例子顯示我們如何處理避免進行開發和維護的工作. 我們先收集每天畫多少時間在處理維護工作. 2-3 周便可以知道大約占我們多少工時. 我們接著便安排多少比例的人專職處理維護的工作. 並且我們持續觀察維護工作的 lead time, 以方便讓我們決定是否要加人或是減人.
此外也嘗試用 5 whys + fishbone, 利用系統思考來找出事情會發生的可能原因.
以下便是利用 5 whys 和 fishbone 的方式, 來討論 test spec 和 test case 的開立, 為何要拖很久並且要反覆修改
結論
1. 好工具不該只有一種
不管是黑貓白貓, 能抓老鼠的就是好貓. 所以不管是 waterfall, Scrum, Kanban 或是其他方法, 只要是能幫助專案成功的, 都可以拿來使用. 而不是堅持這是 agile, 這不是 agile.
2. 利用痛點來逐漸演化
有時候講一些大道理, 希望團隊要去遵守或是追求, 在大多數的狀況下都不容易成功. 我們比較傾向利用看板讓他看到問題, 然後再來提出修正, 並且每次的修正都是一小步, 這樣會比較容易成功.
3. 問題永遠在現場
問題都是出現在現場, 努力觀察便能找出來, 因此若是將壞味道整理下來, 便可以讓團隊成員快速發現. 如果看版上看不出來, 便要思考是否看版上資訊不夠, 無法顯示專案真正的狀態.
留言列表
