[經驗]Scrum Master新手上路

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的最終職責是讓團隊都不再需要自己,事情一樣順利進行下去,仔細想想,是不是有點太玄了點~

參考

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

Create a website or blog at WordPress.com

向上 ↑

%d 位部落客按了讚: