英文原文： How To: Live and Learn with Retrospectives

　　軟件開發不是孤獨的追擊，它需要同其他開發者和其他部門協作。大多數組織建立的軟件生命周期沒有涉及到如何進行這些交互。現實是許多團隊的過程并不符合他們的要求或沒有得到一貫地遵循。當發生這種情況時，很容易讓人產生抱怨情緒，如果你已經有了改進的想法卻又無從下手，也會讓人感到沮喪。本文提供了一個工具，可以幫助你的團隊基于其日常經驗進行過程改進。回顧是工具，團隊可以利用它來產生積極的變化：從遵循過程到駕馭過程。

　　回顧是會議，讓整個團隊都參與到檢查過去的事件過程中，并對就今后如何更高效的工作進行頭腦風暴。團隊根據獲得教訓制定對應措施，并應用于自身。本文旨在說明為推動你的團隊進行回顧，你需要做些什么。

　　背景

　　術語“回顧”是由Norman Kerth在其著作《項目回顧：團隊審查手冊》[1]中創造的。書中描述了如何推動團隊在項目結束時舉行三天脫崗會議（off-site meetings），以總結經驗教訓。這種回顧是一種履行后檢查（post-implementation review）——有時稱為驗尸（post-mortems）！等到項目結束時才開始總結經驗教訓是一件憾事。在2001年，極限編程團隊將回顧納入迭代周期[2]。回顧被加入到另一種敏捷方法 —— Scrum[3]中。并且，在項目生命周期內舉行多次簡短的“心跳”回顧，是現今采用敏捷方法團隊普遍的做法，這使得他們能夠在項目進行期間就能收集和總結其開發過程的經驗教訓，而不是等到項目結束后。

　　從經驗中學習

　　沒有經過反省的經驗僅僅是數據而已。退一步說，反省我們的經驗是我們日常生活中學習和轉變的方式。舉一個簡單的例子，如果我在開車上班途中碰到了嚴重堵車，我會考慮換一條路徑，甚至用其他方式趕到辦公室。經過幾次試驗后，我會習慣于一個新的路徑。

　　如果人們不愿意做那些注定要重復的工作，說明他們并不是真正地在工作（有些瘋狂的定義）。雖然回顧始于回首往事，但這樣做的原因是為了改變我們未來的行事方法 —— 回顧是在進行長遠地轉變。有時候，我們必須重新思考我們的做法，而不是試圖以加快現有過程。

　　回顧還能改善團隊溝通。有一個古老的格言“共享的問題就是減半的問題（a problem shared is a problem halved）”。把我們的經驗復述給朋友和同事是我們日常生活中都做過的事情。在團隊的成果中，沒有人知道完整故事的始末。完整的故事只能通過整理個體經驗來了解。通過探討如何從不同的視角感知同一事件，團隊成員能夠更好的了解對方，并調整了團隊中人們的需求。

　　化解定時炸彈

　　讓我們看看如何舉行一次有效的回顧。當團隊一直受到壓力或面臨嚴重困難時，人們的脾氣可能變大了，而且團隊成員間的關系可能已經出了問題。指望通過把團隊集中在房間里一起討論近來發生的事情簡直就是奇跡，這有點不切實際。像任何富有成果的會議一樣，回顧需要明確的議程和主持人去保持會議平穩進行。如果沒有這些措施，會談很可能會充滿批評和指責。這只會使進入房間的每個人發泄他們的不滿情緒，不可能解決任何問題的，甚至還可能使問題加重。

　　回顧采用精心設計的結構來消除分歧，將重點轉移到學習和借鑒已有經驗上。基本技巧是放慢談話節奏，在完全探究大家對事件的不同看法之后，再下結論。

　　基本指令

　　檢查過去的事件但不評判發生了什么，這更容易使我們轉而問：下次是否可以做得更好? 關鍵是要采用系統思考的角度。為了對此有所幫助，應維持如下假設：問題出在系統創建期間而非個人，這是Norm Kerth所宣稱的回顧基本指令，它是所有回顧的基本原則。

基本指令：不管我們發現了什么，我們必須明白并真正相信，在給定時間、其自身的技能和能力、可用資源及最近狀態的前提下，每個人都盡力做到了最好。

　　該基本指令的意圖經常被誤解。顯然，有時候人們亂作一團時 —— 或許他們不知道有更好做法，或許他們真的很懶或很殘忍。但是在回顧過程中我們的焦點單單是做出改進，因而我們用該基本指令來幫助我們保持在處于有建設性的方式之中。至于個人的拙劣表現則最好交由管理者或人力資源（HR）部來處理，基本指令將這種交流設定在回顧的范圍之外。

　　基本規則入門

　　為了有效進行回顧，需要有人推動會議。主持人應努力營造一種氣氛，使團隊成員對談話感到輕松。

