Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for the ‘未分類’ Category

看板方法入門

leave a comment »

.

0001.png

中間是David J. Anderson 所著的看板聖經(註1),左側是我補充精實原則的參考書籍

(照片是與DevOps 之父Patrick的合影,拿來鼓勵年青人要與世界接軌的)

.

0002.png

從一個你一定會遇到的問題做為開始

.

0003.png

Todo – Doing – Done 是最基礎的工作流程,也是最簡單的開始.

.

0004

當你站在看板前面時,第一件事是先關注它的輻射資訊,再來就是依據精實原則來對他品頭論足了!

.

0005.png

沒有設定 WIP 值的板子就不是實行看板方法(David J. Anderson)

.

0006.png

看板以簡單著稱,但卻有著深遠的改善內涵

.

0007.png

在每一個價值流的過程中建立回饋機制

.

0008

.

0009.png

.

0011.png

不要急著開始改善,先幫工作人員減低負荷才是好的起步

.

0013.png

忙碌的團隊事很難接受任何變革的

.

0014.png

定義半成品的正確觀念對團隊至為重要

.

0015.png

.

0017.png

一個解Queue的範例.

.

0018.png

.

0019

.

0020.png

學會如何看累積流程圖,你自然能夠意識到 WIP的妙用

.

0022

.

0023

.

{

總是會有學員在這裡提出問題來問要如何運用看板來增進個人效能呢?

所以這裡補上;一個人如何實行敏捷!

}

.

0026.png

一個人要如何施行敏捷呢?

.

0028

請參考: 單核工作法一日Sprint個人看板

.

0040

工作時能明確區分重要緊急的事,是提升工作效能的前提

 

 

.

: 這份資料是給公司新進人員的「看板方法」初階課程,時間是 2小時。

1. David J. Anderson 所著的看板聖經看板方法:科技企业渐进变革成功之道

2.《精實開發與看板方法》 by: 李智樺

廣告

Written by ruddyllee

2018 年 06 月 11 日 at 14:33:50

DevOps 實踐指南 : 變革管理

with one comment

.

組織轉變 變革 Change Management

.

我遇過幾次大的變革,英文寫起來輕鬆多了change management,但沒有輕鬆這回事。有從130億的大公司轉變成35億的變革,也有從上千人的公司轉變成數百人的公司的變革,這些年來即便我是以顧問的位階参與組織的改變,但我總覺得自己從沒有看到過變動的全貌,甚至是事後來自報張雜誌上的描述我都沒辦法分變真假,也習慣把不能了解的原因推給自己不是核心成員,因此看不見內幕、不知道是誰、為何做成那樣的決策,又怎麼可能看見全貌呢?!

旁觀者清

但其實是當局者迷,旁觀者清。例如:我嘗試把英文版的DevOps Handbook 5~8章專講變革的部分節錄下來傳給他們(正在進行變革的主管)参考,但總是沒有獲得好的回應(現在可以傳中文版了,結果一樣沒反應),想想;實在不能責怪他們,人們總覺得必需靠自己想清楚了變革才會成功,而書本上講的只是原則,實際上沒那麼簡單,等過了這段渾沌的時間後再來看吧!但其實不是這樣的…

 

用價值流Value Stream幫你看見全貌

變革之初;要先畫出企業引以為生的產品或服務的流程圖來,它可以幫你看見全貌。運用可視化的方式來看清楚自己是怎麼運作的,畫出來的價值交付過程的圖示就叫作「價值流程圖」value stream diagram. 這不是什麼新技術,Toyota 用它來調整工廠運作的生產線效能已經很多年了(註1.)。OK,畫出價值流之後呢? 也就是當你客觀的去面對自己團隊的工作流程時,接下來該做什麼呢?

.

選擇合適的「價值流」作為切入

.

where to start.png

本書最重要的一章,就放在概述完三步工作法之後

.

performance.png

用來判讀「企業效能」的流程範例

( 效能: 企業都不能忽視的地方)

.

職能與市場導向

二種團隊的轉變方向: 「職能導向與市場導向」圖示

.

Puppet Lab 2017.png

書中屢次提到的 Puppet Lab Report

(DevOps Team由2014的16%進步到2017的27%)

.

report 2017

顯示企業效能的4個重要指標

.

Result

驗證 Robin Dunbar 的 150人上線法則

.

註1. 企業面臨轉型時(re-organize)傳統的作法: 先擬定方針再規劃過程最後才決定執行的程序,由這三方面來考慮鋪成細節。現在的組織則說動就動,步調變快了,往往疏忽了許多細節,但更見勇氣可嘉。

