當精實看板遇見人工智能時: 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