本書總結了作者15年、參與近百個敏捷項目的經驗，以及從項目管理經驗中獲得的“以管理視角看敏捷”的見解，共144個提示。每個提示都是作者親身實踐的寶貴經驗，涵蓋了從項目管理到團隊協作、品質保障等多個方面。本書深入剖析敏捷管理方法論，旨在幫助讀者糾正對敏捷的誤解，并提供實踐指導。從敏捷的基本概念、團隊溝通與角色分工，到產出物構建與敏捷管理實施方法，本書全面系統地展示了敏捷實踐的框架。本書分為五大章節，是全面且實用的敏捷開發指南，為敏捷項目管理賦能。

渡會?。╓ATARAI TAKESHI），株式會社MSOL Digital事業部總監，PMI日本支部敏捷管理研究會前任負責人，日本情報處理推進機構（IPA）敏捷工作組成員。曾在Mitsubishi Space Software Co.,Ltd.和IT Innovation,Inc.任職，從事瀑布式開發項目管理工作將近20年。2008年開始接觸敏捷開發，并在中型系統集成商Advanced Soft Co., Ltd.工作期間積累了近10年的敏捷開發實踐經驗，之后轉型成為敏捷教練，并入職Mamezou Co., Ltd.，最后來到株式會社MSOL Digital任職。在近15年的敏捷工作經歷中，擁有60多個敏捷項目的實踐經驗。

高橋辰生（TAKAHASHI TATSUO），畢業于日本關西大學，工學碩士，資深項目管理專家，擁有PMP認證。早期就職于日本五大智庫之一的日本綜合研究所，在大阪、東京、紐約等地長期負責金融項目相關的管理工作。2018年加入株式會社MSOL后，組織創建國內首家第三方PMO咨詢團隊——麥嵩隆管理咨詢（上海）有限公司（任董事長兼總經理），同時負責大中華地區的PMO事業拓展和公司運營事項，也是《PMO不敗法則：100個完美收工技巧》一書的譯者。

羅晨，PMI-PMP、PMI-PBA、Scrum Master、TOGAF、EXIN DevOps Master、ITIL®4 Strategic Leader、SAFe®Practice Consultant（SPC）、SAFe® Lean Portfolio Manager（LPM）。2006年赴日本工作，深諳日本精益思想，擅長融合中日文化和管理理念，打造區域特色項目管理模式。2018年加入麥嵩隆管理咨詢（上海）有限公司，參與中國第三方PMO服務體系建設，具備傳統瀑布式項目管理、敏捷開發、SAFe及混合模式的實踐經驗，為企業提供定制化項目管理支持。曾協助全球知名互動娛樂企業導入SAFe框架，推動敏捷轉型。目前聚焦AI與PMO服務融合，助力株式會社MSOL數字化轉型。

10分鐘速讀敏捷的概述 001

敏捷背后的思考方式——敏捷宣言 013

專欄 敏捷不僅僅是Scrum 022

第1章 你真的了解敏捷嗎 02

提示001 你真的需要“敏捷”嗎 028

提示002 當“敏捷”成為最大的目標時，敏捷就會失敗 028

提示003 在歐美，“敏捷是主流”并不是事實 029

提示004 “敏捷開發方法源于歐美，不適合亞洲文化”是錯誤的說法 030

提示005 不要害怕敏捷開發方法，已有許多成功案例可供參考 031

提示006 敏捷開發方法不是萬能的（“換一種管理方法就能成功” 是不切實際的） 032

提示007 靈活應變≠敏捷開發方法 033

提示008 開始使用敏捷開發方法時，需要的不是標準而是指南 034

提示009 接受變更≠工作量無限增加，這是需要達成共識的事情 035

提示010 以瀑布式方法引入敏捷的悲劇 038

提示011 不要隨意混合瀑布式和敏捷，混合管理很困難，原因何在 038

提示012 讓自己從“一旦決定就很難改變”的束縛中解脫出來 040

提示013 在大多數情況下，必須接受從第一個迭代開始成果無法按計劃達成的事實，否則很容易一開始就失敗 041

提示014 在敏捷管理中，“允許失敗”是有很多“學問”的 042

提示015 完全交由乙方的敏捷，注定會失敗 043

提示016 被動參與的敏捷和被迫參與的敏捷 043

提示017 不了解敏捷宣言的后果有哪些 044

提示018 對于敏捷，你也許會認為即使沒有開發經驗也可以成功，這很奇怪 045

提示019 對于不熟悉敏捷的人來說，和有經驗的人一起工作是最快的捷徑 046

提示020 將敏捷應用于確定性高的項目而導致的失敗 047

第2章 團隊溝通和角色分工 049

2-1 如何使團隊溝通更為順暢 050

提示021 溝通是語言的接力，而不是理論的碰撞 050

提示022 當團隊內部的溝通停滯時，從“我覺得你說得對”這樣的 認同開始 051

提示023 有意識地創造閑聊時間 052

提示024 “有意識地查看”與“無意識地輸入”信息共享的巨大差異 053

