Scrum
Scrum是一種敏捷框架,透過固定的角色、活動與產出物,協助團隊以短期迭代循環處理複雜的工作。
Scrum是一種用於開發與管理複雜產品的敏捷框架,最初在軟體開發領域中成形,如今已廣泛應用於許多產業。它立基於經驗性流程控制的理念:團隊不會事先從頭到尾規劃好整項任務,而是以稱為Sprint的短期、固定時框工作,通常為期一到四週。每個Sprint結束時,都會產出一份可用的工作增量,這為回饋創造了空間,也讓團隊得以調整下一步的行動。這種透明性、檢視與調適三者的結合,使Scrum特別適合用於需求不確定或可能發生變化的工作。
Scrum設定了三個固定的角色。產品負責人(Product Owner)掌管產品的價值,並維護產品待辦清單,也就是一份依優先順序排列、列出所有待完成事項的清單。Scrum主持人(Scrum Master)負責確保團隊在框架內運作、排除障礙,並促進協作,但不直接分配任務。開發團隊則自行規劃並執行工作。四個反覆進行的活動,為每個Sprint建立起結構:開始時的Sprint規劃會議、用於快速同步的每日站會、展示成果的Sprint審視會議,以及用於改善團隊協作方式的Sprint回顧會議。
Scrum最適合用於範疇或解決方案在一開始並不完全明確的任務,例如產品開發,或涉及眾多利害關係人的複雜專案。它與Kanban的不同之處在於固定的時框與明確定義的角色,而Kanban則更仰賴持續流動、沒有固定迭代週期的方式。與傳統的瀑布式規劃相比,Scrum的優勢在於定期檢視:誤判能及早浮現,而不是要等到專案結束時才被發現。在實務上,Scrum失敗的原因往往不在於框架本身,而是因為執行不夠徹底,例如跳過回顧會議,或放任待辦清單缺乏維護。
實用範例
一家中型機械製造企業正在開發用於監控其生產設備的新軟體。這個五人團隊以兩週為一個Sprint進行工作:每個Sprint開始時,團隊會從約40項待辦清單中挑選出十項最重要的項目,並透過每天15分鐘的每日站會(Daily Scrum)進行同步。經過十個Sprint、共五個月後,第一個可用版本便已完成,而不是團隊原本規劃、耗時九個月且中途沒有任何階段性成果的開發方式。回顧會議中發現,前三個Sprint期間,不明確的需求耗費了團隊約20%的產能,因此產品負責人(Product Owner)從那時起開始撰寫更精確的待辦清單描述。
Leanshift 如何提供協助
從本質上來看,Sprint回顧會議就是一個反覆進行的Kaizen循環:團隊停下腳步,誠實檢視剛完成的工作,並在繼續前進之前,對工作方式做出刻意的改善。這符合Leanshift的觀點:改善並非一次性的專案,而是融入日常工作的規律習慣。以這種方式運作的團隊,不僅改善了產品本身,更培養出更多懂得自行改善事物的人。
常見問題
Scrum是否只適用於軟體開發？
不是。Scrum起源於軟體領域,但如今已應用於行銷、產品開發、教育等各種領域,只要工作性質複雜、需求可能隨過程改變,都能適用。
Scrum與Kanban有什麼不同？
Scrum以稱為Sprint的固定時框運作,搭配明確定義的角色與活動;Kanban則將工作以視覺化的方式呈現為持續流動,沒有固定的迭代週期,並著重於限制同時進行中的工作量。
小型團隊真的需要專職的Scrum主持人嗎？
不一定需要作為全職角色。在小型團隊中,這項工作通常由某人在其正常工作之餘兼任;重要的是,促進協作與框架本身確實能被落實維持。