David Ko的學習之旅

Kanban 是甚麼東西? 框架? 軟體開發方法?
Is Kanban A Framework?
http://agilemanagement.net/index.php/site/comments/is_kanban_a_framework/
Scrum 是一個軟體開發方法的框架. 因此很多人把 Scrum 和Kanban 做比較時, 把Kanban 也視為是一個軟體開發方法的框架. 是這樣嗎? 讓我們來看看David Anderson 怎麼說.
Anderson 認為 Kanban 不是一個framework. 如果它是一個開發流程的框架, 它勢必要提出一個流程的骨架, 讓大家可以可以客製化, 去適應到自己所屬的環境. 但是很明顯的 Kanban 並沒有這個東西.
那 Kanban 是甚麼呢? Anderson 說 Kanban 是變革管理流程(Change Management Process). 他提供一個詳細, 可重複的流程, 讓你可以在組織中進行變革. 這個流程一開始適合於 maintenance 的部門, 然後擴展到軟體開發, 接著涵蓋到IT operation, 以及有些知識工作的領域中. 所以 Kanban 應該算是一個 general purpose 的變革管理流程.
Kanabn 有 3 基本準則 (principles)
- 從你所知道的開始
- 你同意以漸進式的方法開始變革-
- 你一開始尊重現有角色, 責任和頭銜
然後有 5 個核心的實踐 (practices)
- 視覺化工作流程
- 限制 work in progress
- 管理工作流程
- 制定明確的管理政策
- 協同地以科學的方法來演進
Kanban 利用這些準則和實踐, 組成變革管理流程. 所以它不是軟體開發流程, 也不是專案管理方法. 藉由務實和可行的建議, 在知識工作的組織內, 來持續, 有效地進行改革.

source:
Detecting Bottlenecks in a Kanban System
http://agilemanagement.net/index.php/site/comments/detecting_bottlenecks_in_a_kanban_system/
David Anderson 在本文中, 提到了以下幾種找瓶頸的方式
1. 停滯不動的工作
在standup meeting中, 我們可以觀察 task board 的工作, 若是發現某個工作一直無法移動, 這便可能是瓶頸所在.
2. WIP 的數量增加
在 Cumulative Flow Diagram中, 你若是發現某個 section 隆起, 差距很大時, 這可能也是一個瓶頸所在.
3. 空白的欄位
在 task board 中若發現某個 step 或是一堆 steps 都沒有工作, 代表前面被擋住了, 前面可能是瓶頸所在.
 

Kanban 的站立會議
Kanban 和 Scrum 在站立會議中, 最大不同之處是 Kanban 著重於工作的流動.
每當會議開始時, facilitator 會帶領大家檢視整個工作版. 大家由最右邊的欄位, 看到最左邊的欄位. Facilitator 會請大家說明狀態, 尤其是在板上無法呈現的狀態, 或者團隊可能不知道的事情.
此外對於被別人阻擋或是已經落後的項目, 成員也需要特別說出來. 有些團隊對於這件事情有特別的作法, 他們會將這些項目以視覺化的方法標示出來. 像是用小的便利貼, 不同顏色的便利貼, 或者是小吸鐵等等, 讓這些事情能更明顯, 以方便下次時追蹤. 這樣也可以形成另類的問題追蹤系統, 解決後就把這些小飾品拿走.
在會議結束後, 會有個after meeting, 由 2 到 3 人所組成. 主要是要討論被阻擋的問題. 這是 kanban 重要的文化之一, 因為要持續改善, 讓流程或是做事方法能更好.

