回顧會議是 Scrum 中最重要的一個會議, 它讓你有機會反省在上個 sprint 所做的一切事情. 老中很努力工作, 可是卻不檢討做事方法, 所以工作的很辛苦,卻不見得有效率.
要開會, 第一件事情就是要決定誰要主持這個會議. 在當開始的時候, 是從 manager 開始, 而且是從我先中獎. 這是因為沒有人教我們如何進行回顧會議(retrospective), 我們家的 RD lead 教我要先犧牲一下. 之後我們主持的順序如下:
(1) 所有經理: 我們有管專案進度和範圍的經理(JM), 開發人員的經理(DM), 和測試人員的經理(QM)
(2) Lead (RD 和 QA 的lead)
(3) 每位成員輪流
這樣作法有些好處:
(1) 一開始可以由經理示範會議要如何進行, 當然這不是絕對, 後面的主持人還是可以修改部分進行的方式
(2) 讓大家輪流可以增加參與感, 不會認為這是某個人的事情
(3) 讓大家都有準備資料, 會更知道專案目前整體的狀況
參加會議的成員, 基本上有開發人員, 測試人員, Human Interface Engineer, UI engineer, SQA 和團隊的經理(JM, DM, QM).偶而會有產品經理(PM), 和一些慕名來插花的人員. 像是別的團隊想要引進Scrum的人.
基本上, 大家都可以發言, 不過別的團隊的並不會發言, 最多是私下詢問 JM 一些相關的問題. 我們並沒有像 Agile中Pig/Chicken, 這樣壁壘分明. 因為只要對團隊有用的, 都可以提出建言, 雖然不一定會採用, 但至少我們保持開放的心態.
一開始RD lead有給我一堆資料, 要我好好惡補, 到底要怎麼開會. 以下是我一開始看的東西:
http://xp123.com/xplor/xp0509/index.shtml
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
說真的, 因為前一兩天才給我, 加上又忙, 我並沒有好好把它看完. 所以整個會議流程有一半以上是自創的.
本來的一開始我們是套用XXXX方法, 列出三項事情來討論: Good, Could have been better, Improvment. 之後變成: Happy, Unhappy, Do more, Do less, Confuse和XXX. 最後演變成Happy, Unhappy, Do more, Do less.
進行的方式類似IDEO brainstorming的process, 步驟如下:
(1) 請大家把想法寫在便利貼上面.
(2) 寫完後貼到白板上(放到上面不同的項目中, 像是Happy或是Unhappy...等等), 並且大聲說出你的想法.
(3) 第一和第二的步驟反覆進行, 直到大家用盡所有的想法
(4) 接著大家開始對這些便利貼做分類, 但是此時不能出聲, 不能交談, 只能移動便利貼. 若是有衝突, 會在數次來來回回移動中, 自然達成共識.(也可能不會, 但是我們最後總會有人屈服, 呵呵)
(5) 然後開始對這些分類後的群組投票, 票選出大家認為前三重要的群組.
(6) 挑選出來後, 便開始對這個群組討論要如何改進.
這樣做可以有以下好處:
(1) 大家可以暢所欲言, 不管是好的壞的, 讓每個人有抒發的管道, 以及感謝的時間點. 以下就是類似的對話
A: 感謝JM提供零食
B: QA不要只是先寫測試程式, 應該要先手動驗證功能是否正確
C. SQA都會適時提醒我們要注意的地方
D. RD要先解show stoppers
.....
大家會感情比較融洽, 因為不會有事只能放在心底.
(2) 將問題視覺化, 不會講完後就被遺忘, 在白板上就能看到這些想法. 且因為有人拋磚引玉, 而促使大家想出更多的想法
(3) 因為是寫在便利貼上面, 字體不會太大, 所以大家需要幾到前面去才能看得見, 可以讓團隊開會更專心, 更緊密. 只要是坐在後面的, 便知道他並沒有想加入討論.
(4) 解答是大家想出來的, 所以大家會比較願意去執行, 不是經理們強迫大家去接受它.
不過這裡有些規則要遵守:
(1) 沒有主意是壞主意, 不要有人一提出想法, 就加以批評.
(2) 每次只有一個人說話
(3) 可以鼓勵成員發言, 但是不用要求每個人依序發言
會議的流程, 本來是只討論這些東西(Happy, Unhappy, Do more, Do less). 後來有人建議需要加上一些專案的資料, 讓大家清楚目前做的狀況. 若是正常一般 Scrum 團隊會看 burndown chart. 可是我們是列出以下項目:
(1) Task board : 讓我們概念性知道多少完成, 多少沒有完成. 因為這裡我們只是拍下照片來檢視, 並沒有任何加工
(2) 故事完成度資訊: 我們會列出每個人在每個故事中預估要做的點數, 實際達成的點數. 這裡是比較詳細的資料, 目前由我們JM來維護這份資料
(3) 現存錯誤個案(defect)的狀況: 列出每個人手上有多少未處理完的錯誤個案, 以及這些錯誤個案都是發生在那些功能上
(4) 未來主要的milestones: 讓大家了解那些大的event在什麼時候要發生
(5) 下一個循環(iteration)要做的故事: 所有人可以先心裡有譜, 接下來有哪些事情要做
項目看起來不少, 但是除了第一次簡報這些項目外, 之後我們每頁大約花不到1~2分鐘就講完, 單然如果有人問問題不算. 所以我們還是留很多時間去做討論. 基本上, 我們認為雙相溝通, 遠比單向傳遞重要.
(6) 回顧之前問題: 看看之前的問題是否已經被解決了, 會請相關的人加以說明.
在討論問題的解決方法時, 時間是一個很大的限制, 我們有幾種作法:
(1) 在會議中討論完: 對於一些不是很嚴重的項目, 或是想不出辦法的, 可能在會議中時間到就會做個結論, 之後並不會再花時間去討論.
(2) 會議後留下來討論: 因為這時候大家都在一起, 並且動機上比較強烈, 若是很嚴重的問題, 大家便會在會議後留下來討論.
(3) 事後個別召開會議: 有些項目比較嚴重, 但是需要一點時間準備, 或是相關的利害關係人不在, 因此需要之後再找時間開會討論.
目前這樣的處理方式, 個人認為優缺點如下:
優點:
(1) 讓大家知道和面對目前的問題, 而不是藏在心理
(2) 或許沒有很好的解法被提出, 但是因為大家知道, 在心理上便會去思考, 或是盡量去減低這些狀況發生的機率
缺點
(1) 不容易有很 solid 的解法, 有些問題並容易解決, 而且可能也沒有太多時間讓大家去找答案
(2) 並沒有很強烈的 follow up 處理, 因為有些並沒有列出詳細的 action items, 只是讓大家提出 high level 解法.
老實說, 是真的還沒有很理想. 但是值得肯定的地方我們能早點給 feedback, 不會等到整個專案結束後才來討論之後要如何改進, 大家願意處理的動機比較強. 可能每次改進10%, 5%, 但是還是有進步, 大家比較能及時被鼓勵到.
至於會議的時間, 一開始是兩個小時, 是有點長, 一方面我們不熟悉會議的流程和議題, 一方面我希望能給大家較多討論的時間. 後來JM覺得這樣時間太長了, 因此我們大約只濃縮到一個小時, 或許這樣讓大家有比較時間做自己的事吧.
因為我們並沒有在 sprint 和 sprint 中間有個休息的時間(slack time), 所以我們再這時候都會去點一些飲料或是點心, 一邊吃一邊進行, 勉強弭補一下. 不過也因為經濟不景氣, 所以豐盛的程度也不高, 是美中不足的地方.
作者：David Ko
作者簡介：David具備Certified Scrum Master以及Certified Scrum Product Owner的認證，也是台灣最早期 Agile 社群（AgileCommunity.tw）發起人之一。 為了推廣Agile知識，還擔任過「Scrum and XP from the trenches」這本書繁體中文的翻譯者。目前在趨勢科技擔任資深研發主管，並從2008年開始在專案中實施Scrum。 八年間累積了非常多的實務心得 - 有針對Agile精神的核心體悟、理解方法的限制、也理解很多教科書上知識更深層的執行方向、當然更多對這方法可能產生的副作用以及解法。
文章出處：David Ko的學習之旅
原文連結：http://kojenchieh.pixnet.net/blog/post/75409372
圖片出處：http://www.empowernetworksupportblog.com/getresponse-setup/
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
