序曲 1
第Ⅰ部分 結構反模式 2
第1 章 幸運輪盤 4
故事背景 6
背景解讀 7
反模式解決方案 7
結果 7
癥狀 8
重構解決方案 8
線上回顧 11
個人經歷 12
第2 章 無視指導原則 14
故事背景 16
背景解讀 17
反模式解決方案 18
結果 19
癥狀 19
重構解決方案 19
線上回顧 20
個人經歷 21
第3 章 深陷困境 22
故事背景 24
背景解讀 24
反模式解決方案 25
結果 25
癥狀 25
重構解決方案 26
線上活動 29
個人經歷 29
第4 章 超時 30
故事背景 32
背景解讀 32
反模式解決方案 33
結果 33
癥狀 33
重構解決方案 34
線上回顧 36
個人經歷 36
第5 章 閑聊 38
故事背景 40
背景解讀 40
反模式解決方案 40
結果 41
癥狀 41
重構解決方案 41
線上回顧 43
個人經歷 43
第6 章 無效的民主 46
故事背景 48
背景解讀 48
反模式解決方案 49
結果 49
癥狀 50
重構解決方案 50
線上回顧 52
個人經歷 53
第7 章 百尺竿頭 54
故事背景 56
背景解讀 56
反模式解決方案 56
結果 57
癥狀 57
重構解決方案 57
線上回顧 61
個人經歷 62
第8 章 政治投票 66
故事背景 68
背景解讀 69
反模式解決方案 69
結果 70
癥狀 70
重構解決方案 70
線上回顧 71
個人經歷 71
第Ⅱ部分 規劃反模式 72
第9 章 何為團隊 74
故事背景 76
背景解讀 77
反模式解決方案 77
結果 77
癥狀 78
重構解決方案 78
線上回顧 79
個人經歷 79
第10 章 親力親為 82
故事背景 84
背景解讀 84
反模式解決方案 84
結果 85
癥狀 85
重構解決方案 86
線上回顧 87
個人經歷 87
第11 章 延期死亡 90
故事背景 92
背景解讀 92
反模式解決方案 92
癥狀 93
結果 93
癥狀 93
重構解決方案 94
線上回顧 95
個人經歷 95
第12 章 草草了事 98
故事背景 100
背景解讀 100
反模式解決方案 100
結果 101
癥狀 101
重構解決方案 101
線上回顧活動 102
個人經歷 103
第13 章 忽視準備 106
故事背景 108
背景解讀 109
反模式解決方案 109
結果 110
癥狀 111
重構解決方案 111
線上回顧 113
個人經歷 114
第14 章 令人窒息的房間 116
故事背景 118
背景解讀 119
反模式解決方案 119
結果 119
癥狀 119
重構解決方案 120
線上回顧 120
個人經歷 121
第15 章 好奇的經理 122
故事背景 124
背景解讀 124
反模式解決方案 125
結果 125
癥狀 125
重構解決方案 125
線上回顧 126
個人經歷 126
第16 章 躲貓貓 128
故事背景 130
背景解讀 130
反模式解決方案 131
結果 131
癥狀 131
重構解決方案 132
線上回顧 134
個人經歷 135
第Ⅲ部分 人員反模式 138
第17 章 失望的引導師 140
故事背景 142
背景解讀 142
反模式解決方案 143
結果 143
癥狀 143
重構解決方案 144
線上回顧 144
個人經歷 145
第18 章 話癆 148
故事背景 150
背景解讀 150
反模式解決方案 150
結果 151
癥狀 152
重構解決方案 152
線上回顧 154
個人經歷 154
第19 章 沉默者 156
故事背景 158
背景解讀 158
反模式解決方案 158
結果 159
癥狀 159
重構解決方案 160
線上回顧 161
個人經歷 162
第20 章 消極者 164
故事背景 166
背景解讀 166
反模式解決方案 167
結果 167
癥狀 167
重構解決方案 168
線上回顧 169
個人經歷 169
第21 章 消極的團隊 172
故事背景 174
背景解讀 174
反模式解決方案 174
結果 175
癥狀 175
重構解決方案 176
線上回顧 177
個人經歷 177
第22 章 缺乏信任 178
故事背景 180
背景解讀 181
反模式解決方案 181
結果 181
癥狀 181
重構解決方案 182
線上回顧 186
個人經歷 186
第23 章 文化差異 190
故事背景 192
背景解讀 192
反模式解決方案 192
結果 193
癥狀 193
重構解決方案 193
線上回顧 194
個人經歷 195
第24 章 死亡沉默 196
故事背景 198
背景解讀 198
反模式解決方案 199
結果 199
癥狀 199
重構解決方案 200
線上回顧 201
個人經歷 202

