當精實看板遇見人工智能時: WIP的探索篇

為何半成品數Work In Progress這麼難設定呢?

.

回答這個問題要從根本說起;那就是利特爾法則Little’s law了。它是由約翰·利特爾在1954年所提出,內容是:

『在一個穩定的系統L中,長期的平均顧客人數,等於長期的有效抵達率,λ,乘以顧客在這個系統中平均的等待時間,W;或者,我們可以用一個代數式來表達:L = λW。』

轉換成產能公式,便成了「Lead Time (產出時間) = 存貨數量 × 生產節拍」

這是一個很棒的Queue解釋的公式,讓人一看便知如何計算生產線的產能,我最常用的影片是這個David Lowe 的麥當勞點餐(用點餐車輛排序來詮釋) 學員們通常一看見懂,感受到原來在Queue是這麼用的。但 …

littlelaw.pngDavid Lowe 的麥當勞點餐影片

.

在真實世界裡事情不是這樣的了

因為影片裡車子都是相同大小的車子,這一點就完全不符合真實世界了。而且在麥當勞點餐,很少會有一群顧客都點一樣的餐點的,其實即便是同樣的餐點內容組合也可能會不太一樣。

》答案是因為生產線上的產出都是相同大小的產品,因此適用利特爾法則。一旦轉換到軟體開發上頭,每個開發的任務Task的大小都不可能會相同時,他還適用嗎? 這一點舉一個例子來探討更容易理解。例如: 當你去設計Queue的程式時,我們很難只設計一個Queue來適用在所有的事件上,因為事件常有它的輕重緩急也就是時間上的需求,所以實質上;通常我們會一口氣設計好幾個Queue,一個是常態的,一個是給緊急性高的,另一個是完全無須考慮時間性的。而有時這麼設計還不夠,有時還會需要有更大的架構作輔助。

一種改良式的利特爾法則便出現了(平均產出時間,Throughput = 1/生產節拍)

avr

.

平均值(Avg.)的方式有用嗎? 對真實世界而言;這種取平均值的方式,它應該只是一個指標,一個足以讓團隊做為參考的指標而已。對數據的意義而言,採用或然率(Probability)的方式,也就是求取最小值與最大值之間可能產生的區間大小,然後再計算機率值是多少,這種方式應該更能表達真實世界的軟體開發吧。

.

怎麼設定WIP值呢?

這裡來介紹一種可以迅速獲得數值又能持續改善的方法。就是由數位化看板的累積流程圖來取得WIP值。如下圖:

累積流程圖_0.png

累積流程圖是看板方法所提供的基本圖示

垂直軸是工作量,對數位看板而言是故事點的多寡,水平軸是時間,一般是以日期來劃分。如果不做換算成時間的話,WIP的值是故事點,而 Cycle time (就是1/生產節拍)則是日期,分析一下可以得到:

 .

WIP = A_wip + D_wip + T_wip

針對該Task A開發時的WIP狀態

A_wip=Analysis 分析所花費的故事點

D_wip=Development 所花費的故事點

T_wip= Test 所花費的故事點

 

所以產能變成了:

Task A的產能 = BC段的故事點 / AB段的時間 = WIP / AB段的 cycle time

 ( 單位: 故事點/ 日期 )

累積流程圖_kanabn

顯示各個欄位有意義的 WIP

怎麼定 WIP值呢?

找一個最快完成的Task, 取得它在各個欄位的WIP值,這是最小可能WIP值。取花最多時間完成的Task, 取得它在各個欄位的WIP值,這是最大可能WIP值。好了;此時你就有了最小、最大的該欄位的WIP值了,接著就可以拿它來做為持續改善的依據了。

.

wip大小WIP出現最小及最大值

(Essential Kanban Condence 內說明結合看板時寬度的增加方式)

.

人工智能可以給我們什麼?

