被指派進現在在的 scrum team 不知不覺也快半年了,剛好前陣子團隊做了 10 個 sprint 的回顧,自己也來做點記錄。

步調大致上是每兩週的第一個星期一會是 user story 排序、任務拆解,中間做事,到第二個星期四做下次衝刺的項目預挑選,第二個星期五是成果展示和回顧會議。

在第一週的星期二到第二週的星期五,每天早上有站立會議,報告進度:昨天做什麼,今天打算做什麼,遇到什麼問題,有需要找誰溝通事情的。

成員一開始的時候有顧問、scrum master, PO, UI x 3, UX, API x 2, iOS, Android, 測試。

中間經過幾次成員變動,到六月底的時候成員組成變成 scrum master, PO, PM 1+1, UI x 2, UX, API, 測試。

使用的工具有問題追蹤系統、 Google 文件系列、trello, Zeplin, slack, 和原本的工具沒什麼不同。比較特別的大概是燃盡圖(Burned down chart),我個人不喜歡這個圖表的名字,覺得每次都快要「燒完了」(Burned out)…😫😫😫

 

覺得最難的大概就是估時程這件事了,要嘛嚴重樂觀覺得這很簡單啦大概就加個XX而已,結果實際上發現根本不知道從哪裡下手去加那個XX;要嘛嚴重悲觀多估了很多時間,結果實際上只是一小時以內搞定的事…

再來就是抓休假的時機。雖然專案上屬於 scrum team, 但組織上還是原來的組織,有點「矩陣式組織」的感覺。也因此還是有原本組織裡的事要做:單週二的大會、雙週二的小會、固定不固定的 1 on 1 …。「休假」這件事以前就已經是「事情只能留給休假完的自己」的狀況了,進到 scrum team 以後感覺更難,還在摸索怎麼放心丟假單。

trello 的使用也是自己還沒有很熟練的地方。理想上應該要有辦法做到像是下一整串條件就可以找到 trello 卡片,實際上每次搜起來都覺得算了我還是開票記錄好了…

 

工程師先後離開專案團隊是個不知道怎麼解決的問題。感覺 scrum team 的「公車指數」一直都是 1 ,就算是其他工程師跳下來以大概百分之一不到的極慢速度研究 app 開發,但光一個 app crash 就看不懂錯誤訊息了🤯🤯🤯,還是沒辦法改變 0 個 app 工程師的事實。🥀🥀🥀


arrow
arrow
    文章標籤
    敏捷開發 scrum
    全站熱搜
    創作者介紹
    創作者 repeat ❤️ 的頭像
    repeat ❤️

    旅行的記憶

    repeat ❤️ 發表在 痞客邦 留言(0) 人氣()