《ACCELERATE：精益軟體與DevOps背後的科學》心得：你衡量什麼，你就會得到什麼
原文書名：Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
中文書名：ACCELERATE：精益軟體與DevOps背後的科學
這本書在說什麼？
作者研究搜集了全世界 23,000 份的問卷回覆，得到超過 2,000 個不同組織的回覆，包含了各領域的新創公司和大企業．透過嚴謹的科學方法了解如何測量軟體績效，以及投資哪些能力來驅動更高的績效．
研究人員發現高績效團隊有這些特點：部署程式碼的頻率高出 46 倍、從提交（commit）到部署的前置時間快上 440 倍、從停機期（downtime）恢復的時間平均快上 170 倍、變更故障率低 5 倍。
透過改善交付軟體的能力，可以幫助你的組織更上層樓，組織才可以更快交付功能，響應環境的變化，並利用快速回饋以吸引更多顧客，滿足他們對產品的期待。
而這本書總結出 24 種關鍵能力，能以統計上顯著的方式，驅動軟體績效中的改善．如上圖所示，可以呈現出指標的相關性．這篇文章將會挑選三個我感興趣的主題（紅色框部分）跟大家做分享。
軟體交付績效
軟體領域中測量績效有一定的難度，主要在於軟體所謂的庫存是無形的、拆分工作方式相對隨機、設計與交付相關活動是同時發生的。因此，我們需要定義一種合理且可靠的軟體交付績效量測。
過去嘗試測量績效時的缺失
過去許多測量軟體團隊績效的嘗試，通常有兩種缺點：第一，著重在產出（output）而非結果（outcome）。第二，著重在個別或局部的量測而非團隊或整體量測。讓我們舉三種例子：程式碼行數、速度（velocity）、使用率（utilization）。
有些公司要求開發者紀錄每週完成的程式碼行數。就解決問題而言，我們更偏好 10 行程式碼的解決方案．若增加程式碼行數，會導致軟體過於臃腫，帶來更高的維護和變更成本。理想上，我們應該獎勵開發者以最少程式碼解決業務問題。
在敏捷方法裡，需求以故事的方式撰寫，開發者會分配一個點數給開發者，表示預期所需的相對工作量，平均一個迭代可以完成的總點數就稱為「速度」。速度是相對的，每個團隊都有不同的基準值，並非是絕對的量測值。速度高只代表著高產出（output），並不意味著產出有價值的功能。
最後，很多組織測量使用率當作生產力的代表。排隊理論告訴我們，當使用率接近 100% 時，前置時間就會趨近於無限大。也就代表著，我們沒有餘裕可以應付意料之外的工作或是一些改善的工作。
四種選定的軟體交付績效的量測
從眾多的量測中，作者選定了以下四種最具代表的指標，通常在這四個指標表現出色的團隊，團隊的績效也會很出色。
- 交付前置時間：從程式碼提交，一直到程式碼可以在生產環境中成功運行的全程所需時間。
- 部署頻率：批量大小（batch size）在軟體上很難被測量與溝通，因為並沒有顯而易見的庫存。因此，我們選定部署頻率作為批量的代表，因為這是容易測量和低變異性．
- 平均修復時間（MTTR）：傳統上可靠性是以故障事件之間的時間長度來量測的；然而在現在軟體產品與服務，故障在所難免．因此關鍵問題變成：當某服務發生事故時，一般會需要多久才能恢復服務．
- 變更故障百分比：多少百分比的生產環境變更會導致服務降級，或是隨後需要補救措施，例如 hotfix、rollback、fix-forward、patch．
Westrum 組織文化
社會學家 Ron Wetrum 在 1988 年發展了一種組織文化類型學，有三種風格迥異的組織類型。
- 權力導向：組織的特徵是草木皆兵般的恐懼與威脅。
- 規則導向：組織會保護各自部門。
- 績效導向：組織專注在使命上，我們如何達成目標？
Westrum 的理論假設，有較佳資訊流的組織運作起來更加有效，這種組織通常有兩個特徵：第一，良好的文化有賴整個組織上下的信任與合作。第二，較佳的組織文化能顯示出較高品質的決策。最後，具備這些文化準則的團隊更可能會善待人，因此問題會更快被發現並處理。
在組織剛成立時，很可能是權力導向．但是隨著組織漸趨成熟，慢慢轉向成規則導向．甚至，最後可能會邁向績效導向的組織．通常，較佳的組織文化，會帶來較佳的軟體交付績效與組織績效．根據 2016 年的研究結果，有 31% 的受訪者被分類為權力導向、48% 是規則導向、21% 是績效導向。
那我們如何改變組織的文化呢？美國汽車製造廠精益製造運動的創始者 John Shook，曾說：「要改變文化的正道並非先改變人們的思維模式，而是從改變人們如何行事開始，也就是他們的所作所為」。
每個人都是獨立的個體，企圖想要改變他人的想法是非常困難的，但是我們可以從改變他人的做法開始．當他們開始嘗試新作法，並且從新方法中獲得好處時，他們的想法就會開始產生改變．「Do It, Prove It」。
持續交付
持續交付是一整套的能力，把所有種類的變更，包含功能、組態設定變更、臭蟲修復、實驗等等，部署進生產環境，並且安全、快速並永續地交到使用者手中。持續交付有 5 個關鍵原則：
- 內建品質：戴明管理 14 要點中的第 3 點：「停止倚賴檢查以達成品質．藉著從一開始就將品質內建在產品中，消除大量檢查的需求」．
- 以小批量工作：藉著把工作拆分成小很多的部分，每個部分的可以快素交付可測量的業務結果，得到所進行中工作之必要回饋．
- 電腦執行重複單調的任務；人來解決問題：區別出那些會耗費很長時間的重複單調工作，比如回歸測試與軟體部署，然後投資在簡化這些工作並將其自動化．
- 努力不懈追求持續改善：高績效團隊的特徵就是永遠不滿足，總是力圖改善．
- 每個人都有責任：軟體交付中的每個人需要緊密協作．
為了實施持續交付，需要以下三個基礎：
- 全面而詳盡的組態設定管理：以完全自動化的方式，從儲存在版本控管系統的資訊來供應我們的各式環境，並且建置、測試以及部署。
- 持續整合：以小批量工作，並內建品質。讓分支短暫存在（少於一天份量的工作），並且頻繁地將這些分之整合進主幹。
- 持續測試：自動化單元與驗收測試應該針對每次上到版本控制系統的提交（commit）來做，提供給開發者迅速的正確性回饋。
持續交付有助於增加品質，那麼，有什麼好的指標可以量測品質呢？作者找到最強烈相關是「在重工或意外工作花費時間所佔百分比」，包含損壞與修復工作、緊急軟體部署與補釘、回應急迫文件審核需求等等。
根據分析結果，高績效團隊花費 49% 的時間在新工作上，花費 21% 的時間在意外或重工上。相較之下，低績效團隊花費 38% 的的時間在新工作上，花費 27% 的時間在意外或重工上。
因此，我們可以推斷當一個團隊有較低的意外和重工花費時間百分比時，這個團隊的績效通常比較好，這個結果也很符合我過去的工作經驗。
心得：你衡量什麼，你就會得到什麼
如何幫不同的交付團隊訂定共同指標，讓管理層可以進行整體的監督與管理，一直是管理人員很頭痛的問題。我們很難找到單一指標，可以呈現團隊目前的績效。
「Perhaps what you measure is what you get. More likely, what you measure is all you’ll get」H. Thomas Johnson 曾經這麼說。
即使我們真得找到單一指標，最後可能也無法得到預期的結果。簡單的說，就是當你設定量測指標後，團隊就會嘗試透過各種方式滿足這個量測指標，最後，你只會得到你想要得到的好數據。
這本書提供一個有意思的切入點，它不是試圖尋找單一量測指標，證明這個指標與交付團隊績效有直接關連性。而是採用問卷調查的方式，將定性與定量的資訊收集起來後，以統計學方式分析指標之間的關聯性。
關聯性以能力驅動模型圖呈現（參考本篇文章上方第一張圖片）。因此在閱讀這本書的時候，我建議先翻到 224 頁，這個圖片涵括作者的研究成果。書本中的每個章節就是分別講述其中特定指標與前後相關指標的關聯性。
這本書最精彩的地方，在於提供四個關鍵指標，幫助我們測量軟體交付績效，包括交付前置時間、部署頻率、平均修復時間和變更故障百分比．如果團隊在這四個指標都表現良好的話，通常這個團隊也會有高績效．
如果你喜歡我的文章，歡迎「拍手」給我支持，或是「追蹤」我，讓我提供更多的優質文章給你。
