David Ko的學習之旅

我在 Kanban 中的文件中, 常常發現有人提到單件流(one piece flow)的觀念, 對於資工出身的我, 十分困惑, 它到底是什麼? 和軟體開發的關聯是什麼? 可以帶來什麼好處呢? 最近花了點時間整理了一下.

原本單件流的定義:
每次生產和移動一個工件,  整個過程希望盡可能連續流動, 並且上下流的工作能夠剛剛好接上.

在 Kanban 中, 第一件事情, 是要將工作流程視覺化, 也就是將工作流程畫出來. 每個步驟會變成一個欄位, 你的便利貼 (工作) 便會在這些欄位 (步驟) 中移動.

此外, Kanban 還會引進拉式系統觀念, 也就是生產是由需求驅動的. 當下游還沒有完成, 或是沒有需求時, 上游不能一直生產東西往下遊送. 為了實踐這樣的觀念, 你流程中的某些步驟, 可能會有兩個子步驟, 並且會有兩種表示方式:

1. ready/doing
1-1. ready: 在這個子步驟中, 有些工作正等待被處理, 這些工作是從上個步驟放入的

有人說 Scrum 改成 Kanban 很容易, 只要在 task board 中的欄位加上 WIP limit 就可以了. 所以原先的 scrum board

ToDo -> In Prog -> Done

便會長成像
              (WIP = XX)

在李小龍的截拳道中, 有定義出四種攻擊距離: 踢技, 拳技, 抓技, 寢技.

截拳道強調四種距離在戰鬥中都同樣重要。多數武術專注於其中一或二種距離，但李小龍認為真實格鬥中四種距離都隨時會發生，所以要全面地訓練。

可是在 agile 開發方法中, 常常會出現只用一種方法, 或是只適用一種背景的開發方法, 因此在推廣常會遇到阻礙. 例如 scrum/XP 大多是用在單一開發團隊的狀況, 若是對於多個團隊, 或是維護為主的團隊, 便會適應不良.

2013 David Anderson 在 Lean Kanban University 上發表了一個演講, 其中提到李小龍, 引用他的哲學來說明 Kanban, 讓我十分驚豔不已.

以下是李小龍的想法和 Kanban/Lean 想法的對照:

在社群或是公司中, 常常會聽到以下問題:
agile/Scrum 的想法很好, 但是我們公司的文化不喜歡改變這麼大
我們的組織不喜歡不斷的衝刺 (sprint), 太累了
我們的成員成熟度不夠, 無法自動自發
我們只想求溫飽, 不需要一直追求完美

豐田系統的效率是舉世有名的, 那他們如何來改善他的工作流程或是做事方法呢? 以下是個人小小整理心得:

1. 狀態視覺化
將工作流程和狀態給視覺化, 發現到異常現象, 立刻來處理. 以下是如何利用 Kanban 來視覺化狀態的簡介
http://kojenchieh.pixnet.net/blog/post/343997120

上次在網路上看到一個例子(sorry, 我忘記出處), 來描述為什麼要用 WIP limit (Work in Progress), 想來跟大家分享:

Kanban 最主要的是看 flow 的流動是否順暢, 任何會影響 task 在工作流程上的移動, 都可能會是問題. 但是你要如何及早找出有問題的地方呢? 

你可以把這件事情想像成實體的河流流動, 你要如何觀察這個河流是否流動順暢? 是否有淤積? 在台灣常聽到的做法, 是在冬天水量較少的時候, 安排清淤泥的工程.  

很多人問說一定要實體看板嗎? 為什麼不用 Trello 或者是其他電子系統呢? 個人覺得理由有下:

    

1. 精神比較重要
對很多團隊來說, 都是剛剛實施 agile 沒有很久, 還並不了解 task board 的作用什麼, Task 要怎麼寫. 因此在早期是需要對大家做機會教育的, 然大家面前提醒大家, 這個 task 要如何移動, 哪些資訊沒有填寫, 要如何在立會時報告 task 內容. 因此重點不會是在要用電子系統或是軟體工具, 而是大家是否有注意到要小心的事情. 此外, 如果要很多錢來買, 老闆還會覺得不知有沒有效果就要花錢, 之後還可能一直碎碎念.