　　設置基本規則和回顧目標有助于回顧順利進行。還有一些明顯地規則是適用于大多數有成效的會議的，比如設置手機為靜音狀態。那么我們還需要為回顧增加些什么特別地規則呢？聽取每個人的意見是很重要的，因此一個重要的基本規則是“不要打斷”，如果在某個激動的瞬間該規則受到了忽視，那么你可以嘗試使用“說話棒” —— 某一時間只有一個人可以說話，即持有說話棒令牌的人（令牌不一定非是一根棒子，它可以是辦公室的任何東西，如杯子。我所工作過團隊用的是一個毛絨玩具，它比杯子更適合在屋里扔來扔去）。

　　一旦會議基本規則建立起來了，就應該把規則寫到活動掛圖紙（flipchart paper）上，并張貼在人人都能看見的墻上。如果人們開始忘記基本規則了，那么主持人的工作就是提醒大家。例如，如果有人在會議室接聽了電話，主持人應該和氣地引導其離開，這樣他的談話內容不會干擾到回顧。

　　安全檢查

　　另一項重要的基本規則是可選的，即在回顧中參與練習。有些人在小組討論中可能感到不自在或被揭發了，如果你想讓他們在回顧中作出貢獻的話，不要在他們的感覺上再雪上加霜是很重要的。當一個團隊做最初幾次回顧時，執行“安全檢查”是很有用的，以了解誰能輕松的對待談話。來一個匿名投票可以做到這一點，匿名投票要求每個人說明他們多想在回顧中發言，在小紙片上寫下范圍從1到5的一個數字（1表示“不可能分享我的觀點”，5表示“完全可以公開談論”），主持人收集并統計這些選票，將結果張貼在房間的活動掛圖（flipchart）上。此舉目的是讓與會者認識到，房間里人們相互信任程度是不同的，讓主持人評估在隨后的討論中采用何種形勢。如果個人的信任程度比較低，讓人們在更小的組里工作，并做更多的練習（人們可以匿名的寫出評論）是有效的做法。

　　動作回放

　　運動員利用動作回放來分析自己的動作并尋求改進。在回顧里與之等價的是時間線（Timeline）。

　　首先為團隊建立一個空間，將過去的事件按發生順序張貼出來；從左至右，從過去到現在。每個團隊成員用彩色便簽（或索引卡）加入時間線。主持人為每種顏色的卡片定義一重含義。例如，粉紅——消極事件，黃——中性事件，綠——積極事件。用顏色有助于在這一系列事件中顯示出圖案。會議的這一部分通常進行地很快，因為團隊成員是并行建立一個共同的圖案。

　　創建時間線的練習有幾個服務宗旨——幫助團隊記住都發生了什么事情，為團隊的每個人提供機會以張貼要談論的話題，并試圖將討論定位在實際事件而非大概的預感上。事件時間線是一個短暫的中間成果，以幫助提醒團隊都發生了什么事情，但它通常不作為回顧的最終產出。

　　總結教訓

　　一旦對事件達成了一致的觀點，團隊就可以開始總結教訓了。讓團隊按時間線從開始走到結束，其目的是確定：“什么是行之有效的，我們要記住?”，“下次有什么不同做法?” ，“什么還仍然困擾著我們?”。

　　主持人閱讀在時間線上的每個注解，并邀請他們作出評論。團隊既要找出好的經驗和也要總結壞的教訓。這個階段提醒團隊是很重要的，我們的想法是要為未來的行動計劃找出具體的解決方案。

　　作為主持人，嘗試抄寫下寫字板（或其他看得見的空間）上交流內容的摘要信息，但需與團隊一起檢查你所抄寫的東西是否準確代表了原意。記下原始表達觀點有助于顯示一個人的關切已經受到了聆聽。

　　根據我的經驗，開發者傾向于抽象地談論一些事情——產生無確實證據的觀點。作為主持人，深層挖掘、檢查假設和推論（請開發者提供具體的例子來支持其所提出的觀點）都是很重要的。

　　行動計劃

　　通常，大多問題被確定但還不能立即采取行動。團隊在開始計劃行動前必須先發現問題。團隊必須用現實的思維模式而非想象的思維模式。在迭代結束回顧中，不超過3至5項行動將是一個合理的限度。

　　在設置任何新的行動之前，團隊應該檢查在以前的回顧中是否有出色的行動。如果有，值得探討一下該行動為什么及是否需要重塑。有時人們確定行動時野心太大，需要減小他們所能實際實現的事情的范圍。對每一項行動，嘗試從下一步目標（可能是一小步）中分離出長遠目標。團隊甚至可能決定試試水，把采用新的工作方法改進流程作為實驗，在下一次回顧時檢驗其效力。區分短期修改和解決根源問題也很重要。團隊應該需要兩種類型的行動，有本書提供了好的模式，用以區分行動的類型，它是Edward De Bono所著的“六雙行動鞋”[4]。

