DevOps的開發方法 – 看板驅動開發
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
二個重點是； 極度訊息透明: 共同意識。 去中心化: 賦能。
.
.
.
.
.
.
.
.
颱風報導是監控與持續度量的極端展現
.
但結果卻往往出人意外
.
.
.
.
.
.
.
其實需求更需要 Pull Request
.
.
.
.
.
.
.
最好的回饋是能在問題發生之前提出預警
.
.
.
.
.
.
整理過的數據，一定要運用不同的視角在整理一遍
.
讓效能成為適應性的後盾
.
.
團隊經常會淪陷在追逐故事點的迷失之下
.
.
.
無論如何一定要嘗試用不同的視角來審視你所整理過的資料
.
.
讓開發作業更透明，因為工程師總是在開完站立會議回到自己的座位繼續規劃工作
.
.
.
註 : 《加速:精益軟體和DevOps的科學:如何構建和擴展高性能的技術組織》一書，為 Nicole Forsgren, Jez Humble, Gene Kim 的共同著作。它對 Puppet & DORA 的年度報告做了充分的詮釋。
DevOps 三步工作法: 第一步 流動
.
第一步是追求組織日常作業的高效能
.
DevOps 三步工作法第一步：流動 FLOW.就是追求快速，從提案成立一直到交付到客戶手上的時間，就是要快。但這其中的障礙是你必須先克服:
有一些你自以為不可能作到的事! (其實是心魔在作祟 …)
首先是； 實行 測試開發法 TDD
你會說：對不起；專案實在太趕了，跟本沒時間作TDD(我們甚至連單元測試都省略了!) 然而，專案從來就沒有不趕的時候。你會說新人實在太多了，沒時間做教育訓練，這一點就讓人想到伊拉克戰場上的霧卡VUCA理論，部隊裡總是有一堆沒經驗的菜鳥，但戰爭還是得打下去啊，等你訓練完了，可能也就不需要了，要知道敵人的情況也是一樣的。永遠沒有最佳時機點的。
.
再來是；《持續交付》書裡頭的流水線
這就比較複雜了，我們由整合開始談起吧！把資源都集中到Git是第一步，這個不難，難在你作 Trunk base development 了嗎？ 你會說：不可能的，我們的團隊分工很細，除了前後台之外還有各種 Devices 的 App要處裡，不可能作到的。但信不信由你，Google 有 13,000 開發人員在一個程式庫裡，同時這麼做著。
.
接著是；自動化測試後自動布署
這就更有意思了，如果「開發環境 ≠ 測試環境 ≠ 上線後環境」的話，誰敢直接布署呢？（你會說：對我們所在的這個行業而言，就是不斷的在跟客戶進行互動作業，要做好 sandbox 開發環境，這是完全不可能的事…)
.
常常被問道：『敏捷化；到頭來也就是處理人的事情吧？』
我的回答總是肯定的：『是的!』
.
如何做好DevOps的三步工作法呢? 打開心魔是第一步。
「勇氣」是第一道障礙，「決心」則決定你可以走到那裡？
其實；對許多公司而言，都早已作到上述的事情了，而且這只是基本要求，不要懷疑？！別跟我說你沒聽過「搗蛋猴」了！這是化被動為主動的代表，又稱為故障注入Fault injection！你敢嘗試嗎 …
.
用來追求線上極致的運維服務作業(2016 就到2.0版了)
.
後語
DevOps 三步工作法的第三步 持續學習與實驗，正是要用來打破這種因為對系統太過熟悉而預設立場的思維方式。因此要想做好 DevOps 必須先能 打開心魔 才是真正的起步。
.
看板方法入門
.
中間是David J. Anderson 所著的看板聖經(註1)，左側是我補充精實原則的參考書籍
(照片是與DevOps 之父Patrick的合影，拿來鼓勵年青人要與世界接軌的)
.
從一個你一定會遇到的問題做為開始
.
這是女兒實際發生上一張圖情境時，我教她如何畫看板的草稿(珍藏版).
.
請試著解讀圖中 1~10 的看板基本元件.
(1)站立會議三件事. (2)燃盡圖. (3)Scrum 三大支柱 . (4)老闆要在站立會議結束後才能講話. (5)工作單該包含哪些屬性. (6)緊急事件要加開取渠道. (7)運用人名來設定渠道是一種剛開始時的好方法. (8)看板是單向的工作流. (9)在欄位內再去劃分次欄位，可以看得更清楚. (10)回顧會議是團隊學習的重要會議 .
.
Todo – Doing – Done 是最基礎的工作流程，也是最簡單的開始.
.
當你站在看板前面時，第一件事是先關注它的輻射資訊，再來就是依據精實原則來對他品頭論足了!
.
.
年輕的工程師，較難議會這一張圖(也就是對產品的業務價值沒有感覺)
.
對上一張圖沒感覺，對精實的七大浪費也就不容易體會了
.
沒有設定 WIP 值的板子就不是實行看板方法(David J. Anderson)
.
看板以簡單著稱，但卻有著深遠的改善內涵
.
在每一個價值流的過程中建立回饋機制
.
.
.
不要急著開始改善，先幫工作人員減低負荷才是好的起步
.
忙碌的團隊事很難接受任何變革的
.
定義半成品的正確觀念對團隊至為重要
.
.
一個解Queue的範例.
.
.
.
學會如何看累積流程圖，你自然能夠意識到 WIP的妙用
（這張圖對初學者而言，太複雜了些，可以考慮移除）
.
.
.
{
總是會有學員在這裡提出問題來問要「如何運用看板來增進個人效能呢?」
所以這裡補上；一個人如何實行敏捷!
}
.
.
.
工作時能明確區分重要跟緊急的事，是提升工作效能的前提
【課後心得】
上面的教材顯得華麗而深了一點，因此沒能按步就班的教導新進人員弄懂這些道理，造成教學的效果不佳。如果要拿來作新人訓的話，當發現這個現象時應該即刻改換成比較有互動性的方式來進行。例如：讓他們發表在看板前進行站立會議的心得或是評價一下目前團隊進看板的效果，由一些實務面來引導看板的初學者或許會更好一些。
.
註: 這份資料是給公司新進人員的「看板方法」初階課程，時間是 2小時。
1. David J. Anderson 所著的看板聖經《看板方法:科技企业渐进变革成功之道》
2.《精實開發與看板方法》 by: 李智樺
DevOps 實踐指南 : 變革管理
.
組織轉變 – 變革 Change Management
.
我遇過幾次大的變革，英文寫起來輕鬆多了change management，但沒有輕鬆這回事。有從130億的大公司轉變成35億的變革，也有從上千人的公司轉變成數百人的公司的變革，這些年來即便我是以顧問的位階参與組織的改變，但我總覺得自己從沒有看到過變動的全貌，甚至是事後來自報張雜誌上的描述我都沒辦法分辨真假，也習慣把不能了解的原因推給自己不是核心成員,因此看不見內幕、不知道是誰、為何做成那樣的決策，又怎麼可能看見全貌呢？！
旁觀者清
但其實是當局者迷，旁觀者清。例如:我嘗試把英文版的DevOps Handbook 5～8章專講變革的部分節錄下來傳給他們(正在進行變革的主管)参考，但總是沒有獲得好的回應(現在可以傳中文版了，結果一樣沒反應)，想想；實在不能責怪他們，人們總覺得必需靠自己想清楚了變革才會成功，而書本上講的只是原則，實際上沒那麼簡單，等過了這段渾沌的時間後再來看吧！但其實不是這樣的…
用價值流Value Stream幫你看見全貌
變革之初；要先畫出企業引以為生的產品或服務的流程圖來，它可以幫你看見全貌。運用可視化的方式來看清楚自己是怎麼運作的，畫出來的價值交付過程的圖示就叫作「價值流程圖」value stream diagram. 這不是什麼新技術，Toyota 用它來調整工廠運作的生產線效能已經很多年了(註1.)。OK，畫出價值流之後呢? 也就是當你客觀的去面對自己團隊的工作流程時，接下來該做什麼呢?
.
選擇合適的「價值流」作為切入點
.
本書最重要的一章，就放在概述完三步工作法之後
.
用來判讀「企業效能」的流程範例
( 效能: 企業都不能忽視的地方)
.
二種團隊的轉變方向: 「職能導向與市場導向」圖示
.
書中屢次提到的 Puppet Lab Report
(DevOps Team由2014的16%進步到2017的27%)
.
顯示企業效能的4個重要指標
.
驗證 Robin Dunbar 的 150人上線法則
.
註1. 企業面臨轉型時（re-organize)傳統的作法： 先擬定方針再規劃過程最後才決定執行的程序，由這三方面來考慮鋪成細節。現在的組織則說動就動，步調變快了，往往疏忽了許多細節，但更見勇氣可嘉。
2.價值流其實是多維度的，而價值流的描述或是應用的工具卻多是線性的，這一點經常為人垢病，但把它視為抽像化的結果卻可以讓我們看得更清楚些，也是值得的。
流程改變參考書籍
《過程改進手冊》by: 特里斯坦·布特羅斯
《组织变革管理》by:伊恩·帕尔默
.
DevOps 實踐指南 : 介紹篇
.
.
簡化目錄章節可以看見內容的全貌
.
DevOps實踐指南的用戶故事地圖
.
作者想要交付什麼價值給讀者
.
從觀念概述開始說起
.
由理論及參考書籍可以想像到內容
.
註. 無疑的《DevOps實踐指南》是DevOps技術實踐的最高指南手冊(共346頁)
第二部分談的是變革 Change Management，也就是談企業轉型到DevOps的實務轉換步驟。俱有相當的參考價值: 在這裡，一掃《鳳凰計畫》缺少實踐實務的陰影(下回再介紹)。
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. 比任何人都學得快一些，也就是遇問題要先能深入的去觀察它，然後給自己做顧問，先教會自己，你才可能去教別人。
註: 做顧問需要什麼能力呢?
我已經渡過十多年的顧問生活了，經常有年輕的學子跑來問這個問題:「做顧問需要什麼能力呢?」。我想說；撇開你得想辦法養活自己、或許還有家庭之外，上面這幾點是你可以持續訓練自己的功課。加油!
.
