David Ko的學習之旅

有人問我, 是否可以提供一些業界實踐 Kanban 的範例, 最好能包含大型企業, 以及新創公司等等. 這樣讓他們比較好開始使用 Kanban. 因此我稍微收集了一下, 希望能有點幫助
 
 
1. Spotify 
(1) Spotify 的敏捷擴張之道：部落、班、橫向編組與同業公會
http://zh.scribd.com/doc/148375738/Scaling-Agile-Spotify-%E4%B8%AD%E6%96%87%E7%BF%BB%E8%AD%AF%E7%89%88
(2) Spotify 如何打造產品？ 
http://zh.scribd.com/doc/148574585/Spotify-%E5%A6%82%E4%BD%95%E6%89%93%E9%80%A0%E7%94%A2%E5%93%81%EF%BC%9F
(3) Spotify的大规模敏捷：采访Henrik Kniberg 
http://www.infoq.com/cn/news/2013/06/scaling-agile-spotify-kniberg
(4) Use of Kanban in the Operations Team at Spotify 
http://www.infoq.com/articles/kanban-operations-spotify
2. Lean from the Trenches: Managing Large-Scale Projects with Kanban
http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859
3. Experiences from Applying Kanban at SAP 
http://www.infoq.com/news/2013/12/applying-kanban-SAP
4. Taming the Customer Support Queue - A Kanban Experience Report
http://www.agilealliance.org/files/4613/2435/0839/Taming%20the%20Customer%20Support%20Queue%20A%20Kanban%20Experience%20Report.pdf
 
5. Kanban at Scale – A Siemens Success Story 
http://www.infoq.com/articles/kanban-siemens-health-services
6. Lean Lessons Learned: Our Experiences Moving to Kanban 
http://www.infoq.com/presentations/Moving-to-Kanban
7. 3 years of Kanban at Sandvik IT: The Story of an Improvement Journey 
http://www.infoq.com/articles/kanban-Sandvik-IT-1
8. Scrum and Kanban: Making the Most of Both 
http://www.infoq.com/news/2010/01/kanban-scrum-minibook

很多人對於Kanban 要如何使用不是很清楚, 覺得 Kanban 講的太玄了, 這裡有個“簡單"的介紹, 告訴你如何用 Kanban 來進行視覺化管理, 希望能對大家有點幫助.
Visual managment from 仁傑 柯

目前因為開發人員(RD)和測試人員(QA)工作流程不同, 彼此做事方法還差很大, 因此一開始時將雙方的工作, 以不同的工作流程來表示:

 
1. RD 工作流程
Backlog: 需要處理的事情(例如: 需求分析, 設計, 編碼)
Do: 處理這項工作
Check: 檢查這項工作是否做好, 例如 code review, design review, spec review等等
Done: 處理完畢
起初這個工作流程的重點, 是要確定RD 做完之後有進行review 的工作, 以提升產出的品質.
2. QA 工作流程
Backlog
Scope Review
Design Review
Code Review
Test Case Creation
Test Case Review
Test Case Execution
Verification
Done
在執行一段時間之後, 我們發現了一些問題:
1. RD 和 QA 不同步
RD 已經開始處理很多工作, 可是QA 並沒有處理到相對應的地方. 例如有些設計已經review過了. 可是QA 還沒對這個 feature進行 scope review, design review 等等. 可能是 QA 沒有空進行, 也可能是 RD 並沒有通知 QA 來參加.
2. 工作和需求的關聯性不明確, 且便利貼太多
對於每個需求, RD 會把它展開成task, 貼在task board上面. QA 對每個需求只有一張便利貼, 隨著移到不同step, 代表進行到不同工作. 因此 RD 會對每個需求貼了很多工作, 這將導致在工作版上, 很難知道這個功能到底處理得如何了, 或者很難知道哪些工作是跟哪個需求有關.
心得
1. 視覺化的看板, 可以讓你很快看到變化的趨勢. 不過你要有夠大的板子
2. 很多task 會增加管理難度. 不管你是放在task board 或是project file內. 也許可以用以下方法減輕其症狀
a. 屬於某個需求的功能就在同一個 row. 但是 task 數量而是很大.
b. 利用流程的 step 來代表不同階段的工作, 而不是功能拆成一堆不同階段的工作. 不過每個需求的工作拆解需要大致相同, 否則就無法使用.
c. 2 tier task board: 用上層的task board 表示概略的流程步驟, 下層的 task board 來存放工作細項.
3. 如果多個工作流程之間有關連性, 目前似乎還無法有好的解法去同步其關聯性. 這部分還需要進一步研究
4. 在專案初期, 工作流程頻繁變動修改是很正常. 所以放到 tool 似乎不是重點, 而是要能快速調整.

每次要檢視kanban 上的狀況時, 我都會問我自己, 到底要檢查甚麼. 後來大致上整理出以下方向


