华为敏捷 DevOps 实践:产品经理如何开好敏捷回顾会议
開篇小故事:
前幾年,一本叫《沉思錄》的書在國內(nèi)突然曝光度很多,因?yàn)榍澳硣翌I(lǐng)導(dǎo)人“擺案頭,讀百遍”。《沉思錄》是古羅馬皇帝馬可·奧勒寫給自己的書,內(nèi)容大部分是在鞍馬勞頓中寫的。其實(shí)有一句“我們所聽到的不過只是一個(gè)觀點(diǎn),而非事實(shí)。我們所看到的不過只是一個(gè)視角,而非真相”。
全員都參加的回顧會(huì)議,其實(shí)就是希望能通過全員視角,全員的觀點(diǎn)來回顧做的好的,做的不好的,改進(jìn)之。從敏捷宣言,到敏捷的諸多實(shí)踐(如Scrum),到DevOps,都一直提倡回顧這種形式。
其實(shí)回顧這種形式,并不是敏捷/DevOps專屬的,在華為最早的CMM流程中,也有類似的活動(dòng)。有時(shí)候團(tuán)隊(duì)碰到域郁悶,痛苦的時(shí)候,還會(huì)主動(dòng)自發(fā)的開。
所以,回顧,我一直認(rèn)為這是人類作為一個(gè)智慧物種相比其他生物的一個(gè)重要區(qū)別。我有的時(shí)候回通過回顧會(huì)議來判斷這個(gè)團(tuán)隊(duì)會(huì)不會(huì)成功。最極端的,如果甚至都沒有人想著要約大家一起回顧,這個(gè)團(tuán)隊(duì)極大概率要88了。
華為內(nèi)部不僅研發(fā)交付團(tuán)隊(duì),連一線的市場(chǎng)團(tuán)隊(duì),在重大的市場(chǎng)項(xiàng)目,交付項(xiàng)目的過程中都會(huì)定期進(jìn)行回顧會(huì)議,算是華為內(nèi)部這么多年積累的一個(gè)很好的實(shí)踐。
必須鮮明表達(dá)的觀點(diǎn)——回顧有三個(gè)不是
從華為這么多年的實(shí)踐來看,上面的三種情況都出現(xiàn)過,所以提醒大家要小心。
這么些年實(shí)踐過來,我們發(fā)現(xiàn)出現(xiàn)以上情況,也是因?yàn)椴阶幼叩锰?#xff0c;低頭玩手機(jī),忘了“回顧”的初心:
回顧會(huì)議的基本原則
回顧會(huì)議的Step by Step
a)團(tuán)隊(duì)所有成員都參加。
b)領(lǐng)導(dǎo)是否參加,試情況,如果領(lǐng)導(dǎo)參加利大于弊,就邀請(qǐng),否則還是算了。
c)如果是重大的項(xiàng)目發(fā)布或項(xiàng)目結(jié)束的回顧會(huì)議,還應(yīng)該叫上所有對(duì)項(xiàng)目有付出的成員。
d)建議指定一個(gè)會(huì)議引導(dǎo)人,可以是敏捷教練,也可以是團(tuán)隊(duì)成員輪流(團(tuán)隊(duì)成員建議熟讀本文)。
a)如果條件允許,離辦公位盡可能遠(yuǎn)一點(diǎn),避免有同學(xué)中途又回去處理工作了。
b)盡可能不要使用傳統(tǒng)會(huì)議室的布局,圍坐一個(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)場(chǎng)打開就可以,類似如下這樣:
b) 團(tuán)隊(duì)成員上個(gè)迭代的感受,可以認(rèn)為是主觀數(shù)據(jù)的收集。
c) 每日站立會(huì)議的要點(diǎn)。每日站立會(huì)議中都會(huì)提出并跟蹤解決一些問題,回顧這些問題也可以幫助我們審視過程中的情況。
d) 準(zhǔn)備一個(gè)規(guī)則,會(huì)議開始前貼出來或打印出來或投影儀投出來。規(guī)則是為了保證會(huì)議的紀(jì)律和效率,比如不能隨便打斷別人講話,每人發(fā)言時(shí)長,會(huì)議時(shí)長(建議10~12人的團(tuán)隊(duì),限定在1小時(shí)內(nèi))。
a) 準(zhǔn)備和引導(dǎo)——明確目標(biāo)。重申回顧會(huì)議的目標(biāo)和原則,讓成員重拾回顧的“初心”,發(fā)布公示如下的回顧宣言,重申會(huì)議紀(jì)律,時(shí)長。準(zhǔn)備和引導(dǎo)環(huán)節(jié)是讓大家放下手機(jī),進(jìn)入回顧會(huì)議狀態(tài)的必要環(huán)節(jié),無論開過多少次,都不應(yīng)該省掉。
b)?數(shù)據(jù)、過程的回放——建立共同的全景。展示本迭代的度量數(shù)據(jù),如果有使用類似DevCloud的敏捷管理工具,可以直接打開系統(tǒng)。全景的數(shù)據(jù)展示回顧,讓視角更全面。對(duì)于一些“歷經(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ì)來推動(dòng),個(gè)人也可以實(shí)施的改進(jìn),也應(yīng)該支持。
d) 確定措施——想清楚就干,才有誠信。識(shí)別了重點(diǎn) 的改進(jìn)項(xiàng),為每一個(gè)改進(jìn)項(xiàng)指定計(jì)劃,執(zhí)行的措施,需要更高層面去解決的措施需要單獨(dú)列出來,項(xiàng)目Leader會(huì)后要發(fā)揮“死纏爛打”的精神去騷擾領(lǐng)導(dǎo)了,同時(shí)每個(gè)改進(jìn)措施都應(yīng)該明確一個(gè)責(zé)任人,如果沒有明確的責(zé)任人,大家都會(huì)認(rèn)為是別人的事情。
e) 結(jié)束會(huì)議——果斷結(jié)束,絕不拖泥帶水。將會(huì)議中達(dá)成共識(shí)的措施和計(jì)劃整理記錄下來,如果使用了敏捷管理的工具系統(tǒng),可以直接輸入到系統(tǒng)中,記錄為Story或者任務(wù)。
來自實(shí)踐中的一些坑和雷
最后的最后,每個(gè)迭代回顧會(huì)議,都不要忘了感謝辛苦碼代碼的自己,也不要忘了感謝為了心中教堂而努力的所有團(tuán)隊(duì)成員的。
總結(jié)
以上是生活随笔為你收集整理的华为敏捷 DevOps 实践:产品经理如何开好敏捷回顾会议的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Github上 Star 数相加超过 7
- 下一篇: HTTP学习记录:二、请求方法