Sprint 1 Retro：《不是因為天氣晴朗才愛你》Cover by 氣球
回顧
Sprint 1 順利落幕了，先來看看成果
一、估點數
在計畫時間（Sprint Planning Meeting）中，我把 Sprint 待辦清單上的所有細項寫在便利貼上，按相對複雜度低至高，由左至右排列。接著評估點數，將點數依序寫在便利貼的右上角。
二、看板
一開始所有細項都在 To Do 下方，因為不是每天都有新的狀態，所以底下只有就狀態有更新的日子附上看板圖。
其中，在第 4 天的時候，判斷細項「進階副歌」因為會花過多時間，且對成果的效益很低，故移除該細項。
隨著 Sprint 進行，看板持續更新如下：
三、燃盡圖
由於每天有空的時間不一樣多，加上有些細項比較大，無法在一天內完成。故會出現點數有幾天持平，另外幾天下降比較快的狀況。以下是 Sprint 1 的燃盡圖：
檢討
Sprint 1 走下來雖然大致上順利，但還是有遇到一些困難。以下是問題描述以及想法：
一、估點困難
在最初估點數的階段，很難評估項目的複雜度。
這個在一些不熟悉的故事上（比方未來想用一個 Sprint 研究 NFT）可能甚至連細項都很難拆分，更別說是估點數。
目前沒有良好的解法，只能在 Sprint 開始前多撥出一些時間做初步研究。
二、Sprint 內增減項目
在第 4 天，稍微執行細項「進階副歌」一小段時間之後，覺得難度太高且對於整首歌彈唱起來的效果不如預期，最終決定放棄這個細項。
我認為 Sprint 內並非絕對不能增減項目，但是通常是由 Product Owner 決定項目的增減。因為 PO 本身不參與項目的實作，所以可以比較中立的考量外部關係人的需求以及內部團隊的狀況。
但是在個人的 Scrum 中，我同時扮演所有角色，所以可能會因為「太困難」、「做不完」等因素，決定放棄一個其實很不錯的項目。又因為我實際上不需要對任何外部關係人負責，所以儘管成果品質因此下降，頂多也只是發佈到網路上比較不好看而已。所以尤其在移除預定項目的時候，應該要格外謹慎。
三、燃盡圖消耗點數的速率
燃盡圖最大的目的在於用視覺化的方式呈現目前剩餘點數與預期剩餘點數之間的差異。理想上搭配看板即可迅速反應真實狀態。誠如在燃盡圖小節提到的原因，本來實際消耗點數的速率就不可能是完美的斜直線。只要不偏離參考線太多，我想都是可以接受的。
在工作上，我們剛組成新團隊，開始跑 Scrum。我們以兩週（10 個工作天）為一個 Sprint 的週期。在 Sprint 1 我們預計完成約 120 點，在第 7 個工作天結束時只完成約 40 點，卻在第 8 個工作天把剩餘的約 80 點通通完成。這很不合理！後來梳理原因有二：
- 因為大多數項目都是開發成員沒有實作過的，我們特別在每個大項目多拉出一個「研究」的時間，而且因為不確定要研究多久，所以都估很大的點數。結果發現開發成員實際上會一邊研究一邊實作相關細項，等所有相關細項都完成才會把研究項目移到看板 Done 下方，在燃盡圖上看起來就會是在某一刻完成大量的點數。
- 因為相關細項關聯性高，而且前項會影響後項。成員對實作的結果沒有信心，想要在後續項目使用前面項目確定都沒問題後，才一併更新看板狀態。延續上一點，這會造成一整個大項完成時才一併更新狀態。
針對上述，我們在未來的 Sprint 的解決方案是：
- 移除細項「研究」，並在針對各細項估點時，將各細項的研究時間考慮進去。
- 做完一個細項就在看板上更新狀態至 Done。如果後來真的發現已完成的項目有問題，就再移回 Doing 就可以了。
四、複雜度與預期的不同
在練習彈唱的過程中，發現自己很快就能練到七八成，但是後來又花很多時間練習，卻只有微幅進步到八九成。甚至到已經要錄影的時候，因為緊張（對！錄影也好緊張 >0<），導致本來還算熟悉的地方也會彈錯。所以實際上在「彈唱合併」和「錄影」這兩個細項上多花很多時間，複雜度遠遠超出預期。
這個我覺得難免，而且在越不熟悉的領域可能落差會更大。只能盡量在 Sprint 開始前做一些初步研究，然後留一些 buffer 給未知囉！
NEXT
Sprint 2 故事：撰文介紹書目《Agile 成功法則》
敬請期待~
