DevOps Handbook 中提到要先繪製價值流, 然後轉換成看版, 藉由監看看板中項目的流程, 可以找出瓶頸或是多工的問題.
價值流 (value stream mapping) 就是你現在的處理流程, 因此大家應該可以很容易繪製出來, 可是接下來要把價值流變成看板就沒那麼簡單. 這裡我找了維護團隊的處理流程, 大家來試畫看看, 你會產生出什麼看板呢?
圖一 維護團隊的價值流程圖
我做了一個版本出來, 其處理流程如下.
處理流程
(1) 當 Bug 進來後會放到 bug backlog 中
(2) QA 有空的話, 會從 bug backlog 中拿到 "分析和重現 bug”. 這裡我們會依據 bug 的優先順序來拿
(3) 如果無法重現, 這時候會移到 "等客戶提供更多資訊", 等待客戶反應. 如果客戶有回應, 則會再移到 "分析和重現 bug”
(4) 當 QA 重現之後, RD 有空會去拿 bug 到 "修復bug"
(5) 當 RD 修復 bug 後, 這時候這個 work item (bug) 會分成兩張, 一張給 QA 拿到 "驗證 bug", 一張給 writer 拿到 "撰寫 readme”
(6) QA or writer 處理完後會放到 "Ready For Hotfix”, 當兩者都完成, 就會合併成一張, 等待 RD 有空拿到 "產生 hotfix”
(7) 當 RD 產生完 hot fix 之後, 便移到 "給客戶驗證”
由這個看板, 大致可以看出每個角色處理的量如何, 那邊會是瓶頸, 團隊可利用這個訊息, 來決定行動或是改善方向.
圖二 維護團隊的看板 v1
在圖二這個 board 中, “等客戶提供更多資訊” 欄位就是放等待客戶處理的工作, 某種程度來說, 就是這個工作被 blocked 住, 被客戶給 blocked 住. 因為不知道客戶多久會回覆, 所以 WIP limit 的值是無限大.
你覺得這樣的設計有什麼問題呢?
最主要的問題, 就是這個欄位的工作 會堆起來.
如果留在原先 "分析和重現 bug” 欄位中, QA 會有壓力要去詢問客戶狀況如何, 現在變成就是把它丟到一個沒人管的地方去.
這樣看板的好處: 減少多工 和 利用 WIP 出發改善等優點都沒了. 都因為這樣的設計, 而無法發揮出來.
所以要怎麼修正呢? 可以採用圖三的模式. 可以在 story 上加上 tag, 來標示這個 story 被 blocked 住, 但是還在同一個 WIP 限制下, 所以不會忽視掉它. 這樣是不是好多了
圖三. blocked 改善 pattern
接下來我們要看的是流程效率
在 DevOps Handbook 中有提到要來計算 flow efficiency, 可以知道目前效率如何?
那你覺得這張維護流程的 flow efficiency 是多少呢?
以及你覺得 flow efficiency 得直要多少才算不錯呢?
正常算法: 流動效率 = (加值活動的時間) / (加值活動的時間+非加值活動的時間) x 100%
所以, 一開始我會想這樣算
流動效率 = 3.8 d / (15.2d + 3.8d) x 100% = 20%
15.2d = (1) + (2) + (3) + (4) + (5) + (6) + (7) + (8) + (9) + (10) + (11)
但是, 這個價值流圖有點複雜, 有平行的, 也有 loop. 所以上面 20% 這樣算法是錯的, 無法單純這樣算
首先, 我們先來看平行的部分: 撰寫 readme 和 驗證 bug.
這包含兩條路徑 (5) + (7) 和 (6) + (8), 我們只要算最長的部分, 因此只要計算 (5) + (7) 就好
接著, 有兩個 loop
Loop1: (3) -> (2),
Loop2: (4) -> (5)/(6) -> (7)/(8) -> (9) ->(10)
先說簡單一點的狀況: Loop 2, 在我們團隊的狀況, 交給客戶後, 會再被退的狀況很低, 在 1/1000 之下. 因次這個 loop 2 會再回去的機率不高, 我們是可以忽略它的存在. Lead time 的時間會因為 loop 2 多加一些, 但是不多.
然後我們來看 Loop 1, 這個情況就還蠻頻繁的, 10% 會 1 次 loop 發生, 10% 會有到 2 次發生, 其餘 80% 是 0 次 loop.
所以非增值部分的時間就要按這個比例去計算, 這還蠻複雜的, 這邊只是讓大家知道這樣的概念, 我們並不進行計算
看到這邊有沒有覺得流動效率的計算不簡單 ....
Kka
文章標籤
全站熱搜
留言列表