提示025 在真正意義上，將看不見的“信息”替換為可見的“東西” 055

提示026 會議主持人不應固定由Scrum Master擔任 055

提示027 團隊規則（工作協議）的細化和遵守 056

提示028 讓第三方公司打成一片 057

提示029 對客戶保持信息公開，沒有任何隱瞞 058

提示030 導入課題管理系統 059

提示031 開發團隊內不創建次級團隊的真正原因 059

提示032 促進可持續性開發，并不意味著不允許加班 060

提示033 學會活用會議的節奏 060

提示034 如何在遠程辦公中也能實現“在一起工作” 061

2-2 敏捷團隊中各自的角色 062

2-2-1 產品負責人 062

提示035 產品負責人真的只能有一個嗎？團隊制也是一個選擇 062

提示036 產品負責人不是“客戶”，而是一起工作的同伴 064

2-2-2 開發團隊 065

提示037 起用代理產品負責人，關鍵是要讓他能完全代入產品負責人的角色來進行決策 065

提示038 敏捷開發團隊有很多事情要做 066

提示039 開發團隊不必一開始就是多面手，他們會隨著團隊的成熟而逐漸成長 067

提示040 開發團隊人數限制的陷阱 068

2-2-3 Scrum Master 069

提示041 Scrum Master不應該是敏捷團隊的主角 070

提示042 Scrum Master的真正職責是塑造一個即便沒有他也能持續成長的團隊 072

提示043 為什么讓Scrum Master同時兼任產品負責人是不好的 072

提示044 Scrum Master應該由產品負責人公司還是開發團隊公司的人來擔任 073

提示045 以現有的角色直接代入敏捷團隊是不可取的 074

2-2-4 傳統開發中項目經理的角色應該由誰來扮演 074

提示046 為什么要在敏捷方法中將項目經理的角色進行分割 075

第3章 敏捷團隊的成果 077

3-1 創建項目核心的用戶故事清單 078

提示047 需求定義書與用戶故事清單的決定性差別 078

提示048 不是優先級，而是優先順序 080

提示049 調整用戶故事顆粒度的精髓 081

提示050 用戶故事中必須寫的和不能寫的內容 082

提示051 用戶故事和INVEST的陷阱 084

提示052 從MECE（相互獨立，完全窮盡）的束縛中擺脫出來 085

提示053 怎樣對用戶故事進行拆分 086

提示054 用橫向切分的思維得出每個迭代的可交付成果 088

提示055 如果在迭代中沒能按計劃完成用戶故事應該怎么辦 089

3-2 待辦事項清單要以迭代為單位進行創建和廢棄 090

提示056 待辦事項清單與WBS的區別 090

提示057 怎么讓產品負責人參與待辦事項清單的創建 091

提示058 待辦事項清單中需要寫哪些任務 094

提示059 進度管理和適當的任務顆粒度 095

提示060 怎么處理突發任務 097

3-3 可交付成果與其質量 098

提示061 始終保持只有一個最新的“可交付成果” 098

提示062 確保產品質量 099

提示063 在敏捷中如何實現“共通化” 099

提示064 只要出現Bug就立刻將其修復是否真的有價值 102

提示065 傳統開發和敏捷開發是如何確保質量的 102

提示066 如何縮小理想化的測試驅動開發與團隊能力之間的差距 103

3-4 讓估算成為計劃的參照 104

提示067 估算在敏捷開發方法中的作用 104

提示068 由誰進行估算，這很重要 105

提示069 估算需要開發團隊全員一起來做的理由 107

提示070 估算的基準是“過去的我們” 109

提示071 在敏捷中為什么廣泛使用計劃撲克 110

第4章 敏捷的實施方法 112

4-1 通過溝通和時間管理來促進團隊運作 113

提示072 為什么越是生產效率高的團隊，越會花時間進行溝通 113

提示073 如何確定最適合自己團隊的迭代周期 115

提示074 并不是說因為是敏捷所以不按時完成也沒關系。如果不進行反省和改進，那就只是單純的拖延 118

提示075 迭代計劃與日歷之間的關聯 119

4-2 迭代開始前需要做的事情 121

提示076 不做“迭代0”的敏捷在起步時就會遭遇困難 121

提示077 項目啟動藍圖不是成果，而是讓團隊成員之間達成共識的工具 123

提示078 項目啟動藍圖類似于項目計劃書，但并不完全相等，并不是越詳盡越好 124

提示079 項目啟動藍圖不能做完后就擱置不管 126

4-3 對于敏捷來說，計劃也很重要 127

提示080 迭代計劃會議的規劃 127

提示081 做迭代計劃，等于在做群體設計 129

提示082 要記住在敏捷中，設計的時機和實施與傳統方法有著根本的不同 130

提示083 不要把迭代計劃會議分段執行 131

提示084 為什么與其他團隊比較Velocity數字是沒有意義的 132

提示085 價值實現效率大于開發效率 133

提示086 迭代計劃并不是敏捷中唯一的計劃，全體計劃也很重要 134

提示087 對“如果不發生變化的話，會產生怎樣的效果”進行持續展示的重要性 135