本書為你而寫
我很早之前就想為你寫這本書。事實上，我準備了如此長的時間，以至於這已經成為我的家人和朋友之間流傳已久的一個笑話。
我設想，也許某個夜晚你坐在沙發上，對自己作為一個回顧活動引導師所經歷的一切感到沮喪，你迫切希望知道有人能夠幫你分擔痛苦。如果情況正如我所說，那麼這本書就是為你而寫的。我將告訴你我在回顧活動中經歷過的的所有錯誤以及它們是如何不斷地重復發生，促使我將這些反模式都寫出來。
不要因為我將這些錯誤描述為反模式而感到氣餒：在每個反模式的講解中，都包含了對其相應的解決方案的描述。大多數的解決方案都需要你在下一次回顧活動中做出不同的計劃；比如，我可能會幫你想辦法，告訴你如何記住解釋某一項活動的原因。但是，也有一些實時的解決方案，可以在回顧活動過程中針對事件自發地做出反應，例如，關於如何鼓勵人們在沉默時發言的方法。
在閱讀本書時，你可能會注意到，我在回顧活動的背景下描述的大多數反模式也可以在其他類型的會議中找到。我認為，反模式中描述的解決方案可以適用於你所引導的任何類型的會議。因為所有的會議都有一位引導師，沒錯吧？（Eckstein 2019）中也對這一點提出了支持的主張，即回顧活動的結構可以在更多的環境中使用，而不僅僅是我在上下文中所描述的那種團隊周期性活動。她描述了回顧活動如何幫助你在遠比Scrum 團隊更大的範圍內實現組織變革，而Scrum 團隊通常與回顧活動的概念相聯繫。
如果你剛開始接觸這種引導工作，可以先讀一讀我的書，因為這樣你就能注意到所有可能會遇到的挑戰。另一方面，我們不總是習慣於臨時抱佛腳嗎？我們永遠隻有在迫切需要的時候，纔願意認真學習相關的知識，所以在你開始認同這本書之前，你需要先讓自己犯錯誤。現在讀這本書可能隻會讓你笑一笑：“她真的這麼做了嗎？”“到底是什麼讓她覺得那樣說是個好主意？”不過吶，做人呢，重要就是開心。所以呢，這本書對你來說總是有價值的。
本書的誕生
在本世紀初，我擔任在丹麥奧爾胡斯舉行的JAOO 會議（現在稱為GOTO）的聯合組織者和項目主席，琳達·瑞幸（Linda Rising）在這次會議上受邀做演講。她與瑪麗·連恩·曼斯(Mary Lynn Manns)合著了《擁抱變革：從優秀走向卓越的48 個組織轉型模式》（2005）一書，她向我介紹了諾姆·柯思（Norm Kerth）的重要著作《項目回顧活動：項目組評議手冊（2001）》。我一直很喜歡聽她的演講，但這次尤為特別。回顧活動的想法激起了我強烈的興趣，我發現它對我們客戶組織的團隊以及我們公司的團隊都非常有用。在會議結束後，我讀了她的書，由此對引導回顧活動有了信心。就這樣，在2007 年，我開始引導一些回顧活動。
在這個旅程中，我接下來參加了戴安娜·拉森（Diana Larsen）的敏捷回顧活動引導課程。這次學習真的讓我看到了各種可能性和挑戰。
我很幸運能在丹麥協助戴安娜（Diana）進行後面的課程，作為老師，你學到的東西甚至比作為學生還要更多。從那以後，我一直沉迷於幫助他人和團隊進行反思及學習。我開始引導更多的回顧活動，首先是為我在IT 行業的同事，後來是在其他公司和場合中。在過去的10 年裡，我在幾十個組織中引導了百次回顧活動，並在各種會議、極客之夜以及（坦白地說）在任何能夠“洗腦”的場合裡，發表關於敏捷回顧活動引導的演講。
我讀過很多書籍和文章，看了很多演講，既有網上的，也有會上的。當然，我還學習了很多種活動技巧，但我很快就意識到，要成為一個優秀的回顧活動引導師，不僅是要知道應該應用哪些（回顧活動）活動，還有更多需要學習的內容。我花了一些時間去學習肢體語言，《身體語言密碼》（Pease & Pease 2004）讓我了解到眼神接觸、握手的重要性以及在與他人交往時自己不同的站位會造成哪些不一樣的影響。我從許多書籍中獲得了靈感，即使這些書並非直接針對引導回顧活動，你可以參閱本書末的參考文獻部分。
我丈夫經常吐槽我記性差，殊不知，正是這個所謂的毛病促使我養成來多年來一直堅持記錄回顧活動引導活動過程的習慣。我在一個黑皮小本本上記下了我嘗試過的所有技巧以及這些技巧是否有助於幫助團隊取得進步和避免陷入困境。如果我臨時想出一種方法可以重新引導一個正在兜圈子的討論，我就在本子上面用寥寥數語記錄下來。當一組開發人員需要一個正確的方向以保持會議的建設性和有用性時，我就用這個小黑本來提醒自己已經嘗試過什麼方法以及它是否有效。如果我發明或偷學了一個傻乎乎的遊戲或練習，但能夠在人們因為久坐討論而身心疲憊的時候讓他們活動起來，我也把這個遊戲或練習記下來。到目前為止，將這些筆記本中的回顧活動記錄全部加起來，我已經為27 個公司中的68 個團隊做過296 次回顧活動引導，同時我清楚地知道，在開始做筆記之前，我就已經做了很多相關的工作。
事實證明，當我使用這個筆記本的時候，它不僅能提醒我哪些工作有效、哪些無效，而且還能幫助我跟進團隊在之前的回顧活動中可能已經決定的實踐。我還為每次回顧活動寫了計劃A 和計劃B，這樣我就可以把所有的計劃集中在一起，並且從我早期的工作中獲得靈感。有些人可能會依靠自己的記憶來了解過去的成功和失誤，但這不是我的做法。當我開始引導線上回顧活動時，初我忘了用我的筆記本，使用的是在線上工具。在經歷了一些不太成功的線上回顧活動之後，我發現筆記本在線上回顧活動中同樣有用，因為它能讓我快速了解情況，並幫助我回憶。
我從2013 年10 月開始寫這本書，它其實萃取自我的“黑皮小本本”—或者更確切地說，是眾多“小黑本”。至少是對其中糟糕部分的提煉，因為這是一本關於反模式的書，所以提煉出來的都是人們曾經掉進過的“坑”、我自己犯過的錯誤以及我填坑和修正錯誤的建議。引導回顧活動的工作從來不會有兩次是相同的，如果有，那麼它本身就是一個反模式。我一直都在學習如何讓會議更有意義，如何讓團隊更好地合作。我也非常樂意向那些持懷疑態度的軟件開發人員展示—他們總是隻願意一個人靜靜地敲代碼—他們可以從每周的工作中挪出一小部分時間來與同事交流，從中獲益匪淺。
雖然學習的過程永無止境，我自己也還在不斷地學習，但我希望能與更多的人分享我目前所學到的東西。在書中和網上都能找到很多關於如何成功地引導一次回顧活動的資料，但多年以來，我還是看到很多人都在為同樣的問題而苦惱。這就是為什麼我決定將這本書構建為反模式的集合。回顧活動並不容易引導，但是，很容易被破壞或者至少使其效率降低，因此我認為出版一本反模式書籍的時機已經成熟。但是，請不要被反模式的消極影響所嚇倒。每一個反模式都包含一個對我和我所幫助的團隊非常有效的重構解決方案。
此外，當你閱讀本書中的重構解決方案部分時，請記住，在采用我的建議之前要先考慮你自己的上下文。正如過去每當我問戴安娜·拉森（Diana Larsen）在回顧活動中應該怎麼做時，她常常這樣說：“這要看具體情況。”她的意思就是，這取決於上下文。
前提
我假設，既然在閱讀這本書，說明你應該已經熟悉回顧活動和引導師的角色。如果需要復習，你可以花一些時間在互聯網上閱讀關於回顧活動的文章，當然，也可以閱讀《敏捷回顧活動：團隊從優秀到卓越之道》這本書。
我在書中添加了很多信息框來解釋那些你可能不知道或者已經忘記的概念。如果已經了解了這些不同概念所涵蓋的內容，你可以隨意跳過它們。
什麼是回顧活動？
回顧活動是一個團隊在有組織的會議中對過去進行反思和學習的機會。回顧活動的主要目的是檢查形勢，適應現實。檢查和自適應是任何敏捷過程的核心，早是隨著《改變世界的機器》（Womack，Jones & Roos 1990）一書中的日文單詞kaizen 流行起來的。為了獲得真正的檢查並能夠適應某種情況，我們需要創造一種充分信任的氛圍，在這種氛圍中人們可以愉快地分享他們的經驗。引導師要確保每個人的意見都能以某種方式被聽取，然後由團隊共同決定哪些內容需要花時間討論或是進行原因分析。回顧活動的結果通常是團隊為了改進工作方式而進行的一些實踐。或者，正如《敏捷回顧活動》（Larsen & Derby 2006）所說的那樣，回顧活動是為了讓“團隊從優秀到卓越！”回顧活動也是一個團隊分享自上次回顧活動以來經歷了哪些不同事件並獲得相互間的理解的機會。正如先父常說：“理解一切，就是原諒一切。”
回顧活動的五個階段
在回顧活動的各種定義中，《敏捷回顧活動》（Larsen & Derby 2006）將回顧活動的歷程描述為五個階段。
1．設置場景：引導師首先需要創建一種安全信任的氛圍，確保每個人的意見都能被聽取，查看之前的實踐，確定回顧活動的主題，並負責回顧活動開始前所有的必要任務事項。
2．收集數據：團隊收集回顧活動所關注的時間段內的數據（關於經驗、事件、測試、銷售等）。
3．生成洞見：團隊尋找數據背後的故事和故事背後的原因。這個階段可以以自由討論或根因分析的方式來進行。
4．達成共識：團隊根據所討論的經驗，共同決定如何改善他們的合作方式。
5．結束回顧活動：團隊決定由誰負責跟蹤實踐。引導師總結回顧活動中所發生的事情，如果他/ 她認為回顧活動有價值，可能會提供對回顧活動的評估，即在回顧活動中回顧活動。
我經常聽到有人說，在短時衝刺回顧活動中，沒有必要經歷這所有五個階段。但這種思維方式正是導致過早決策的原因，我們將在後面第1 章“幸運大轉盤”中深入描述。
什麼是模式
所謂模式，是對經常重復出現的問題進行抽像之後所得到的解決方案；是一種以文學形式來傳播經驗的手段；是對設計、編碼或其他所有領域解決方案的另一種描述詞彙。模式是一種方法，用來描述事情在組織中是如何進行的。它包含了對背景以及定義需要解決問題的影響力的描述、模式解決方案以及應用模式的成效和結果。一個模式通常會涉及到其他模式，因為在另一個模式中找到的解決方案可能會對這一模式的結果有所幫助。
相關解決方案
背景和影響力
模式解決方案
成效
結果
模式的要素
模式的概念是由建築設計師克裡斯托弗·亞歷山大（Christopher Alexander）與其合著者在《建築模式語言：城鎮、建築、構造》（1977）中提出的。僅僅十多年後，肯特·貝克（Kent Beck）在Smalltalk 報告中的文章“模式語言簡介”裡介紹了模式在軟件中的應用，並將重點放在了交流上。兩年後，這個概念因為《設計模式：可復用面向對像軟件的基礎》（Gamma et al.1995）一書而流行起來，這本書現在被稱為“GoF”，因為其四位作者被業內統稱為“四人組”。
在使用模式時，比如觀察者模式、組合模式和策略模式（Gamma et al.1995），我們隻需參考模式的名稱而不必從頭開始解釋某個設計或概念，這一點是很有用的。模式之所以有效，是因為大腦處理認知模式和認知自動化的方式。當學*件事情時，這些新知識的細節會“粘合”在我們的長期記憶中，形成一種認知模式。認知自動化或者說如何對這種模式作出反應，也和認知模式一起被灌輸進了大腦中，幫助我們認識到這是一種自己已經學會如何行動的情況，從而做出應對。我的前任經理邁克爾·卡珀森（Michael Caspersen）幾乎教會了我關於學習的所有知識，他的博士論文（Caspersen 2007）中包含許多關於大腦的認知模式和認知自動化的例子和參考。
我的博士論文（Cornils 2001）①（細心的讀者會發現，我論文上的名字並不是這本書上的名字。這是我任丈夫的姓氏，也是我當時的姓氏。順便說一句，這也是一個反模式:自己的名字，不要輕易改，至少在出版之後不要改。）聚焦於軟件模式，而且我注意到，我總是能在各種事物中發現模式，這種能力在我們人類中其實並不罕見。
什麼是反模式
反模式是描述經驗的一種方式。作為一種概念，反模式初是由威廉·布朗（William J. Brown）與他的合著者在《反模式：危機中軟件、架構和項目的重構》（1998）中命名並描述的。它是對一個經常發生問題的解決方案的描述，在這個解決方案中，結果大於成效。
本書中的反模式是由於引導師不知道如何做得更好或者沒有時間或機會去做正確的事情而造成的。也許這個解決方案曾經對另一個小組的引導師有效，因為小組成員有不一樣的溝通方式或是彼此間更為了解，但它在新的背景中卻意外地“翻車”了。
我通過給大家舉兩個反模式的例子來介紹反模式。個早期的例子導致了一場舉世聞名的大災難。1912 年4 月14 日深夜，皇家郵輪泰坦尼克號撞上了冰山。4 月15 日凌晨，它沉沒了，船上2224 名乘客和船員中有1500 多人喪生。要想了解這艘船沉沒的原因，就必須研究大量的小細節，這些小細節共同導致了這場災難。我選擇關注的是一種可以稱之為“遵從不知情上級的命令”的反模式。如果在維基百科上搜索“上級命令” ，會找到以下內容：“上級命令，通常被稱為‘紐倫堡抗辯’‘合法命令’‘隻是服從命令’或者一個德語短語Befehl ist Befehl （命令就是命令），是指一個人，不管是軍隊、執法部門、消防部隊的成員或者是平民，在法庭上對服從上級軍官或官員命令的行為不被追究罪責的抗辯。”這種反模式已經在許多地方和時間被確認過，而且，也恰好發生在泰坦尼克號的故事裡。
泰坦尼克號上的兩名無線電臺操作員為馬可尼無線電報公司工作。接線員的任務是將乘客的信息傳遞到他們在陸地上的朋友和家人那裡，以展示馬可尼公司提供的無線通信服務。另外一個因素是，公司會為每一條乘客發出或收到的信息向他們兩人付費，因此他們的收入多少是依賴於優先保證乘客的通信，而不是船對船的禮節性通信。幾乎從航行一開始，他們就收到了關於冰山的警告，並將大部分信息傳遞給了駕駛艙。不幸的是，由於無線電操作員專注於執行他們公司的命令，有一些發給泰坦尼克號的信息丟失了。因為他們的上級是無線公司的老板，而不是船長。
這就解釋了為什麼當天晚上9 點40 分，與泰坦尼克號在同一水域航行的梅薩巴號發出了浮冰警告，但這條信息卻一直沒有被傳到駕駛艙。晚上10 點55 分，附近的另一艘遊輪加利福尼亞人號發來消息，說它被冰層包圍後停了下來，但泰坦尼克號上的一位無線電操作員責備加利福尼亞人號打擾到了自己，因為他當時正忙著處理乘客的信息。
結果是，船長沒有得到浮冰情況比預期更糟的警告，所以他繼續全速航行。船一直沿著預訂航線前進，直到晚上11 點40 分，當瞭望臺發現一座冰山時，駕駛艙的工作人員纔開始給泰坦尼克號轉向，但由於它是一艘高速航行的巨輪，一切都為時已晚。泰坦尼克號的船舷沿著冰山擦過，船身破裂。我們都知道故事的結局是什麼。
通常情況下，一個背景中的模式可能是另一個背景中的反模式。例如，在泰坦尼克號的案例中，無線電操作員有義務服從上級的命令。然而，如果他們知道背景發生了變化，船正面臨著緊急情況，他們就不會盲目地服從命令，這樣做會構成一種反模式。
隨著技術和流程的改變及改進，模式也可能隨著時間的推移變成反模式。當一個好的解決方案被一個更好的解決方案取代時，對於一個反復出現的問題，原本的解決方案可能會被視為一個糟糕的解決方案。
第二個例子是微服務模式，它是（Fowler & Lewis 2014）所描述的一種設計，通過這種設計，開發人員創建一組小型服務，每個服務都有自己的功能。在軟件架構中，微服務模式被證明是可維護的、靈活的和彈性的，它被譽為是自切片面包①（和設計模式）以來好的東西。該模式促進了可獨立部署、可復用組件的開發，使開發人員能夠創建使用微服務構建的可擴展繫統。這些繫統的成功導致了許多單片繫統向微服務架構的轉變。
① 譯者注：切片面包是美式俚語，形容極好的事物，一般用作對產品、商品、發明等的贊美。
之後發生的事情，就是我們在使用模式時可能會遇到的情況：模式被濫用了。如果組織缺乏維護繫統所需的專業知識，缺乏從這種實現中受益的領域或者服務之間的邊界定義不明確，那麼微服務就可能會產生負面影響。微服務架構演進的方向之一就是復雜性增加，在錯誤的環境中，繫統會變成一個更復雜的龐然大物，而不是一套更小、定義明確的微服務。所有預期的成效（比如可擴展性、獨立性和可復用性）都會丟失，如果在錯誤的背景中使用，微服務模式就會變成反模式。應用模式的背景非常重要，而且總會有一個不適用於該背景的模式解決方案，終導致反模式。① （GoF 書中的單例模式是模式過度使用的一個絕妙示例。）