站長資訊網(wǎng)前幾年，一本叫《沉思錄》的書在國內(nèi)突然曝光度很多，很多讀者都是“擺案頭，讀百遍”。《沉思錄》是古羅馬皇帝馬可·奧勒寫給自己的書，內(nèi)容大部分是在鞍馬勞頓中寫的。其實(shí)有一句“我們所聽到的不過只是一個(gè)觀點(diǎn)，而非事實(shí)。我們所看到的不過只是一個(gè)視角，而非真相”。
全員都參加的回顧會議，其實(shí)就是希望能通過全員視角，全員的觀點(diǎn)來回顧做的好的，做的不好的，改進(jìn)之。從敏捷宣言，到敏捷的諸多實(shí)踐(如 Scrum)，到 DevOps，都一直提倡回顧這種形式。
其實(shí)回顧這種形式，并不是敏捷 /DevOps 專屬的，華為最早也有類似的活動。有時(shí)候團(tuán)隊(duì)碰到域郁悶，痛苦的時(shí)候，還會主動自發(fā)的開。
所以，回顧，我一直認(rèn)為這是人類作為一個(gè)智慧物種相比其他生物的一個(gè)重要區(qū)別。我有的時(shí)候回通過回顧會議來判斷這個(gè)團(tuán)隊(duì)會不會成功。最極端的，如果甚至都沒有人想著要約大家一起回顧，這個(gè)團(tuán)隊(duì)極大概率要88了。
華為內(nèi)部不僅研發(fā)交付團(tuán)隊(duì)，連一線的市場團(tuán)隊(duì)，在重大的市場項(xiàng)目，交付項(xiàng)目的過程中都會定期進(jìn)行回顧會議，算是華為內(nèi)部這么多年積累的一個(gè)很好的實(shí)踐。
必須鮮明表達(dá)的觀點(diǎn)——回顧有三個(gè)不是
1. 不是“回溯”。“顧”和“溯”一字之差，在中文的語境中，卻會導(dǎo)致變成刨根問底。
2. 不是“批評與自我批評”。“批評與自我批評”是一個(gè)很好的形式，但是會導(dǎo)致團(tuán)隊(duì)陷入一種不必要的緊張和犯錯(cuò)感。
3. 不是“問責(zé)和處罰”。軟件的不確定性，不可見性，復(fù)雜性，易變性決定了軟件開發(fā)過程總會有些磕磕絆絆，我們提倡的是改進(jìn)，不是懲罰。
從華為這么多年的實(shí)踐來看，上面的三種情況都出現(xiàn)過，所以提醒大家要小心。
這么些年實(shí)踐過來，我們發(fā)現(xiàn)出現(xiàn)以上情況，也是因?yàn)椴阶幼叩锰欤皖^玩手機(jī)，忘了“回顧”的初心：
1. For a better future;
2. Learn from past;
3. Take action in present.
回顧會議的基本原則
1. 對事不對人。舉個(gè)例子，我們可以說“代碼評審不充分，所以代碼缺陷較高”，不能說“某帥哥評審不認(rèn)真”，當(dāng)然夸人帥還是可以的哈。
2. 聚焦于下次能否做得更好。還舉同樣的例子，我們可以說“這個(gè)迭代代碼評審不充分，下個(gè)迭代我們怎么才能保證更充分的評審”。
3. 從系統(tǒng)角度思考改進(jìn)，而非個(gè)人。我們可以說“團(tuán)隊(duì)的工作安排上，導(dǎo)向上是不是不重視代碼評審?”
回顧會議的 Step by Step
1. 確定參與人(Who)
a) 團(tuán)隊(duì)所有成員都參加。
b) 領(lǐng)導(dǎo)是否參加，試情況，如果領(lǐng)導(dǎo)參加利大于弊，就邀請，否則還是算了。
c) 如果是重大的項(xiàng)目發(fā)布或項(xiàng)目結(jié)束的回顧會議，還應(yīng)該叫上所有對項(xiàng)目有付出的成員。
d) 建議指定一個(gè)會議引導(dǎo)人，可以是敏捷教練，也可以是團(tuán)隊(duì)成員輪流(團(tuán)隊(duì)成員建議熟讀本文)。
2. 選擇合適的場所(Where)
a) 如果條件允許，離辦公位盡可能遠(yuǎn)一點(diǎn)，避免有同學(xué)中途又回去處理工作了。
b) 盡可能不要使用傳統(tǒng)會議室的布局，圍坐一個(gè)大桌子那種不好。可以拉幾把椅子圍成一個(gè)半圓形。
c) 需要有白板，或者墻壁可以貼個(gè)大白紙。
3. 準(zhǔn)備回顧的內(nèi)容(What)
a) 準(zhǔn)備上個(gè)迭代的客觀數(shù)據(jù)，特性、需求、缺陷等數(shù)據(jù)，如果使用了像 DevCloud 這樣的敏捷管理工具，準(zhǔn)備數(shù)據(jù)其實(shí)很快的，甚至不用特別準(zhǔn)備，現(xiàn)場打開就可以，類似如下這樣：
b) 團(tuán)隊(duì)成員上個(gè)迭代的感受，可以認(rèn)為是主觀數(shù)據(jù)的收集。
c) 每日站立會議的要點(diǎn)。每日站立會議中都會提出并跟蹤解決一些問題，回顧這些問題也可以幫助我們審視過程中的情況。
d) 準(zhǔn)備一個(gè)規(guī)則，會議開始前貼出來或打印出來或投影儀投出來。規(guī)則是為了保證會議的紀(jì)律和效率，比如不能隨便打斷別人講話，每人發(fā)言時(shí)長，會議時(shí)長(建議 10~12 人的團(tuán)隊(duì)，限定在 1 小時(shí)內(nèi))。
4. 回顧會議的過程(How)
a) 準(zhǔn)備和引導(dǎo)——明確目標(biāo)。重申回顧會議的目標(biāo)和原則，讓成員重拾回顧的“初心”，發(fā)布公示如下的回顧宣言，重申會議紀(jì)律，時(shí)長。準(zhǔn)備和引導(dǎo)環(huán)節(jié)是讓大家放下手機(jī)，進(jìn)入回顧會議狀態(tài)的必要環(huán)節(jié)，無論開過多少次，都不應(yīng)該省掉。
b) 數(shù)據(jù)、過程的回放——建立共同的全景。展示本迭代的度量數(shù)據(jù)，如果有使用類似 DevCloud 的敏捷管理工具，可以直接打開系統(tǒng)。全景的數(shù)據(jù)展示回顧，讓視角更全面。對于一些“歷經(jīng)劫難”的迭代，可以畫一個(gè)時(shí)間線，把這個(gè)迭代發(fā)生的重大的一些事件按照時(shí)間順序展示出來，幫助團(tuán)隊(duì)成員回顧都發(fā)生了什么。
c) 提出見解——我們?nèi)绾尾拍茏龅酶谩？梢酝ㄟ^頭腦風(fēng)暴，全員參與，有很多種分類的方法，如下圖中是分為“Good”(下個(gè)迭代哪些好的方法可以繼續(xù)保持)，“Could Better”(下個(gè)迭代可以哪些地方可以做得更好)，Improvements(新的改進(jìn)的具體想法)。可以采用“有限投票”的方式，每個(gè)成員有 5 票(比如小磁貼或直接記正字)，大家共同團(tuán)隊(duì)層面需要重點(diǎn)改進(jìn)的。其實(shí)投票未排進(jìn) Top 的改進(jìn)，如果不需要組織和團(tuán)隊(duì)來推動，個(gè)人也可以實(shí)施的改進(jìn)，也應(yīng)該支持。
d) 確定措施——想清楚就干，才有誠信。識別了重點(diǎn) 的改進(jìn)項(xiàng)，為每一個(gè)改進(jìn)項(xiàng)指定計(jì)劃，執(zhí)行的措施，需要更高層面去解決的措施需要單獨(dú)列出來，項(xiàng)目 Leader 會后要發(fā)揮“死纏爛打”的精神去騷擾領(lǐng)導(dǎo)了，同時(shí)每個(gè)改進(jìn)措施都應(yīng)該明確一個(gè)責(zé)任人，如果沒有明確的責(zé)任人，大家都會認(rèn)為是別人的事情。
e) 結(jié)束會議——果斷結(jié)束，絕不拖泥帶水。將會議中達(dá)成共識的措施和計(jì)劃整理記錄下來，如果使用了敏捷管理的工具系統(tǒng)，可以直接輸入到系統(tǒng)中，記錄為 Story 或者任務(wù)。
來自實(shí)踐中的一些坑和雷
1. 不持之以恒。那什么幾天打魚，幾天曬網(wǎng)的可不行。
2. 理想主義。團(tuán)隊(duì)級的回顧會議應(yīng)基于現(xiàn)實(shí)，而非理想，或者說理想可以有，詩和遠(yuǎn)方也可以有，但是回顧會議還是應(yīng)接地氣。
3. 沉迷于細(xì)節(jié)。程序員有的時(shí)候特別認(rèn)真，容易把問題引入到技術(shù)細(xì)節(jié)，這樣會導(dǎo)致議題發(fā)散。
4. 為了調(diào)節(jié)會議氛圍，可以準(zhǔn)備些吃的，補(bǔ)充能量，大腦才能激發(fā)。
最后的最后，每個(gè)迭代回顧會議，都不要忘了感謝辛苦碼代碼的自己，也不要忘了感謝為了心中教堂而努力的所有團(tuán)隊(duì)成員。
特別提醒：本網(wǎng)內(nèi)容轉(zhuǎn)載自其他媒體，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點(diǎn)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實(shí)，對本文以及其中全部或者部分內(nèi)容、文字的真實(shí)性、完整性、及時(shí)性本站不作任何保證或承諾，并請自行核實(shí)相關(guān)內(nèi)容。本站不承擔(dān)此類作品侵權(quán)行為的直接責(zé)任及連帶責(zé)任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益，請及時(shí)聯(lián)系我們，本站將會在24小時(shí)內(nèi)處理完畢。
