理想的sprint長度為何
What's the ideal Sprint length
http://agilesoftwaredevelopment.com/blog/jackmilunsky/whats-ideal-sprint-length
November 20, 2009 by Jack Milunsky
作者提到很多人會問他, 一個理想的sprint長度為何.
一般來說, 這個答案是需要依據專案的的狀況來決定的. 因此一開始, 作者就先舉一個專案的例子
專案狀況:
一個團隊有5個成員, 他們的Srint長度為10天. 在前5個的sprints中, 她們並沒有100%完成該sprint所要做的user story, 大約只完成了60%-70%左右.
曾經有建議要把sprint增加到15天, 這是因為10天中的review meeting和planning meeting, 造成不少overhead.
我的想法:
官方的說法, Scrum sprint的長度是30天. 但是我並不這麼認為(我並沒有任何資料支持我的講法, 但是這個感覺來, 是自來自於論壇中的討論), 雖然已經有很多團隊已經採用一個sprint是30天.
大部分的agile社群同意, 較短的sprint會比較好. 所以兩週的sprint, 或是甚至一週的sprint以漸漸變成主流.
為什麼較短的sprint會比較好
1. 我們從精實的夥伴身上學到的經驗是, 短的sprint意味著較少的工作正在進行, 也就是會用較少的時間以及會產生較少的浪費
2. 此外, 較短的sprint會傾向於強調你的流程, 和快速顯示出任何缺失. 例如像是沒有自動化建構流程, 沒有單元測試framework來輔助我們的自動化測試等等. 修復這些缺失, 可以幫助你的組織更有生產力.
假設你認為較短的sprint會比較好的話. 我初步對這個問題的答案會是, 不要試圖去縮短你的sprint. 反之, 找出為什麼你只完成60%-70%.
此外, 60%-70%並不是代表不好, 畢竟你有一個團隊, 已經可以在sprint結束後, 展示出一些sprint的成果了
所以我認為, 不論是故事點數(story point)的評估不一致, 或者團隊過度承諾. 我會建議她們採取以下方法:
試圖在retrospective中去真正評估發生什麼事情, 讓團隊成員自由發言, 說出他們對這件事情的想法
我肯定會花些時間重新評估已完成項目的大小, 例如, 原先這個故事是10個故事點數, 那現在來看他們的大小是否還是10點. 這樣的重新評估可能會幫助你解決問題.
有些人, 像是Ron Jefferies, 會爭論說為什麼你需要把你的評估記下來. 在我看來, 可預測性可以大大地幫助團隊消除壓力. 可以讓團隊有自信地說, 我們可以承諾100點, 每個sprint大約可以交付90到110點不等. 我想你的老闆會喜歡這點
所以重點是先弄清楚為什麼2個星期是不妥當的, 許多團隊都可以達到, 因此兩週是可行的. 如果團隊認為還是需要15天, 那也沒有關係, 只要你們確定那是正確的就可以.
希望這篇文章能幫助你決定適當的sprint長度
留言列表
