探索持續改進

  • 5 分鐘

持續改進是 DevOps 分類法八大功能的其中一個。

探索為什麼需要持續改進

持續改進牽涉到衡量方式，而且也需要衡量方式。 如果不加以衡量，如何能識別是否有所改進？

弗雷斯特 (Forrester) 研究公司在 2017 年發行的報告《更快速的軟體傳遞可加速數位轉型》(Faster Software Delivery Will Accelerate Digital Transformation)，指出前置時間和流程時間之間有大量的浪費。 這提醒我們，如果沒有經過衡量，就不知道有何差異，或是您的組織產生多少浪費。

衡量特定浪費對流程的影響後，就可輕鬆排定工作的優先順序以進行改善。

圖表顯示在 123 天的前置時間與 39 天的處理時間之間，有顯著的浪費。這相當於 84 天的等候時間。

來源：Forrester《更快速的軟體傳遞可加速數位轉型》，2017 年 3 月 9 日發行，由 Diego Lo Giudice、Christopher Condo 及 Christopher Mines、Luis Deya 所撰寫

但是，如果您未加以衡量，要如何改善客戶體驗？ 弗雷斯特研究顯示「經過測試的功能和使用的功能之間，只有一小部分重疊，代表開發人員需要更好的客戶深入解析。」 經過測試的應用程式功能和使用的應用程式功能，兩者之間的重疊大約是 35%。

圖表顯示經過測試的功能與使用的功能之間只有 35% 的重疊。

如果您不衡量新功能的使用方式和影響，該如何建立合適的軟體？ 當發生錯誤的機會是 65% 時，便必須瞭解其中的差異為何。

持續改善是什麼？

持續且坦率觀察您的 DevOps 流程，可讓小組找出可能改進的機會。

所有的改進都需要改變，但並非所有改變都會成功。 這就是為什麼對於使用 DevOps 的組織來說，衡量是成功的關鍵因素。 如 Peter Drucker 所說：「如果您無法衡量，就無法加以改進。」

缺乏有效的意見反應機制，會難以改進應用程式對企業的影響。 這說明對 DevOps 改進而言，建立一個環境來培養以學習為中心的方法非常重要，同時要將重點放在資料方面的調整。 圖表顯示我們應該使用度量和影響來產生改善。測量應該會導致正面行為變更。組織應發展為持續學習和意見反應的練習，以建立軟體傳遞效能的持續改進。

衡量和衡量標準

首先，我們來談談衡量。 根據 Nicole Forsgren、Jez Humble 和 Gene Kim 所撰寫的書《加速》(Accelerate)，四項最重要的軟體傳遞效能衡量方式為：

  • 變更的前置時間：衡量軟體傳遞效能的步調。 從已認可的程式碼到於生產環境中成功執行的程式碼，期間所花費的時間
  • 部署頻率：直接或間接衡量回應時間、小組凝聚力、開發人員能力、開發工具效率，以及整體 DevOps 小組效率。
  • 平均還原時間：發生服務事件時，通常需要多久的時間來還原主要應用程式或服務。
  • 變更失敗百分比：生產環境變更失敗百分比 (包含如軟體版本和基礎結構設定變更)。

DevOps 領導階層有責任衡量作業健康情況計量、使用方式、速度和即時網站健康情況等項目。 換句話說，是要衡量影響，而不是活動。 只有當我們可以針對衡量標準採取行動時，衡量標準才有其效用。

雖然 Scrum 小組會衡量小組產能、小組速度、待執行工作和錯誤數量，但這些衡量標準只會在小組內容中有其意義。 然而，DevOps 領導階層必須將重點放在影響。

重要

衡量影響，而非活動！

我們衡量的事項：

使用方式

速度

即時網站健康情況

  • 取得
  • 參與
  • 滿意度
  • 流失
  • 功能使用方式
  • 組建時間
  • 自我測試時間
  • 部署時間
  • 學習時間
  • 偵測時間
  • 溝通時間
  • 緩和時間
  • 客戶影響
  • 事件預防項目
  • 老化的即時網站問題
  • 每位客戶的服務等級協定
  • 客戶支援衡量標準

不需監看的事項：

  • 原始評估
  • 完成時數
  • 程式碼
  • 小組產能
  • 小組待執行工作
  • 小組速度
  • 錯誤 (bug) 數量

重要

衡量標準會影響業務成果。

將關鍵效能指標和習慣保持一致很重要。 這個作法有助於達成正面的業務成果。

強化關鍵效能指標，並設定小組成功的重要習慣應包括：

  • 小組自主性和組織一致性：我們組建的內容、方式與原因。 您需要在組織中採取共同的步調或活動訊號，讓所有領導階層和功能小組能以透明且有效率的方式共同作業。
  • 以客戶為重：所有努力都必須對客戶價值有直接或間接的影響。
  • 生產優先的思維：擁有生產優先的思考方式，不拘泥於功能或錯誤是在開發、測試或作業支援期間進行處理。 一切都應該在生產階段進行自動化、版本設定和微調。
  • 及早進行品質測試和快速檢錯：建議您儘早在功能傳遞週期中進行測試和安全性的檢閱、驗證和核准，來打造品質優先和快速檢錯的思維。

圖表顯示計量、KPI、習慣和商務成果之間的關聯性。計量支援 KPI，這應該與習慣一致，以達成業務成果。KPI 範例包括前置時間、部署頻率、還原的平均時間，以及變更失敗率。這些 KPI 應該符合習慣，例如: 小組自主性和組織對齊、客戶焦點、生產優先思維，以及讓品質保持左和快速。這項調整有助於達成業務成果，例如更快速上市時間、高品質、減少浪費和端對端安全性。

持續意見反應

接下來，我們來考量如何使用持續意見反應進行共同作業。

最熱門的現代化應用程式開發人員是來自新創公司。 他們為什麼會成功？ 因為他們有精簡的實務做法，不受經年累月改進的流程所阻礙。

精簡型新創公司建立了最佳的途徑，透過打造無比正面的持續意見反應文化，從中發展、交付並改進想法：

  • 及早發行，經常發行
  • 從最小可行的產品開始
  • 使用假說驅動開發
  • 透過客戶意見反應持續改進

圖表顯示連續意見反應的迴圈。我們從構想開始、建置程式碼，並測量收集資料的結果。日期將協助我們學習並產生新想法。持續意見反應會將迴圈的總時間降到最低。

透過價值流程圖持續改進

有了衡量方法和意見反應，改進便成為資料驅動的作法。

支援持續改進的有效方法之一，就是利用價值流程圖。 價值流程是組織為了交付客戶要求，而執行的一連串活動。

價值流程圖是一種非常有效的方式，可學習如何在工作進行中，查看和解決中斷連線、冗餘和缺口。 這個方式不僅是一項工具，也是以小組為基礎的方法，我們相信是經過證實的管理實務基礎。

價值流程分析可讓您分解傳遞流程，並衡量前置時間、週期時間和閒置時間，來協助小組針對工作流程依據資料進行調整。

這些衡量方式有助於小組規劃、找出效率變化，並找出潛在的流程問題。

圖表顯示傳遞程式的階段。前置時間是所有階段的總時間。閒置時間是兩個階段之間的時間。流程或週期時間會測量階段的持續時間。

提示

前置和週期時間愈短，您的小組擁有的輸送量就越大。

我們必須能夠識別不必要的非附加價值工作和必要的非附加價值工作兩者之間的差異，這有助於找出未來的流程改進空間。

不必要的非附加價值工作是真正的浪費：客戶不重視，且組織不需要進行這類工作也依然可以營運下去。 這類工作會耗損資源，也不會為產品增加任何價值。

圖表顯示前置時間包含不必要和必要的非附加價值流程時間，以及有附加價值的流程時間。

資料驅動 DevOps：衡量標準有助於引導您的旅程

DevOps 轉換是一種旅程，在 DevOps 旅程中，最好且最有效的方法是透過資料驅動 DevOps。

圖表顯示 DevOps 旅程圖的流程。Teams 開始轉換並識別快速勝出。自動化可協助低位執行者進行中度的進度。自動化會增加以手動方式處理的測試需求。技術性債務之山會封鎖進度。技術債務和增加的複雜度會導致變更的額外手動控制項和程式層，使工作變慢。持續不斷的改進工作會帶來卓越及高效能！具有優秀且傑出績效者會善用其專長，從環境中學習，追求顯著提高生產力。

最後，請考慮建立全面的方法來衡量 DevOps 的效益，並提供 DevOps 轉換計畫的透明度。 透過將重點放在突顯成功的衡量標準，建立提倡學習和實驗的文化，是 DevOps 所需要的。 與其處罰錯誤，更應該藉由獎勵正確的行為來表揚成功。