在項(xiàng)目回顧過(guò)程中，可以不斷總結(jié)發(fā)現(xiàn)團(tuán)隊(duì)中實(shí)踐的問(wèn)題，然后針對(duì)有問(wèn)題的實(shí)踐找出解決方案并應(yīng)用在后續(xù)的迭代中。如何開(kāi)好敏捷回顧會(huì)議呢？

大家好，我是華為云DevCloud項(xiàng)目管理服務(wù)的產(chǎn)品經(jīng)理恒少！

作為布道師和產(chǎn)品經(jīng)理，出差各地接觸客戶(hù)是常態(tài)，經(jīng)常和華為云的客戶(hù)交流、布道、技術(shù)沙龍，但是線下交流，覆蓋的用戶(hù)總還是少數(shù)。

我希望借助線上的平臺(tái)，和用戶(hù)持續(xù)交流華為在研發(fā)效能提升上的思索和考慮。

一、開(kāi)篇小故事

前幾年，一本叫《沉思錄》的書(shū)在國(guó)內(nèi)突然曝光度很多，因?yàn)榍澳硣?guó)家領(lǐng)導(dǎo)人“擺案頭，讀百遍”。

《沉思錄》是古羅馬皇帝馬可·奧勒寫(xiě)給自己的書(shū)，內(nèi)容大部分是在鞍馬勞頓中寫(xiě)的。其實(shí)有一句：“我們所聽(tīng)到的不過(guò)只是一個(gè)觀點(diǎn)，而非事實(shí)。我們所看到的不過(guò)只是一個(gè)視角，而非真相?！?/p>

全員都參加的回顧會(huì)議，其實(shí)就是希望能通過(guò)全員視角，全員的觀點(diǎn)來(lái)回顧做的好的，做的不好的，改進(jìn)之。從敏捷宣言，到敏捷的諸多實(shí)踐（如Scrum），到DevOps，都一直提倡回顧這種形式。

其實(shí)回顧這種形式，并不是敏捷/DevOps專(zhuān)屬的，在華為最早的CMM流程中，也有類(lèi)似的活動(dòng)。有時(shí)候團(tuán)隊(duì)碰到域郁悶，痛苦的時(shí)候，還會(huì)主動(dòng)自發(fā)的開(kāi)。

所以，回顧，我一直認(rèn)為這是人類(lèi)作為一個(gè)智慧物種相比其他生物的一個(gè)重要區(qū)別。

我有的時(shí)候回通過(guò)回顧會(huì)議來(lái)判斷這個(gè)團(tuán)隊(duì)會(huì)不會(huì)成功。最極端的，如果甚至都沒(méi)有人想著要約大家一起回顧，這個(gè)團(tuán)隊(duì)極大概率要88了。

華為內(nèi)部不僅研發(fā)交付團(tuán)隊(duì)，連一線的市場(chǎng)團(tuán)隊(duì)，在重大的市場(chǎng)項(xiàng)目，交付項(xiàng)目的過(guò)程中都會(huì)定期進(jìn)行回顧會(huì)議，算是華為內(nèi)部這么多年積累的一個(gè)很好的實(shí)踐。

以下是我個(gè)人對(duì)產(chǎn)品經(jīng)理如何開(kāi)好敏捷回顧會(huì)議的建議：

二、回顧有三個(gè)不是

1. 不是“回溯”?！邦櫋焙汀八荨币蛔种?，在中文的語(yǔ)境中，卻會(huì)導(dǎo)致變成刨根問(wèn)底；
2. 不是“批評(píng)與自我批評(píng)”?！芭u(píng)與自我批評(píng)”是一個(gè)很好的形式，但是會(huì)導(dǎo)致團(tuán)隊(duì)陷入一種不必要的緊張和犯錯(cuò)感；
3. 不是“問(wèn)責(zé)和處罰”。軟件的不確定性，不可見(jiàn)性，復(fù)雜性，易變性決定了軟件開(kāi)發(fā)過(guò)程總會(huì)有些磕磕盼盼，我們提倡的是改進(jìn)，不是懲罰。

從華為這么多年的實(shí)踐來(lái)看，上面的三種情況都出現(xiàn)過(guò)，所以提醒大家要小心。

