1. 程式人生 > >敏捷軟體開發中的版本規劃

敏捷軟體開發中的版本規劃

IMG_1627_副本 如上圖,開始之前我們假設產品backlog做過第一次梳理,並且總的故事點為127. 0. 在迭代開始之前,需要有一個產品backlog,並且其中頂部的一些故事是相對更詳細的。 1. 產品backlog需要符合INVEST標準(參見我的一篇部落格)。為了達到這個標準,需要產品負責人(PO)和團隊一起(早期有可能是團隊代表或核心人)對產品backlog進行優先順序排序,估算(有故事點估算、團隊估算、三角估算等方法)等梳理工作。 2. 假設我們有一個產品backlog如附件所示,每個sprint為3周,第一個sprint團隊計劃完成21個故事點,基於以上假設,這個專案需要6個sprint完成,即6x3=18周時間 3. 當第一個sprint結束的時候,很不幸,團隊只完成了14個故事點。那麼需要基於這個事實,對於釋出計劃進行調整。需要10個sprint完成,即10x3=30周時間 4. 如果第二個sprint完成了18個故事點,則基於第一個和第二個sprint的資料,釋出計劃調整為8個sprint,即8x3=24周。此時,由於有了2個sprint的資料,我們可以對釋出計劃的承諾是在24周(最好的情況下)~30周(最差的情況下)
之間。 5. 如果第三個sprint完成了20個故事點,則基於前三個sprint資料,釋出計劃調整為7個sprint,即7x3=21周。此時,由於有了3個sprint的資料,我們可以對釋出計劃的承諾是在21周(最好的情況下)~30周(最差的情況下)之間。 以此類推,一般來說,我們都是在3個迭代之後,對專案的釋出計劃做出承諾的。 ================================================================ 歡迎大家提出其他不同的版本規劃方法,或者建議。謝謝!

-----------------------------------------------------------------------

qrcode_for_gh_1a45f645cae5_258 (1)
微信公眾號: 敏捷那些事兒(agileplus)
Agile1001公開課,每月一次,旨在推廣和傳播敏捷開發思想和Scrum,希望更多的開發者受益。歡迎關注。課程資訊會定期釋出,敬請關注。公開課彙總連結