深入核心的敏捷開發：ThoughtWorks五大關鍵實踐

序曲  ThoughtWorks的敏捷開發 1

第Ⅰ部分  核 心 原 則
第1章  敏捷宣言到底有幾句 19
為什麼寫此文 19
敏捷宣言到底有幾句 20
第2章  開發人員的客戶思維 23
開發人員與客戶思維 24
第Ⅱ部分  核 心 實 踐
第3章  基於統一反覆運算節奏的全功能團隊 33
從汽車貼膜看專業團隊 33
團隊的精進之道 37
第4章  基於用戶故事的需求及範圍即時管理 41
估算的目的 41
需求風險的壞味道和對策 44
需求的冰川 50
淺談軟體專案規模估計，到底在估什麼 53
軟體專案規模估計，怎麼估？ 57
第5章  基於持續集成和測試前置的品質內建 63
關於Gitflow 63
改善單元測試的新方法 68
超越“審，查，評”的代碼回顧 74
不做代碼審查又怎樣 76
敏捷實踐之提前驗收 82
讓我們再聊聊TDD 85
結對程式設計的正確姿勢，你學會了嗎？ 89
第6章  基於效能和週期時間的持續改進 95
看板和利特爾法則 95
點之殤 100
高效回顧會議的七步議程 107
第7章  組建人人深度參與的統一團隊 111
開不好站會？因為不同階段站會的目的不一樣 111
展示會的七宗罪 114
淺談敏捷離岸團隊溝通 119

第Ⅲ部分  管 理 體 系
第8章  為什麼你的Scrum會失敗？ 129
三個角色 130
四個會議 132
第9章  技術領導者即服務 135
責任拆解 136
技術棧管理 137
第10章  專案管理中的敏捷實踐 139
敏捷的專案管理：追求最大價值的成功 140
那麼，這個定義是正確的嗎？ 141
用戶故事 142
估算和反覆運算計畫 143
反覆運算會議和功能演示 144
站會和用戶故事開卡 145
代碼審查和回顧 145
最大程度的視覺化 147
溝通計畫 148
結語 150
第11章  也談精益 151
追求快速價值交付的小批量生產模式 152
追求極致卓越的生產匠藝 154
結語 155

第Ⅳ部分  轉    型
第12章  團隊敏捷轉型的三個階段 159
階段一(Agile 0～1)：建立敏捷流程，縮短交付週期 160
階段二(Agile 1～3)：引入技術實踐，品質內建，減少返工 161
階段三(Agile 3～5)：提升價值交付效率和回應力 165
結語 166
第13章  績效考核，敏捷轉型的鴻溝 167
敏捷轉型過程中的必然挑戰 167
傳統績效考核 169
績效考核的困境 170
如何破局？ 171

第Ⅴ部分  案    例
第14章  一個交付故事 179
技術帶來的新挑戰 179
自治團隊的演化 181
第15章  又一個交付故事 185
明線：所有權？經營權？決策權？監督權？ 185
暗線：尋找時間之矢 188
第16章  一個遺留系統自動化測試的七年之癢 191
背景 191
七年之癢：痛點 191
問題分析 192
解決問題 193
第17章  如何在團隊建設工程師文化？阿裡資深技術專家這麼做 197
工程師文化與KPI文化 197
敏捷 200
基礎技術團隊實踐 200
第18章  敏捷轉型下的團隊管理：來自一線管理者的思考 207
管理者的“神光”並不總是好事 209
敏捷轉型下管理者應該如何自處？ 210
需要團隊管理者首先要做到信任和放手 210
自組織團隊需要適度的灰度管理作為土壤，以管理者的自律來澆灌 210

附錄  2017中國企業敏捷實施的調查與反思 213
參考文獻 225
 
 

推薦序
“大象起舞”，別有一番風景
—— 價值驅動的精益研發轉型實錄

2019年7月30日早上8:30，深圳南山科技園招行研發大樓，步履匆匆的上班族；8:45，每一層的員工圍向各自工作區域的看板，開始每日站會，面對面溝通當天工作。已使用電子看板的開發室組，深圳、杭州、成都三地同事在同一個看板上進行遠端即時溝通。9點左右，站會結束，緊張充實的一天開始了——這是招行資訊技術部深、杭、蓉三地6500多員工（含外包）每天工作的開始。
從2015年看板和敏捷SCRUM的引入，到2019年7月全面規模化精益研發
轉型，招行經歷了四年多的時間。事實上，規模化精益研發轉型並沒有相對成熟的可參考的案例，尤其對於監管嚴格的大型銀行科技部門，一路走來，可以說一直摸索著前進。值得欣慰的是，招行有一群致力於工程管理、過程改進，有責任心和使命感的SPI（Software Process Improvement）人，始終緊緊圍繞科技的目標及痛點，瞄準“價值”“品質”“效能”，持續開展前瞻性研究、試點，立足當下，著眼未來，腳踏實地，敢於創新，摸索出一條適合招行的精益研發轉型之路，這個過程可謂環環相扣、步步為營，推動招行科技在支持全行業務發展的新時期未雨綢繆、佔領先機。這個過程中，招行與ThoughtWorks諮詢事業部精誠合作，共同探索，為轉型輸入了先進的理念和方法。