這么些年實(shí)踐過(guò)來(lái)，我們發(fā)現(xiàn)出現(xiàn)以上情況，也是因?yàn)椴阶幼叩锰?，低頭玩手機(jī)，忘了“回顧”的初心：

1. For?a better future;
2. Learn from past;
3. Take action in present.

三、回顧會(huì)議的基本原則

1. 對(duì)事不對(duì)人。舉個(gè)例子，我們可以說(shuō)“代碼評(píng)審不充分，所以代碼缺陷較高”，不能說(shuō)“某帥哥評(píng)審不認(rèn)真”，當(dāng)然夸人帥還是可以的哈^_^。
2. 聚焦于下次能否做得更好。還舉同樣的例子，我們可以說(shuō)“這個(gè)迭代代碼評(píng)審不充分，下個(gè)迭代我們?cè)趺床拍鼙ＷC更充分的評(píng)審”。
3. 從系統(tǒng)角度思考改進(jìn)，而非個(gè)人。我們可以說(shuō)“團(tuán)隊(duì)的工作安排上，導(dǎo)向上是不是不重視代碼評(píng)審？”。

四、回顧會(huì)議的Step?by Step

1. 確定參與人（Who）

1. 團(tuán)隊(duì)所有成員都參加。
2. 領(lǐng)導(dǎo)是否參加，試情況，如果領(lǐng)導(dǎo)參加利大于弊，就邀請(qǐng)，否則還是算了。
3. 如果是重大的項(xiàng)目發(fā)布或項(xiàng)目結(jié)束的回顧會(huì)議，還應(yīng)該叫上所有對(duì)項(xiàng)目有付出的成員。
4. 建議指定一個(gè)會(huì)議引導(dǎo)人，可以是敏捷教練，也可以是團(tuán)隊(duì)成員輪流（團(tuán)隊(duì)成員建議熟讀本文）。

2. 選擇合適的場(chǎng)所（Where）

1. 如果條件允許，離辦公位盡可能遠(yuǎn)一點(diǎn)，避免有同學(xué)中途又回去處理工作了。
2. 盡可能不要使用傳統(tǒng)會(huì)議室的布局，圍坐一個(gè)大桌子那種不好?？梢岳瓗装岩巫訃梢粋€(gè)半圓形。
3. 需要有白板，或者墻壁可以貼個(gè)大白紙。

3. 準(zhǔn)備回顧的內(nèi)容（What）

1. 準(zhǔn)備上個(gè)迭代的客觀數(shù)據(jù)，特性、需求、缺陷等數(shù)據(jù)，如果使用了像DevCloud這樣的敏捷管理工具，準(zhǔn)備數(shù)據(jù)其實(shí)很快的，甚至不用特別準(zhǔn)備，現(xiàn)場(chǎng)打開(kāi)就可以，類(lèi)似如下這樣：

2. 團(tuán)隊(duì)成員上個(gè)迭代的感受，可以認(rèn)為是主觀數(shù)據(jù)的收集。

3. 每日站立會(huì)議的要點(diǎn)。每日站立會(huì)議中都會(huì)提出并跟蹤解決一些問(wèn)題，回顧這些問(wèn)題也可以幫助我們審視過(guò)程中的情況。恒少之前專(zhuān)門(mén)寫(xiě)過(guò)的實(shí)踐文章《華為敏捷/DevOps實(shí)踐：如何開(kāi)好站立會(huì)議》，可以參考。

4. 準(zhǔn)備一個(gè)規(guī)則，會(huì)議開(kāi)始前貼出來(lái)或打印出來(lái)或投影儀投出來(lái)。規(guī)則是為了保證會(huì)議的紀(jì)律和效率，比如不能隨便打斷別人講話，每人發(fā)言時(shí)長(zhǎng)，會(huì)議時(shí)長(zhǎng)（建議10~12人的團(tuán)隊(duì)，限定在1小時(shí)內(nèi))。

4. 回顧會(huì)議的過(guò)程（How）