這只是古老的統計學,在最新的看板發展裡《Essential Kanban Condensed》由 David J Anderson 和Andy Carmichael 於2016年共同撰寫的看板方法(註1)裡加入了蒙地卡羅方法 Monte Carlo method統計模擬方法(它是1940年代中期由於科學技術的發展和電子電腦的發明)。在Forecasting and Metrics一章裡運用了蒙地卡羅方法進行預測與度量團隊在看板方法上的進度模擬。

蒙地卡羅.png

(於英文版41)

由於電腦的輔助運算,讓模擬團隊的Sprint開發作業成為了人工智能對軟體開發在預測上的貢獻(XD?),雖然我們都知道這僅僅是統計學上的預測,在上圖中的 50%,85%及95%的或然率說明。這樣的衡量可以讓我更清楚事件的發展過程,跟我們可以依據哪些資訊、在哪裡使得上力,以改善開發作業的效能。

結論

如果你正在運用看板進行軟體的開發作業,請不用氣喪始終定不好 WIP值,這一點跟我們在作Task的工時預估是一樣困難的。還不如倒過來;想想如何運用電子看板所記錄下來的數據,幫助我們進行學習,讓我們看到當時在計畫會議上的估算跟實際結果之間的差異,這種回饋是在真實不過的了,但卻很少有人把它放大來看,反思一下;如果人工智能可以拿來運用在這一塊持續改善上面,讓它幫我們整理團隊在上一個Sprint或開發作業時所運行的種種狀態,並依據事實給我們Comment,正好可以用來彌補我們在這一塊領域上所忽略了的學習。

如何設定各個欄位的 WIP值呢? 先跑一次Sprint然後從紀錄裡取得WIP值。接著開始統計出WIP的最小值及最大值,然後用它來作為回顧會議時提出來調整事項的結果依據,讓團隊一起來討論它,重點是提出如何改善的措施並共同承擔結果。

.

利特爾法則Little’s law適用於產出物相同的情形下。

.

註 1. 最新的看板發展

Essential Kanban Condensed》由 David J Anderson 和Andy Carmichael 於2016

 

 

 

看板方法: 限制半成品限額 Limit Work-In-Progress

當我們依據利特爾法則在追求最高產出時,才豁然發覺實際上我們是在追求「平衡點」。

追求工作數量 workload 與 工作能力 Capacity 的平衡點。

 

MyKanbanBoard_wip

 

「平衡點 」Balance

看著看板上的各個欄位,為了要追求流程的最高產出,我們必須在每一個欄位的最上方做設定,設定這個欄位所允許的「工作事項的限額」,我們稱它為半成品 WIP: Work-In-Progress。這個限制半成品數量的動作,可以讓我們藉著調整工作的需要時間(Cycle time)來改變生產率(依據利特爾法則),因此而得到最佳的產能。(其實沒有所謂最佳的產能,它只是我們不斷在追求的一個目標。而我們一直在作的只是在調整平衡點而已,並希望藉由這樣的調整能獲得讓我們滿意的產能,更接近最佳產能。)

這個平衡點看起來蠻單純的,但執行起來還需要多考慮、多取得工作上的溝通跟認可,處理人的共識有時候比找出平衡點還重要,必須先與上下游之間有共識以後實施起來才不至於造成困擾。接著我們就來走一回最基本的WIP制定原則。

 

※ 單工的考量

一個人同時只做一件事時效能最高(請參考: Multitasking is evil)。所以當團隊有三個開發人員,此時我們就可以考量把 In progress 欄位上面的 WIP值設為3。也就是每人最多同時做一件事。反過來說,當你在設定「個人看板」的時候,In Progress 欄位通常應該是 1。也就是說一次只作一件事,相信這個時候你的工作效能最好。可惜的是,我們很少能一次只作一件事,忙碌總是不請自來的! 因此考慮如何多工又能做得有高效能才是重點。

 

※ 多工的考量

