DevOps 三十六計 解讀

.

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

.

儘量延遲決策  – 我的第36計

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

.

.

模式 Pattern與計策Stratagems

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

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

.

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

.

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

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

.

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

.

我在哪裡?

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

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

.

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

.

我寫的不是三十六計

我想大部分作者都跟我一樣，寫了四、五十計後再回過頭來挑出要交差的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已補上了！

 

 

廣告

做顧問需要什麼基本能力

.

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

.

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

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

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

.

 

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

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

.

 

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

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

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

 

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

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

.

累積流程圖 Cumulative Flow Diagram 解密

.

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

.

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

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

.

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

.

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

半成品的定義

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

.

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

.

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

 .

累積流程圖解讀

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

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

.

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

.

 調整方式:

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

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

.

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

.

Lead time 的趨勢圖

.

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

 .

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

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

.

結論

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

.

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

.

設定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值為準，也就是以完成時的半成品數為基準做計算。不論你選擇那一種方式，主重點是不要混用，只採用一種固定的計算方式，數值只是一個参考比較的指標，別忘了相對的意義重於精確的數據，重點是提供持續改善的指標。

.

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

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

.

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

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

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

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

David Lowe 的麥當勞點餐影片

.

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

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

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

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

.

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

.

怎麼設定WIP值呢?

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

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

垂直軸是工作量，對數位看板而言是故事點的多寡，水平軸是時間，一般是以日期來劃分。如果不做換算成時間的話，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

 ( 單位: 故事點/ 日期 )

顯示各個欄位有意義的 WIP 值

怎麼定 WIP值呢?

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

.

WIP出現最小及最大值

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

.

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

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

