Retrospective--The Way To Make Things Better

標籤：回顧   流程改善   

本文討論回顧（Retrospective），使用英文做文章標題有兩個方面原因：一個是回顧這個詞現在很多人都在用，從中文字面上看可能對它並不感冒，覺得回顧是一件很簡單可做可不做的事情，但事實上做回顧很難也很重要，所以用一個看上去很多人都不一定認識的英文單詞來做強調；另一方面文章的副標題用的是“the way to make things better”，個人很喜歡這句話，覺得我們日常的工作、學習、為人處世不就是想把事情做好一點嗎，所以用這句話和大家共勉。

回顧這個詞最近見得比較多的一個可能原因是因為敏捷開發的如火如荼，對敏捷領域而言，尤其是Scrum，回顧是作為整個架構中的一個步驟來執行的，很多學者認為回顧是敏捷開發中最需要做的一件事情，個人也深表贊同。尤其是在團隊尚在成長期，面臨研發過程中諸多問題的時候，回顧就是我們手中的武器，是要緊緊握在手裡，時刻不能丟掉的。同時，因為回顧在敏捷領域受到的廣泛關注，平時在團隊中推行回顧的時候很大程度上參考了現有的一些著作和資料，其中受Esther Derby和Diana Larsen合著的《Agile Retrospectives: Making Good Teams Great》啟發最大，本文中也大量參考和引用該書中的一些思路和做法。

一. 為什麼我們要做回顧？

在項目/產品研發過程中的某個時段，結合并不成熟的團隊狀況，或多或少會面臨研發管理不合理的現狀，比較典型的有：

• 多項目交叉
• 分布式、多部門協作
• 開發資源、任務並行
• 項目缺乏計劃性
• 產品缺乏創新點

這些現象導致的結果歸根結底就是進度上的問題，無論是項目按計劃驗收還是產品根據市場快速做出反應，時間永遠是軟體企業最需要把控的一個核心要素，對互連網公司更是如此。但當因為研發過程中產生這種那種的問題導致進度不盡理想時，大家有想到要做些什麼嗎？

要做的事情有很多，個人認為首當其衝的就是“Stop And Thinking”，包括兩個主要方面：

• 檢視（Inspect）：檢查和診視。通過分析現狀、收集資料、頭腦風暴等方式總結和梳理團隊目前存在的問題，包括需要量化的過程記錄性資料作為流程改善的輸入以及流程改進點本身存在的問題這兩個主要方面。
• 調整（Adapt）：流程改善。有了量化的資料和流程改進的突破點，就可以確定調整策略和下一步的工作計劃，並落實責任人。

“Stop And Thinking”體現的就是回顧思想，個人認為回顧是流程改善中諸多方法論和實踐的一個集合體，也和品質管理領域中的主流思想是一致的，回顧本身也是如下PDCA環（戴明環）的一種具體體現：
二. 怎麼做回顧？
怎麼做回顧？答案是通過回顧會議。開會的目的是分析資料、剖析流程並在團隊層級形成統一認識。回顧會議的相關主題有：
1. 會議的流程

回顧的流程可以分為5個部分，當然各個團隊可以根據實際情況進行調整和裁剪，但會議的輸入、輸出和議程應該是一致的：

1. 確定目標：確定本次回顧會議中需要改進的目標，一般一次回顧會議1~2個目標是最合理的
2. 收集資料：為了對改進過程有量化的標準，需要進行資料收集。資料來自日常研發過程中與該改進目標相關的方方面面
3. 激發靈感：使用資料進行集思廣益，通過各種激發靈感的工具和活動讓團隊成員提出自己的想法
4. 決定做什麼：收集團隊中的靈感並進行討論和分析，最終確定下一步的目標
5. 總結收尾：總結本次回顧會議的過程和成果並落實行動計劃和責任人

其中前兩步需要在會議前完成，回顧會議的目的是對研發過程中的客觀資料進行分析從而得出結論和行動計劃。

2.會議召開的時機在Scrum中，回顧會議召開的時間是在一個迭代結束之後，在《Agile Retrospectives》這本書中，兩位作者也是提出類似的觀點，但前提是團隊正在使用基於迭代的敏捷方法進行研發管理。並不是所有團隊都會採用敏捷方法，如果團隊沒有採用敏捷方法，個人認為以一定的節奏定期開展回顧會議是一項最佳實務，如果是不定期開展回顧活動，過程的節奏感和持久性上會大打折扣，可能導致後續大家都對回顧失去興趣。關於回顧和傳統周會本文後續還會有進一步闡述。3. 參與者和期間

回顧會議的參與者不要太多，主要包括：

• 團隊成員：執行流程改善的整個團隊，確保需要參加的人員都到位
• 顧問：顧問很多時候是需要的，顧問可以來自其他職能團隊，也可以是其他研發團隊中有回顧和流程改善經驗的同事

回顧會議的期間上會因為回顧目標和主題的不同而有所不同，但通常建議在半小時到一小時之間。
4. 背景和目標回顧會議的背景和目標視具體的回顧主題而定，本文後續的情境分析中會提到幾個具體的執行個體。
5. 活動和工具回顧會議流程中的每一個環節都可以使用一些有效活動和工具進行工作的展開，有些活動和工具來自傳統品質管理領域，如魚骨圖；有些則在團隊建設中被廣泛使用，如頭腦風暴。但無論使用那種活動或工具，都是圍繞著具體目標的特點而定。個人平時使用比較多的活動和工具有：

6. 產出和行動回顧會議的產出通常是團隊對具體改進目標的統一認識和行動計劃，這些行動計劃有些面向具體一個工作點，則改進的效果相對比較容易衡量；有些則面向工作流程，而流程的改變通常需要一段時間，故這類行動計劃的有效性需要在後續的回顧會議中時常進行總結和討論以確定其推進的方向上是否還具有時效性和可行性。
三. 情境分析

