Sprint
Sprint是一個長度固定的工作週期,通常為一到四週,最常見的是兩週,並以具體、可用的成果作結。
這個詞來自Scrum,一種廣泛應用於軟體與產品工作的敏捷框架。在Sprint開始時,團隊會就這段期間要處理哪些任務達成共識,這份清單稱為Sprint待辦清單。這份清單在整個Sprint期間保持鎖定,新的請求會排入下一個週期,而不會打斷目前正在進行的Sprint。每個Sprint結束時都會舉行Sprint審視會議,團隊在會中展示實際完成的成果,接著進行聚焦於下次如何做得更好的回顧會議。
固定的時框正是Sprint能夠發揮作用的關鍵。它迫使你將任務拆解得夠小,使其真的能在這段期間內完成,而不是拖延數月之久。Sprint的長度通常介於一到四週之間,實務上最常見的節奏是兩週。較短的Sprint意味著更多的規劃負擔,而較長的Sprint則會延遲回饋,讓錯誤的假設在被發現之前跑得更遠。
這種模式的應用早已超越Scrum本身,例如設計衝刺(Design Sprint),以五天的週期測試單一構想,或單純作為營運與行政工作中反覆出現的工作節奏。這些應用共通的地方,都是同一個循環:設定目標、限制時間、交付成果、反思,然後開始下一個週期。這也是Sprint與里程碑(milestone)的不同之處,里程碑標記的是時間軸上的單一時點,而非反覆出現的工作節奏。
實用範例
一個六人開發團隊規劃了一個為期兩週的Sprint,目標是為其內部軟體開發一項新的報表功能,承諾完成34個故事點。Sprint結束時,29個故事點已完成,並在Sprint審視會議中現場展示,另有5個故事點退回產品待辦清單。在回顧會議中,團隊發現業務部門的意見在這個週期中提供得太晚,因此為下一個Sprint安排了更早的溝通時點。
Leanshift 如何提供協助
Sprint是Kaizen的縮影,一個固定且反覆出現的規劃、執行、展示與反思節奏。每一次回顧會議,都是一次刻意的停頓,詢問下一個週期可以如何做得更好,而不是一味向前衝。這正是Leanshift所謂「改善以培養更多改善者」的核心所在:Sprint的成果固然重要,但團隊從每個週期中學到了什麼,同樣重要。
常見問題
一個Sprint應該持續多久？
介於一到四週之間,最常見的選擇是兩週。確切的長度並不如在各週期之間保持一致來得重要,這樣才能隨時間累積出可比較的數據。
Sprint結束時,未完成的任務會怎麼處理？
它們會退回產品待辦清單,並重新排定優先順序,留待未來的Sprint處理。Sprint進行中不會加入新任務,因為那會破壞Sprint目標。
Sprint與里程碑有什麼不同？
里程碑標記的是專案時間軸上一個重要的單一時點。Sprint則是一個反覆出現、長度相等的工作週期,擁有自己的規劃與審視流程。