(於英文版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

 

 

 

看板驅動開發（KDD）

看板驅動開發（KDD）的目的是在運用看板來透明化工程師進行程式開發的過程，讓工程師看見自己是怎麼進行開發工作的，並依據記錄來分析自己的開發工作是否有足夠的效率，作為增進效能、持續改善的依據。

.

運行工程師實際工作的看板

.

這麼作的原因是：

一、我們經常可以看到工程師在團隊站立會議之後，回到自己的座位上便開始進行一天的工作規劃，他們會用便利貼安排好一天該作的事，然後貼在自己個人的小看板上，開始他們在上班期間的工作。

》這個現象說明了工程師在上班期間不是只有作他在團隊看板上所認領的工作！其實還有許多事情都會佔據他的上班時間，而這些事在大看板上是看不見的，而這類的非開發工作，敏捷開發的因應之道是要求工程師盡量把這些工作之外的事務維持在工時的15%以內，盡量不去影響開發工作便可以了，但實際上；這是一種模糊不清的做法，對看板方法而言是一種不良的假設。

(我常常被工程師問道，這便是個人看板嗎？註1.）

這也是目前在一般團隊在運行看板時最不明確的地方，因為我們常常假設工程師每天都能擁有足夠的時間去進行開發作業，忽略了許多會消耗掉他工作時間的額外工作，例如：開會、協助解決問題、與他人進行溝通、處理緊急事件等等事情，都會大量的消耗掉工程師的上班時間。敏捷的一種解法是在估算的時候，以一個理想的工作日來作範圍的調整（例如在VSTS上頭，把一天設定成5小時）這麼作雖然給我們很大的彈性，但也隱藏了許多真實的工作事項，讓我們看不見事情的真貌不知道要進行改善，這一點很不符合精實Lean的精神。

二、工程師可以運用 KDD來分析自己一天的時間都用到那裡去了，藉此作為改善效能的依據。有一種現象是工程師不管再怎麼忙碌，但總能夠在第二天準時完成他的工作，他們常常會在不到二個真正工作的小時裡卻能完成超過四個小時的工作(Tasks)，也就是二倍工作量的開發任務。當然原因可能是因爲他加班了，或是把工作帶回家去作了，但不論如何我們都需要弄清楚真正的原因，因為只有如此才能作為任務評估的真實依據，否則將始終看不到事情的真實樣貌。（主管如果把這種狀態視為是一種合理的現象，這種誤解往往會造成員工不能理解或不願配合公司策略的因素之一，因為它是不正常的，不該忽視它也不能鼓勵，大可私下稱讚一下他的負責盡職精神就好，實在應該找出原因避免重複發生）

 .

 

KDD是自我改善的依據，換句話說就是給自己看的

要先看見問題才能改善。過往寫程式的過程，就是坐下來coding就是了（當然你可能運用 TDD來加強邏輯思維的審密性或是配合團隊採用 BDD的coding模式來兼顧程式的品質），但總覺得好像少了些什麼，效能不夠沒看見全貌。這就好像跑步一般，一個簡單的計時器，能讓你知道自己的速度在那個區間裡，一段柔軟操能讓你一路不抽筋直到終點，小小的紀錄都能對跑步的成績有著巨大的幫助。而KDD就是這麼來的，試著想想看你要從那裡開始改善自己coding 的效能吧！但基本上還是先從客觀的看得見全貌開始，先看見自己一天工作的全貌，認知到自己在那裡，接著再來探討那些是需要改善的。

.

開發工作應該以達成任務為目標而不是依靠估算來作為完成工作的統計依據，所以必需以度量為基礎。

.

 

如何開始運行KDD呢?

先從看見自己的工作流程開始，然後把它紀錄下來，用 Trello 或 Bitrix24都行，重點是要有數據才能進行分析，要有看板才好調整WIP來進行改善作業。

 

.

在座位旁的牆壁，用便利貼試著開始運行KDD

.

找一個在座位旁的牆壁，或是買一塊小板子也可以(最終還是要數位化的，小板子可以維持紀錄著一、二天的進度)，給出透明度讓大家都知道自己在做些什麼，數位的紀錄則很像跑步計時的馬錶一樣，是給自己參考的，只是拿來做改善用的(累積流程圖的展示價值會出乎你想像的好用的)。

你都有些什麼工作?!用不同顏色大小的貼紙來表示工作種類及耗時。甚至用特殊符號來展示你在進行工作時的心情、進度如何都OK。就照著實際來的工作忠實的記錄它，一開始先用「待辦 – 進行 – 完成」的最簡易看板作開始, 隨後在視需要進行調整。重點只有一個，就是忠實記錄，原則也只有一個就是維持單工作業，遵守作重要的事而不是作緊急的事(參考: 一個人如何施行敏捷)。用最簡單的方式來養成習慣，因為只有養成習慣才可能持之以恆。所以先設計好流程養成習慣，之後就容易持續下去了。

.

.

 

調整工作的比例

試著用比率的方式來看待你的工作項目，因為時間是固定的因此你唯一可以做的就是按比例來分配，然後給他們設定一個目標值，一個讓你覺得適合的比率，並在一段時間後來作回顧，這種作法可以幫助你掌握自己，同時又能增加自己的適應性。

 

.

工作項目的心情歷程圖

.

我很喜歡上面這個圖示，它讓人一目了然自己的厭惡及喜好，人應該要盡量忠於自己的感受。心情歷程圖讓我們知道要多做一點上面(高興區間)的工作，少作一點下面(困擾區間)的工作，上班時就會覺得幸福些。（這一點可以作為給公司的回饋）

 .

企業存在的意義有兩個：一是為社會創造幸福，二是為員工創造幸福。

– 智庫百科

.

學習是追求幸福的捷徑

寫程式本來就是一種學習的過程，而學習可以讓人心無旁騖專心沉浸在解題的過程中，事後又能產生高度的成就感(怪不得工程師常常會說，與其去參加無趣的活動，我寧可留下來寫程式)，而敏捷所推行的學習型組織，正是一種最穩定又高效的組織型態。但學習確實是需要借助外在的因素的，KDD 可以幫你看見自己工作的歷程，而不是盲目的任憑感覺來模糊的作改善，依據看板真實的記錄來讓你作為行為改善的依據，自然能更為有效。

.

 

註1. 這便是個人看板嗎？

嚴格的說；不是的，因KDD只包括上班時的工作時間，而個人看板理論上應該是24小時的，也就是還包含其它事項，例如: 家庭生活、個人生活、還有興趣 . . 等。

 

需求與產品開發中的價值

.

抱怨團隊的開發速度不佳 …

.

需求的業務價值決定產品的開發價值

.

需求排序與價值的對照，滿足客戶的要求

.

需求排序與價值的衡量，決定敏捷合約

.

敏捷合約以度量業務價值是否達成為依歸

許多執行scrum的團隊仍然以將描述需求的用戶故事全數作完，專案才算開發完成，而不是以達成使用者的需求也就是達成足夠的『業務價值』為驗收的準則，這一點很不敏捷也浪費了許多開發團隊的戰力來作一些低業務價值又客戶很少會用到的功能，解決之道是以度量為主，我們可以運用「影響地圖」作為簽約時的度量依據。

.

運用影響地圖進行度量

.

註: 需求的柱狀圖形來自《Essential Scrum》

衡量: 讓紅黃綠燈更明確化

紅綠燈的顏色是世界共通的，不論走到哪裡都是『紅、黃、綠』三色。(英文用的黃色是 Amber 琥珀色，所以紅、黃、綠簡寫成 RAG.) 採用這三種顏色的理由是，因為對人類而言，最容易辨識的顏色依序是紅、黃、綠的緣故。顏色有隨著光線減弱而不好分辨的傾向。而紅色不管多遠、多小，依然可以清清楚楚的看到，而且從進入眼睛的光、傳入腦中的速度也以紅色最快，所以拿紅色來做警示訊息最洽當不過了。

 .

{ 紅綠燈最初問世是在1868年，是在英國的西敏寺使用紅綠兩種信號裝置。三燈式信號機則首見於1918年於紐約啟用的手動裝置；日本則是隔年的1919年在東京的十字路口利用紅、綠色板的手動式機械燈號，台灣是在1940年中山北路上設立了第一個紅綠燈。 }

.

須先取得團隊對燈號的明確共識，以避免誤判(draw by Gina Abudi)

.

專案開發的紅黃綠燈

用燈號標示狀態，來關注它的風險，具有淺顯易讀的效益。聽起來或是看起來都似乎很容易又好用，在看板上也容易表現出來。一般的解讀是，「紅燈」拿來表示有重大問題發生了，專案時程可能會因此延誤或超出預算，需要我們立即的關注。「黃燈」表示有出現問題的可能性，需要開始關注它了。「綠燈」表示一切按照預期，沒有脫軌的現象。在運行看板的時候，我們常會在無法控制的工作卡片上，用標註燈號的方式來顯示它的狀態。(例如一些委外開發的工作項目，比較困難取得即時的資訊，就採用亮燈的方式來做風險管理。)

.

簡單但不夠明確反而容易造成誤解

顏色容易隨著亮度的不同而造成誤判。虛擬的顏色則容易跟隨著描述者所採用的詞彙而造成聽者的不同詮釋。例如:在看板的站立會議上，最怕出現QA人員描述最近的Bug必較多要亮黃燈了，提醒大家要注意品質。聽起來沒什麼問題，是QA人員在報告時，提醒大家要多注意品質，但這種描述的方式對透明度並沒有幫助，反而容易造成誤解，工程師可能解讀成「QA對我們的品質感到不滿」或是「我們害了QA人員需要加班才能完成測試的工作」。若以明確化為目的；較正確的說法應該要透過數字來的作報告，譬如:「 昨天Bug的解決比例是5/15，新增15個Bugs解決5個Bugs，品質亮黃燈。用這種方式來陳述事實而不帶容易讓人誤解的形容詞」。

.

站立會議作報告時；應該盡量提出可供衡量的數據，讓會議的內容更明確化。

.

燈號在加上數據的陳述

.

適當的加入度量值

估算只是估算，基本上只是對未來即將完成工作的一種預計性時間的猜測。在沒有做完以前實在很難做成比較明確的度量，但如果因此而不去做衡量，就失去修正、改善的機會，犯了不敏捷的錯誤。

.

衡量Measure；只要能让你知道得比以前多，就是一项成功的衡量

.

追求敏捷化，我們需要知道得更多一點點
只要能夠獲得比以前多一點的訊息，就是一项成功的衡量。大家都知道傳統的開發方式就是做了一個最大的假設，假設我們能在專案一開始就把所有的事都想清楚的前提下，而犯了最大的錯誤假設，為了修正它，敏捷便以小增量、多個迭代的方式來取代它。至於，有什麼方法能使我們更敏捷呢? 那就是運用衡量measurement 來設法去減少假設跟猜測。至於要衡量什麼呢? 如何來衡量呢?(請參考，註1.如何衡量萬事萬物. by 道格拉斯‧哈伯德)

三件我們必須做衡量的事:

• 不確定的事 – 為了做成決策，必須先做些假設的事

• 有風險的事 – 我們害怕會出問題的事

• 對訊息的判讀

.
衡量很難嗎?
為什麼要做衡量? 衡量的目的是減少風險，面對假設。因為敏捷很務實，不做太多假設，要做到這一點，要減少假設，只有透過度量的方式才能對一些訊息明確化。哈伯德教我們要做衡量:「宣稱萬事萬物沒有不能衡量的」。第一次聽到這句話時，你可能不以為然，但是如果你拿Bill Burnett所著的《Design your life》(註2. 為比爾‧柏內特與戴夫‧埃文斯所合著，是教人如何運用設計思維來設計生活的書，獲5顆星級亞馬遜圖書)裡面對你人生的衡量或是對個人健康、愛情的衡量方式，也就是拿狀態表的方式來作衡量，是不是就不會太排斥了呢(看起來是不是很像紅、黃、綠燈的形式，只是它多分了一份，我個人偏好使用5等份的評估方式)?

對愛情做度量的狀態表

.

》請避免黃燈效應；影射人們在遇到需要下決策時，停下來觀望做了拖延的動作，也就是錯失良機的問題。在公共交通管理中，人們常常見到這樣的標語或口號：“紅燈停，綠燈行，黃燈亮了等一等”；“一慢，二看，三通過”；“寧停三分，不搶一秒”等。由此就產生了對決策過程中人們冠冕堂皇進行拖延的一種形象比喻－－黃燈效應。

.

什麼是好的度量

會改變行為的度量，才是好的度量

 

.

結論

請把衡量拿來當成減少不確定性、優化問題的有效手段. 這一點應驗了管理學之父. 彼得·德魯克 Peter F. Drucker 所說的: 「如果你不能衡量它，就不能管理它」。我們拿公司的老闆來做比喻，你可以相信所有做老闆的人心中都有一把尺吧! 他拿它來衡量整個公司、所有有關的事物(怪不得做老闆的人都容易失眠)。 我們若把衡量放到敏捷開發裏頭來，前提是針對系統而非個人所進行的一種度量，它減少了許多的猜測，撇開了那些沒必要的假設，它讓我們更容易看到風險，也務實多了。(度量跟衡量被我混為一談了，原文是measurement)

.

from Peter F. Drucker 

.

註1. 書: 《如何衡量萬事萬物：大數據時代，做好量化決策、分析的有效方法》，作者: 道格拉斯‧哈伯德。這是一本麻省理工學院指定教材，長踞亞馬遜網站商業類暢銷書榜，為一生受用的衡量技術！

註2. Bill Burnett所著的《Design your life》，史丹佛大學最夯的生涯規畫課圖書，中文書名: 

做自己的生命設計師：史丹佛最夯的生涯規畫課，用「設計思考」重擬問題，打造全新生命藍圖 (Designing Your Life: How to Build a Well-lived, Joyful Life)