本節將根據上文中的回顧會議流程進行一些情境分析，協助大家瞭解和掌握回顧會議中的具體做法和注意點。文中的執行個體可能並不適合所有的團隊，僅供參考。

1. 確定目標

確定目標有兩個活動，分別是“聚焦”和“不良反應響應”。聚焦是主動地去關注研發過程中的某一個潛在需要改進的點，而不良反應響應通常是因為發生某個事故導致我們不得不被動的去應對這些事故並探討是否有可以避免再發生該類事故的方法。從品質成本的角度講，聚焦是一種一致性成本而不良反應響應是不一致性成本，日常研發過程中如果有條件的話應多採用聚焦的方法以降低品質成本。

下面是一個聚焦的例子，我們關注Jenkins使用方式，發現有若干次構建失敗的情境，根據團隊工作的規則，可能就需要觸發我們去召開回顧會議看看是什麼原因導致Jenkins構建工作會經常性的出現問題。通過回顧我們通常會得出代碼提交、系統整合方面流程上的不規範性，從而進一步確定相關規則：

關於不良反應響應的例子也很多，下面就是一個內部服務發布缺少配置導致相關功能測試失敗的例子，從這個不良反應中我們也可以看出服務發布的流程上缺乏相應進行伺服器配置的校正工作，所以也可以在回顧會議上展開流程方面的討論：

2. 收集資料收集資料一個有效活動就是”時間表“，如果團隊維護著這麼一份時間表，則每天發生的問題都會有一個明確的記錄，這些記錄就為我們的回顧活動提交了無可辯駁的回顧資料，通過對這些資料進行分析，我們就能進行靈感的觸發，從而找出解決問題的思路。下面是一個服務發包失敗記錄的時間表執行個體：
資料也可以在日常研發過程中各種非正式場合下進行收集，如每日例會和各種團隊交流等。
3. 觸發靈感

“頭腦風暴“是我們經常使用的一種觸發靈感的活動，下面是需求和UI介面匹配問題團隊成員之間一次簡單的頭腦風暴，通過討論大家就工作流程做了一項改進：

表現端端開發人員：需求文檔中的介面和UI中的介面不是很一致，我處理起來要返工。
伺服器端開發人員：我是參考需求文檔中的介面設計的介面
需求分析師：嗯，兩者應該盡量統一
專案經理：那我們以後UI出來之後，BA和UED碰一下頭之後再發布給開發

“5個為什麼“也是敏捷領域比較推崇的一個流程改善實踐，原理很簡單但確實很有效。下面是對某專案服務器部署失敗而進行的“5個為什麼“分析，並最終確定開發人員在服務發布之前與發布人員進行溝通和確認是保證該流程正確執行的一項有效實踐：

下面是一張”魚骨圖“，魚骨圖又叫因果圖、石川圖，是品質控制領域最具代表性的分析工具之一，也被廣泛使用到流程改善中。圖中從研發團隊的各個方面出發找出導致開發效率低的原因，從而為我們後續的行動計劃指明方向：

“學習矩陣”相對比較少用，但在有些情境下也是我們可以用來進行靈感觸發的有效工具。如，針對分布式協作下的團隊開發，我們首先總結做得好的和做得不好的方面，再看看有沒有新的想法，如果實現不行我們也可以看看找誰幫忙，這些過程性成果都可以通過類似的學習矩陣進行細化和明確：

4.  決定做什麼

關於決定做什麼，雖然後續工作安排取決於具體的目標，但個人認為有兩個方面我們需要注意：

• 關注流程：從點覆蓋到面是我們梳理流程的一個目標。例如，從Jenkins打包失敗這個點提出在流程上需要進行提交代碼前先本地打包這一覆蓋到面的改進；再如，從測試環境部署失敗看流程問題的話就需要我們先搭建開發環境然後在發布前先部署開發環境。
• 使用SMART原則：SMART原則是指具體（Specific）、可衡量（Measurable）、可實現（Attainable）、相關性（Relevant）和有時間限制（Time-bound），是目標管理領域的一個核心原則。我們在指定行動計劃時如何判斷改進工作安排是否合理和可行很大程度上可以參考這一原則。

5. 總結收尾當回顧會議接近尾聲時，我們需要做會議總結，可以採用“+/?“方法。通過分析目前做的比較好的工作（+，代表需要進一步加強）和尚待改進的工作（?，代表需要進一步改進），團隊成員在意識形態上達成一致有助於改進工作的順利開展。下面是一個樣本：


四. 關於周會
講完回顧，講一講周會。傳統型周會的議程和目的實際上就是進行團隊資訊同步，會議本身無可厚非，但通常大家都是把自己本周的工作像過流水賬一樣過一遍，往往流於形式而不能真正解決存在的問題。如果團隊已經採用了類似Stand-up Meeting這樣的工程實踐、也使用Jenkins、Redmine這樣的團隊協作工具，又有規範的內部開發流程，個人認為通過這些流程和工具，團隊資訊同步的目的已經達到，傳統型周會意義不大。周會如果要開，使用回顧會議的方式通常是更加高效的做法，回顧型周會的召開方式如下：


五. 小結
回顧是我們的武器，個人在推行回顧的過程中覺得一方面作為管理者要對研發過程中的“Smell“有充分的敏感性，能夠推動回顧活動的正常運轉；另一方面，我們也需要一種持久性的節奏，回顧是一項需要長期堅持的工作，這也是要取得流程改善成果的必要條件。

Retrospective--The Way To Make Things Better