目前正打算整理 Kanban 相關的基礎知識, 赫然發現自己會的東西真的不多, 但是要花時間學好的項目不少, 明年繼續好好加油. 打算把一些相關文章和觀念彙整起來, 然後都是由這一篇當起始點來找起, 這樣就可以知道自己已經了解多少了 XDD

 

1. Kanban 簡介
(1) Kanban 不是軟體開發方法

精實軟體開發是根據精實原則所產生的, 因此你必須先了解什麼是精實原則, 才能知道精實軟體開發重點放在哪裡. 在 Lean Software Development: An Agile Toolkit 一書中, Mary 整理出了以下原則:

1. 消除浪費 (Eliminate Waste)
在這篇文章中描述了軟體開發中常見的浪費是什麼

看板並不是軟體開發方法, 他是變革管理的方法, 當客戶所提出的需求, 和團隊的能力不匹配時, 它能即時展現這樣的狀況, 讓你能得到警告. 當你實施改進做法, 你也可以從看板上看出, 這個方法是否有效.

那當客戶需求和團隊能力不匹配時, 我們會怎麼做呢? Kanban 的想法是這樣的, 當進來和出去的不能匹配, 會導致每個項目處理的時間變長, 所以要解決的問題是如何讓處理的時間變短, 讓客戶能儘快拿到有價值的商品, 也就是 cycle time 越小越好. 

人們通常善於解決問題, 但是比較不擅長去把有問題的地方給找出來. 在精實思想中, 它整理出一些有問題的地方: Muda, Mura, Muri. 我特定把他們在整理了一下, 時時刻刻提醒下自己, 這些 bad smell 要特別小心.

 
1. Muda (浪費)
做一些不會對產品加值的事情

在精益思維中, 排除浪費是一間非常重要的事情. 在製造業中, 什麼是浪費大家已經定義的很清楚了. 可是在軟體開發中, 大家對這樣的事情還不熟悉.

因此 Mary 和 Tom Poppendieck 在Lean Software Development: An Agile Toolkit 一書中, 很詳細說了軟體開發有哪些浪費. 其中有一項浪費是半製品, 也就是未完成的工作. 什麼事未完成的工作, 例如沒有被檢視的需求文件, 設計文件; 或是寫完但未經測試的程式碼. 只要不是最後可以交付到客戶手上的功能, 任何中間產物都算是未完成的工作. 即使你可能已經檢視過, 或是測試過, 只要沒被客戶驗收認可, 都是可能會有變, 會不再算數.

那我們看板中要如何管理半製品呢? 我們可以用 WIP (Work-In-Progress)來觀察. 如果我們能讓 WIP 的數目越小, 也就是代表半製品越少, 那可能的浪費也就越低.

在討論 Kanban 和 Scrum 的差別時, 大多數的人都是參考 Henrik Kniberg 的 scrum and kanban making the most of both 書中的說明. Al 則是從兩者的思考方式來比較, 我想從思想上來做探討, 會讓你更深入他們的差異性. 以下是 Al 的比較結果:

我發現到 Al 大老對 LKU 槓上了, 兩邊對 Kanban 有著不同見解. 對我來說這是不錯的機會, 從他們討論中, 讓我可以思考 Kanban 到底是什麼.

Al 認為, 一般來說, 談到 Kanban 可能有以下幾種意思:
1. 一堆有資訊的卡片, 通常用小寫的 kanban 表示

這是我在 qCon 上海 2013 所發表演講的摘要 (http://www.qconshanghai.com/node/403), 描述在專案中使用 Kanban 的經驗. 歡迎大家多多指教.


專案背景
首先先介紹專案的背景. 這部分其實很重要, 因為我的解藥可能會是你的毒藥. 你必須要先了解的背景和來龍去脈, 這樣你便可以判斷是否可以套用在你的專案中. 因為沒有所謂的銀製子彈, 只有較合適的做法.

很多人認看維護團隊適合使用看版, 所以我很理所當然地在維護團隊中嘗試它. 一開始時, 我定義處理的流程如下 

當開發人員在解 bug 時, 常常會有想換種寫法來解決問題的作法. 這個方法比較方便, 可以不用管過去的作法, 尤其是當原先程式不是你寫的.

這時候, 經驗老到工程師會說, 如果沒有找出 root cause, 只是換種作法, 事情可能沒有真正被解掉, 之後有可能會再冒出來.