當有限的資源遇到突如其來超過原有資源數量時,排隊現象(queuing)就產生了。如果我們不想要產生排隊現象怎麼辦? 那就只好增加人力資源。但,沒那麼多人可以加入怎麼辦? 那就只好要求一個人同時做好幾件事了,也就是進行多工作業(Multitasking)。雖然我們都知道多工對效能一定會有所損失(工作在做轉換的時候,一定多多少少會消耗人的精神跟時間的)。那看板方法又是如何來處理這種現象呢?

二種方法供選擇:

一、將WIP的數值調大到你願意承擔的 Queue 的最大值,然後再視狀況依次遞減下來。

二、預設每個人需要承擔的多工數目乘上人數作為WIP值,用最小值的方法作設定,然後再視狀況依次遞增上去。

二種方法都有人用,見仁見智,請視狀況嘗試看看。但選擇哪一種方法都沒關係,因為重點在調整的方法上頭。重點在嘗試調整到讓產值與一個循環所需要的時間能夠達到你滿意的數值,然後這就是你的「平衡點」了。

怎麼樣的數值會讓你滿意呢?

就是累積流程圖(CFD: Cumulative Flow Diagram)的曲線能達到平滑。上面的二種方法;一個是由大到小,一個是由小到大,目的都在不斷嘗試著找出產生阻塞時的WIP點。找出來之後再由現象作判斷考慮調上或調下(找到平衡點);也就是曲線能否達到平滑的地步來做WIP值的調整依據(CFD圖的解圖,請參考:累積流程圖)。

※ 無可避免的緩衝區(Buffer)設計

在瓶頸前設置緩衝區,這是一種充分利用瓶頸處資源的典型作法。緩衝區的大小很重要,他就跟排隊 Queue一樣,它會增加WIP的數量,請注意: 當WIP的數值越大,就表示前置的時間就越長,所以WIP數值越小越好。但這二個數值間接的改善了曲線的平滑度,也增加了曲線的可預測性,可以增加我們作決策時的準確度。它也使得工作流程不會停頓下來,加速了交付的速度。

緩衝區的運用可以確保瓶頸處的資源一直處於工作狀態,從而提高了資源的利用率,避免了阻塞。真是好用,但一樣的前提一再的提醒我們,千萬不要為求敏捷而犧牲了品質,主管們最想要的除了高產能之外可預測性應該也很重要。

 

到底排隊(Queue)的大小要設多大呢?

要你憑空去設定一個數值好像蠻難的,但其實RUN過一輪以後你就知道了。就把它設得比產出速率大一點點就可以了,目的當然是讓流程可以不會被中斷。例如: 團隊每周可以交付 5個工作事項,而針對排隊的補充速率是每周一次的話,那把它設成6 或7就都可以了,至於是 6還是 7就看交付速率的穩定度來決定了,一般而言 7應該比較好一點。至於甚麼時候才應該調整這個排隊大小的數值呢?

當團隊提前完成時,若是才過了星期三,團隊就已經達成7 個工作事項,接著就會產生了大的盈餘時間,團隊成員會覺得太輕鬆了(通常是老闆會看不下去),這就表示Queue的大小明顯的可以再調高到 8。調整的狀態,經常會受工作事項的困難程度而影響,到底哪個數值才好,應該是隨著工作的難易度動態的調整,運用即時的判斷來作調整就可以了,沒有必要太傷腦筋或執著於某一個數值,因為它是相對的。

 

看板上沒有設置WIP值的欄位

當產出能力遠比瓶頸處的產出時間大的時候,就可不用設定WIP值了。也就是說在那個節點上有相當得盈餘時間在,當然沒有必要再設WIP值了。哈哈! 如果你是主管的話,此刻想的應該是如何消除盈餘時間,對不對?!

 

還有,最後一個欄位通常都不會設定 WIP值,下回再說吧!

 

 

 

 

 

 

 

 

 

 

 

 

實施看板方法一些注意事項

TechDays 2014 上了一堂看板方法課程

