Google Drive
Gist
Clipboard
共筆從這開始
這兩天大家都聽了很多，像是昨天 Paul 説他們團隊可以一天一個 release，所以研討會帶給大家很多焦慮
萬一剛好我的老闆也在場也聽到了，就下令了研討會東西要帶回去實施下去，回去把一天十個 release 實現起來，就是個焦慮要怎樣做
更慘的是我的企業有很多規矩，但我們又不像 google，辦不到怎麼辦？很多事要做又不敢或是不知道怎麼做怎麼辦
＝>非得做點什麼症候群
只有組織調整是遠遠不夠的。
＝>到底要怎樣才行？
這本書不是要給大家焦慮，而是提出三個方法，讓大家可以順利化解這些焦慮
用另外一個角度分析三步工作法，關鍵要素，用存量增量流量來講，順便蹭一下熱度。
用一些因果關係來串連一下。
如果把要素串連起來，各位得到好處，萬一組織很難達到第一個要素，可以從因果關係得到施力點。此路不通的話，就從旁邊的路去打通，就可以減輕我的焦慮。
因為人生在世常常不得意，失意的事情十之八九，別人要我做的事常常都做不到，但我走其他路可以更快樂。此路不通但有別得路可以走。
不保證這場會講的跟這本書完全一樣，但會差不多。
之前在食品加工業擔任部門經理
製造多層牛肉漢堡(不對吧，是在另外一個M吧)
都沒有人笑！是怎樣ＸＤ
內梗太深
(TSMC??)
之前跟一個 CEO 聊天他說只有台灣人知道什麼是多層牛肉吉事堡，…公司說不能直接說公司名字。
三步工作法，看起來更像是三種指導原則。實際上不是step。
沒有強調一定要按照一、二、三的順序去做。
有沒有什麼軟體設計的時候只希望他運作五年就淘汰。
沒想到他活了46年還被 active used。
有沒有想到是什麼軟體？
老高：關於這點，我們以後會幫大家專門做一個視頻來講解
（距離地球最遙遠的人造物，航海家1號 | 老高與小茉 Mr & Mrs Gao 大概1'30''左右）
1977年的軟體到現在還活著，還可以在這麼艱困的環境，軟體還可以work真是人類的奇蹟，所以我們食品加工業的…還真是奇蹟。
新聞 ：45 歲還能工作！NASA 延長航海家 2 號儀器 3 年壽命
內在品質，存量(stock)
如果『內在品質』是一個可以計算、可以加減的數字
可以用蓄水量來表示軟體的品質，會隨著時間慢慢地流失
品質不是一個固定的常數，隨著時間流逝，若動力變弱電池失效，任務改變，根據熱力學第二定律，遇到外力衝撞，品質會下降。
品質如果會下降，要怎麼讓品質改善？
要靠 debug 去改善。
就像一個大水缸，品質就像是水量。
用以下方式來比喻三步工作法
隨著混亂跟不確定性，工作流程會歲著時間低迷直到失效。
環境的變化、硬體的老化、古老的程式語言等等
不是我們做錯了什麼事，是外面世界的變化
軟體不做錯事品質還是會慢慢衰退。
軟體被使用就會被修改，所以必須得寫的可以被修改！
每次的修改不一定是完美的修改，可能會造成結構的損害，暴力修改，會流失軟體品質
當我們遇到問題時，都希望可以修改解決問題，急就章的解決
讓問題慢慢變小變少
可是我們只做了quick fix會破壞軟體內在品質，會讓內在品質變差，會增加 issue raised。讓問題發生機會增加變成惡性循轉。
幾年前有聽過我開的系統思考的課，就知道這是飲鳩止渴
Legacy code是因為大家對軟體品質不重視。認為重要的事軟體可以正常工作，但這是錯誤的認知。我遇到最快的工程師，特別注意讓他們的程式碼容易維護，不會因為不顧品質而加快速度。他們抱持高品質，才能保持快速寫程式。
結構健全、容易維護，軟體的品質好，才會好維護。
高品質是個關鍵存量，才能維持軟體品質可以。
現在切菜是在說切割對吧？ 記得PM機台就好，不然要被higilight。
關鍵存量：要常常注意軟體的內在品質
關鍵流量：refactoring aggressiveness, 不只是 code，連工作流程都要 refactor
所有的需求要取怎樣探索，怎樣讓東西搞清楚才下去做，流程也是軟體品質的一部分，高檔的軟體研發人員要關注品質也要關注花力氣在讓你品質更好的事情上。
比日常工作更重要的就是改善日常工作
持續改善。把焦點放在工具跟組織架構上很簡單，但這些東西遠遠遠遠不夠啊。
看到上課的學員寫出這樣的文字：
我們工作太忙了，不適合持續改善
要研發新的功能，又要改善，時間根本不夠… by 基層工作者的抱怨
管理者如果知道不持續改善就是飲鴆止渴的話，應該要刻意把資源放在管理流量上。
管理者不知道這樣事情，要下意識的要把資源放在最下面的那一條流量上面去改善。
查看 backlogs 觀察哪些比例是研發、bugs
解法一
解法二:
重點是關鍵存量是內在品質，關鍵流量。持續改善、持續學習、持續實驗
重要精神是品質，跟refactor的積極度。
若把他用CLD（casual loop diagram 剖析因果關係）方法簡化的話，長期主義->內在品質
Devops 是一種尋找瓶頸的方式，甚至是一種在公司更高層次上尋找的方式
REF: DevOps Handbook ｜打造世界級技術組織的實踐指南, 2/e
希望讓所有浪費跟困境都更容易被看見 - observability 可觀測性
讓系統的可觀測性變好才能找到瓶頸
盡量讓暢流損失的程度少一點，要怎麼做？
code review 每次如果都要一千行怎麼可能看得懂？在製品太大就會流失掉
想要避免暢流下降，WIP 就要越小越好
或是使用feature toggle上線，讓暢流程度保持高檔，品質保持更好。
WIP 跟回饋力道有關係，越少東西，回饋的力道跟即時性會越強。
左半邊要怎樣把暢流程度加大？
全局可視化程度 => 排除阻礙因子的力道 => 改善暢流程度
增加全局可視化程度的方法
希望增加系統內的資訊流多元性、即時性、透明度，發生p0事件可以儘速的解決掉
幫助我們快速釐清事物的因果關係，快速發現並處置任何瑕疵或差錯
defect 是存量，但我們希望這裡傳遞到下游愈小愈好。對於任何存量，都會從上、下游一起思考，從源頭讓瑕疵不會發生。
可以把defect team裁掉就好了嗎？
怎樣從源頭「預防」瑕疵發生，讓上游的落網之魚不會流向下游。瑕疵從 coding 當下就會發生，因為越往下流，代價就會越高，到 unit test 就會代價高一點，到測試環境到正式環境的變動會更高。
重點是能不能在上游就發現瑕疵
(測試左移，資安左移)
所以要從上游就把水龍頭拴緊。
修理瑕疵：fix & rework
因果關係要清晰，就是要WIP越小，你若是每次都上1000行code上去，因果關係當然沒有辦法清晰。
可視化程度越高，因果關係更清晰
回饋力道越即時，因果關係更清晰
理想很美好，現實很骨感
回饋力道會跟暢流程度會有一些副作用存在。
資安會覺得你在CI就應該把漏洞檢查把scan放在前面，你就希望差的東西不會跑到下面。但被死線追著跑的時候，就會覺得被中斷，花很多東西去fix。很多東西都containerize就不是你團隊去管的。base image有問題跟你無關，要找其他team處理就是一個嚴重的「中斷」（剛剛 Ruddy 老師說的心流）。
大家都知道部門跟部門之間，如果一個東西需要另一個部門去改，那他可能不是非常積極的。
「中斷」增加，就會把暢流的水龍頭打開～這樣就完全不暢流了。這是很多企業在追求回饋力道需要花力氣溝通的。
回饋力道越強會有短痛，但長遠來看很多東西在根本上處理，會比較沒有阻礙。
如果有些 bug 只是因為不想更換而不去處理，但很多瑕疵後面你不見得能夠去負責。
所以公司對於引起中斷會分級，就
可能會分 fatal, medium，有些東西在一天以內要解決，有些在一個禮拜或一個月，或是有空再處理，依照 security 等級去處理。
長遠來看還是盡量不要去忽視。盡量用正規方法排除阻礙，長遠才能根本解決暢流的程度。
Toyota 發明的方法，我們食品加工業也在做。
刻意凸顯局部問題，打斷整體作業
e.g. 心流 context switch
這會促進組織不停學習，避免因為時間流逝而遺忘事件脈絡，也因為環境改變措施關鍵資訊。
烤箱ＸＤＤＤＤ
？？
光阻劑可能缺貨（？
三步工作法互相會有關係跟幫助
掌握全局會很重要
| 關鍵變量存量 | 關鍵變量流量 | 關鍵結構 | |
|---|---|---|---|
| forward flow | Text | Text | |
| feedback | Text | Text | |
| continuous improvement | Text | Text |
暢流程度很差的話，不能夠一天 release 十次，怎麼辦？
可能是因為老闆要求或產業特性，本來就很困難
如果這條路，短期內辦不到怎麼辦
身為部門經理近期內解決方式都是加強因果關係清晰度來做釐清，盡量讓瑕疵降低，暢流程度會增加，就算release沒那麼多。先接受現實，可以保證出來的東西是好的，這樣整個企業出來的效益還是好的
所以此路不通，所以換一條路走就好了
如果現階段的內在品質太差，讓全局可視化程度提升，有問題就提早曝光，新增很多偵測點，至少問題快要出來的時候，讓瑕疵可以及早發現
大Ｍ會哇哇叫嗎（？）
DevOps 是一種尋找瓶頸的方式，在更高的層次上尋找瓶頸。
在更高層次上尋找瓶頸
早期是把一些製造業的觀點想出來的，像是精實生產，都是從汽車製造業，影響到 IT 領域（像是看板 kanban），慢慢發展後，這些精神都會回頭去影響製造業。
食品加工業也慢慢在趕上這些思路。
FAB RUNS ON CODE
可觀測化跟心理安全感有問題，太赤裸裸揭秘出可能不敢讓東西曝光，但長期來說對品質絕對是壞處。
企業希望讓這些東西可以好好的曝光，就要營造一個不怕嘗試不怕正確犯錯的環境，我覺得「正確犯錯」這本書滿有趣的。不是鼓勵犯錯而是鼓勵「正確」犯錯，錯誤的犯錯就是該發現卻沒發現。這樣企業在嘗試跟創新才有機會。
以後有機會再多講講這個主題～
推薦書：
DevOps Handbook ｜打造世界級技術組織的實踐指南, 2/e (中文版)
天瓏今天有擺攤，去買書！
買！都買！第一版跟第二版都有收，推薦！
買越多省越多
我跟你談海洋，你說塞子
要有塞子
請給我食物
便當來了嗎
OST 那邊有零食
Ｉ棟那邊不是有一堆ＸＤ
下午還有18天嗎？
需要這個讓心靈澄靜…
18 天很好喝欸
Value Stream 如果是用時間軸來觀測的話，那麼主要看的是每一個時間點的發生事件對客戶價值的增量減量嗎？這樣聽起來還是對每一組事件去檢視是否對於客戶有價值，不一定需要用時間軸來逐一盤點。
護國神山的限制太多了吧
法務會海巡
何止限制很多
Fab Food Runs On Code
DevOpsDays Taipei 2024
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe