「精益軟體與DevOps背後的科學」這本書讀後的知識整理與個人感想、經驗

1. 精益軟體與 DevOps 背後的科學
重點整理、個人見解與實務經驗
RYAN CHEN 陳品澤

2. 2
我們可以如何應用科技來驅動商業價值？在過去的很多年裡，我們一直被告知：軟體交付團隊的績效
並不重要，無法為我們的公司提供具競爭力的優勢。本書作者透過4年的開創性研究，納入Puppet
《DevOps境況報告》所收集的資料，同時利用嚴謹的統計性方法，立志找出測量軟體交付績效的方法，
以及何者驅動它。本書呈現了該研究的成果及背後的科學，讓讀者可以採用在自己的組織中。
我們希望當您閱讀此書時，您會發現作為一個技術專家暨技術領導，能讓您組織更上一層樓的要素，
即從軟體交付開始。正是透過改善我們交付軟體的能力，組織才可以更快交付出功能，必要時隨機應
變、回應合規性與安全性變革，並利用快速回饋以吸引更多顧客，且取悅現有顧客。
閱讀本書後，您將了解如何測量團隊績效，並該投資哪些能力來驅動更高的績效。本書值得所有管理
階層一讀！
天瓏書局網站上的簡介

3. 3
 書本內容摘要
 關鍵能力
 團隊實踐狀況
 成效數據
 遭遇困難問題
本次分享內容

4. 4
 是四年來經過同行審查的認真研究的產物。
 調查哪些能力和實踐對於加速軟件的開發和交付以及對公司的價值至關重要。
 書本內容主要分三個部分：研究結果、方法論、案例研究
 DevOps：是一套實踐、工具與文化哲學，旨在自動化並整合軟體開發團隊與IT團隊之間的流程；強
調賦權團隊、跨團隊溝通與協作及技術自動化
 準確測試DevOps能力並與領導階層溝通測量結果，助以決策、謀畫與調整組織技術態勢
書本內容概要

5. 5
 軟體領域要測量績效有一定的難度
 成功的績效測量方法有兩個關鍵特徵：1.著重在整體結果以確保團隊不會彼此惡性競爭（困惑高牆、
穀倉效應）。2.應著重在結果而非產出
 四種量測：交付前置時間、部署頻率、修復服務所需時間、變更失敗率。
 前置時間(Lead Time)：從下單需求（客戶提出需求），到收到貨物（該需求被滿足）之間的時間。
 前置時間分兩部分：1.設計並驗證某產品或功能所需的時間（設計部分。計時不清，具高度變異性）。
2.交付該功能給客戶所需時間（交付部分：實做、測試及交付，較易測量，較小變異性）。
 保持戰略軟體在公司內部開發
 “交付績效對組織績效的影響”的統計數據表明，軟體開發和 IT 不是成本中心；他們可以提供競爭
優勢。
 作者專注於交付時間的交付部分——“實做(程式碼提交)、測試和交付工作所需的時間”
測量績效

6. 6
前置時間的兩部分

7. 7
 問卷調查受訪者企業的組織績效：獲利能力、市佔率與生產力來評分（與投資報酬率高度相關）
 組織的軟體交付能力，可以為生意提供競爭優勢
 無論組織的使命為何，一個技術組織的表現可以預料整體組織的績效
 高績效者加倍可能超越非商業績效目標：商品數量、運維效率、客戶滿意度、產品或服務品質以及
達成組織或使命目標
交付績效對組織績效的影響
軟體交付績效
組織績效
非商業績效
深遠影響

8. 8
 自己的組織團隊落在哪個分類？
 量測四項指標（MTTR平均修復時間），並設定目標，要求團隊朝向目標
交付績效分群

9. 9
 書本2017年的研究，四種指標變成三種：前置時間、發佈頻率、恢復服務時間，而變更故障率無法
通過信度和效度檢驗
 但研究資料分析後，變更故障率仍與軟體交付績效有顯著關係
 Google的研究，現在仍是以這四個指標來評量
軟體交付績效

10. 10
Google 2018-2021分類

11. 11
 【iThome 2022 CIO大調查(中)｜DevOps能力分析】臺灣企業DevOps能力首度揭露數據，僅4.2%
企業是精英（點我）
台灣現況

12. 12
Announcing the 2022 Accelerate State of DevOps Report
• From Google

13. 13
 在DevOps圈子裡，文化是非常重要的。藉著施行DevOps實踐，來影響並改善文化。
 組織文化存在於組織的三個層面上：基本假設（最不顯眼，約定成俗、習慣）、價值觀與產出物
（最顯眼，具體申明、正式程序、儀式典禮）
 組織文化類型：病態型（權力導向，恐懼、隱藏、扭曲）、官僚型（規則導向，自保、地盤）、
生機型（績效導向，使命、目標、績效）
 優質資訊：為接收方需要解答的問題提供解答、即時、使接收方能有效利用的方式來呈現
 以Westrum組織文化類型學，發展出李克特量表的問卷來分析評估組織文化類型
組織文化

14. 14

15. 15
 Westrum組織文化：
 理論假設：有較佳資訊流（公開透明）的組織運作起來會更加有效
 先決條件：組織上下的信任與合作、高品質的決策
 改變文化的作法並非先改變人們的思維模式，而是從改變人們如何行事開始
Westrum組織文化
Westrum組織文化
軟體交付績效
組織績效
深遠影響
持續交付
精益管理

16. 16
 限制進行中工作(WIP)：確保團隊不會變得過載（不堪負荷，導致更長前置時間），要與視覺化展示
合用
 視覺化展示：顯示關鍵品質與生產力指標，以及當前工作狀態（包括瑕疵），可展示的資訊種類、
資訊共享、取用容易，促使能見度高與高品質的溝通的
 使工作流程顯而易見
 輕量化變更的審核：Peer Review、Pipeline自動偵測壞的變更
精益管理
精益管理 軟體交付績效
更少過勞
組織文化

17. 17
 持續交付效能，對軟體交付效能、組織文化以及其他諸如團隊過勞、佈署上的折磨有深遠影響
 持續交付的核心有五個關鍵原則： （關鍵目標：使推出個別變更的成本能降到甚低）
1. 內建品質：打造一種由工具和人所支持的文化，因此可以迅速查詢到問題，馬上修復
2. 以小批量工作：可快速交付可測量的業務結果，得到回饋，進行修正
3. 電腦執行重複單調的任務，人來解決問題：譬如簡化回歸測試與軟體佈署工作將其自動化
4. 努力不懈追求持續改善：高績效團隊最重要的特徵
5. 每個人都有責任：軟體交付過程中每個人之間緊密協作
持續交付

18. 18
 全面而詳盡的組態設定管理：各式環境組態設定儲存在版控系統，提供自動化建置、測試及佈署軟
體使用
 持續整合：短暫分支，時常合併分支進行整合
 持續測試：應該無時無刻進行之，源碼提交就進行單元測試。已經寫完自動化測試並通過此測試，
開發工作才算做完了。開發者負責自動化測試，會更在乎這些測試，並投入精力維護與修復。每次
提交都應觸發軟體建置並運行一套快速、自動化的測試。
 QA：手動測試如探索性、可用性與驗收測試，協助開發者創建並逐步進化自動化測試套件
持續交付的基礎

19. 19
 對所效力的組織有強烈的認同感
 更高水準的軟體交付績效（建置時間、佈署頻率、恢復服務所需的時間）
 變更故障率更低
 生機型、績效導向的文化
 佈署折磨的程度更低
 團隊過勞的程度降低
 做好持續交付的團隊，會更加認同所效力的組織。因為這樣的環境文化會是讓開發者有體認到承
擔整體結果的責任：譬如品質與穩定度
做好持續交付的團隊
持續交付
更少重工
認同感
軟體交付績效
Westrum組織文化
組織績效

20. 20
 可測試性：不需要一個已整合好的環境，就可以進行大多數測試。各系統可獨立變更並驗證。
 可佈署性：可以自外於所仰賴的其他程式/服務，去佈署或發佈應用程式
架構上的兩重要特徵助高績效

21. 21
 團隊可對系統設計進行大規模變更，而不需要團隊以外的任何人許可
 團隊可對系統設計進行大規模變更，而不用仰賴其他團隊變更其系統，或給其他團隊造成客觀其他
的工作量
 完成團隊的工作，而不用與其團隊以外的人溝通協調
 應需佈署並發佈產品或服務，不用顧慮所仰賴的其他服務
 應需進行大部分的測試，而不需要一個已整合好的測試環境
 能在正常營業時間進行佈署，只會微不足道的停機時間
 在架構能力項目得高分的團隊中，交付團隊之間只需要少量溝通就可以把工作做好，並且系統架構
是設計來讓團隊可以測試、佈署，並修改他們的系統，而不用仰賴其他團隊。架構與團隊是鬆散耦
合的。交付團隊是跨職能的，同一交付團隊技能具備設計、開發、測試、佈署以及運維系統
持續交付最大促成因素（架構）

22. 22
 運用有界脈絡（Bounded context）與API來作為一種方式去解耦大領域成為較小的、更鬆散的耦合
的單元
 運用測試替身（Test double）與虛擬化技術，作為隔離測試服務或組件的一種方法
架構方法

23. 23
 耗費數月編預算、分析及需求收集，然後才開始做
 工作堆積成大型專案，發佈卻少得可憐
 客戶的回饋常被當作事後諸葛（感想：負面看到客戶的回饋，認為客戶事前無意見，事後才高談
闊論；談需求時沒意見，做出來後才說這個結果不行）
假敏捷

24. 24
 從產品生命週期的一開始，就藉由頻繁地進行使用者研究、來測試產品設計與商業模式。
 在萬事草創渾沌不明時，以輕量化方式去探索新的商業模式與產品構想
 強調採取實驗性方法來進行產品開發（源自客戶的反饋，經過自身產品團隊溝通討論）
 一開始就建構併驗證原型，以小批量方式工作，並且及早且經常演進或「轉型」產品與其背後商業
模式
精益產品開發與精益創新模式

25. 25
 以小批量工作
 視覺化管理
 收集並實做客戶回饋
 團隊實驗
 感想：團隊間的合作模式與組織文化，會影響這樣作業的難易度。例如，主要以SI進行產品導入專案
的情境，可能就受限於SI的態度。若是由自己開發發佈到雲端SaaS的系統直接面對終端客戶，較容易
達成這樣的工作模式。
精益產品開發
精益產品管理 軟體交付績效
更少過勞
Westrum組織文化
組織績效

26. 26
 軟體於撰寫時，並沒有考慮到可佈署性
 手動變更生產環境佈署，失敗的機率大增
 複雜的佈署往往需要團隊間的多次交接：穀倉化的組織，DB管理者、網管、系統管理者、資安、QA、
開發者在不同團隊作業
佈署折磨的因素

27. 27
 開發產品系統可容易佈署到多種環境，可以察覺並容忍其環境中的故障，能讓系統各組件獨立更
新
 確保生產系統的狀態可由自動化的方式，從版控系統中的資訊被重現（除了生產環境資料）
 在應用程式及平台中內建智能，使佈署流程簡單
減輕佈署折磨的作法

28. 28
 工作過載
 缺乏控制：無力左右那些為影響自己工作的決策
 不充分的獎賞報酬
 社群崩毀：不支持人的工作場域
 公平性蕩然無存
 價值衝突：組織價值與個人價值不匹配
六個能預示過勞的組織危險因子

29. 29
 培養尊重、支持人的工作環境，強調失敗中學習而非指責
 與員工溝通重要的人生意義
 投資在員工的栽培
 詢問員工哪些事物阻礙他們無法達到目標，然後修正那些事物
 給員工時間、空間與資源來實驗並學習
 員工一定要被授權去做那些會影響其工作的決策，尤其是那些他們要對其結果負責的領域
 改善技術實踐（如：促進持續交付的那些技術）以及精益實踐（如：精益管理與精益產品開發）
避免過勞

30. 30
 組織文化：尊重及支持人，較好
 佈署折磨：降低折磨，較好
 領導效用：限制WIP、為團隊移除路障，較好
 組織投資在DevOps上：投資技能發展，較好
 組織績效：給員工時間與資源去改善他們的工作，支持實驗、失敗與學習的工作環境，較好
哪些組織因素與高度過勞最強烈相關

31. 31
 測量NPS（淨推薦值）僅根據單一問題：你多可能會向朋友推薦公司/產品/服務
 高績效組織員工更可能（2.2倍）去做推薦
員工滿意、認同與投入
精益實踐
持續交付
組織績效
認同 /
工作滿意度

32. 32
 工具是DevOps實踐的重要組成，而其中許多工具讓自動化成為可能
 好的DevOps技術實踐可以預先顯示出工作滿意度
 自動化很重要，它讓電腦去做電腦在行的機械式重複的工作，不需要思考。
 讓開發者的時間花在思考上。
工具

33. 五類24個關鍵能力與團隊實踐
五類24個關鍵能力

34. 34
 驅動軟體交付績效改善，接著就是組織績效改善
 五類
 持續交付
 架構
 產品與流程
 精益管理與監控
 文化
總結五類24個關鍵能力

35. 35
 運用版控系統控制所有生產環境產出（衍生）物：組態配置...
 感想：
 版號對齊源碼 tag，源碼版本容易追溯
 測試與正式發佈，清楚界定
 倉庫Tag ＝ 套件組件檔名上或檔案屬性上的版本 ＝成品版本查詢UI上的版本資訊
 產出物與版控系統例如：
1. 源碼、環境組態，Git
2. 套件，NuGet、Maven
3. Container image，Container Registry
4. 測試腳本與測試資料Script：Git
持續交付-1

36. 36
 自動化佈署流程
 感想：區分以下不同功用佈署區，並實踐自動化佈署流程，減少人工時間與錯誤發生
1. 開發區
2. 整測區
3. 自動化測試區
4. 壓力測試區
5. 預發佈區
6. 正式區
持續交付-2

37. 37
 實做持續整合
 感想：開發階段
1. 源碼交付：自動進行快速的品質掃描、編譯建置、單元測試
2. 每日：網頁自動化測試、Web API自動化測試
3. 每週：較耗時的資安品質掃描
持續交付-3

38. 38
 運用主幹開發：分支留存時間短，儘快merage到主幹。很少或從來沒有鎖住程式碼。
 感想：
 GitFlow：開發工作用develop分支、整測
期用release分支，發佈後源碼併入入master
分支。非必要不建立feature分支。
 三駕馬車分支：主要的開發工作用開發
分支（主幹），整測期用預發佈分支，發佈
後源碼入發佈分支。
持續交付-4
為你自己學Git

39. 39
 實做測試自動化：開發者應主要負責自動化測試套件之創建與維護
 感想：
1. 每日：網頁自動化測試、Web API自動化測試
2. 即時生成自動化測試的系統環境，容器化的DB
3. DB寫入產品出廠初始資料，與測試所需的測試資料
4. 用開發分支或release分支編譯出（組件已加密）的成品測試
5. QA編寫測試腳本與測試時，可reuse Pipeline建置乾淨環境使用
持續交付-5

40. 40
 測試資料管理：最小化運行自動化測試所需的資料量
 感想：
1. 測試腳本
2. 自動化測試的DB測試資料SQL Script
3. 存放在版控系統中
持續交付-6

41. 41
 資安左移：將資安整合進軟體開發的設計與自動化測試階段，使用資安上已核准的函式庫
 感想：
1. 開發/整測階段，每週：資安掃描軟體進行掃描分析
2. 佈署網站後，可使用 OWASP ZAP 進行弱點掃描
持續交付-7

42. 42
 實做持續交付(CD)：軟體皆是處於可佈署的狀態，有無法佈署時，會馬上修復
 感想：
1. 開發區：源碼交付就會進行持續整合後佈署至開發區，Pipeline failure無成功時，開發者會立刻查
找問題進行排除。源碼隨時可以為正式發行的版本是一個大挑戰，但隨時從成品庫取得上架的成品
進行佈署應該是要確保可行。
2. 整測區：人員[QA]驅動佈署Pipeline，標示標籤、產出成品放置於成品區或倉庫，接著取得成品佈
署
3. 交付型：測試通過後，從成品區或測試版倉庫取出打包交付上架到正式版倉庫
4. 正式區：從正式版倉庫取出佈署
持續交付-8

43. 43
 運用鬆散耦合架構：可以獨立測試與佈署
 感想：
1. 單元測試用Mock技術可隔離，獨立測試
2. 有 Web API 測試工具提供Mock機制（ 如MeterSphere），應可隔離其他系統服務進行測試
架構-9

44. 44
 授權團隊可選擇的架構：可以任意選擇工具來使用的團隊，持續交付會做的比較好，進而驅動更佳
的軟體開發與交付效能
 感想：這點需要主管接受並擬定評估規範，應該是需要經過一定的評估方式才做選擇
架構-10

45. 45
 蒐集並貫徹客戶回饋
 感想：
1. 每個Sprint demo邀請利害關係人參與，並收集反饋
2. End User的反饋收集，提供聯繫信箱
3. 藉由Google Analytics或自行開發工具收集終端使用者使用狀況數據
4. 提供線上問卷
5. FOAK專案、雲端實驗性產品
產品與流程-11

46. 46
 讓工作（作業）流（動）透過價值流變得更顯眼：團隊應該對工作（作業）流有良好的理解與能見
度，而此工作流從業務端一路到客戶端，包括產品與功能狀態。我們的研究發現這對IT績效有正向的
深遠影響
 感想：
1. 相關人士的習慣性作法會影響接受度成效
2. 身為RD的您瞭解您負責的產品在業務端的狀況嗎？ 我想許多是不知道的，可能是RD沒有意識到需
要瞭解，也可能是因為組織活動沒想過要讓RD瞭解
產品與流程-12

47. 47
 以小批量工作：每小塊可以在一週內完成。MVP做實證學習。縮小前置時間，也會有較快的回饋迴
路。格外重要，可讓團隊能將使用者研究整合進產品開發與交付。
 感想：
1. 敏捷Scrum方式開發
2. 兩週一個Sprint，一個Sprint進行小量可開發完上線的功能
3. 第二週週四Sprint Demo對利害關係人，收集反饋
4. 若利害關係人對demo的成果可接受，第二週週五上線到Production
5. 要能這麼快上線推出，必須要豐富的自動化測試來提升速度
產品與流程-13

48. 48
 培養並賦能團隊實驗：嘗試新想法，開發流程途中創造及更新規格之能力，不需要外部團隊的核准。
當與小批量工作、廣納客戶回饋、並使工作流顯眼等結合時，會格外具有深遠影響
 感想：這非常取決架構、文化、產品環境是否允許
產品與流程-14

49. 49
 有輕量化變更核准流程：基於同儕審核，勝過外部的變更審核委員會
 感想：
1. 每週團隊內部demo review，但這其實可看的量有限
2. 同儕審查或是資深者審核，對人力吃緊的團隊難以進行
3. 可搭配品質分析工具（如： SonarQube、Fortify、Black Duck ）檢查，除了省時外，這些工具的
檢查能力，甚至比許多的資深工程師更好。工程師也可以藉此學到許多Good Practice.
精益管理與監控-15

50. 50
 橫跨應用程式及基礎設施監控以影響業務決策
 感想：
1. 監控注意Hardware足夠支撐業務量
2. 使用者行為數據收集，知名如Google Analytics，但若是套裝軟體架設在無法連線網際網路的客戶
環境，有其他工具可以應用嗎？自行開發是另一個設計議題
3. 收到了數據，該怎麼分析才能找到價值的洞見，這才是重要的！
精益管理與監控-16

51. 51
 積極主動檢查系統健康度：緩和問題
 感想：
1. 檢查硬體資源的耗用狀況
2. 檢查軟體系統的反應狀況、一個簡單但觸及到DB（甚至其他服務）的驗證程序是否正常執行完畢
精益管理與監控-17

52. 52
 改善流程並以限制進行中工作（WIP）來管理工作：限制同時處理在製品（進行中的工作）的數量。
不過載，打通阻礙，讓生產力提升
 感想：
1. 工具使用Roadmap、MS Project file、Backlog / Task 看板等等
2. 成員跨產品/平台/工具開發的狀況在業界蠻常發生，這種情境下，能有一目瞭然呈現彙整WIP狀況
資訊與視覺化看板是很有幫助的。
精益管理與監控-18

53. 53
 視覺化工作以監控品質並與團隊上下溝通
 感想：
1. 有各工具的Dashboard（例如：Jira、SonarQube、Fortify等等），但分散
2. 期望未來能有工具彙整這些資訊在一處觀看及主動通知示警機制
精益管理與監控-19

54. 54
20. 支持一種生機型文化：量測的特點包括良好的資訊流、高度合作與信任、團隊間的橋樑（接），與
追根究底
21. 鼓勵並支持學習
22. 支持並促進團隊間協作：多擅長與彼此就開發、運維與資訊安全方面互動
23. 提供使工作變得有意義的資源與工具：從事有挑戰性且具意義的工作，也給予所需的工作與資源來
把工作做好
24. 支持或體現轉型領導統御：五種特徵：遠見、腦力激盪、啟發性（鼓舞人的）溝通、支持性領導統
御、與個人表彰
文化

55. 55
匯總各項之間影響的關係
Westrum
組織文化

56. 56
匯總各項之間影響的關係(英文版)

57. End~