看到許多來參加課程的主管及工程師們紛紛起了嘗試 Kanban Method的興趣,真是讓人欣慰(也開始擔心起來)。要知道;看板方法十分簡單,實施起來只有簡單的規則,但它是屬於經驗主義之下的過程控制方法,經驗在這裡佔據成敗的最大成分,因此趕緊補上有關看板方法執行失敗的一些注意事項:

not simple

規則簡單但需要持續的改善才會成功!

作為一種漸進式變革管理工具的看板已逐漸為人熟知,它是精益敏捷陣營中適應性最強大的方法(如上圖,Kanban Method 只有3個產出物),這也就意味著它的標準化程度最低(如下圖,很少有長得一模一樣的看板)。所以一些團隊雖然參加了《看板方法課程》的培訓,實際應用時卻十分容易流於形式。大家雖都能把規則倒背如流,看板具有的6大核心實踐:視覺化、限制WIP、管理工作流、過程規則化、要落實回饋、協作式改進,但需要知道的是;達不到這六點就稱不上成功實施看板方法? ! 因為他們是息息相關的。( 其實;看板方法實施起來一點都不簡單。在 David J. Anderson 的看板方法一書裡頭,第六到第十五章講的正是實施看板的方法,初次看的人一定會頭昏腦脹,更別說後面談到模式的那幾章了,但話雖如此;有料的書應該買得讓人有比較值得的感覺吧!)

( 在課程中,舉了個人看板作為範例,請注意: 個人看板主要談的是持續改善進而確定人生的方向,人們很少用硬梆梆的數據來描述自己的行為的,反倒是能否容忍自己的作為表現才是重點。團隊的看板就不只如此了。)

  • 第一要忠實分析你的價值流程圖 Value Stream

     (這是精益精神的基礎,不要去看當初公司制定的制式規範,要透過團隊一起確認工作方式才是真正的工作流程。別忘了讓團隊自我管理,多畫幾次…)

  • 千萬不要本末倒置,讓流程反過來去配合看板 😦這是初次運用看板方法的必經過程)
  • 不要畫得太詳盡,要適度的抽象化,千萬不要什麼都想放上去(我的第一次失敗經驗)
  • 一定要實體與數位看板並行。讓團隊自己討論,讓他們自己挑出合用的工具,RUN 它一個星期之後再來個大PK(讓團隊自已做抉擇,這種經過團隊用心討論出來的東西,最有價值不過了)。

  • 要有個十分明確的目標,讓站在看板前面的人可以說得出來,問題(會阻礙達成目標的種種因素)自然也會呈現出來。
  • 千萬不要讓自己掩埋在Buffer裏頭,勇於嘗試! 想辦法看到瓶頸才是真正的目的,不要老是用小小的加加減減來欺瞞自己,因為要看到現象才能對症下藥,所以盡可大膽的嘗試。
  • 注意,在以能夠達到最大產能的原則下, WIP Work-In-Process 半成品的數值要越小越好,不需要分出多餘的Column時,就把它刪掉,若是刪錯了,別太擔心,最多就這一、二天問題自然會跑出來的(有問題出現,透過討論找出解決之道,看板自然就又改進了一步,持續改善是看板方法最重要的精神)

  • 千萬不能讓成員打迷糊仗: 如果一大早在Kanban 前的會議,有團隊的成員始終沒有進入狀況,也就是對看板上所出現的現象一知半解的,請務必花時間進行充份溝通,這是"經驗之談"。因為一旦有人脫鉤了,接著下去的整個 Sprint 他都會始終在狀況外。這是最最要不得的。 Scrum Master 一定要加以輔導盡到職責。

  • 遇到瓶頸基本上的因應之道可以考慮增加 WIP 的額度或是增加緩衝區的大小。但不要忘了 WIP 和 Buffer 都是越小越好的東西

  • 看板是一個實驗性的過程,因此WIP的限額需要視狀況進行適當的調整(請參考TOC的五步聚焦法)。

下面是一個實務化的看板,圖片的下半部有一些說明是用來提醒工程師在每個階段該做的事!

實例化看板

還有些話要說,等下次了…

用來提升個人效能的「個人看板系統」– Personal Kanban

images9CTXEYN5
用來提升工作效能的個人看板

(在Youtube 上的說明影片 )

用來提升個人效能的「個人看板系統」Personal Kanban ,創始人 Jim Benson

  • 一個人需要執行敏捷開發 Scrum ?

這是一個經常被問到的問題,

請問: 工程師一個人要如何來執行敏捷開發Scrum呢? 有必要嗎?

過去我的答覆都是這樣的: 由於Scrum對角色的要求,因此一個人沒有必要執行Scrum,只要符合敏捷開發的精神就可以了。但是在經年累月的scrum課程中這個問題始終沒有間斷過,確實有很多工程師屬於長時間、一個人單打獨鬥的環境下進行開發作業,但又渴望能有提升效能的方法,那要怎麼辦呢? 現在增加一個答案可以回答了,請嘗試「個人看板系統Personal Kanban

.

「 個人看板起始於先弄清楚自己現在的狀態,然後逐漸的邁向對未來的願景。」

.

(上面的問題在我的書裡頭說得較詳細。書裏頭用「類專案」來談一個人如何敏捷的做專案。「類文件」:一個人開發需要些甚麼文件。書名:" 精實開發與看板方法)

.

用來提升個人效能的個人看板系統

個人看板是用來增進個人理解自己的工作和進一步透過分析來改善流程使得更有效工作的方法。它透過視覺化目前手頭上的工作,然後運用WIP(work in process: 半成品,對軟體工作者而言,指的是還在coding中的程式 )的管制來調整個人對工作進行的流程管理,進而能夠經由有效的管理工作流程來提升工作效能。真是很有效率,也很有趣! 特別是採用微軟系列開發工具的工程師,若能夠透過 Visual Studio 所提供的看板機制,實際管理一下自己的工作與生活瑣事,讓撰寫程式的工具與個人的生活事物相結合也是一種提升個人工作效能的好方法。(看板方法之父 David J Anderson 實際上是出身自微軟, Kanban Method 也是首先運用於微軟的專案上。)當然如果你已經採用了個人看板系統;透過自身的實行,對於整個開發團隊一起實施Kanban Method時,能夠事半功倍是可以預見的。 要深入解釋這種運作,首先要有一種概念:「多工造成效能不佳」談起。(請試著在網路上搜尋: Multitasking is evil 後面在加上 “哈佛” 就有參考文獻了,或是參考這段影片 https://www.youtube.com/watch?v=US9Sff8BFx0 )就很容易了解是怎麼回事了。

多工反而降低了工作效能 — Multitasking is evil

人們總是不自覺的同時處理多件事情。對電腦而言,它能很有效的做到多工(multitask)的動作,而且相當有效率。但人腦卻很難這麼做,我們太容易分心了,對於外界所傳達的訊息我們幾乎來者不拒,是這些干擾的訊息造成我們很容易就開啟了另一個工作而對原來的工作降低了該有的專注力,這一點;對程式設計言;這當然是 BUG的好來源,對測試而言;萬惡則莫過於邏輯思維受到中斷所埋下的缺陷(這是種比較難被測試出來的疏失)。所以針對專注力不夠的朋友,我想推薦Personal Kanban,透過運用它來管理你的工作,運用工具來有效管理手頭上的工作讓生活更好過些。

實行 Personal Kanban 三步驟

  1. 視覺化: 把你手頭的工作用流程畫出來。(Gerry Kirk 在youtube 上的幾篇個人看板運用說明,值得一看!  畫出你的第一個看板)。
  2. 限制WIP(Work In Progress進行中的工作)。(為 Dave Lowe 所製作的一段默片,他運用了Drive through窗口點餐作範例,再清楚不過的說明了WIP的功用,以及我們該注意甚麼。) 試著設定WIP值,請參考這裡WIP 0
  3. 管理工作流(透過反省、分析最佳化你的工作,這是最有價值的一段)。 依稀記得在第一次閱讀 David J. Anderson 所寫的「看板方法」時,就發現給 Comment的許多人中,一致認為看板不只是如此而已,它潛在的可運用空間很大。我想指的就是這裡。(可以參考Gerry Kirk 在youtube 上的其他說明)

(Personal Kanban 的創始人Jim Benson 在書上只列了前二個步驟,並且認為它可以適用在家庭、學校… 任何有人的地方,它能讓人們能更有效的工作(我完全讚成!)。但在這裡我還是加了第三條執行原則,也就是善加管理你的流程。所以這裡就多列了原始Kanban的第三項步驟! )

※ 先介紹 David J. Anderson 所寫的「看板方法」 一書: 如果你想採用 Kanban Method 的話,這是必讀的經典參考書籍。但請務必去看更新資料 http://www.djaa.com/ 查看他最新的定義,這是一個用功的傢伙,隨著時事的改變他也不斷在精進自己所創的理論。(Kanban Method 的開發原則,目前已經稱為6個 practices了)

※ Personal Kanban「個人看板」 Jim Benson 所著。很有參考價值。

kanban
簡體中文版,看板方法:科技企业渐进变革成功之道
personal kanban
原文版

已經沉浸在 Kanban的信息分配多時了,真是有太多麟麟角角,很多只能意會難以言傳的東西,希望找到更好的說詞。想想那些教授看板理論的老師真是難為了。以下是看板方法的六個核心實務(6 practices),前三個常常被稱為3大準則 3 Principles。

6 core practices for kanban

個人看板讓你掌握時間《做自己

個人看板不只是拿來提升個人工作效能, 它更能拿來管理自己生活與工作流程,讓你知道如何掌握時間《做自己》。如何做呢? 靠分析瓶頸來達成改進的需求。

分析三步驟:
(1) 注意自己開始和完成工作的速率。
(2) 每個工作是否按步就班在自己能夠容忍範圍之內完成。
(3) 超過 WIP 限制的情況嚴重嗎? 應該採用寬鬆的方法(加大WIP值),還是緊縮的方法,讓現象能夠改善呢?

(Queue 跟 Buffer 的運用,有一點複雜找機會再來詳細說明)

當然;日子要過得快樂才對,但為了在龐大的工作壓力下還能笑得出來,來試試 Personal Kanban吧!

kanban tools 0

一開始;我覺得越簡單越好,就直接用 OneNote 自己畫看板(如圖中最左邊的),後來因為經常坐在床上更新工作事項(當然用iPad了,也就換成 trello了),最近已經換成 KanbanFlow (非常好用!),因為它多了番茄鐘,可以提醒我專注在工作上的時間。建議大家不遑多試試看,用習慣了就是好的。

為何不直接使用 Visual Studio呢?

答案是當然可以! 不過我會建議你用角色的方式來運用 Visual Studio,因為它比較適合團隊運作的方式,你若能將在家裡的角色、在公司的角色或區分成更多角色,分開來運用,則更能跳脫那種公私不分的枷鎖(這是良心的建議)。

附上一張個人使用看板方法的參考圖示。 (想試試看嗎? 參考: 運用個人看板做時間管理)

.

personal kanban

.

結論

你想增進自己的工作效能嗎?你想讓自己活得更愉快嗎?首先;你要先弄清楚此時此刻你要的是什麼?現在什麼事對你是最重要的,你最在乎的是什麼?然後把每天所作的工作,花費多少時間去做,記錄下來。再從記錄上去分析你是否把時間都用在自己最想要的工作上了,如果不是的話,就設法增加它的比重、調高它的優先順序,然後再執行ㄧ陣子看看,持續改善它,讓自己為自己所想要的東西而活。

請參考: 一個人如何施行敏捷 (來自單核工作法的聯想)

.