我的序言以加速

幾年前，我讀到一份報告，上面寫著：「我們現在可以自信地斷言，高 IT 效能與強勁的業務效能有關，有助於提升生產力、獲利能力和市場佔有率。」當我讀到這種東西時，我通常的反應是把它用力丟進垃圾桶，因為這通常是偽裝成科學的胡說八道。不過，這次我猶豫了，因為這是「2014 年 DevOps 狀態報告」。它的作者之一是 Jez Humble，他是一位同事兼好友，我知道他對這種廢話也過敏。（雖然我必須承認，不把它丟掉還有一個原因，那就是我在 iPad 上讀它。）

所以我改用電子郵件詢問 Jez，這句話背後是什麼道理。幾週後，我與他和 Nicole Forsgren 通電話，他們耐心地向我說明了推理過程。雖然我不是他們使用的方法的專家，但她說得夠多，足以讓我相信這裡有一些真正的分析正在進行，遠遠超過我通常看到的，即使是在學術論文中。我關注後續的 DevOps 狀態報告，但同時也越來越沮喪。這些報告提供了他們工作的結果，但從未包含 Nicole 在電話中向我說明的解釋。這大大削弱了它們的可信度，因為幾乎沒有證據表明這些報告的依據不只是推測。最後，我們這些看過內幕的人說服 Nicole、Jez 和 Gene 寫這本書，揭露他們的工作方法。對我來說，這是一段漫長的等待，但我很高興現在有東西可以真正推薦，作為檢視 IT 交付效能的一種方法，而且不只是基於幾個分析師零散的經驗。

他們描繪的畫面令人信服。他們描述了高效能的 IT 傳遞組織如何在大約一小時內將程式碼從 committed-to-mainline 轉換為 running-in-production，而較差的組織則需要數月才能完成。因此，他們每天更新軟體的次數很多，而不是每隔幾個月才更新一次，這提高了他們使用軟體來探索市場、回應事件以及比競爭對手更快發布功能的能力。這種回應能力的顯著提升並未以穩定性為代價，因為這些組織發現他們的更新導致故障的比率遠低於表現較差的同業，而且通常會在一個小時內修復。他們的證據駁斥了雙峰 IT 的觀念，即你必須在速度和穩定性之間做出選擇，相反地，速度取決於穩定性，因此良好的 IT 做法可以同時給你這兩者。

因此，正如你所預期的，我很高興他們已將這本書付梓，並將在未來幾年內不遺餘力地推薦它。（我在演講中已經使用了草稿中的許多部分。）不過，我確實想提出一些注意事項。他們很好地解釋了為什麼他們對調查的方法使他們的調查成為資料的良好基礎。然而，這些仍然是捕捉主觀感知的調查，我想知道他們的樣本族群如何反映一般的 IT 世界。當使用不同方法的其他團隊能夠證實他們的推理時，我對他們的結果將更有信心。本書已經包含了一些這方面的內容，因為 Google 對團隊文化的探討提供了進一步的證據來支持他們對 Westrum 生成式組織文化在有效軟體團隊中所扮演的重要角色的判斷。這樣的進一步工作也會讓我比較不擔心他們的結論證實了我大部分的倡議 - 確認偏誤是一種強大的力量（儘管我大多在別人身上注意到它 ;-）。我們還應該記住，他們的書重點在於 IT 傳遞，從提交到生產的過程，而不是整個軟體開發流程。

但是，儘管存在這些吹毛求疵，但它們不應該讓我們分心於本書的主旨。這些調查以及對它們進行的仔細分析，為可以顯著改善大多數 IT 組織的實務提供了最佳的理由之一。任何經營 IT 團隊的人都應該仔細審視這些技術，並努力使用它們來改進他們的實務。任何與 IT 團隊合作的人，無論是內部人員還是像我們這樣的 IT 傳遞公司，都應該尋找這些實務，以及與它們相符的持續改進計畫。Forsgren、Humble 和 Kim 已經勾勒出 2017 年有效 IT 的樣貌，IT 從業者應該將此作為地圖，加入高績效者的行列。

---