Scrum 或是 Kanban? 要用哪個?
Scrum or Kanban? YES!
http://agilitrix.com/2010/05/scrum-or-kanban-yes/
Scrum 是利用管理的角度, 來實踐 agile 的精神. 它要有release planning meeting, sprint planning meeting, daily standup meeting, reviewing meeting 和 retrospective, 來規劃, 檢視和調整所做的事情. 它把事情切成小批次進行, 每個批次都在一個固定的時間(iteration的概念)內完成. 此外, Scrum 也是一個架構(framework), 它定義了要進行甚麼事情, 也就是前面提到的 meeting 和小批次, 但是沒有提出要如何實作, 因此每個團隊可以根據它的環境, 決定要怎麼做.
而 Kanban 則是提出了一個更簡化的架構. 它以目前你所使用的流程為主, 來進行改進和排除浪費. 他利用WIP (work in Progress) 來替醒大家要系統思考, 不要只是局部最佳化. 它不需要每固定一段時間就交付可發行的產品, 它也不需要一定要進行 scrum 所提到的 planning, 它是採用pull 的觀念, 做完後拉下一個工作來處理, 進行及時(Just in Time, JIT )的規劃即可.
因此它限制最少, 可以套用的環境最多. 但是也因為限制少, 你可能會不知道要如何進行, 所以你可以搭配 Scrum 和 XP 的實務(practices) 來進行, 也就是說 Kanban 和 Scrum/XP 是互補的. 你可以搭配 Scrum 的daily standup meeting 來每天同步訊息, 也可以利用 XP 的 continuous integration 來確保修改的部分不會影響之前的系統.
所以當你在學習 Kanban 時, 建議你需要先有 Scrum 和 XP 的知識, 把 Scrum 和 XP 當作基礎知識. 然後再來學習 Kanban 中的精實思考(lean thinking), 系統思考(system thinking), 排隊理論(queuing theory), 和價值流對應(value stream mapping). 接著便要學習如何把Kanban 和 Scrum/XP 整合在一起, 以調整去適應你所處的環境或專案. 很多文章或是書籍, 都會介紹 Scrum 和 Kanban的不同, 以及互相互補和套用的地方, 若是你完全不會 Scrum, 便會不知道它們在講些甚麼.
適用環境
1. Scrum
- 適合有共同目標和任務的環境
- 你團隊成員大多是通才, 可以處理多個領域的事情
- 適合需要深度合作或創新環境
- 適合團隊成員數目在 7 +/- 2 人
2. Kanban
- 當你會遇到許多中斷或打擾, 例如: 可能要處理不同任務, 或者要處理外界突然進來的事情
- 你團隊成員是各個領域的專家
- 大多是重複性質的工作, 例如像是生產線的事情
- 適合團隊成員數目大於9人以上
以下是圖形可以來描述, Scrum 和 Kanban各自適合情況
a. Y 軸是指專注程度. 越上面通常是只處理一個專案, 越下面則代表他越容易受到打擾, 或者需求相當發散分岐
b. X 軸是指工作重複和清晰程度. 越左邊重複性越高, 可能需要專門技術人員來處理. 越右邊越需要探索, 因為不確定性很高
所以可以知道 Scrum 落在右上方的地帶, 而 Kanban 是在中間地帶. 每種方法有其適合的甜蜜點, 並非他能適合所有狀況. 此外, 你應該把 Scrum/XP/Kanban 視為是你能使用的工具, 工具沒有對或錯, 只有好不好用. 你可以殺雞用牛刀, 但是也可以用別的. 你應該是不同狀況, 決定使用的工具, 而不是讓工具使得你綁手綁腳的.
就宮本武藏所說的: 勿以器御心. 是你在選工具, 而不是讓工具綁架了你.

看板初體驗 - 可視度篇
在執行兩周後, 目前的 task board 帶來了以下好處:
1. Backlog 的內容
把所有要做的事情(stories)都放在這裡, 大家可以了解還有多少事情我們還沒處理.
2. 優先順序
我們把所有 stories 的優先順序都指定好, 所有人可明確知道哪件事情要先處理. 此外, lead 或是經理們也可以因應外界需求的改變, 即時在 task board 上更改 stories 的優先順序.
3. 檢查多工
每天 standup meeting 前, 個人可以看看自己是否同時處理多個 stories. 如果是, 等下會議時, 可以詢問哪個要先處理. 同時經理們也需要幫忙檢視, 是否有同仁同時處理多個 stories, 發現時需要和組員確認是否有項目遇到瓶頸, 否則為什麼同時會處理這麼事情.
4. 檢查每個人工作分配
有時候新的需求進來時, 我們從 task board 上便可以快速檢視, 那些人在處理那些項目, 目前還有哪些 P1 需求, 然後對這新的需求, 做出正確的指派.
5. 每個 Story 執行狀態
每個 story 進行到工作流程的哪個狀態, 會在 task board 很清楚的顯示出來. 如果發現狀態還是很模糊, 或許要討論這個工作流程是否需要修改, 或是是否這個 story 不適合以這個工作流程來處理.
目前在想, 或許可以再增加一些數字統計的資訊在上面. 這樣若是要調整時, 更有資料來佐證是否合適. 或許一個月後再來分享一下學到的經驗.