與大多數銀行科技組織一樣，招行的軟體工程管理大體分為三個階段，如下圖所示。

讓我們看下幾個重要的時間點。

* 2009年和2013年，招行科技分別通過了CMMI2級和3級的認證，建立了軟體過程管理體系，專案開發的過程能力和品質相對穩定，積累了軟體工程管理、過程改進等方面經驗，尤其培養了招行IT人的規範化工程管理素質。

* 2015年，面對互聯網金融的衝擊和市場競爭，如何提高需求回應速度和交付速度，如何把有限的IT資源投入到更有價值的需求開發中，是擺在科技面前首要解決的痛點。當年，招行與ThoughtWorks合作，開始在個別相對獨立的軟體產品上試點敏捷SCRUM開發；同年，引入了“看板”在基層開發組織落地，並著手研究和規劃DevOps流水線建設，積累了一些反覆運算開發的經驗。

* 2016年下半年，一個問題自然擺在面前，面對業務不斷增長的需求及快速交付的呼聲，90%的傳統開發專案該何去何從？11月，總結敏捷試點經驗，秉承循序漸進的改進原則，確定了雙模的“精益研發轉型”目標和方向。

* 2017年初，招行確定了Fintech戰略，首次提出了“科技敏捷帶動業務敏捷”的要求。6月，敏捷產品模式從幾個業務片區做起，逐步形成套路，開始推廣到其他片區。著手培養招行內部的精益教練隊伍。

* 2018年9月，總結提煉三年多的經驗，確定精益研發管理與工程實踐集，明確雙模的定義及使用場景，創新提出“過程制定選擇”機制，正式發佈了 “價值驅動、品質為先”的“精益研發管理體系V1.0”，軟體工程管理翻開了新的一頁。

* 2019年3月，招行科技啟動規模化精益研發轉型，截至7月底，近60%科技隊伍轉入精益研發模式，可以預見在不久的將來，招行科技將全面完成精益研發轉型。

值得一提的是：招行不但沒有放棄、而是繼承了原有軟體過程管理體系(CMMI)的框架，保留了原有體系中經過多年驗證有效的過程及活動，在此基礎上總結、吸收了這幾年試點的精益、敏捷的理念及核心實踐，重構工程與管理實踐集，建立新的價值驅動的端到端的軟體生命週期，改變原來串列的來料加工式的開發模式，真正形成從產生想法到上線運營資料分析的閉環。研發模式上，明確“精益專案”和“敏捷產品”兩種模式，及相對彈性的定制選擇機制。這些是招行精益研發管理體系的核心。

思想上統一認識，行動上才有一致的可能，我們總結提煉了“精益研發”的願景、目標及四項原則：

* 願景：打造招行端到端的精益研發管理體系，價值驅動、品質為先，以行業領先的科技能力驅動創新與變革。

* 目標：更高的產品品質，更快的交付速度，更好的客戶滿意度，更高的研發效能，建立生機型文化氛圍。

* 原則：價值驅動，品質為先；快速回應，高效執行；尊重信任，緊密協作；持續改進，追求卓越。

精益原則已納入招行科技組織級的價值觀中。其核心是“價值驅動”，這也借鑒了ThoughtWorks“價值驅動的業務創新管理框架”的理念。這四個字不僅僅是指業務價值，也包含IT自身的價值衡量，比如如何優化IT內部流程，盡可能減少浪費，如何在關鍵的技術環節強化決策等等。同樣，“緊密協作”不僅僅是深化IT與業務的融合，IT內部的開發、測試、運維等等，也需換位思考，緊密協作。

招行始終堅持走演進式而非顛覆性的持續改進之路，注重“體系化、結構化、規範化”，時刻聚焦轉型的“願景和目標”。2017年，招行Fintech戰略的落地，也推動了業務部門的思想轉變，使IT與業務融合走向深入，為精益研發轉型提供了有利的條件。

規模化轉型落地方面，繼續發揮EPG（Engineering Process Group）工作組牽頭作用，從願景和目標分解出幾大專項工作，強化組織級的推進，逐年扎實落地，

* 重構軟體過程管理體系及資產庫。戰略上，“願景-目標-原則”，層層分解、保持統一；戰術上，“領域-實踐-定制選擇”，針對每一個跨職能交付團隊的痛點和目標，定制選擇合適的開發模式和實踐（含管理實踐和工程實踐）。

從業務（產品）片區入手、相對彈性的定制選擇（而非全盤強制執行）、變“要你做”為“我要做”，是招行精益研發管理體系的一項創新。定制重點考慮的因素有：業務戰略重點、需求的連續性及特點、軟體交付期望、業務架構與系統架構狀況、CICD成熟度、業務方的能力與參與度、資源情況等等，針對性地選擇相匹配的研發模式及實踐，形成各自特色的實施方案，重點強化業務IT緊密協作，真正解決研發過程中的痛點與難點。 

