前言

從1968年第一次提出軟件工程的概念，軟件產品和系統改變了人類的生活方式，它們已經滲透到了社會的各個角落。巨大的新系統開發以及現有系統的維護需求都保證了計算機在相當長的時間內都會是個容易找工作的熱門專業。令人遺憾的是，和其他工程（如電子工程、土木工程、機械工程等）相比，軟件工程的開發是效率最低、浪費最大一個領域。Frederick Brooks（1987）在30年前就清楚地闡述了軟件系統開發的特殊性及困難點，也建議了一些可能的突破點。軟件從業者也在實踐中不斷嘗試，可惜幾十年來都沒有真正突破參照制造業形成的計劃驅動、接力開發、按預定過程執行的軟件開發模式。越來越多的人意識到這種模式不能有效支持解決軟件開發中存在的需求不確定性、技術創新要求的問題。

這幾十年來我一直從事軟件工程的教學、咨詢和研究工作。在這個過程中，我深深體會到學校教的軟件工程方法和企業實際用的開發模式都有不少不合理的地方。我們用來度量項目好壞的指標，很多時候并不能體現企業領導者真正關注的點，同時軟件過程改進的一些誤區也給企業、團隊及個人帶來了不同程度的危害，如盲目僵化地使用六西格瑪方法指導軟件過程改進；在不理解CMMI模型實踐希望解決的問題的前提下，進行評估驅動的CMMI導入。這些做法使得過程改進對組織的質量文化起了負面作用，對企業商業目標的實現沒有起到真正的支持作用。

老實說，我也發表過一些研究性的論文，在不少軟件工程會議上也做過一些案例分享，卻一直沒有觸發寫書的念頭，因為寫書真的是一個重體力活。最近十幾年來以敏捷和精益開發為代表的軟件工程革命性變革，讓我感覺到我們比以往任何時候都更加接近軟件方法開發之匙。從大的框架角度，從開發管理原則角度，從具體實踐角度，從企業實施效果角度，已經形成了一套相對完整、具備指導意義、具備系統性的新一代軟件開發方法。

摸索出一些有效軟件開發模式是我這些年投入很大精力在做的事情。如果有一本能夠充分反映這幾方面成果的書顯然具有重要意義，這極大地促使了我忽略肩周炎、腰椎間盤突出的痛苦，下決心開始碼字寫書。本書不追求所謂純粹的敏捷或精益，而是希望找到解決軟件開發中長期沒有很好解決問題的鑰匙。我一貫相信存在必有其合理性，所以這把鑰匙一定是各種模式中好的實踐的結合物。

軟件組織的管理人員、技術人員、質量人員和過程改進人員都可以從本書中獲得他們需要的知識點。本書的一個特點是希望把原因講清楚，回答好“為什么”的問題，因為理解“為什么”比知道“如何做”更重要。理解了“為什么”才能從“形似神不似”中走出第一步。貫穿本書的一個主題是如何通過敏捷、精益實踐，用低成本實現軟件產品的高價值點，時刻把握住軟件開發中的核心經濟指標，避免盲目追求可能沒有真正價值的替代度量指標。

我在近幾年做敏捷、精益培訓及實施指導中發現，大部分Scrum、極限編程、看板（Kanban）實踐者雖然接受過敏捷培訓，閱讀過一些敏捷和看板書籍，也有些實施經驗，都會提一些類似的問題：什么是正確實施方法？如何在自己特定的企業讓敏捷、精益在組織、團隊、項目中落地，使其價值最大化？許多在CMMI框架下建立了開發體系的讀者，都面臨著和CMMI模型有效結合的挑戰。希望本書能對持有類似疑問的讀者有所幫助。

本書主要包含4部分內容，相互之間有一定的獨立性。本書讀者并不一定需要有敏捷和精益的背景知識，他們可以根據自己的需求獲得有價值的幫助。前三部分的重點是討論以Scrum和極限編程為代表的敏捷實施，第四部分則是深入探討看板及新一代精益軟件開發方法。在探討Scrum、極限編程、看板、新一代精益的核心理念、架構、實踐時，我會提出具體實施的建議。這些建議包含實踐層面及理念層面的東西，體現了近年來業界對敏捷及精益的最新理解。有些建議也許會是有爭議的，這些爭議可能源于作者堅持敏捷、精益核心實踐的完整執行以保證價值最大化，也可能源于對靈活度的把握的理解不一。

由于各種原因，本書的撰寫耗時很久，未能按計劃交付，在此向一直耐心等候的編輯致謝，向一直期待此書完成的讀者致歉。作為延期的代價，我有必要將近幾年軟件開發模式及方法的新實踐追加進去，同時將一些因時間推移而價值變低的內容做些刪減。例如，新一代精益軟件開發的內容本不在本書最初計劃范圍內，但今天它已經成為不可忽略的內容，因為新一代精益模式將敏捷革命帶入了一個新的境界，它在方法論、原則、具體實踐等方面大大豐富了軟件工程的內容。