4-4 通過每日站會來找出變化 136

提示088 如果團隊成員開始說“進度比計劃的要慢”，那就是一種危險的信號 136

提示089 任務不應該靠“推”，而要去“拿” 137

提示090 “一直沒有異?！北旧砭褪且环N異常 ，其原因是缺乏心理上的安全感 137

提示091 每日站會中的三個問題的利與弊 139

提示092 為了在每日站會中不錯過變化，需要做什么 140

提示093 在迭代實施過程中，任務的增加真的是不可接受的嗎 140

4-5 熟練應用任務看板 141

提示094 要注意任務看板上的優先順序 142

提示095 迭代結束時如果任務看板總是呈現相同的狀態的話，則是一種異常 143

提示096 在任務看板上，應該只在進行中的任務上注明其責任人 144

提示097 看得到進行中的任務狀態的話，就能看到成員間的工作分布不均 145

4-6 燃盡圖的具體改進方法 146

提示098 舉例說明可以通過燃盡圖發現的異常 147

提示099 燃盡圖不僅僅是用來觀察進度的 149

提示100 燃盡圖的利與弊，以及如何活用燃起圖 149

提示101 燃盡圖的縱軸應該是任務數量還是估算點數 150

提示102 可以從微笑日歷中獲得的信息 151

4-7 關注任務的執行，以求能夠確實地實現可交付成果 153

提示103 10分鐘規則（有不明白的事，立刻向知道的人詢問，要打造這樣的文化） 153

提示104 在敏捷開發中如果不進行重構會怎么樣 154

提示105 開發團隊的效率提升取決于產品負責人是否能當機立斷（即使決策錯誤，也可以在下一個迭代中修正） 156

提示106 不給成員選擇的余地，強行推動配對工作或群體工作是危險的 157

提示107 只是導入敏捷工具、實踐或活動的話，并不能實現真正的敏捷 158

提示108 配置管理是敏捷的基礎 159

4-8 怎樣的成果反饋能讓可交付成果變得更好 160

提示109 成果反饋不是進度會議（只展示已經通過測試的內容） 160

提示110 當成果反饋變成由產品負責人或利益相關者進行的審查會時，該如何突圍 161

提示111 成果反饋不是用來進行公開測試的，獲得反饋才是真正的目的 162

提示112 在成果反饋中進行追責只能換來沉默的結果，試著傳達一下感激之情吧 163

提示113 讓產品負責人來擔任成果反饋主持人的意義 164

提示114 要讓全體成員都參加成果反饋 164

4-9 通過回顧促進團隊成長 165

提示115 如果停止進行回顧的話，那么團隊的成長也會一并停止 166

提示116 在微弱的聲音中往往隱藏著對團隊有幫助的意見 166

提示117 在回顧中要注意Try的欠債。在下一個迭代中確實能執行的，才算完成 168

提示118 一開始從個人層面出發即可，隨著對回顧的熟練，再逐漸 過渡到團隊層面 170

提示119 通過KPT確保心理上的安全感 170

提示120 為什么KPT模板在回顧中如此流行 171

提示121 讓一度停止的回顧復活的方法 173

4-10 通過精煉讓產品價值進一步提高 174

提示122 開發團隊的參與對于精煉來說是必需的 174

提示123 精煉的作用會隨著團隊成熟度的變化而發生變化 176

提示124 如何熟練使用探針 178

提示125 精煉的結果不能只體現在團隊內部，不能每次都與利益相關方分享的話就是失敗的 180

第5章 高級篇 如何使敏捷更加完善 182

5-1 多個團隊共同創建一個產品 183提示126 在團隊劃分上的反面教材 183

提示127 成果反饋和回顧應該共同進行 186

提示128 專家應該與開發團隊一起參加活動 188

提示129 小型產品的開發可以考慮組建聯合團隊 189

5-2 開發和運維都讓同一團隊負責 190

提示130 為了實現產品管理目的而進行的DevOps 191

提示131 如何保持開發和運維的平衡 192

提示132 為傳統的運維團隊導入敏捷，以實現工作方式改革 193

5-3 敏捷與合同 196

提示133 為什么敏捷合同基本上采用準委任的方式 196

提示134 學會利用個別合同實現敏捷 198

提示135 如果甲方和乙方的關系是對等的話，就不會被視為虛假承包 199

5-4 敏捷的理想與現實的解決方案 200

提示136 發布迭代的利與弊 201

提示137 Velocity數字應該保持穩定還是繼續增加 203

提示138 敏捷中的KPI是Scrum Master能夠體現價值的地方 206

提示139 應該專注于什么才能高效地推進（資源效率與流程效率） 208

提示140 守破離的誤用。為了不讓打破常規變成不倫不類，我們 應該怎么做 209

5-5 借助外部專家的力量 211

提示141 敏捷教練能為我們做什么 212

提示142 引入和利用A-CoE 213

提示143 敏捷啟動指南的思路 214

提示144 如何巧妙地利用敏捷培訓 216

寫在最后 218