2.價值流其實是多維度的,而價值流的描述或是應用的工具卻多是線性的,這一點經常為人垢病,但把它視為抽像化的結果卻可以讓我們看得更清楚些,也是值得的。

流程改變參考書籍

過程改進手冊》by: 特里斯坦·布特羅斯

组织变革管理by:伊恩·帕尔默

.

 

Written by ruddyllee

2018 年 05 月 25 日 at 11:26:58

張貼於未分類

Tagged with ,

DevOps 實踐指南 : 介紹篇

leave a comment »

.

作者介紹

.

全貌

簡化目錄章節可以看見內容的全貌

.

價值流程.png

作者想要交付什麼價值給讀者

.

介紹.png

從觀念概述開始說起

.

介紹1.png

由理論及參考書籍可以想像到內容

.

註. 無疑的《DevOps實踐指南》是DevOps技術實踐的最高指南手冊(共346頁)

第二部分談的是變革 Change Management,也就是談企業轉型到DevOps的實務轉換步驟。俱有相當的參考價值: 在這裡,一掃鳳凰計畫》缺少實踐實務的陰影(下回再介紹)。

Written by ruddyllee

2018 年 05 月 24 日 at 11:54:46

DevOps 三十六計 解讀

leave a comment »

.

36計封面

書的封面跟被邀請的宣傳照

.

儘量延遲決策  – 的第36計

如果你只是聽說過這本書,那就不要急著立刻去購買它,它純粹就是一群有豐富經驗的講師們,在DevOps大會期間把自己最在意或是最拿手的主題用經驗描述出來罷了。方法是模仿設計模式(design pattern)的做法,只是我們把Pattern這個詞中國化了,把「模式描述成了「計策,把商場變戰場化了,書裡頭就是一些經驗談,如果你想看到完整的篇幅來描述傳統的三十六計,那還不如去坊間購買《圖解三十六計》或許能看得過癮一些。書的內容就像上面那二張圖式一樣,半中半西的;感覺上有一些怪怪的,但又說不上是哪裡在作怪,明明是科技的文章卻有著新舊混合起來的宣傳照,哈哈!那純粹是我個人的感覺,你可能不覺得,甚至願意從口袋掏錢出來購買它,請「三思而後行」:孔子說得好,請再多考慮一下,不要一時衝動就買下來了,不要讓它成為書櫃裡的又一本藏書,不遑多思考一下,這是精實開發裡所謂的延遲決策不要急著太快下決定。請參考: 第三十六计、延迟决策減少错误,系统思维看见隐藏在看板之后的全貌。

.

36計系統思維.png

.

模式 Pattern與計策Stratagems

在看Eric Gamma 所寫的設計模式書(註1)的時候,最怕的就是對某個pattern 無感或有看沒有懂,無法體會其中的奧妙,總覺得把英文翻譯成中文的時候翻得不夠味,因此就造成我們的不易吸收或沒感覺,就這樣地把責任推給了負責翻譯的人。但反觀國人對《三十六計》所謂的計策就完全不會無感了,還記得三十六計「走為上計」的說法嗎? 這是完全不用加以解釋的; 意思就是快溜吧! 所以當我們有機會把經驗變成策略的時候,運用大家耳熟能詳的計策便成了首選。

請務必反過來看它,要請大家用閱讀設計模式的思維模式來看《DevOps三十六計》這本書。請不要用閱讀一般書籍時,哪種時時在揣測作者到底想表達什麼的想法來看它,要以解答問題為出發點,書上是記載著當你遇到什麼樣的問題時,而作者已經遇過了,而且把經驗寫下來了,如果你還看得下去的話,請參考: 我是全書陳列的第二位作者,寫的是精益篇的看板系統思維。接著,

.

16頁.png

可視化是看見全貌的一道妙方

.

我在意的是你「看見全貌」了嗎?

每位作者在書內,就自己的專長或在意的 DevOps議題,作了三十六計計策的論述,至於我的部分;請翻開第16頁,我講的是系統思維System Thinking,這正是我最在意的地方,提醒大家: 在專案開始之初務必先看見全貌,而看見全貌就必須由系統思維著手,方法是由確認真正的問題開始,由於系統本身可能太複雜了,所以必須由問題去規範你所思考的系統這樣才能定的出系統的邊界,把範圍侷限出來,否則怎麼知道要從哪裡下手呢?尤其是遇見越複雜的問題,越需要確認解題的方向。而系統思維便是針對複雜的狀態採用較簡單的原理來詮釋它罷了。

.

當你看見全貌之後,接著該做什麼事呢?

.

我在哪裡?