在精實思考中, 提到了拉式系統(Pull System) 觀念和推式系統(Push system), 到底這個推推拉拉, 會怎樣影響我們工作的方式呢?
拉式系統
1. 定義: 是後一作業根據需要加工多少產品，要求前一作業製造正好需要的零件
   * 軟體開發團隊只做目前要功能, 避免一開要對整體的東西作分析設計, 以及產生整體的文件或計畫. 讓做出來東西, 之後不會變成沒用的東西.
   * 讓你可以盡可能晚點做決定. 等到要做時, 資訊比較豐富時, 才下決定要怎麼做.
2. 客戶有發現問題時, 就停下來解決問題, 直到沒問題時, 才做下一件事情.
   * 也就是當客戶立即使用產品時, 發現了缺陷, 給了你回饋, 你立即處理, 並且可進一步思考整體改善.
3. 客戶不一定指外面的使用者, 可能是內部不同部門或團隊.  後期的部門拉動得到需求, 前期的部門才開始建立產品
4. 推式系統通常意味著短周期和小批次. 但是要配合Kaizen(改善)來解決, 因短周期所引起的整體費用和覺成本增加的問題.
5. 範例:
   * 在便利商店結帳時, 便利商店店長依售出的數量向總公司進貨. 但如有存貨會先補貨上架. 公司會再向各供應商下單.
推式系統
1. 定義:  在推進式生產中，每一工序都根據生產計劃，盡其所能地生產，儘快完成生產任務，不管下一工序當時是否需要。
   *一開始要交付很多文件, 但很可能之後都需要更新, 或者變成沒有用
   * 一開始要決定很多事情.
2. 客戶有發現問題時, 可能是下個版本再處理, 或是交由維護團隊處理.
3. 前期的部門會為後期的部門建立庫存, 庫存中的產品都是部分完成的.
   * 前期的部門無法及時得到回饋, 不確定目前做得東西是否有用.
   * 前期的部門可能 over design
   * 導致整合測試要延後才發生, 前期的部門說做完, 可能是還沒有. 當後面發現問題時, 前期的部門說他沒有排這個工作或時間來處理這件事
   * 缺陷要到很後面才發現, 導致修復時間變得很長
所以你說推推拉拉有差別嗎?

之前提到公司內 QA 團隊在執行 Scrum 的困難, 因此打算開始做些修改執行的方式, 試著採用看板的方法.

首先, 針對要處理的事情, 我們歸納出有以下幾類
(1) 功能測試
a. 一般常見的功能測試工作. 這裡是針對新版本所要新增的功能
b. 我們目前的處理流程如下:
Analysis -> TCC (Test Case Creation) -> TCR (Test Case Review) -> TCE (Test Case Execution) -> Verification -> done

(2) 非功能性測試項目
a. QA 有些大型的測試工作, 像是效能測試, HA 驗證. 這些需要詳細規畫, 並且以小型專案方式處理
b. 我們目前的處理流程如下:
Plan -> Review -> Execution -> Done

(3) 自動化開發工作
a. QA 會需要進行自動化測試, 或是開發大型 benchmark 系統. 這時候便像是在開發小型系統
b. 我們目前的處理流程如下:
Analysis -> Design -> Coding -> testing -> Production -> done

(4) 臨時交辦事項
a. 有些事情並不需要詳細計畫, 只需要及時處理, 或者有處理即可. 便可歸到此類.
b. 我們目前的處理流程如下:
To Do -> In Prog -> Done:

