iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 5
0

Kanban,也就是「看板」,也是敏捷開發裡的其中一種方式,主要是利用一塊板子,在上面區分多的區域,作為流程分類,將一張便利貼(卡片)視為一個User Story,從0 ->1 的流程控制與狀態移轉

在詳細提Kanban之前,先說明兩個名詞Pull & Push SystemWIP

前情提要,前先時間很紅的澳洲打工,很多我的同學都去體驗人生,剛好有三個人他們都是在草莓園工作,而且是不同職務,一個是挑選好的草莓裝盒、一個是將一盒裝好的草莓複查秤重貼標籤、一個是將已貼好標籤的盒裝草莓蒐集整箱搬運出貨,剛剛好是一整條供應鏈呢!我們就用這個實例來說明吧~

Pull & Push System

我們假設挑選草莓要1分鐘、複查貼標籤要2分鐘、搬運出貨要4分鐘,因為裝盒的速度比較快,一完成就可以直接到下個進程,複查貼標籤,當時間累積下來,很多盒草莓就會積累卡在第二關,這就是Push System,用推的,把完成的項目往下個流程推過去

但是複查貼標籤本來就是需要比較仔細一點小費時的工作,這樣的方式,容易造成說好像是第二個環節的人能力不足或是產能低下,更遑論當到第三階段是要搬運出貨,儘管他們說都只是很短的一段路程來回只要4分鐘,還是會因為前些項目的所需時間成本不高,而導致囤積,那如果在每個環節的地方增加一個完成區,當這個環節做好了就放置在完成區,等待下一個流程的人手上有空出時,把該些工作拉過去做,就是Pull System

Kanban方法是一種Pull System,雖然看起來好像差不多,但是實際跑起來就會發現,因為放置在完成區,下個流程有空出的人可以將其拉去做,大大改善了原本因為直接指派給下一個流程的某個人去做,而導致因為其囤積過多工作而阻礙了產線流暢

WIP (Work In Process)

定義來說什麼是WIP,就是當每個人只能負責一條供應鏈,同時只能做一項工作的情境設定下,增加多少人力可以得到的產能會是最大值,這個人力/卡片的上限就是WIP

同樣用上面的例子,我們假設挑選草莓要1分鐘、複查貼標籤要2分鐘、搬運出貨要4分鐘,總流程時間為7分鐘

並假設當我們WIP限制為1時,表示整個供應鏈上只允許1批草莓裝盒、貼標籤與搬運,所需時間為7分鐘,此時的效率為1 / 7
假設當我們WIP限制為3時,表示整個供應鏈上只允許3批草莓裝盒、貼標籤與搬運,所需時間為9分鐘,此時的效率為3 / 9
假設當我們WIP限制為5時,表示整個供應鏈上只允許5批草莓裝盒、貼標籤與搬運,所需時間為10分鐘,此時的效率為5 / 10

WIP / 供應鏈上草莓批數 花費時程(單位分鐘) 效 率
1 7 0.15
3 9 0.33
5 10 0.5
7 14 0.5
9 18 0.5

由此表格所述,當WIP等於5之後效率就都維持在5成上,因此WIP就訂為5即可,不用增加不必要的浪費,可以把資源投注到其他的地方

限制WIP就是為了避免資源的浪費,要團隊關注在實際的產出上,而不是徒增成本


在了解了什麼是Pull & Push System和WIP後,我們要開始切入正題,什麼是Kanban?
先看一下這張圖
https://ithelp.ithome.com.tw/upload/images/20190921/201119166w00QlhxCA.png
圖片來源:了解看板(Kanban)方法的核心方法,活化你的管理思維

Kanban的核心概念其實就是下面六個重點:

  1. Visualize 視覺化看板
    要實踐Kanban的第一個步驟就是將工作項目和流程視覺化,以便得知目前的工作狀態,如上圖中將需求卡片化,然後分布在其對應的流程狀態中,一目瞭然,非常清楚各需求目前狀態
  2. Limit WIP 限制Work In Process
    一個數字,表示在進行中的工作量,就是同時開工但是卻尚未完工的工作項目數量,每個流程都有其所屬的Limit WIP,如上圖中Top 5 需求,顧名思義WIP為5就在下方括弧中;需求的Limit WIP為3,則會在欄位名稱下方括弧中寫入3。至於為什麼要有限制的WIP呢?就如同更前面說明的草莓供應鏈,要讓開發人員專注在一次一件事情,提高產值,不要因為工作切換、卡住Delay、或是拿更多的工作來掩飾某些工作無法完成的問題
  3. Manage flow 管理工作流
    在敏捷開發中很重要的一個關鍵是快速,而Kanban方法中衡量的方式就是時間,主要有兩個分類,都是針對開發團隊訂定的
    • Cycle Time:一項工作從進入一個流程區到離開這個流程區所需要的時間,例如T1->T2是一個Cycle Time
    • Lead Time:整個工作項目經過所有流程到完成所需要的時間,例如T0->T5就是個Lead Time,至於T5右邊綠色邊界再過去,就是發布維護等,不屬於開發團隊的範疇,因此不納入計算
  4. Make policies explicit 定義工作流
    意思是要讓團隊內所有成員都清楚明白每一個工作項目進入與離開每個流程區的條件與規則,例如:
    • 什麼條件下BU Top 5會進入需求流程、什麼情境下,需求進行中的項目會進入完成
    • 當遇到Bug的時候要如何處理?遇到阻礙時該如何處理?
      有些團隊會在Kanban上增加一些圖形表述,像下圖,有多一條緊急通道,且WIP為1,給予真正緊急且重要的Bug先通行,另有兩個項目遇到阻礙
      但是這其實跟第一個條件Visualize 視覺化看板很類似,因此也有一些人是認為不需要多此一條
      https://ithelp.ithome.com.tw/upload/images/20190921/20111916S1a24viTGG.png
  5. Implement feedback loops 落實回饋
    大部分的開發流程都會需要有回饋的這項重點,舉凡需求管理、開發、測試、發布等等的環節,包含在不同的情境、團隊下,都會有很多的可回饋空間,而Kanban開發法很重要的一點是「建立逐步改善的文化」,因此回饋更成為其重要的步驟之一
    不過也有一些人認為此項可歸於Manage flow 管理工作流,因為為了讓工作流更加順暢快速,而必須要有回饋機制
  6. Improve collaboratively, evolve experimentally 合作改善
    敏捷開發的精神就是透過合作,不斷改善,但是Kanban和Scrum與XP有一個很大的不同,就是Kanban並沒有週期的概念,不會有Sprint之類的,主要是依據工作項目流程,以達到持續演化進步的方式

最後,在上面的說明後,應該可以區分Kanban 與 Scrum Board,用途跟概念完全不同,千萬不要以為增減幾個欄位在板上就會是Kanban或是Scrum了,至於這兩者的比較表會在之後的文章中整理

參考資料、延伸閱讀:

下集預告:Agile 敏捷開發(二)


上一篇
Scrum
下一篇
Agile 敏捷開發(二)
系列文
後端功城獅30天DevOps探討挑戰30

尚未有邦友留言

立即登入留言