敏捷開發中如何做好Sprint規劃?
什麼是Sprint規劃?
Sprint規劃是scrum中用來啟動Sprint的事件。迭代規劃的目標是定義Sprint可以交付的內容,以及如何完成各項工作。迭代規劃需要整個scrum團隊合作完成。
與體育概念中的最後衝刺不同,scrum中的『衝刺』(sprint)要求團隊一直保持極速狀態以提供可工作的軟體,與此同時還需要不斷學習和提高。在scrum中,Sprint是所有工作都得以完成的一段時間。只是在開始行動前,需要設置Sprint的相關條件:例如要決定時間週期的長度、Sprint目標以及從何處開始行動。Sprint規劃會圍繞Sprint中的應辦事項和工作重點展開。如果組織得當,Sprint規劃會還能夠為團隊營造一個充滿激情和挑戰並指引團隊走向成功的環境。糟糕的Sprint規劃可能會因為設定不切實際的目標,而導致團隊的失敗。- 做什麼——Product Owner闡述Sprint目標以及對實現目標有益的PBI。Scrum團隊據此決定在即將開始的Sprint中需要做什麼,以及要做哪些才能實現Sprint目標。
- 怎樣做——開發團隊根據需要交付的Sprint目標來規划具體工作。經開發團隊和Product Owner協商一致後,最終得到一個基於價值和工作量的Sprint計劃。
- 誰來做——Sprint規劃必須要有Product Owner和開發團隊的參與。Product Owner根據產品的價值取向來制定Sprint目標。而開發團隊則需要弄清楚能否實現該目標。二者都必須參與,缺一不可,任何一方的缺席都將導致Sprint計劃無法進行。
- 輸入——Product Backlog是Sprint計劃中非常重要的一個出發點,因為它提供了可能會成為當前Sprint一部分的「基本特徵」表。除此之外,團隊還需要查看增量中已完成的工作,以瞭解進度和剩餘工作量。
- 輸出——Sprint規劃會議最重要的目的是讓團隊闡述Sprint目標,以及如何實現這個目標。這些內容將體現在Sprint的Backlog中。
Sprint規劃會的前期準備
要舉辦一場精彩的Sprint規劃會需要滿足一些基本要求。Product Owner要做好充足的準備,結合前一次的Sprint Review會議中總結的經驗教訓、利益相關者的反饋以及他們對產品的願景,奠定Sprint的基礎背景。透明度方面,Product Backlog應是更新後的版本,確保清晰精準。Backlog Refinement是scrum中一個可選事件,因為有些backlog不需要進行梳理優化的。但對大多數團隊而言,最好在sprint規劃會前將團隊聚在一起對backlog進行review並做出優化。
專家提示:週期為2周的Sprint,要在中期舉行一次backlog梳理會議。跳出當前的Sprint來思考下一個對團隊來說大有裨益。這樣不僅能夠為Sprint規劃做準備,還可以為評估當前的工作提供不同的視角。
限制Sprint規劃的時間
Sprint規劃的時長應限制在每週兩小時以內。所以,一個為期兩周的Sprint,其規劃會議將不會超過兩個小時。這叫做「timeboxing」,即設定團隊完成一項任務所需的最長時間,在這個前提下,進行Sprint規劃。Scrum Master負責確保會議在規定時間內完成。如果團隊在限定時間內達到了滿意的效果,就可以認為會議順利完成。時間限制僅強調最長時間,對最短時間沒有限制。
專家提示:將Sprint目標作為Sprint規劃的重點,不要將過多的精力放在Backlog的細節上。 聚焦目標而非具體的工作,才能讓團隊有更多的精力找到實現目標的最佳方案。
聚焦結果而非具體工作
在做Sprint規劃時,團隊很容易陷入「細節困境」,糾結於哪個任務應該先做,由誰做,以及完成這項任務需要多少時間等。對於比較複雜的工作,初期掌握的信息有限,且大部分判斷都是基於假設。Scrum是一個完全根據經驗的過程,這就意味著很多工作沒辦法提前規劃,而是要通過實踐來學習,然後將學習到的信息反饋到整個開發流程中。
Sprint目標以一個比較高的水平對Sprint的目標進行闡述,而backlog列表也可以用結果導向的思維來編寫。用戶故事是一種從用戶角度描述工作的非常好的方式。如下圖所示,用戶故事應該將焦點放在客戶最終想要實現的效果的缺陷、問題和改進上,而非觀察到的問題。