同時，根據產品發展的狀態及市場績效的變化，定期對方案進行適應性檢視，並提供研發模式之間的轉換及多模的協同機制。

* 全面推行精益看板。看板是招行最早引入的精益實踐，招行一開始就把看板定位于基層開發室組（<=12人）的跨組織管理與工程管理的工具（而不僅僅局限於反覆運算管理），建立了招行看板應用的成熟度模型，全面推廣，逐年提升應用能力。推廣的前期側重於組織管理，後期隨著精益研發的深入，與新的軟體生命週期緊密結合，側重於工程管理及效果，聚焦資源效率和流動效率，與精益轉型形成1 1>2的態勢。看板的全面推廣，在工作透明化、限制在製品、加快工作流動、高效溝通、建立自組織文化氛圍、提高基層小組織的活力等方面發揮了重要作用。

2017年，招行開始著手電子看板的自主開發，截至2019年7月，已有2/3的物理看板遷移到電子看板，在功能上與專案管理、DevOps流水線、度量分析平臺等實現無縫連結，可以說開闢了大規模IT組織研發過程數位化的嶄新道路，未來也必將是招行精益轉型取得更大成效的重要利器之一。

* 建立持續交付的DevOps流水線。工具平臺對研發管理來說可謂如虎添翼。DevOps在招行精益研發體系中佔據重要位置，也是規模化精益轉型的核心支撐。早在2015-2016引入敏捷SCRUM的同時，招行即著手研究“DevOps”理論與實踐，2017年形成招行的DevOps實施框架和路線圖，並提出目標：建立適應招行特點的端到端的持續交付“高速軌道”，更快地交付高品質的軟體產品，全面支援精益研發轉型。幾年來，招行大力投入資源推進工具平臺建設，優化整合原有的工具資產，並將精益管理實踐和工程實踐有機結合，形成工具生態鏈，為規模化轉型提供了強有力的支撐。

* “精益需求分析”，轉型的核心實踐，沒有之一。要達成“價值驅動、快速反覆運算交付”的目標，必然要求在需求側做好兩件事：一是結構化分解業務目標，做好價值分析與決策；二是分解及細化需求，形成MVP，建立和維護需求動態優先順序清單，做好版本規劃。這兩點是精益需求分析的根本目的，也是研發轉型的前提。傳統專案開發始終困擾的需求不清晰、需求分解問題（結構化、條目化）、無法排出優先順序、需求價值無法衡量和驗證等諸多問題，在精益需求分析實踐中一一考慮解決。這是個艱巨的任務，但又是PO或BA必須掌握的能力，唯有迎難而上。

* 內部賦能，能力自建。2015—2016年招行與ThoughtWorks合作引入敏捷Scrum期間，當時的教練主要以外部為主，2017年起，招行開始建立內部教練的培養機制，加大內部精益教練（包括管理方向、技術方向）的培養力度，因為我們認識到，面對幾千人的規模化精益轉型，僅靠外部資源遠遠不夠，培養內部教練隊伍，加強能力自建，才能更好做到及時回應、務實有效，也才能走得長遠。兩年多時間，招行培養了近100位的精益教練，開展各項社區、開放日活動，營造精益敏捷文化氛圍。不但QA隊伍全面轉型精益教練，各開發團隊也逐步培養自己的教練隊伍，一方面在轉型中輔導內訓、回饋問題，發揮佈道者作用，另一方面這支隊伍在適當時候轉身QA角色，開展背靠背的審計活動，監督執行過程，自我發現問題，自我持續改進。

* 建立精益研發度量體系。資料讓我們知道現在的能力與目標的差距，瞭解自己的現狀，為管理決策提供依據。度量分析是招行從CMMI2級就開始建立的組織級重要能力，多年來招行堅持用資料說話，所謂“來自一線、服務一線”。精益研發轉型，也同樣從願景和目標分解出可度量的指標，同時優化度量分析平臺，與電子看板等數位化管理工具結合，為專案、團隊、組織級提供及時的指標資料，助力轉型效果的自我量化分析。

“不忘初心，方得始終”，每年底，EPG工作組對標精益轉型的願景與目標，組織專題研討，提出下一年度的目標和具體行動計畫，採取“方案-試點-驗證-形成規範-發佈推廣”策略，協同作戰，穩步推進。研發模式與實踐的定制選擇、自我能力建設、自我度量分析、自我回顧改進等，逐步形成良性迴圈，自驅式的生機文化在招行科技隊伍中慢慢生根發芽，也即將蔚然成風。

當前，招行科技又提出“從精益研發到精益組織”的目標，可預見的未來必然是：“大象起舞”別有一番風景——轉型，我們仍在路上。

歐紅
招商銀行總行資訊技術部  專案辦&EPG負責人
過程改進與管理變革資深專家
2019年8月19日，深圳