敏捷開發,那就來個回顧會議吧


前陣子剛好專案到一個段落,團隊也找時間做了敏捷開發中所謂的回顧會議 (Retrospective),今天就來分享我們團隊這次回顧會議的內容。

其實回顧會議的方法有千百種,我也經歷過幾次不同形式會議,基於這些經驗,加上事前研究,這次由我帶領大家做回顧會議。

回顧會議的重點,在於找出要改變的地方,並開始改變


這次用的方法取經自 SKS (Stop, Keep, Start),但在執行上做一點小調整,以下是我們會議的進行方式。

成員

專案團隊含主持人共 7 人,但主持人不參與討論

時間

會議時間預計 90 分鐘,安排在下班前,開完會直接下班

工具

線上看板

有鑒於大家對於動手寫字都有點障礙,不採用常見的便利貼方式,而是改用線上看板的形式,因此與會的人都必須準備電腦或是手機

有人覺得帶電腦或手機會讓與會的人無法專心,這確實也是個會發生的情況,但鑒於團隊過往的經驗,動手寫字反而讓大家更頭痛

背景音樂

每個段落搭配不同的音樂,營造出不同的氛圍

流程

會議大概分成三個段落

很棒

  1. 每個人寫下 1 至 3 點覺得很棒的地方,不限於流程或個人
  2. 每張卡片有 1 分鐘的說明時間

要改變

  1. 每個人寫下 1 至 3 點覺得要改變的地方,以專案流程或是團隊方向為主,避免針對個人
  2. 每張卡片有 1 分鐘的說明時間
  3. 大家一起對這些想法進行分類,將每個人的想法收整成幾個類別
  4. 投票選出 1 至 2 點要優先改變的類別

動起來吧

  1. 針對之前選出要優先改變的類別,每個人提出 1 至 3 點行動項目
  2. 每張卡片有 1 分鐘的說明時間
  3. 大家一起對這些想法進行分類,將每個人的想法收整成幾個項目
  4. 投票選出 1 至 2 點要優先執行的項目
  5. 找出負責人

上述提到的數字是依據團隊規模,以及專案長度而定,主要避免會議過長


依照上述流程,順利(?!)完成了回顧會議,會議的看板長成這樣


身為會議主持人,有幾個心得

  1. 整個會議時間約 80 分鐘,中間沒有休息,有在預期的時間內結束,但如果可以控制在 60 分鐘 內會更好,開會超過 60 分鐘真的是頗累
  2. 要改變,有些卡片是直接提出應該要怎麼做,比較理想的情況,這個段落要聚焦在哪些地方要改變,而不是直接提出方案,這點是主持人可以事先提醒大家的地方
  3. 動起來吧,有些想法不夠具體,或是牽涉到的範圍過於龐大,造成後續討論的時候有些困難,主持人可以先準備幾個範例,讓大家在提出想法的時候有個概念

總結來說,我們這次有達到回顧會議最重要的目的 - 產生行動事項 (action items),接著就是看如何執行啦,希望下一次的專案我們會做得更好!

#agile #software engineering #software development






留言討論