前　　言

從“軟件工程”這一名詞誕生以來，“質量”和“效率”就是它的目標。IT組織大多在這條路上探尋，從最初的瀑布模型，到CMMI，很多組織曾經尊其為軟件開發過程的“圣經”。而當“敏捷運動”興起時，他們想要“做”敏捷；當聽說“持續交付”時，他們想要“做”持續交付。現在，DevOps也來了！在各種各樣的交流大會里，不斷傳來DevOps勝利的凱歌，各種媒體也在報道它的好處。很多公司又想要“DevOps”了……

我們的確聽到過一些美妙的“故事”，但它們可能都不屬于我們自己。在自己身邊，就連“如何讓大家對這些理念或實踐達成共識”都成了一大困難，這令你感到無比困擾。就像走在一團迷霧之中，耳邊一直聽到美妙的音樂響起，也隱約看到遠處的點點亮光，然而腳下的“路”卻忽明忽暗。

多年工作經歷讓我對這一領域有了新的認識，并進行總結與反思。“持續交付”是一個非常有吸引力的名字，總會讓人浮想聯翩，業務人員似乎看到了一絲希望，“所有的需求，上午提出來，下午就能拿到手”。然而，太多的企業低估了自己所面臨的困難。這些困難一部分是顯性的，如沒有自動化測試，也做不到自動化部署，主干開發更是不可想象；還有一部分困難是隱性的，例如，職能部門之間的“墻”存在已久。業務人員嫌開發團隊的軟件交付速度慢，開發團隊嫌業務人員提出的需求不靠譜。這很可能歸因于每個人的價值思考方式。

本書的目標是希望企業中所有角色轉換價值思考的角度，改進軟件服務端到端的商業價值交付方式，提升相關人員之間的協作效率，最終以安全可靠的方式快速驗證想法，縮短實現真正商業價值的時間。也就是說，本書不僅關注“從需求列表到可運行的軟件”這一過程，還提出“價值探索-快速驗證”雙環，如圖0-1所示，這也是本書的書名“持續交付2.0”的由來。

事實證明，沒有放之四海皆準的企業管理解決方案能夠完美解決每個企業遇到的問題。但是，管理者只有從整體視角出發，抵住局部優化的誘惑，才能在資源有限的情況下，引領企業創造更大的價值。本書提供了一個整體框架，給出了這個框架中各節點所涉及的原則與相關的實踐方法，同時介紹了它們的優勢與約束。

圖0-1　持續交付雙環模型

如果你將“持續交付2.0雙環模型”應用到整個企業范圍，就是一種企業級的組織管理變革指引；如果你將它引入某一個團隊，對這個團隊來說，就是團隊工作模式的改進套路。既然“持續交付2.0”是一個管理框架，企業勢必要根據自己的實際情況來進行定制。因此，書中列舉了很多實際案例，告訴你其他企業或團隊如何應用這些實踐方法，達到它們的目標。這些案例也說明，解決方案與實施路徑很難在企業之間進行復制，企業必須應用書中的原則，結合自身的實際情況（產品形態及所處的商業競爭階段、團隊的規模與人員技能水平、軟件系統架構，以及組織管理機制與文化等），逐步探索出自己的道路。