目前還無法判對這四類型, 是否有辦法應付所有的工作. 需要一段時候才能確證. 但是就先把手頭上能想到的先列出來, 並且保留原先執行的狀況, 並不刻意改進工作流程.


進行方式
1. 由經理或是 team lead 先把所有工作項目放到 backlog queue, 並且記錄以下資訊
- 工作的 priority
- 工作的 ID
- submit date
- 工作的名稱
- owner
- 適用哪一類型的工作流程

2. Team member 從 backlog 中拿出工作來執行, 放到某個工作流程的第一個欄位, 並且填入開始工作日期到工作的便利貼上

3. 隨著處理狀況, 將工作的便利貼在流程中的欄位移動

4. 當工作移到 done 欄位, 填入完成日期到便利貼上面.

對於 team member 來說, 並沒有特別麻煩. 他們只需要從 backlog queue拿工作來處理, 並且填下開始工作日期和工作完成日期.

對於經理和 team lead, 他們有了這些資訊和便可以查看工作狀態, 並且計算 lead time 和 cycle time, 並且觀察一陣子後, 並可以開始限定 WIP 以及每種流程工作量的比例.

希望這樣的修改, 可以讓我們對於專案的狀況, 能夠掌握度更高.

忘了Burndown, 改用 Burnup 圖吧
http://www.nearinfinity.com/blogs/lee_richardson/forget_burndown_use_burnup_charts.html
在Agile社群中, 我們會使用 burndown 來顯示目前"還剩多少工作"要做. 這可以幫助經理們, 追蹤速度, 評估大概多久才能完成.
但是當專案過程中有新的需求進來時, burndown 圖便會破功.
讓我們來看下面這個圖吧. 這圖一開始有 100 點數的事情要處理, 經過了 8 個 iteration, 剩下了 20 個點數的事情, 這時候我們大約可以說每個 iteration 約處理 10 個點數的工作.
但是看看 iteration 6, 發生甚麼事情了? 只處理了 2 個點數的事情, 大家都在偷懶是麼? 還是大家都放假去了? 事實上有可能是當時顧客新增了一些需求進來, 因此團隊事實上來是很努力在處理.
原先剩下: 47
新增需求: 6
處理速度: 8 (在 iteration 6)
==> 47 + 6 - 8 = 45
因此在 burndown 圖中缺乏兩個重要的資訊:
1. 有多少事情在這個 iteration 被完成
2. 當時專案總共有多少要做. 或者當時增加了多少事情進來
所以我們可以用 burnup 突來顯示這樣的資訊, 這樣不就清楚多了. 這樣老闆就部會怪罪你們, 說你們 iteration 6 都在摸魚.

超多Kanban and Agile 相關的 blog. Enjoy it
1. Agile Anarchy
http://agileanarchy.tumblr.com/archive     
2. David Anderson Agile Management

http://www.netobjectives.com/blogs/why-kanban-board-value-stream-map-scrum-board-isnt-and-what-tells-us
價值流程圖是一個流程來顯示, 你的工作是如何進行的. 這裡有一個範例可以參考:
如果要把它轉換成看板, 會以以下形式呈現. 看板中的欄位, 就是價值流程圖中的步驟.
比較看板和價值流程圖, 你會發現價值流程圖每個步驟間的時間, 轉換成看板中queue 的概念.
但是眼尖的讀者, 會發現看板內少了一些步驟. 從request到sign-off部分都沒有包含到看板中. 這是因為看板一般不包含產品組合管理（PPM, product portfolio management). 所以看板內的流程只能是價值流程圖的一部分.
看板還是提供了工作怎麼被執行的資訊, 產品組合管理可以根據這些資料做出反應.
但是在Scrum的白板中, 不會把流程描述在其中. 它只有 "To Do", "In Progress", 和 "Done". 無法顯示
價值流程圖
雖然在看板和 Scrum 中, 你都可以對每個欄位, 設定其WIP來限制同時可以執行的task個數. 但是你還是無法把價值流程圖放到Scrum白板中.