什麼是Sprint?

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敏捷博客

歡迎訪問交流更多關於技術及協做的問題。

文章轉載請註明出處。