Sprint指Scrum團隊完成一定數量工作所需的短暫、固定的週期。Sprint是Scrum和敏捷的核心，找到正確的Sprint週期將幫助您的敏捷團隊交付更高質量的產品。

「在Scrum框架中，龐大且複雜的產品將被拆分成一個個小的片段，通過一系列被稱為「Sprint」的迭代來完成。」

Sprint使項目更易於管理，讓團隊更快、更頻繁地交付高質量的工作，並使團隊能夠更靈活地適應變化。

許多人將Scrum的Sprint與敏捷軟體開發聯繫起來，以至於不明就裡的人將Scrum和敏捷當成是同一件事。但實際上，兩者根本不是一回事兒。敏捷是一套開發的原則，而Scrum則是一個能夠幫助你把活兒搞定的框架。

如何規劃和執行Scrum Sprints？

Scrum踐行者們考慮十分周到。通過召開Sprint planning會議，用於規劃即將開始的Sprint。Sprint Planning是一個團隊協作活動，這個過程中，團隊需要回答兩個基本問題：本次Sprint要完成哪些工作？如何完成？

Product Owner，Scrum Master和開發團隊需要協作選定每個Sprint中要做的工作項。Product Owner則需要商討Sprint要達成的目標，以及在Sprint結束時可以確保目標實現的PBI。

然後團隊需要在此基礎上制定一個計劃，說明他們將如何構建Backlog列表並在Sprint結束之前將其「完成」。選擇工作事項以及如何完成這些工作事項的計劃被稱為Sprint Backlog。Sprint Planning結束時，團隊已經準備好開始Sprint Backlog的工作，將Backlog列表中的工作推進到「進行中」和「已完成」。

Sprint期間，團隊通過每日站會彙報工作進展。站會的目標是展示可能影響到團隊順利交付Sprint目標的阻礙或挑戰。

Sprint完成之後，團隊將在Sprint Review上展示他們在Sprint期間完成的工作。這也是在產品正式上線前，團隊向利益相關者和團隊其他成員展示工作成果的機會。

最後，以Sprint Retrospective來為整個週期畫上一個圓滿的句號。這也是確定團隊在下一個Sprint中需要在哪些地方做出改進的機會。在此基礎上，就可以著手開始下一個Sprint週期了。

要和不要

即便在掌握了前述基本準則的情況下，大多數團隊在剛剛開始嘗試sprint實踐時也會遭遇諸多困難。以下是一些建議的做法和注意事項。

推薦要做的事項：

  • 一定要確保團隊設定並真正理解了Sprint目標以及Sprint成功與否的標準。這是確保每個成員協同一致並朝著共同目標前進的關鍵。
  • 確保Backlog中所有的工作項按照優先順序和關聯關係順序進行排列。如果管理不當，這可能會是一個極大的挑戰，並且還會破壞整個過程。
  • 確保團隊對速度有很好的理解，並且要體現休假和團隊會議等事項。
  • 用Sprint Planning會議來充實需要完成工作的具體細節。鼓勵團隊成員為Sprint中的所有需求、bug和任務草擬工作任務。
  • 如團隊無法判斷相關性，例如來自另一個團隊、設計和法律簽署的工作則應該暫時擱置。
  • *最後，一旦做出決策或計劃，請確保有人在項目管理或協作工具中能獲取該信息。這能夠確保每個人都可以輕鬆地查閱相關決定及其理由。

當我們致力於成為完成前述所有「推薦要做的事項」的Scrum團隊時，也要避免下面這些危險事項：

需要避免的事項：

  • 不要一次性設計太多用戶故事、高估團隊速度，或在Sprint中加入無法完成的任務。盡量避免設定那些註定會導致團隊失敗的目標。
  • 不要忘記質量或技術債。要為像bug和工程師健康等這樣的QA和非功能性工作預留緩衝時間。
  • 不要讓團隊對sprint中工作內容存在不清楚的地方。確保每個人都清楚地瞭解，不要太專註於快速推進而忘記確保每個人都朝著同一個方向前進。
  • 此外，不要承擔大量未知或高風險的工作。將龐大或具有高度不確定性的用戶故事進行拆解。可以大膽地將部分工作留到下一個Sprint去完成。
  • 如果聽到團隊成員表達的擔憂，無論是關於團隊速度、低確定性工作，還是他們認為超出預估的工作量，都不要忽視這些聲音。解決他們提出的問題，並在必要時重新校準。

更多敏捷乾貨盡在公眾號「WorKtile研發中心」

現在關注即可免費領取電子書《2019研發績效》

P.s. 文中軟體示例來自「Worktile」


推薦閱讀：
相關文章