1. 流程流動是否順暢
我的目的是要讓工作趕快做完. 如果工作在哪裡卡住, 代表那裏可能出了甚麼問題. 可能是做事流程有問題, 或是做的人遭遇到困難.
2. 流程狀態是否透明
如果目前的工作流程無法顯示你在做甚麼, 或者無法顯示出你做到哪裡, 導致你無法判斷要如何改善工作效率, 便是要做修改.
3. 是否同時做很多事情
如果一個人同時做很多工作, 他便會有很多便利貼在上面. 可以詢問他是真的這麼厲害, 還是他某個工作要等別人, 或者是遇到阻礙, 便可以著手進行改善.
目前為止, 基本上用這三招, 就可以找出一堆問題, 讓我處理不完. 如果你有發現別招, 記得跟我分享一下.

在紀錄 task 的資訊時, 我們大概會記錄以下資訊
 


1. 工作項目
工作代碼: 流程代碼 - 月份 - 流水號
工作敘述
負責人
工作產生的時間
工作開始做的時間
工作結束時間
評估的大小
2. 每個流程
- 每周新增多少工作
- 每周完成多少工作
- 每周完成的工作的平均 lead time
- 每周完成的工作的平均 cycle time
3. 每位員工
- 每周開始處理多少工作
- 每周完成多少工作 (全部/大/中/小)
- 每周完成的工作的總時數
4. CFD
目前由這些統計, 我們可以知道
1. 工作是否流動很快
- cycle time/lead time
- 每周開始處理多少工作
2. 工作大小是否適合
- 每周開始處理多少工作
- 每周完成多少工作 (全部/大/中/小)
3. 工作是否來的太多
- 每周新增多少工作
- 每周完成多少工作
4. 是否同時處理多個工作
- CFD
- 每周開始處理多少工作
我們不希望記錄太多東西, 但是目前記錄的東西似乎可以花出很多花樣, 不過還是藉由實驗和觀察, 來決定哪些資訊有用, 哪些資訊我們需要在收集.

在我目前的想法中, Kanban 最主要拿來處理這兩件事情

1. flow 流暢度: 我要確定功能能盡快做完. 如果無法流動很快就會有問題
2. 避免多工: 希望員工不要同時處理很多事情, 最好能一次處理一件事情, 趕快做完後, 在做下一件
 

Stop starting, Stop Finishing
http://www.amazon.com/Stop-Starting-Start-Finishing-Roock/dp/0985305169/ref=sr_1_1?ie=UTF8&qid=1376140716&sr=8-1&keywords=stop+starting+start+finishing
 
Little’s Law

Stop starting, Stop Finishing
http://www.amazon.com/Stop-Starting-Start-Finishing-Roock/dp/0985305169/ref=sr_1_1?ie=UTF8&qid=1376140716&sr=8-1&keywords=stop+starting+start+finishing
 
當Justin 發現有一大堆工作在看板上面, Justin 就詢問團隊成員, “你們同時可以處理多少工作?”

Stop starting, Stop Finishing
http://www.amazon.com/Stop-Starting-Start-Finishing-Roock/dp/0985305169/ref=sr_1_1?ie=UTF8&qid=1376140716&sr=8-1&keywords=stop+starting+start+finishing
 
 

看板初體驗 - 兩層式看板
在執行 kanban 一段時間後, 我們開始對目前工作流程做出調整. 首先第一個問題, 便是改善專案整體進度的能見度.
在我們部門因為分工的緣故, 開發人員和測試人員是屬於不同老闆所管轄. 雖然導入Scrum 已有一段時間, 但是因為組織緣故, 無法把開發人員和測試人員合成一個團隊, 一個老闆.
此外也由於人數眾多, 大約20人左右, 變成一個團隊也是大了點. 若是要變成 feature team, 也因為沒有經過好的訓練和教育, 無法強迫進行.
因此目前雖然開發人員和測試人員, 一起合作開發要交付的功能, 可是卻各自有各自的task board.
RD task board
QA task board
不過在溝通方面, 雖然測試人員有自己的 daily standup, 但是測試人員也會去參加開發人員的daily standp. 因此雙方資訊的同步還算良好.
並且我們還會有 lead level 的 daily standup, 開發人員的 lead, 測試人員的 lead, 和經理們會一起討論目前專案的進度, 以及遭遇到的問題.
但 是總覺得對於所有要交付的功能, 其進度的掌握還是有些不足. 雖然每個 lead 會描述其功能的進度和狀況, 但是講完後還是容易忘記. 因此在下一個 release 開始, 我們打算增加一個project level 的 task board. 會列出目前專案要處理的功能, 以極其目前所在地階段為何.
我們分成了以下階段
1. requirement clarification: RD, QA 和 UI designer 討論需求規格
2. design: RD 在進行 design 和 design review
3. coding: RD 在撰寫程式
4. integration: RD 之間先進行整合測試
5. testing: QA 進行全面性測試
6. verification: RD 改完defect, 交付由 QA 進行 regression
7. done: 此功能已經可以準備交付
希望我們就有兩層式看板. 開發人員和測試人員各自有它們自己的 task board. Project level 也有自己的 task board. 這樣會讓資訊更加通透, 更容易掌握專案的情況