因為這幾年手邊幾個重要專案陸續導入SCRUM，Peggy在這個旅程中也順道收集了相關資料，紀錄了一些實際run的流程和學習心得，提供給有需要的朋友參考，歡迎一起聊聊討論。
今天主要來聊聊Sprint retrospective meeting，特別是暖身小活動部分。
/
What is Sprint Retrospective meeting?
顧名思義就是「回顧會議」，用來改善開發流程的一個很重要的關卡，服用時機主要是在每一個Sprint結束前。
透過回顧會議，讓我們有機會稍微停下來去思考這一個Sprint當中做了哪些事？也了解團隊成員心目中，哪些是好的需要好好維持的部分，哪些是不夠好而需要改善的地方。
減少工作很辛苦但是效率不夠高的情形發生。最後挑出幾個比較重要需要改善的項目，且討論出具體的改善方針。
在實際經驗中，通常是在新專案的前幾個 sprint 會固定有retrospective。等到需要改善的項目已收斂，剩下就是需要時間和resource 完成，就會調整成幾個sprint 才進行一次retrospective，並在每次的retrospective 一開始會回顧上次的action item 與成果，檢視是否有改善，這樣會較有意義。
/
誰應該主持？
因為Peggy是專案經理，所以通常是Peggy先來run第一次。
也可以試試看不同角色的人來host, 會有不同的效果，另一方面也可以讓members準備時更全面了解專案內容。
/
誰該參加？
基本上Sprint團隊的成員都要參加。包含團隊中的managers, leaders, DevOps 成員, data scientist , architect等等。
/
開會時間要多久？
一般不建議超過四小時，通常Peggy 大概會預先抓兩小時。
/
How to run Sprint Retrospective?
通常agenda如下
- Project status in this spring/上次retrospective meeting action items and result review
- 暖身小遊戲
- 收集 idea about good / could be better and so on.
Project status in this sprint:
通常Peggy 會很快的帶大家一起看一下project進行的狀態，哪些完成了，哪些沒有，哪些drop等等。
Previous retrospective meeting action items and result review
如果不是這專案的第一次 retrospective meeting，那建議可以回顧一下上次的action item 與累積的進步和成果，也讓member 更感受到團隊是真的有在往改善的方向前進的。
暖身小遊戲
在正式進入燒腦的思考前，進行一個小暖身是蠻好的安排。
Run過幾個不錯的暖身小活動，搜集了其中幾個在這分享。
這邊也特別要特別謝謝 team 裡面幾位有創意的同事們，貢獻了好幾個有意思的暖身小遊戲
Activity 1 : 表達感謝的小活動
輪流講在這個 sprint 中想感謝什麼人，為什麼想感謝對方。
這個小活動有幾個好處，除了讓大家感受到專案是需要團隊合作之外，收到感謝的人也會覺得因為被肯定而高興。有時候也會覺得小驚喜，原來一些順手做的小事會讓同事覺得這麼有幫助呢！通常一剛開始進行的時候，會有點害羞和靦腆 XD。
Activity 2 : 加深成員之間互相了解的小活動
分幾個小組，約3 - 4人一組。
先由某一成員A當起始，順時針開始，剩下兩三位( 同事BCD) 再依序講述印象中這位同事A在這個sprint 作哪一件事， 最後這位同事再加以補充和說明，每一位(BCD)都會輪到。
此一小遊戲的目的是讓同事們互相了解彼此，以後有問題討論也比較知道找誰。另一好處是，當自己做的事有被看見，多數時候也是有被肯定的感覺。
適合剛成立的team，成員間可能不是那麼了解對方在做什麼時候。
Activity 3. 同理心小活動
根據職能角色分組：如 Data team 、 DevOps team 、Managers 等等
分別寫下在此專案中，自己這個角色可能被別人羨慕的與不喜歡的部分。另外也寫下羨慕別職能角色的地方與猜測對方不喜歡的部分。最後開獎，看有沒有落差。
舉例來說，Data team 成員就可以先討論出本身可能被人羨慕的點(ex. 可以一直玩data） 與自己不喜歡的部分(ex. data quality 比想像中差）。接下來討論羨慕 DevOps team 與 Manager 角色的點與對方可能不喜歡的點。
到開獎結果時，常有「喔～」的聲音出現，原來對方有遇到自己想像不到的困難點啊～（那個角色沒有想像中過的爽？ＸＤ）。
Activity 4. 客戶價值
這個小遊戲是提醒 team member 專注於產出客戶價值。
進行方式是先run table 的問大家從起床到進office間會產生的活動有哪些，依時間排序。
接下來用情境 —「如果今天是被 P0 call 起床，需要妳/你盡快進office處理 」來引導大家思考哪些是一定要做且要符合盡快到公司的的關鍵任務。
最後引導大家去思考，把到公司處理重要事情對照到 fulfill business need, P0 的緊急程度代表商場上的競爭激烈與時效，在專案上有哪些關鍵任務須完成才能順利產生value。
/
關於如何搜集需要好好維持的部分，哪些是不夠好而需要改善的地方。
Peggy參考之前主持 brainstorming 會議常用的流程。
- 首先請大家先把想法寫在便利貼上
- 主持者在白板上畫出大項目(ex. good/could be better)
- 等大家寫完第一輪(通常先給十分鐘的時間)，寫完以後請成員一次一個人依序移動靠近白板，大聲說出每一張內容，且分別貼到白板上相對應的good/could be better欄位。
- 歸納：將相近主題的便利貼放在一起。一般做法有兩種，一種是全部的成員都貼完，在請大家一起分類。另一種是第一個成員講述完，第二個成員就可以邊說一邊分類
- 開始投票，從good/could be better中各選出前三重要的群組
- 針對選出來的主題接續討論，著重在怎麼改進，要有action items
過程中有幾個要注意的原則：
- 鼓勵成員自由發想，嚴格禁止隨意批評
- 當依序貼完，有人有新的靈感時，也可以很快補上便利貼
以下是一些例子
Good:
- 導入Scrum
- 明確的release plan
- 緊密的溝通
- ...
Could be better
- Unit test 太少
- 開發環境不夠user friendly.
- data quality 太差
- ....
Action items
- 目標：增進開發效率
- 建立合用的 developing environment in AWS
- ...
/
Peggy目前覺得這樣run有以下幾個優點。
- 有機會可以讓大家早點暢所欲言，不會只悶在心裡爛直到整個專案結束
- 透過機會也知道團隊中的pain/need/happy，進而討論讓sprint跑得更好
- 透過討論與共識而執行，大家意願會比較高，非top down的強硬要求
/
以上為個人的經驗分享，提供給有需要的朋友參考囉，也歡迎交流討論啊。
ref: photo source
若有您轉貼需求，請來信討論。 轉貼時禁止修改內容及標題且保持所有連結。禁止商業使用，請註明原文標題、連結以及作者。
沒有留言:
張貼留言