改善閃電戰：Toyota 生產系統的啟示#
Toyota 生產系統中有一個稱為 improvement blitz（或 kaizen blitz）的實踐——在數天的集中時間內，專注解決某個特定問題。Dr. Spear 解釋：「一群人聚集在一起，專注於一個有問題的流程……閃電戰持續幾天，目標是流程改善，方法是集中利用流程外部的人來指導流程內部的人。」
其產出通常是解決問題的新方法——如新的設備佈局、傳遞資訊的新方式、更有組織的工作空間，或標準化的工作。
Target DevOps Dojo 的實踐#
Target 的 DevOps Dojo 是改善閃電戰的 DevOps 版本。Ross Clanton（Target 營運總監）負責加速 DevOps 的採用，其主要機制是 Technology Innovation Center（即 DevOps Dojo）。
Dojo 佔地約一萬八千平方英尺的開放辦公空間，DevOps 教練在此幫助 Target 各技術組織的團隊提升實踐水準。最密集的形式是 30-Day Challenge：
- 內部開發團隊進駐一個月，與 Dojo 教練和工程師合作
- 團隊帶來自己的工作，目標是在三十天內解決一個他們長期掙扎的內部問題
- 在三十天中，團隊以兩天為一個 sprint 密集工作，進行規劃、執行和展示
Ravi Pandey（Target 開發經理）說：「過去我們要等六週才能拿到測試環境。現在幾分鐘就拿到了，而且我們與 Ops 工程師肩並肩工作。」Clanton 補充：「團隊在幾天內就能達成原本需要三到六個月的成果。」
Dojo 還支援較不密集的模式：
- Flash Builds：一到三天的活動，目標是在活動結束前交付 MVP 或某項能力
- Open Labs：每兩週舉辦一次，任何人都可以來 Dojo 與教練交流、觀看展示或接受訓練
制度化償還技術債務的儀式#
我們需要安排儀式來強化為 Dev 和 Ops 保留改善工作時間的做法。最簡單的方法之一是安排和舉行為期一天或一週的改善閃電戰：
- 團隊中的所有人（甚至整個組織）自組織來修復他們關心的問題
- 不允許功能開發工作
- 問題可以是程式碼、環境、架構、工具等任何領域
- 這些團隊橫跨整個價值流，通常結合開發、營運和資安工程師
- 每個團隊在期末向其他人展示他們的改善成果
改善閃電戰的目標不是單純地實驗和創新以嘗試新技術，而是改善日常工作——解決每日的權宜之計。雖然實驗也可能帶來改善，但改善閃電戰非常專注於解決我們在日常工作中遇到的具體問題。
這類儀式的其他名稱包括：hack days、hackathons、20% innovation time、spring or fall cleanings、ticket queue inversion weeks。不幸的是，hackathon 有時候聚焦在產品創新和原型設計新市場想法，而非改善工作，且通常僅限於開發人員——這與改善閃電戰的目標大不相同。
改善閃電戰的力量#
改善閃電戰如此強大的原因在於：我們賦權那些最接近工作的人，讓他們持續識別和解決自己的問題。
Dr. Spear 用蜘蛛網來比喻：我們的複雜系統就像蜘蛛網，絲線不斷弱化和斷裂。如果正確的絲線組合斷裂，整個網就會崩塌。沒有任何命令與控制式管理能指揮工人逐一修復每根絲線。我們必須創造組織文化和規範，讓每個人都能在日常工作中持續發現和修復斷裂的絲線。
正如 Dr. Spear 所觀察的：「難怪蜘蛛會在絲線出現裂痕和撕裂時就修復，而不是等待失敗累積。」
Facebook Hackathon 的案例#
Mark Zuckerberg 描述：「每隔幾個月我們就舉辦一次 hackathon，每個人都為自己的新點子建造原型。活動結束後，整個團隊聚在一起看看所有被建造出來的東西。我們最成功的許多產品都來自 hackathon，包括 Timeline、聊天、影片、行動開發框架，以及一些最重要的基礎設施如 HipHop 編譯器。」
HipHop PHP 編譯器的故事特別值得注意：2008 年 Facebook 面臨嚴重的容量問題。在一次 hack day 中，Haiping Zhao 開始嘗試將 PHP 程式碼轉換為可編譯的 C++ 程式碼。兩年後，HipHop 編譯器讓 Facebook 的平台能處理比原生 PHP 高六倍的生產負載。後來的 HHVM 專案進一步改善了效能，到 2012 年完全取代了 HipHop 編譯器。
讓每個人都能教學與學習#
動態的學習文化創造條件，讓每個人不僅能學習，還能教導——無論是透過傳統的教學方法（課程、訓練）還是更具體驗性的開放方法（研討會、工作坊、導師制度）。
Nationwide Insurance 的 Teaching Thursday#
Steve Farley（Nationwide Insurance IT 副總裁）說：「我們有五千名技術專業人員。自 2011 年以來，我們致力於創造學習文化——其中一部分是我們稱之為 Teaching Thursday 的活動，每週撥出兩小時讓每位同仁教學或學習。」
跨領域技能的重要性#
隨著越來越多技術價值流採用 DevOps 原則和模式，Operations 和測試工程師越來越需要熟悉開發技術、儀式和技能，如：
- 版本控制
- 自動化測試
- 部署管線
- 配置管理
- 建立自動化
National Instruments DevOps 轉型的 Karthik Gaekwad 說：「對於正在學習自動化的 Operations 人員來說，這不應該是可怕的——只要去問一個友善的開發者，因為他們很樂意幫忙。」
分享 DevOps 研討會的經驗#
為了建立學習型組織，我們應該鼓勵工程師（開發和營運）參加研討會、在會上演講，必要時也創建和組織內部或外部研討會。
DevOpsDays 仍然是今日最活躍的自組織研討會系列之一，許多 DevOps 實踐都在這些活動中被分享和推廣。DevOps Enterprise Summit 則於 2014 年創建，讓技術領導者分享在大型組織中採用 DevOps 的經驗。
企業內部研討會的案例#
許多公司也舉辦內部技術研討會：
- Nationwide Insurance：2011 年創建內部技術研討會 TechCon
- Capital One：2015 年舉辦首次內部軟體工程研討會，有十三個學習軌道和五十二個場次，超過 1,200 名內部員工參加
- Target：自 2014 年以來舉辦了六次內部 DevOpsDays 活動，在內部技術社群擁有超過 975 名追隨者
建立內部諮詢和教練以傳播實踐#
建立內部教練和諮詢組織是跨組織傳播專業知識的常用方法。例如在 Capital One，指定的主題專家定期舉辦 office hours，任何人都可以前來諮詢和提問。
Google Testing Grouplet 的案例#
Google 的 Testing Grouplet 是由 Bharat Mediratta 和 Nick Lesiecki 組成的自發性團隊，使命是推動自動化測試在整個 Google 的採用。他們沒有預算也沒有正式權力，但利用了多種創新機制：
Testing on the Toilet（TotT）：每週在 Google 全球幾乎每間辦公室的每間洗手間張貼測試相關的通訊。目標是「提升整個公司的測試知識和精進程度」。
Test Certified（TC）：提供了一個改善自動化測試狀態的路線圖：
- Level 1：快速建立基線指標
- Level 2：設定政策並達成自動化測試覆蓋率目標
- Level 3：朝長期覆蓋率目標邁進
Test Mercenaries：全職的內部教練和顧問團隊，與各團隊實際合作改善測試實踐和程式碼品質。
Fixits：全公司性的改善閃電戰。Mike Bland 描述為「當普通工程師有了想法和使命感，招募所有 Google 工程部門進行為期一天的密集衝刺，進行程式碼改革和工具採用。」他組織了四次全公司 Fixit，最後一次涉及超過二十個辦公室、十三個國家的一百多名志願者。
結論#
本章描述了如何建立儀式來強化學習文化——我們都是終身學習者，我們重視改善日常工作勝過日常工作本身。我們透過以下方式實現：
- 保留時間償還技術債務
- 創建論壇讓每個人都能互相學習和教導
- 提供專家來幫助內部團隊——無論是教練、諮詢或開放辦公時間
透過讓每個人在日常工作中互相幫助學習，我們在市場上超越競爭對手。但我們也幫助彼此實現作為人的全部潛能。