思考之後便該採取行動,因為光是思考是不能改變任何事情的,唯有行動才可以讓我們更接近目標,但應該從哪裡開始呢? 我以為: 「在開始行動之前,先確認自己在哪裡!」

在接到高效運維社區.蕭總的邀請時,當下第一個反應便是趕緊去 Google一下,傳統的三十六計都有些什麼 …

.

描述.png讓自己圖文對照,避免離題太遠(感謝編輯的一再提醒)

.

我寫的不是三十六計

我想大部分作者都跟我一樣,寫了四、五十計後再回過頭來挑出要交差的36個範式。就是這麼回事,老實說:不寫文言文焉知自己的國學程度有多差,如果你很在意國學這檔事,相信這本書你是看不下去的,把書放下來,挑個輕鬆一點的來閱讀吧!

我的三十六計

一、【本质论】

  • 第一计、DevOps 看板不分家,Dev离不开Ops, Ops 启始于 Dev。
  • 第二计、建制看板:由左而右,解读看板:由右而左。
  • 第三计、看板加快开发速度: 真实显示价值流,务实祛除大浪费。
  • 第四计、WIP据实反应出阻塞。
  • 第五计、实时调整价值流,追求最佳流速值。
  • 第六计、持续调整勤改善。

 

二、【围魏救赵,实质统计可以见真章】

  • 第七计、累积流程可看流程的分析。
  • 第八计、燃尽图标可看进度的轨迹。
  • 第九计、消化需求,拯救这个世界。
  • 第十计、阶段再细分成次阶段,状态就会被呈现。
  • 第十一计、不可控制事项,不画入流程。
  • 第十二计、避免沦为暑假作业:标示工时、开工日,不标完成日。

三、【 调虎离山,实时调整多适应】

  • 第十三计、罪魁祸首是多任务。
  • 第十四计、计算前置时间看统计。
  • 第十五计、调整半成品数尝试流程新速限。
  • 第十六计、调整字段数目尝试新流程。
  • 第十七计、调整显示属性,让工作内容更清晰。
  • 第十八计、调整布置配合季节更合宜。

 

四、 釜底抽薪,勤调整】

  • 第十九计、抢单只为团队更精实。
  • 第二十计、平时互助让交接更顺利。
  • 第二十一计、紧急事件加渠道。
  • 第二十二计、实时更新勿等待,看板引导更顺畅。
  • 第二十三计、值日新生学最多。
  • 第二十四计、众人都来看门道。

五、【 败战计,可视化风险评估 】

  • 第二十五计、风险评估在团队。
  • 第二十六计、学习成长在个人。
  • 第二十七计、看板让项目进度可视化。
  • 第二十八计、个人进度看板游。
  • 第二十九计、盈余时间看个人。
  • 第三十计、拖拉系统更明确。

六、 纵观全局,敌战计 】

  • 第三十一计、系统看板维护佳,系统思维见真章。
  • 第三十二计、看板开发系统,用Scrum来配合。
  • 第三十三计、改善流程靠原则。
  • 第三十四计、落实开发不返工,看板单向移动不向后。
  • 第三十五计、视觉化工作流程,消除浪费最容易。
  • 第三十六计、延迟决策減少错误,系统思维看见隐藏在看板之后的全貌。

 

.

註1.  Eric Gamma 所寫的設計模式書《Design Patterns: Elements of Reusable Object-Oriented Software》書中結合設計實作範例,從物件導向的設計中精選出23個設計模式Pattern,總結了物件導向設計中最有價值的經驗,並且用簡潔可複用的形式表達出來。向四位作者致上崇高的敬意,如下:

  • Erich Gamma博士是瑞士苏黎士国际面向对象技术软件中心的技术主管。
  • Richard Helm博士是澳大利亚悉尼IBM顾问集团公司面向对象技术公司的成员。
  • Ralph Johnson博士是Urbana-Champaign伊利诺大学计算机科学系成员。
  •  John Vlissides博士是位於纽约Hawthorne的IBN托马斯沃森研究中心的研究人员。

註2. 40位作家寫36計 (40 x 36= 1440)

全書應該有 1440計才是,但實際上只有1349個計策。原因是有幾位作家採用合寫的方式,而也有厲害的作家,一個人寫了二篇。 

註3. 如果你立即Scan 上面的QR code 想聽我說書的話,真抱歉! 由於連日的課程,讓我的聲音有一點走樣,給我一點時間休養,會盡快補上。5/19已補上了!

 

 

Written by ruddyllee

2018 年 05 月 14 日 at 10:17:41

張貼於未分類

Tagged with

做顧問需要什麼基本能力

leave a comment »

.

做顧問需要具備的三項基本能力:

