Scrum，敏捷開發，筆者以往僅是聽過，直到某一次調動單位後，該組有在執行Scrum，因為地緣關係，溝通較方便，就這樣就被Team Leader (TL)指派，懵懵懂懂的成為了一名Scrum Master，含我共4人一組，有兩位比我資深許多的同事，以及一位工作年資比我稍長的新人，以下就來說說當SM後，我工作上有哪些轉變。
Scrum的例行公事
開始執行Scrum後，多出了許多例行會議，像是
- Standup meeting:
每天一次，盡量不要太久，大家互相了解各自的進度況，遇到哪些問題，一起集思廣益想看看 - Plan meeting:
利用一整天來討論未來兩周的工作，對於每一個task都要討論到如何實作，如果是較複雜的功能可拆分階段，或是先設計做法，再投票出預估的時程，最終不論是誰接到task，都可以完成任務，當然理想很完美，最終挑任務的時候，大家還是會以自己熟悉的為優先，接到不熟悉的task，多花一些時間詢問也是很正常的 - Demo meeting:
將這兩周的成果展示出來，除了讓TL了解工作成果以外，可以邀請需求單位來旁聽，可能會因此更有感覺，而提出更貼近現實的需求 - Retro meeting:
這兩周的sprint，哪些事做的比預期好，或者有什麼需要改進的地方，比較像是對事不對人的檢討會，但要小心不能變成批鬥大會XD
上傳下達的夾心餅乾
這邊可能就有違Scrum精神，但每家公司的文化和制度不同，我們task的優先順序以及哪些事要列為task，都是由TL決定的，有時候也會出現成員做法及習慣和TL不同，Plan meeting時就有點尷尬的情況，後續還是得由SM想辦法努力溝通，就優缺點來讓成員了解，這對我這個資淺的菜菜來說，是一開始最不能適應的地方了~
團隊進度跟進和產出把關
大家做的task我都要盡量了解，並且跟進參與，像是和需求方開會、一些API和架構設計我也要協助review，確認是否有可以改善的地方，如果是重要的專案，更是幾乎從頭跟到尾。另外task完成的代碼，主要也是由我進行code review，對於完全不熟悉的業務流程的專案，真的有點瞎子摸象，只能盡量請成員Demo給我看，來確認是否達到當初設定的完成目標，關於code review之前有寫過一篇文章 [經驗]關於Code Review兩三事。
排除萬難解決團隊遇到的問題
這個還蠻刺激的，當成員遇到技術問題，或是被bug卡住，我就要跳下去趕緊解決，盡量不要拖到進度，而且大家經驗都比我長，遇到的問題還會簡單到哪去，幾乎都需要仔細鑽研，或者不斷嘗試找到真正的key word才能找到解法，整體來說都會花不少時間。
校長兼撞鐘
SM的職責，最常見的比喻就是球隊教練，當球員遇到問題時，要協助解決，自己則不會下場比賽。由於我並不是專職的SM，也需要接task，實際做下來才發現，原來我不只是教練，還兼職球員和球隊經理XD，當然TL有讓我的task盡量減少，但有時忙起來，自己的task都無暇照顧，又或者專心投入在task時，自動就忽略其他成員的進度和需求，等到忙完後才發現，我好像忘記了自己的職責。
一路走來，很感謝成員們互相配合，相處都還算愉快，某次無意間聽到成員說平常還蠻依賴我的，心裡真是有點矛盾，一是開心我真的有幫助到他們，二是太過依賴SM也不是好事，畢竟SM的最終職責是讓團隊都不再需要自己，事情一樣順利進行下去，仔細想想，是不是有點太玄了點~
參考
木澤的研發腦 
發表迴響