Agile 🏈 Scrum 開發流程心得：為什麼我的Sprint一再失敗
筆者任職 Yahoo ，《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師，粉絲團《程式猿吃香蕉🍌》
這幾天讀到 Ron Jeffries 再次談到 Working Software 的概念，回想起自己在2015 年為前公司導入 Scrum 的時候，所遇到的種種困難。當時還發了一篇筆記，記錄 Sprint 一再失敗的原因。
事隔多年之後，多了許多歷練，後來對於當年的問題有了較好的解法，因此決定之後另外發系列文，紀錄2020年的想法轉變。本篇是2015年原文復刻，當時文筆較為粗糙也比較犀利，大家可以參考看看是不是目前自己的 Scrum 流程也相同的問題，以下為 2015 原文：
- 2015 原文開始：
因應業務端急遽成長的需求，打算以 Timeboxing 來劃分每個階段的release。因此在公司內導入Scrum開發流程。在Sprint執行的過程中經歷各種酸甜苦辣。以下為總結為什麼我的 Sprint 一再失敗，留下記錄給自己或後人參考。
▍Story 沒有切成 End to end
功能整包綑綁的結果，難以在下一輪 Sprint 插拔 Story，其實 Story 要切成 end to end 是一件很難的事情，需要Product Owner、Stakeholder (也許也需要Scrum Matser的參與）戮力合作才有可能產出。而Story 能否切成 end to end 又主要取決於大家對於專案的理解程度，實行起來非常地高難度。
▍Product backlog refinement meeting 沒有落實
每一次 Sprint 結束之後，並沒有確實進行 backlog refinement，依照專案執行的情況進行調整。但也有可能是因為一開始 Story 沒有切成 end to end，導致 refinement 難以進行。
▍時程緊迫 Sprint Planning Meeting 難以落實
由於時程緊迫，大家都埋頭做事。Planning Meeting 沒有確實把 Product Backlog 裡面的的 Story 做切分或調整。哪些可以平行跑，哪些事項依賴哪些先完成？專案進行又回到各做各的，最後關頭再整合的瀑布式開發情況。
▍Daily Stand up meeting 應該要 Cross functional team 一同參與
大家才能一同了解目前的情況。
▍Team 成員同時進行太多專案，或是中途抽換頻繁
每個 Sprint 應盡可能將 Member 專注再同一個 Sprint 上，人員抽換或是同時進行多個專案。都會反應在溝通成本上，應極力避免。
▍Scrum Master 應專注排除障礙，與 Product Owner 密切聯繫
之前上 Scrum taining 課程時，老師就有提到 Scrum Master 幾乎不可能有時間寫 code (在我實際上跑了之後也有同樣的看法)，當 Scrum Matser 自己也有Task要開發時，就無法綜觀大局。當 Team 開發有問題的時候，Scrum Matser需要時時和 Product Owner 討論情況，確認每個 Story 的優先序。安排下一輪 Sprint，確保下一輪 Sprint 正常進行。
目前常有因為 Scrum Matser 和 Product Owner 太忙，下一輪 Sprint 該做的項目還沒跟確認完畢，導致下一輪 Sprint 根本無法開始。
▍Review Meeting 應落實
確保 Stakeholder 看到他們想要的東西，做錯了也能即時得到 feedback，確保專案航行的方向正確。該做的功能不會漏，該砍的功能也不會傻傻的繼續做。
逝者已矣，來者可追。與各位走在軟體開發大道的人們共勉之，加油！明天會更好！
- 2015 原文結束
當時的這些問題現在看來彷彿歷歷在目，同樣的問題後來也在我其他專案出現，覺得依然有參考價值，之後會再寫系列文紀錄新的一年的心得，以及一些更好的作法 (更新：以下為這幾年的心得系列文)。
若是喜歡我分享的內容，歡迎幫我按個拍手，可拍 50下，給我一點鼓勵，或是加入我的粉絲團《程式猿吃香蕉🍌》，一起分享軟體知識與心得！
