深入核心的敏捷開發：ThoughtWorks五大關鍵實踐 ( 簡體 字) |
| 作者：肖然 張凱峰 | 類別：1. -> 程式設計 -> 綜合 |
| 譯者： |
| 出版社：清華大學出版社 |  3dWoo書號： 51877
詢問書籍請說出此書號！【有庫存】
NT售價： 395 元 |
| 出版日：10/1/2019 |
| 頁數：224 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787302537342 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：推薦序1 “大象起舞”，別有一番風景
——?價值驅動的精益研發轉型實錄
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日，深圳
推薦序2
ThoughtWork敏捷開發的四大經濟價值
15年前，ThoughtWorks開始在中國技術社區推廣敏捷開發理念和實踐，由一開始被認為是一小撮離經叛道者的游戲，逐漸生根發芽，被越來越多的實踐者所接受。特別是最近幾年，商業環境的變化節奏不斷加快。科技，特別是軟件，正是在這種變化的驅動下開始在業務當中扮演核心角色。這些變化倒逼著企業尋求突破，采用高響應力的軟件開發模式，其影響也延伸到了商業的組織模式。
ThoughtWorks不是一家互聯網公司，卻是一家數字原生的組織。我們一直吸引追求卓越的專業人士，打造學習型的組織，尋求更好的方法應用科技來解決復雜商業問題。更重要的是，我們與一群難能可貴的客戶合作。這些客戶有的是以互聯網模式運營的數字化公司，也有正處于積極轉型當中的百年企業。他們的業務和組織差異巨大，但都有個共同點，就是擁有銳意進取、勇于變革的領導團隊。ThoughtWorks和這些組織一起，探索適合業務發展的技術和方法，共創科技驅動的數字化組織。在這個過程中，一線團隊并不死守教科書式的各大敏捷流派，而是在明確核心原則的基礎上，在一線生產的熱土中，反省和提煉經驗，總結核心實踐。本書就是這些實踐的生動呈現，并且深入分析了這些實踐所處的組織和管理生態，最后以企業實際所經歷各個發展階段的演進案例，以及采樣豐富的行業分析，描述了這個領域從微觀到宏觀的動態。
最近，Forrester在對大量ThoughtWorks客戶調研之后，撰寫了關于總體經濟影響（Total Economic Impact）的研究。報告以量化的度量，總結了ThoughtWorks方法為各種商業組織所帶來四個方面的經濟價值：
* 通過更快將產品和服務投入市場提升營收
* 通過縮短新客戶導流的周期加速營收的產生
* 減少維護遺留系統的成本
* 減少新開發系統的維護成本
但是，要讓實踐持續發揮上述商業價值，除了需要軟件開發團隊不斷學習，刻意練習，以至于能夠嫻熟地運用書中的核心實踐以外，還需要團隊所在公司文化和結構上的配合，也就是要把敏捷理念和方法融入運營的流程、預算和政策，我們稱其業務敏捷。
來自一線開發團隊的總結讓本書的實操性區別于世面上的其它書籍。希望本書能為打算采納敏捷方法的團隊提供有價值的參考，幫助已經起步、正在持續改進的團隊提供努力的目標。
張松
ThoughtWorks中國區總經理 |
內容簡介：《深入核心的敏捷開發：ThoughtWorks五大關鍵實踐》介紹了ThoughtWorks是如何實踐敏捷開發的，主題包括測試驅動開發、持續集成、持續交付、全功能團隊、需求分析和敏捷轉型等。ThoughtWorks經過十多年的實踐和沉淀，總結得出一套獨特的、切實可行的敏捷軟件開發核心原則、核心實踐、管理體系和敏捷轉型過程。全書共5部分18章，介紹了什么是合理正確的需求分析方法，如何采納先進和理性的技術，自適應的團隊組織形式是怎樣的，如何建立客戶價值優先的思維，如何持續改善軟件交付方法。與此同時，作者也提到了一些可能遭遇的坑，引導讀者參與思考什么是敏捷的實質。
《深入核心的敏捷開發：ThoughtWorks五大關鍵實踐》面向開發者、敏捷咨詢顧問、CIO和CTO，可以幫助他們順利導入和實施敏捷。 |
目錄：序曲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
階段一(Agile0∼1)：建立敏捷流程，縮短交付周期 160
階段二(Agile1∼3)：引入技術實踐，質量內建，減少返工 161
階段三(Agile3∼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 |
| 序： |
