突破敏捷困境：來自敏捷實踐的144個提示

10分鐘速讀敏捷的概述 ………………………………………………… 001
敏捷背後的思考方式——敏捷宣言 …………………………………… 013
專欄　敏捷不僅僅是Scrum …………………………………………… 022
第１章　你真的了解敏捷嗎… …………………………………… 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
第２章　團隊溝通和角色分工… ………………………………… 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
第３章　敏捷團隊的成果… ……………………………………… 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
第４章　敏捷的實施方法… ……………………………………… 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　“一直沒有異常”本身就是一種異常 ，其原因是缺乏心理上的安全感 …………………………………………………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
-10　通過精煉讓產品價值進一步提高………………………………… 174
提示122　開發團隊的參與對於精煉來說是必需的 ………………………174
提示123　精煉的作用會隨著團隊成熟度的變化而發生變化 ……………176
提示124　如何熟練使用探針 ………………………………………………178
提示125　精煉的結果不能只體現在團隊內部，不能每次都與利益相關方分享的話就是失敗的 ……………………………………180
第５章　高級篇…如何使敏捷更加完善… ………………………… 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