我人生中的第一個sprint

在公司全面導入敏捷的任性而為之下，我們開啟了Scrum的第一次sprint之旅
記錄一下這個Sprint發生的大小事吧~

我們定義的TimeBox如下：

Sprint時長：2 weeks
Sprint Planning：2 hours
Daily Scrum：15 mins
Sprint Review：1 hours
Sprint Restrospective：1 hours

我的角色：SM + SubPO + Team (一看就是工具人)

一般來說，Scrum的長度訂在2週是較合適的作法。
不過原本我們團隊的運作是以一個月來劃分需求功能，
切成2週來跑的時候，一開始大家是會有一點混亂，這倒是可以逐步調適。

Sprint Planning

實施簡述

理論上，Sprint Planning要由PO或團隊先討論Product Backlog (PB)內容，並適當地切分較大的Story，
不過這是第一次，所以由PO和兩位SubPO(這其實是現有組織所產生的角色)討論並訂出來這次Sprint工作項目。
在Sprint Planning時就由SubPO向團隊說明每個Story要做的事情並排入Sprint中。

可再改善

我們並沒有給團隊評估工作內容大小，團隊也無法決定Sprint裡能做哪些，而是由PO直接排定。
工作項目由PO直接指派團隊成員。

後續調適

在第二次Sprint前，將較大的Story先找相關key person討論，並切分為較小的SubTask(類似PBItem)。
切分後也可以順道評估SubTask所需要的工作時間(代替估算)，但這邊的估算其實還是很不準確。

Daily Scrum

實施簡述

每天早上9:15定時召開，每人述說昨天做了什麼、今天預計做什麼以及遇到的困難。
問題討論在會後進行，會議上不深入細節的探討。
團隊能及時回饋進度資訊以及分享或討論一些技術議題，對於需要跨單位協調的事項也能及時同步。
不過大部分工作彼此交集度不高，大約只有3成的工作資訊對團隊成員來說有同步的意義，
會議中大約有一半的回報是以流水帳的方式呈現。

可再改善

沒有採用Scrum Board的方法聚焦大家在這個sprint內的工作，
目前Sprint所列的PB並不完整，所以要優先處理掉這個問題，讓Daily內容可以更有焦點。

後續調適

要思考如何將Sprint Backlog Item (SBI)的內容整理並呈現出來，於Daily中呈現與追蹤。

Sprint Review

實施簡述

在Sprint的最後一天下午舉辦，約1小時，展示完成的SBI。
展示方式不拘，大致以操作執行，並檢示成果畫面或output資料正確性。
由於大家彼此之間的業務不熟悉，展示前先簡要說明本次功能的重點，及預期的input/output。
團隊成員輪流展示完成之功能，有人實機操作，有人預先錄製影片，也有人直接拿出單元測試報告說明。
展示後由團隊/PO/主管們提出議題討論，有些是針對功能涵蓋度、有些是針對接下來可補足的功能提出建議。

可再改善

團隊只關注自己負責的功能，對於其他人的業務不感興趣。
review過程氣氛嚴肅，缺少互動，
也無法由這個會議鼓舞團隊，感受到自己交付價值的成就，反而變成另類的主管追蹤會議。

後續調適

看下次開會前是否能找到主管贊助點心飲料，讓氣氛緩和一點 XD

Sprint Restrospective

實施簡述

一開始採用了Teddy blog寫到的「感謝某某某」活動(http://teddy-chen-tw.blogspot.com/2010/05/retrospective-meeting.html)，
先讓團隊成員輪流說一次在上個Sprint裡想感謝誰的幫忙協助，效果還不錯，
大家很溫馨地用了10分鐘感謝彼此，也可以聽到一些成員間的互動情況。
接著參考了David Ko的方法(http://kojenchieh.pixnet.net/blog/post/75409372)，
請大家對這次的Sprint流程建議想法寫成便利貼，
然後貼到白板上Happy、Unhappy、Do More、Do Less其中之一個區塊中，並說明自己的想法內容。
團隊有提到幾個想調整的部分：

daily在報告的內容與sprint的工作項無法關聯起來
調整daily報告方式，分享較為特別的資訊，像是很奇特的bug、新發現的功能、解決了很難的需求，若無特別的資訊可以直接pass
不想開sprint review會議，覺得彼此工作無相關
已交付的功能，覺得不需要再review

其中只有第2點是比較明確可調整的項目，後續也與PO溝通同意後調整Daily進行方式。

可再改善

在討論流程改善時，團隊提出的意見，還不容易聚焦在Scrum的流程，
不時會跑出像是「為什麼我們要run scrum?」「會議中聽不懂別人的系統，可以不要參加嗎?」之類的問題。
有時候我會再反問其他成員「那你們覺得如何呢?」，但通常不會再聽到別的聲音...
結果變成團隊在反問我(主管代表)對於流程的意見，而我也盡量避免回答我心目中的想法，
深怕團隊聽完後就停止思考，或只思考如何反對我的意見...XD

後續調適

下回的retro再考慮與隔壁團隊的SM交換主持，看能否讓團隊更有效率地提出自己的看法。
若團隊仍無法聚焦，也可以先暫停retro，先帶一些活動做Team Building，
待團隊成形後，再回復執行retro會議。

結語

我寶貴的第一次經驗就這樣結束了!!

搜尋此網誌

大象想敏捷