1. 準(zhǔn)備和引導(dǎo)——明確目標(biāo)。重申回顧會(huì)議的目標(biāo)和原則，讓成員重拾回顧的“初心”，發(fā)布公示如下的回顧宣言，重申會(huì)議紀(jì)律，時(shí)長(zhǎng)。準(zhǔn)備和引導(dǎo)環(huán)節(jié)是讓大家放下手機(jī)，進(jìn)入回顧會(huì)議狀態(tài)的必要環(huán)節(jié)，無(wú)論開(kāi)過(guò)多少次，都不應(yīng)該省掉。

2. 數(shù)據(jù)、過(guò)程的回放——建立共同的全景。展示本迭代的度量數(shù)據(jù)，如果有使用類(lèi)似DevCloud的敏捷管理工具，可以直接打開(kāi)系統(tǒng)。全景的數(shù)據(jù)展示回顧，讓視角更全面。對(duì)于一些“歷經(jīng)劫難”的迭代，可以畫(huà)一個(gè)時(shí)間線，把這個(gè)迭代發(fā)生的重大的一些事件按照時(shí)間順序展示出來(lái)，幫助團(tuán)隊(duì)成員回顧都發(fā)生了什么

3. 提出見(jiàn)解——我們?nèi)绾尾拍茏龅酶??？梢酝ㄟ^(guò)頭腦風(fēng)暴，全員參與，有很多種分類(lèi)的方法，如下圖中是分為“Good”（下個(gè)迭代哪些好的方法可以繼續(xù)保持），“CouldBetter”（下個(gè)迭代可以哪些地方可以做得更好），Improvements（新的改進(jìn)的具體想法）。

可以采用“有限投票”的方式，每個(gè)成員有5票（比如小磁貼或直接記正字），大家共同團(tuán)隊(duì)層面需要重點(diǎn)改進(jìn)的。其實(shí)投票未排進(jìn)Top的改進(jìn)，如果不需要組織和團(tuán)隊(duì)來(lái)推動(dòng)，個(gè)人也可以實(shí)施的改進(jìn)，也應(yīng)該支持。

4. 確定措施——想清楚就干，才有誠(chéng)信。識(shí)別了重點(diǎn)的改進(jìn)項(xiàng)，為每一個(gè)改進(jìn)項(xiàng)指定計(jì)劃，執(zhí)行的措施，需要更高層面去解決的措施需要單獨(dú)列出來(lái)，項(xiàng)目Leader會(huì)后要發(fā)揮“死纏爛打”的精神去騷擾領(lǐng)導(dǎo)了，同時(shí)每個(gè)改進(jìn)措施都應(yīng)該明確一個(gè)責(zé)任人，如果沒(méi)有明確的責(zé)任人，大家都會(huì)認(rèn)為是別人的事情。

5. 結(jié)束會(huì)議——果斷結(jié)束，絕不拖泥帶水。將會(huì)議中達(dá)成共識(shí)的措施和計(jì)劃整理記錄下來(lái)，如果使用了敏捷管理的工具系統(tǒng)，可以直接輸入到系統(tǒng)中，記錄為Story或者任務(wù)。

四、來(lái)自實(shí)踐中的一些坑和雷

1. 不持之以恒。那什么幾天打魚(yú)，幾天曬網(wǎng)的可不行。恒少，恒少，就是能持之以恒，哈哈。
2. 理想主義。團(tuán)隊(duì)級(jí)的回顧會(huì)議應(yīng)基于現(xiàn)實(shí)，而非理想，或者說(shuō)理想可以有，詩(shī)和遠(yuǎn)方也可以有，但是回顧會(huì)議還是應(yīng)接地氣。
3. 沉迷于細(xì)節(jié)。程序員有的時(shí)候特別認(rèn)真，容易把問(wèn)題引入到技術(shù)細(xì)節(jié)，這樣會(huì)導(dǎo)致議題發(fā)散。
4. 只開(kāi)會(huì)，沒(méi)有吃的，好餓。皮一下，為了調(diào)節(jié)會(huì)議氛圍，可以準(zhǔn)備些吃的，補(bǔ)充能量，大腦才能激發(fā)

最后的最后，每個(gè)迭代回顧會(huì)議，都不要忘了感謝辛苦碼代碼的自己，也不要忘了感謝為了心中教堂而努力的所有團(tuán)隊(duì)成員的。

本文由 @透明的魚(yú) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來(lái)自Unsplash，基于CC0協(xié)議。