建議讀者從第1章評價項目成功標準入手，真正理解傳統開發方法和軟件產品的不匹配之處，以及造成的低效后果。在這個基礎上，讀者可以從第2章和第3章中了解到敏捷方法價值觀、框架、原則以及為何它能夠在很大程度上解決傳統開發模式的不匹配問題，并明確為什么從“先知后行”到“知行合一”是軟件開發的必然之路。從傳統的瀑布開發模式轉向敏捷主導的模式是一件痛苦的事，如何管理這個轉型也是第3章討論的問題之一。例如，導入Scrum不能保證解決企業軟件開發中的所有問題，但它會讓這些問題突出地暴露出來。實施敏捷的企業有兩種選擇：一是面對問題，努力將敏捷中對應問題的實踐作為解決方案的一部分；二是為了避免變革的痛苦，將問題埋在地毯下，僅僅引入容易在企業內部實施的實踐。令人遺憾的是，許多引入敏捷的企業選擇了第二種方式。它們也能取得一定效果的改進，但那些被忽略的實踐，往往很可能是對它們最有價值的實踐，敏捷的一些重要價值沒有得到真正的實現。

本書第二部分重點討論如何建立以Scrum為框架的軟件開發管理體系，并從有效管控技術債務角度出發，形成和Scrum框架匹配的工程實踐。我最近將業界常用的技術債務擴展成質量債務的概念（Cong,2017），這是一個非常重要的課題，是對敏捷、精益環境下的質量管理的一個新嘗試。如何有效管理技術、質量債務，做到健康迭代而不是帶病迭代，其實也是貫穿本書的一個主題。國內許多軟件組織已經引入了Scrum開發模式，從第4章到第6章，我在Scrum布局準備、管理方法的落地以及和極限編程的結合等方面中做了比較系統的整理。不論是否具備敏捷實踐經驗，讀者都可以通過一些實施案例及作者觀察到的優秀實踐，進一步理解這些章節中的內容。

本書第三部分詳細描述了CMMI和敏捷開發模式結合的有效方法，其內容是許多軟件企業非常關注的，因為目前許多國內的軟件組織都引入了CMMI開發模型。許多政府、企業項目招標時，把CMMI資質作為一個重要的評分項。當這些組織實施敏捷時，就面臨如何在CMMI框架下實施敏捷的挑戰。第7章澄清了一些敏捷和CMMI的偏見，通過實例解釋了二者的互補性。我也把CMMI研究院在敏捷和CMMI結合方面獲得的最新成果納入了相關章節中。讀者在讀第8章時，可以詳細了解到如何在敏捷環境下實施CMMI開發模型中的所有過程域，做到在合理平衡穩定度與敏捷度的前提下，不斷提升開發過程的能力。本書第三部分不僅能讓讀者對敏捷的不足之處有更深入的了解，也可以糾正一些業界常見的CMMI的價值及使用方法的偏見。為了保證讓對CMMI開發模型不了解的讀者也能看懂相關內容，我盡我的能力對模型做了通俗易懂的解釋。

本書第四部分首先重新深入探討了軟件工程和其他工程的差異，特別是其“軟”“易變”“非線性增長復雜度”“創新”等特點，讀者可以更加深入理解為什么我們遵循幾十年的，借鑒制造業的開發模式并不能高效匹配軟件系統的開發。這有助于讀者理解敏捷、精益存在的基礎，同時讀者也可以看到以Scrum和極限編程為代表的敏捷方法的一些不足之處。國內一些軟件組織已經開始引入初級精益方法——看板，我在第10章首先澄清了一些看板實施的誤區，然后重點闡述了如何把Don Reinertsen（2009）提出的支持創新的新一代精益開發方法移植到軟件產品開發中，將其原則、實踐作為精益軟件工程的核心內容。軟件的實踐者其實已經用了其中不少原則，但他們只是憑直覺，只是支零破碎地在用些皮毛。第10章從系統角度全面探討了軟件開發應該遵循的原則，這對軟件組織的管理者、工程人員、過程改進人員都會有很大的幫助。

本書不是純學術著作，而是一本結合實例講解操作方法的書。我同時希望將操作步驟背后的方法論、存在的價值解釋清楚。引入敏捷、精益是一場變革，我想清楚地告訴讀者：為什么要變？需要變什么？如何管理這些變化？如何實現價值？本書的續篇應該通過讀者的實踐來完成，如果閱讀本書能讓一些讀者受到些啟發，并開始在自己工作范圍內做一些改進的嘗試，我想，這也就達到了我寫此書的初衷。

最后我特別感謝人民郵電出版社的編輯楊海玲女士，她對本書的編寫給出了很多好的建議，付出了大量心血。再次謝謝我服務過的眾多軟件企業，這本書算是對你們的信任的一個小小回報。