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

內容來源：華爲雲 DevCloud 首席佈道師 & 資深產品經理劉恆的技術乾貨分享。IT 大咖說經華爲雲和講者受權發佈，轉載請標明出處。

閱讀字數：3737 | 10分鐘閱讀

摘要

<恆少出品，必然妥妥乾貨，一定理論聯繫實踐>，由於軟件無銀彈，探索始終在路上。

————————————————————————————————————

你們好，我是華爲雲DevCloud項目管理服務恆少。

做爲佈道師和產品經理，出差各地接觸客戶是常態，常常和華爲雲的客戶交流、佈道、技術沙龍，可是線下交流，覆蓋的用戶總仍是少數。我但願借線上的平臺，和用戶持續交流華爲在研發效能提高上的思索和考慮。

1、例行的開篇小故事

前幾年，一本叫《沉思錄》的書在國內忽然曝光度不少，由於前某國家領導人「擺案頭，讀百遍」。《沉思錄》是古羅馬皇帝馬可·奧勒寫給本身的書，內容大部分是在鞍馬勞頓中寫的。其實有一句「咱們所聽到的不過只是一個觀點，而非事實。咱們所看到的不過只是一個視角，而非真相」。

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

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

因此，回顧，我一直認爲這是人類做爲一個智慧物種相比其餘生物的一個重要區別。我有的時候回經過回顧會議來判斷這個團隊會不會成功。最極端的，若是甚至都沒有人想着要約你們一塊兒回顧，這個團隊極大機率要88了。

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

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

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

2. 不是「批評與自我批評」。「批評與自我批評」是一個很好的形式，可是會致使團隊陷入一種沒必要要的緊張和犯錯感。

3. 不是「問責和處罰」。軟件的不肯定性，不可見性，複雜性，易變性決定了軟件開發過程總會有些磕磕盼盼，咱們提倡的是改進，不是懲罰。

從華爲這麼多年的實踐來看，上面的三種狀況都出現過，因此提醒你們要當心。

這麼些年實踐過來，咱們發現出現以上狀況，也是由於步子走得太快，低頭玩手機^_^，忘了「回顧」的初心：

1. For a better future;

2. Learn from past;

3. Take action in present.

3、回顧會議的基本原則

1. 對事不對人。舉個例子，咱們能夠說「代碼評審不充分，因此代碼缺陷較高」，不能說「某帥哥評審不認真」，固然夸人帥仍是能夠的哈^_^。

2. 聚焦於下次可否作得更好。還舉一樣的例子，咱們能夠說「這個迭代代碼評審不充分，下個迭代咱們怎麼才能保證更充分的評審」。

3. 從系統角度思考改進，而非我的。咱們能夠說「團隊的工做安排上，導向上是否是不重視代碼評審？」。

4、回顧會議的Step by Step

1. 肯定參與人（Who）

a)團隊全部成員都參加。

b)領導是否參加，試狀況，若是領導參加利大於弊，就邀請，不然仍是算了^_^

c)若是是重大的項目發佈或項目結束的回顧會議，還應該叫上全部對項目有付出的成員。

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

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

a)若是條件容許，離辦公位儘量遠一點，避免有同窗中途又回去處理工做了

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

c)須要有白板，或者牆壁能夠貼個大白紙

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

a) 準備上個迭代的客觀數據，特性、需求、缺陷等數據，若是使用了像DevCloud這樣的敏捷管理工具，準備數據其實很快的，甚至不用特別準備，現場打開就能夠，相似以下這樣

b) 團隊成員上個迭代的感覺，能夠認爲是主觀數據的收集。

c) 每日站立會議的要點。每日站立會議中都會提出並跟蹤解決一些問題，回顧這些問題也能夠幫助咱們審視過程當中的狀況。恆少以前專門寫過如何開好站立會議的實踐文章（https://www.infoq.cn/article/rS2UBmVfabjGCTsgp_9P），能夠參考

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

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

a) 準備和引導——明確目標。重申回顧會議的目標和原則，讓成員重拾回顧的「初心」，發佈公示以下的回顧宣言，重申會議紀律，時長。準備和引導環節是讓你們放下手機，進入回顧會議狀態的必要環節，不管開過多少次，都不該該省掉。

b) 數據、過程的回放——創建共同的全景。展現本迭代的度量數據，若是有使用相似DevCloud的敏捷管理工具，能夠直接打開系統。全景的數據展現回顧，讓視角更全面。對於一些「歷經劫難」的迭代，能夠畫一個時間線，把這個迭代發生的重大的一些事件按照時間順序展現出來，幫助團隊成員回顧都發生了什麼。

c) 提出看法——咱們如何才能作得更好。能夠經過頭腦風暴，全員參與，有不少種分類的方法，以下圖中是分爲「Good」（下個迭代哪些好的方法能夠繼續保持），「Could Better」（下個迭代能夠哪些地方能夠作得更好），Improvements（新的改進的具體想法）。能夠採用「有限投票」的方式，每一個成員有5票（好比小磁貼或直接記正字），你們共同團隊層面須要重點改進的。其實投票未排進Top的改進，若是不須要組織和團隊來推進，我的也能夠實施的改進，也應該支持。

d) 肯定措施——想清楚就幹，纔有誠信。識別了重點的改進項，爲每個改進項指定計劃，執行的措施，須要更高層面去解決的措施須要單獨列出來，項目Leader會後要發揮「死纏爛打」的精神去騷擾領導了，同時每一個改進措施都應該明確一個責任人，若是沒有明確的責任人，你們都會認爲是別人的事情。

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

5、來自實踐中的一些坑和雷

1. 不鍥而不捨。那什麼幾天打魚，幾天曬網的可不行。恆少，恆少，就是能鍥而不捨，哈哈。

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

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

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

最後的最後，每一個迭代回顧會議，都不要忘了感謝辛苦碼代碼的本身，也不要忘了感謝爲了心中教堂而努力的全部團隊成員的。以上爲今天的分享內容，謝謝你們：）

編者：IT大咖說，轉載請標明版權和出處