華為敏捷DevOps實踐：產品經理如何開好敏捷回顧會議

大家好，我是 華為雲DevCloud 專案管理服務的產品經理   恆少：）

作為佈道師和產品經理，出差各地接觸客戶是常態，經常和華為雲的客戶交流、佈道、技術沙龍，但是線下交流，覆蓋的使用者總還是少數。我希望借 助 線上的平臺，和使用者持續交流華為在研發效能提升上的思索和考慮。

<恆少出品，必然妥妥乾貨，必定理論聯絡實踐>，因為軟體無銀彈，探索始終在路上

-----------------------乾貨分割線--------------------------------------

開篇小故事：前幾年，一本叫《沉思錄》的書在國內突然曝光度很多，因為前某國家領導人“擺案頭，讀百遍”。《沉思錄》是古羅馬皇帝馬可·奧勒寫給自己的書，內容大部分是在鞍馬勞頓中寫的。其實有一句“我們所聽到的不過只是一個觀點，而非事實 。 我們所看到的不過只是一個視角，而非真相”

全員都參加的回顧會議，其實就是希望能透過全員視角，全員的觀點來回顧做的好的，做的不好的，改進之。從敏捷宣言，到敏捷的諸多實踐（如Scrum），到DevOps，都一直提倡回顧這種形式。

其實回顧這種形式，並不是敏捷/DevOps專屬的，在華為最早的CMM流程中，也有類似的活動。有時候團隊碰到域鬱悶，痛苦的時候，還會主動自發的開。

所以，回顧，我一直認為這是人類作為一個智慧物種相比其他生物的一個重要區別。我有的時候回透過回顧會議來判斷這個團隊會不會成功。最極端的，如果甚至都沒有人想著要約大家一起回顧，這個團隊極大機率要88了。

華為內部不僅研發交付團隊，連一線的市場團隊，在重大的市場專案，交付專案的過程中都會定期進行回顧會議，算是華為內部這麼多年積累的一個很好的實踐。

必須鮮明表達的觀點——回顧有三個不是

1.不是“回溯”。“顧”和“溯”一字之差，在中文的語境中，卻會導致變成刨根問底。

2.不是“批評與自我批評”。“批評與自我批評”是一個很好的形式，但是會導致團隊陷入一種不必要的緊張和犯錯感。

3.不是“問責和處罰”。軟體的不確定性，不可見性，複雜性，易變性決定了軟體開發過程總會有些磕磕盼盼，我們提倡的是改進，不是懲罰

從華為這麼多年的實踐來看，上面的三種情況都出現過，所以提醒大家要小心。

這麼些年實踐過來，我們發現出現以上情況，也是因為步子走得太快，低頭玩手機^_^，忘了“回顧”的初心：

1.For a better future;

2.Learn from past;

3.Take action in present.

回顧會議的基本原則

1.對事不對人。舉個例子，我們可以說“程式碼評審不充分，所以程式碼缺陷較高”，不能說“某帥哥評審不認真”，當然夸人帥還是可以的哈^_^。

2.聚焦於下次能否做得更好。還舉同樣的例子，我們可以說“這個迭代程式碼評審不充分，下個迭代我們怎麼才能保證更充分的評審”。

3.從系統角度思考改進，而非個人。我們可以說“團隊的工作安排上，導向上是不是不重視程式碼評審？”。

回顧會議的Step by Step

1. 確定參與人（Who）

a)團隊所有成員都參加。

b)領導是否參加，試情況，如果領導參加利大於弊，就邀請，否則還是算了^_^

c)如果是重大的專案釋出或專案結束的回顧會議，還應該叫上所有對專案有付出的成員。

d)建議指定一個會議引導人，可以是敏捷教練，也可以是團隊成員輪流（團隊成員建議熟讀本文）

2.選擇合適的場所（Where）

a)如果條件允許，離辦公位儘可能遠一點，避免有同學中途又回去處理工作了

b)儘可能不要使用傳統會議室的佈局，圍坐一個大桌子那種不好。可以拉幾把椅子圍成一個半圓形。

c)需要有白板，或者牆壁可以貼個大白紙

 3.準備回顧的內容（What）

a) 準備上個迭代的客觀資料，特性、需求、缺陷等資料，如果使用了像DevCloud這樣的敏捷管理工具，準備資料其實很快的，甚至不用特別準備，現場開啟就可以，類似如下這樣

b) 團隊成員上個迭代的感受，可以認為是主觀資料的收集。

c) 每日站立會議的要點。每日站立會議中都會提出並跟蹤解決一些問題，回顧這些問題也可以幫助我們審視過程中的情況。恆少之前專門寫過如何開好站立會議的實踐文章《 華為敏捷 /DevOps 實踐：如何開好站立會議 》，可以參考。

d) 準備一個規則，會議開始前貼出來或列印出來或投影儀投出來。規則是為了保證會議的紀律和效率，比如不能隨便打斷別人講話，每人發言時長，會議時長（建議10~12人的團隊，限定在1小時內)

  4. 回顧會議的過程（How）

a) 準備和引導——明確目標。重申回顧會議的目標和原則，讓成員重拾回顧的“初心”，釋出公示如下的回顧宣言，重申會議紀律，時長。準備和引導環節是讓大家放下手機，進入回顧會議狀態的必要環節，無論開過多少次，都不應該省掉。

b) 資料、過程的回放——建立共同的全景。展示本迭代的度量資料，如果有使用類似DevCloud的敏捷管理工具，可以直接開啟系統。全景的資料展示回顧，讓視角更全面。對於一些“歷經劫難”的迭代，可以畫一個時間線，把這個迭代發生的重大的一些事件按照時間順序展示出來，幫助團隊成員回顧都發生了什麼

c) 提出見解——我們如何才能做得更好。可以透過頭腦風暴，全員參與，有很多種分類的方法，如下圖中是分為“Good”（下個迭代哪些好的方法可以繼續保持），“Could Better”（下個迭代可以哪些地方可以做得更好），Improvements（新的改進的具體想法）。可以採用“有限投票”的方式，每個成員有5票（比如小磁貼或直接記正字），大家共同團隊層面需要重點改進的。其實投票未排進Top的改進，如果不需要組織和團隊來推動，個人也可以實施的改進，也應該支援。

d) 確定措施——想清楚就幹，才有誠信。識別了重點的改進項，為每一個改進項指定計劃，執行的措施，需要更高層面去解決的措施需要單獨列出來，專案Leader會後要發揮“死纏爛打”的精神去騷擾領導了，同時每個改進措施都應該明確一個責任人，如果沒有明確的責任人，大家都會認為是別人的事情。

e) 結束會議——果斷結束，絕不拖泥帶水。將會議中達成共識的措施和計劃整理記錄下來，如果使用了敏捷管理的工具系統，可以直接輸入到系統中，記錄為Story或者任務。 

來自實踐中的一些坑和雷

1.不持之以恆。那什麼幾天打魚，幾天曬網的可不行。恆少，恆少，就是能持之以恆，哈哈。

2.理想主義。團隊級的回顧會議應基於現實，而非理想，或者說理想可以有，詩和遠方也可以有，但是回顧會議還是應接地氣。

3.沉迷於細節。程式設計師有的時候特別認真，容易把問題引入到技術細節，這樣會導致議題發散。

4.只開會，沒有吃的，好餓。皮一下，為了調節會議氛圍，可以準備些吃的，補充能量，大腦才能激發

最後的最後，每個迭代回顧會議，都不要忘了感謝辛苦碼程式碼的自己，也不要忘了感謝為了心中教堂而努力的所有團隊成員。