　　每次行動都需要一個負責人負責交付，找個哥們兒并與其一起工作，以確保在下一次回顧之前完成行動，可能是一個好主意。有些行動可能是團隊外界的直接勢力范圍，需要管理層支持。為獲得支持，團隊可能需要出售這些問題！在這種情況下，你的第一個行動是搜集證據，以幫助團隊說服老板行動起來。

　　包裝

　　在結束回顧之前，主持人需要明確會議將會有怎樣的產出。團隊可以在其工作區的墻紙墻上展示其行動。或者可以用數碼相機記錄下寫字板紙/白板上的內容，照片可以上傳到一個文件共享空間或傳送到團隊的wiki上。在使產出在組織范圍內可見之前，主持人需要與團隊一起檢查公布該產出是否令人不自在。

　　完善回顧

　　進行回顧有利于磨練你的主持技巧——回顧需要準備和全程跟隨。主持人應該預先做完時間的分配工作并不時地改變練習。Esther Derby 和 Diana Larsen所著的“敏捷回顧”是新練習好的資料來源。它給出了一個粗的時間分配指導——團隊每周需要30分鐘回顧時間，按此計算，每月需要2小時、幾個月需要一整天進行回顧。

　　此外，為規劃時間和形式，主持人還需要審查：誰應該來？在哪里舉行會議？何時舉行會議？當一個團隊開始回顧，他們會發現他們團隊內部付出了大量的行動。一旦團隊有自己的房子，通常將與其他團隊交互，擴大邀請名單以包括團隊之外的人員以獲取更廣的視角，這樣做是有價值的。

　　作為團隊領導或經理，當你有觀點和看法想與大家分享的時，有時難以發揮中立調解者的角色。如果你與其他使用回顧的團隊并肩工作，那么團隊間可以互相推動。

　　作為標準做法，在我的回顧結束時，我從參與者那兒收集了“投入時間回報”率，如果你正在嘗試在組織內建立一個主持人團隊，那么收集這些參與者反饋很可能將有助于新的主持人理解他們所做的事情。

　　找到合適的會議場所能產生的效果有很大不同. 挑選一處遠離你正常工作區的會議室可以避免人們在回顧到一半又轉回到工作上。盡可能設法避免會議室的布局——圍坐在一個大桌子周圍立刻會給團隊成員之間設置巨大的障礙——取而代之，你可以把幾個椅子布置成半圓形。你還需要一下檢查室內，至少要有兩米長的干凈墻壁或白板。當一個地點被登記用作回顧時，檢查那兒有無空間能將紙掛在墻上是很重要的。有時我被安排在一個有大量墻紙、書架和古董書畫的會議室主持回顧，只好利用門、窗或在桌子的盡頭搞一個臨時的張貼空間。

　　至于時間，當工作在一個迭代計劃周期內，你需要在下一個跌代計劃之前舉行回顧。但是如果接連舉行回顧與計劃會議將使每個人疲憊不堪，因此試著將這兩個會議分成上下午，甚至單獨一天。

　　最后一句話

　　I有時我被一些想了解更多關于回顧的人問到這樣的問題，“你能舉例說明回顧能產生巨大的成果嗎?”。我已認識到這個問題類似于“你能不能講講這種疾病是如何由正規的治療方法治愈的?”

　　我曾工作過一些團隊，他們長期進行正規的心跳回顧已經使其發生了很大的變化，但這種改變是逐步的而緩慢的，他們并沒有制造頭條新聞。例如，我曾工作過的一個團隊，有一個關于在計劃產品開發跌代期間如何處理業務變更的問題。我們花了幾個月的時間才為每個人建立了計劃，但是如果沒有回顧過程可能需要更多的時間。

　　定期回顧和定期實踐的能力是他們避免了重大問題的發生，所以沒有戰爭故事或神奇的轉變是應該的！擁抱回顧有助于一個團隊以合適的步調來調整他們的過程。

　　作者簡介

　　Rachel Davies是一個獨立敏捷教練，位于在英國。 Rachel經常出席行業會議，她是敏捷聯盟的理事。 欲與之聯系，可以訪問她的網站 。

　　參考資料

　　1. “項目回顧：團隊審查手冊 ”,Norman L. Kerth. Dorset House著。ISBN:0-932633-44-7

　　2. “適應：XP風格 ”xp2001會議文件，Chris Collins 和 Roy Miller著，Rolemodel Software

　　3. “使用Scrum管理敏捷項目 ”，Ken Schwaber著。微軟出版社，2004年。ISBN:978-0735619937

　　4. “六雙行動鞋 ” Edward De Bono HarperCollins著，1993。ISBN:978-0006379546

　　5. “敏捷回顧：使好團隊變得卓越 ” Esther Derby 和 Diana Larsen著。Pragmatic Programmers，2006。ISBN:0-9776166-4-9

it知識庫：敏捷開發：如何通過回顧保持學習狀態，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。