.

1.  具有了解複雜情況的能力,你因此能為專案做好事前的規畫,並據此進行觀察及採取行動,以保持專案能依計畫進行,或是敢於去修正原本的計畫。

2.  具有觀察發生了什麼事的能力,並且能夠從行動要有成效而且符合當時情況所需的觀點,來解讀你的觀察所代表的意義。

3.  在複雜的人際關係中,即使你會感到迷惘、憤怒、或是非常害怕,甚至害怕到你想要當場逃離並找個地方躲起來,但你仍然具有做出適切反應的能力

.

 

《 參考自溫伯格的軟體管理學: 第一級評量

參考: 一些人的讀書心得豆瓣讀書博客來連載

.

 

如果你要我為這個瞬息萬千的時代多說些什麼的話,我會加上這二點:

4. 學會如何去衡量萬事萬物,因為有了衡量(measurement)你才能更進一步去了解它,能避免去做過多的假設,能協助你做出正確的判斷,能讓未來的智慧為你所用。

5. 比任何人都學得快一些,也就是遇問題要先能深入的去觀察它,然後給自己做顧問,先教會自己,你才可能去教別人。

 

註:  做顧問需要什麼能力呢?

我已經渡過十多年的顧問生活了,經常有年輕的學子跑來問這個問題:「做顧問需要什麼能力呢?」。我想說;撇開你得想辦法養活自己、或許還有家庭之外,上面這幾點是你可以持續訓練自己的功課。加油!

.

Written by ruddyllee

2018 年 05 月 04 日 at 16:52:54

累積流程圖 Cumulative Flow Diagram 解密

leave a comment »

.

累積流程圖是用來描述工作是如何在系統中移動的圖示。

.

累積流程圖

一個真實世界的累積流程圖(PP: prepare production)

上圖顯示了隨著開發時間的推移,團隊在每個階段所進行的任務及消耗的時間。水平軸的單位是時間(Sprint日期),垂直軸線則是工作量(一般為故事點)。在Kanban Tool 網站上有一張手繪的累積流程圖,但一般建議不要用手來繪製,應該交由電子看板作自動呈現。下面這張圖看起來很專業但完全不推薦這麼做。

.

手繪累積流程圖.png

Kanban Tool 網站上有一張手繪的累積流程圖

.

他是一張極簡單的工作軌跡圖示,但卻能讓我們看見團隊在專案開發過程中的使用者故事完成的狀態,是一張流量圖,線與線之間的垂直距離,就是故事在欄位裡停留的期間,在這段時間裡它就是半成品(WIP)。

半成品的定義

Work In Progress,縮寫為WIP,又可寫為goods in process,in-process inventory,又稱為在製品,是尚未完成製造過程的商品,或是停留在庫存倉庫或是生產線上,等待著進一步處理的商品。這個術語常使用在供應鏈管理上。在軟體開發上,只要開始工作的任務,在尚未通過QA認可移入完成欄位的開發工作就還是「半成品」。它代表著一種浪費的指標,越大越浪費,也就是生產的效能越差。(WIP的值越大,就表示開發的 Lead time 越長)

.

信息輻射.png

這是我在GOPS 大會上的演講資料(原作是Pawel Brodzinski)

.

信息輻射: 所指的是輻射信息,也就是這張圖給你的第一印象,你在看的時它自然釋放出來的是什麼樣的訊息。

 .

累積流程圖解讀

上圖中有10個現象,畫成這個樣子好像誇張了一點,但相信我只要你繼續待在這個圈子裡,早晚會遇到的。請問;閱讀累積流程圖應該從哪裡看起呢? 這一點和我們看看板是一樣的,要先從它所表現出來的輻射信息開始。上圖中很明顯的「瓶頸」應該是我想刻意表達的(但在演講廳裡,第一個回答的人沒挑那個很明顯的黑圓圈!)

當累積流程圖上面的各個線條都能夠保持常態的間距,就表示開發工作都能在看板上順暢的流動。若是有糾結(kink)的線條則表示出開發作業出現瓶頸了,我們可以透過持續觀察線條的呈現狀態,來追蹤開發作業是遇到瓶頸卡住了呢,還是工程師遇到連續假期讓進度變慢了,便可以思考如何運用調整WIP的數目限制來改善作業狀態。

.

累積流程圖_stat.png

A: 線條有放大的現象,B: 線條有趨近的現象。

.

 調整方式:

》當有二條線有放大的現象時,表示WIP值要變大了,也就是應該要投入較多資源來協助開發。反之;

當有二條線條有趨近的現象時,表示WIP值要減少了,也就是應該要調降投入的資源.

.

累積流程圖_0

上圖中,BC線段顯示出當前每個步驟裡正在處理的工作數目。而水平線條AB則是它們共花費了多少時間。當垂直線條的間距變大了,表示需要花去更多的時間(lead time 變大),也就是當前的開發速度變慢了,若其中有線條靠得很近時,則表示上面的作業追上下面的作業了(若是出現的是開發追上測試的欄位,則表示測試即將變成瓶頸。若是出現的是測試追上完成的欄位,則表示作了一堆小功能,沒太多可測的工作)

.

lead timeLead time 的趨勢圖

.

由lead time (也就是由需求故事被放入待辦事項欄位開始,一直到它被開發完成為止總共花費的時間稱之),上圖中;我們取每三個點的平均值來連接起來,就能看到Lead time 的趨勢線,便能夠預測接下來的開發工作有可能花費的時間了。當WIP值變大時,Lead time 就變長了,因此我們應該追求最小的半成品WIP的極小化。

 .

看板是一個持續改善的依據

由於看板能夠忠實記錄開發的過程,所以我們能夠透過持續觀察累績流程圖上線條的走向(趨勢),然後依靠它來決定如何進行調整的動作。舉例來說:當我們觀察到測試與完成二條線之間的間距有漸行加大的現象時,這表示: 測試作業的時間加長了,有可能會成為發布作業的瓶頸,這時候應該將WIP值加大,也就是投入更多的測試資源,解決之道可能是請測試人員將工作明確的切分出來,然後可能就是請團隊中的開發人員協助投入測試工作,來加速測試作業。

.

結論

實踐看板的三大步驟: 視覺化流程、WIP控管、流程管理。一般的使用者都停在第二步;也就是WIP的控管上。原因很簡單,因為WIP很難設定。設值很容易,但卻始終無法體驗到設定了的WIP值到底有什麼影響? 也就是一直試不出來WIP的影響。怎麼辦呢? 解決方法是去看累積流程圖,從記錄的曲線去看趨勢的走向,想知道調整WIP就能神奇的轉變流量嗎? 答案是;除非你看到了WIP的邊界值,否則你會始終感受不到設定的意義的,也就是調來調去都沒有特別的感覺。一種好的做法是: 配合WIP的趨勢去調整人力資源,而不是只有調整WIP值,去等待變化。這才是務實的做法。試試看吧! 很快你就能看到效果了。 範例:

.

累積流程圖_ab

由累積流程圖看開發流程的趨勢

.

設定WIP來改變趨勢走向

我們應該善用顯示在累積流程圖上頭的數據,不只因為數據可以讓我們看見過程,更可以看見趨勢,而WIP的調整正是用來調整流程的流動趨勢的。累積流程圖上線條的走向,劃一條垂直線就是開發作業在幾條交叉線之間所停留的工期,也就是 WIP值。由上圖中,4/12到4/13的開發過程,A點的數據Doing的WIP值由 8 提升到B點的 12,也就是 Lead time 變大了,原因可能是團隊正在開發一個較大的功能,所以開發時間就變長了。這段時間維持到 4/19 號,WIP值開始下降了,到 4/20 回復正常。所以測試欄位的 WIP值最小值是3,而Doing 的WIP值最大是E點的15。

反過來檢討;我們在遇到B點開發作業的WIP急遽增加時(8 增加到12時),可以發現是否遇到較大的開發功能了,該如何調整人力來縮短這段時間呢? 也就是要如何來縮短 4/12 到 4/20的開發負荷才能讓團隊維持在正常的產能。做法可能是找到合適的工程師來開發這項耗時的功能,或是把這項功能Breakdown 成更多細部的項目讓團隊發揮力量一起來運用分工的方式來克服它,這就需要視情況而定了。

.

.

註1. Kanbanize 的CFD 教學影片

註2. 上面圖示均採用 VSTS所產生的累積流程圖及 Lead time 圖示.

註3. 很多書上有另一種速率的度量方式: 也就是以開始點的WIP值為準,形成一種倒三角形的計算方式,立意是以開始時的半成品數為基準。我個人傾向以完成點的WIP值為準,也就是以完成時的半成品數為基準做計算。不論你選擇那一種方式,主重點是不要混用,只採用一種固定的計算方式,數值只是一個参考比較的指標,別忘了相對的意義重於精確的數據,重點是提供持續改善的指標。

another.png

.

Written by ruddyllee

2018 年 04 月 23 日 at 11:33:56

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

leave a comment »

為何半成品數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

 

 

 

Written by ruddyllee

2018 年 04 月 18 日 at 13:49:04

張貼於未分類

Tagged with ,