Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
估算速度
好的, 所以我們對於最重要的故事已有了一些粗略的時間估算. 下一步就是估算我們每個sprint平均的速度.
這意味著我們需要去決定我們的投入程度. 請參見"團隊如何決定哪些故事要被放到sprint中"
投入程度基本上表示"團隊的時間有多少花在目前所承諾的故事上". 它不可能是100%, 因為團隊會發時間在做一些沒有規劃到的項目, 或是切換工作內容, 幫助其他團隊, 檢查mail, 修理他們出問題的電腦, 在茶水間討論一些政治等等.
假設我們決定團隊的投入程度是50%(相當低, 我們一般都是70%左右). 並且sprint的長度假設是3周(15天)長, 然後團隊是6個人
每個sprint都是90人天, 但是只能被期待去產出45人天的故事 (因為投入程度是50%)
所以我們估算的速度是45個故事點數
如果每個故事的時間估算都是5天(但實際上不是), 那團隊將會差不多能在一個sprint中完成9個故事.
在發佈計畫中考量所有因素
現在我們有時間估算和速度(45), 我們可以很容易把產品backlog中拆解到sprint中.
在沒有超過45的估算速度下, 每個sprint盡可能塞下很多的故事.
現在我們知道我們大約需要三次sprint, 才能完成所有"必須要做"和"應該要做"的
3個sprint = 9 個星期 = 2 個月. 這是我們要承諾客戶的最後期限嗎? 這要視合約的性質而定, 以及範圍有多固定, 等等. 我們通常會增加蠻多的緩衝, 來保護糟糕的時間估算, 無法預期的問題, 以及無法預期的功能等等. 所以在這種狀況下, 我們可能會同意會"保留"1個月, 然後設定交付日期再三個月後.
最棒的事情是, 我們能每三個星期, 展示一些有用的事情給客戶. 並且在我們進行中, 邀請他們更改需求(當然啦, 這要看這是什麼合約而定)
調適發佈計畫
現實不會調整自己去適應計畫, 所以我們必須削足適履.
在每個sprint後, 我們會檢查一下這個sprint的實際速度.如果實際的速度和估算速度差距很大, 我們會調整下一個sprint的估算速度, 並且更新發佈計畫. 如果這會帶來麻煩, 產品負責人會開始和顧客談判, 或是檢查一下是否可以在不違反合約下調整範圍. 或者他跟團隊想出一些方法, 藉由消除在sprint過程中, 所發現的某些嚴重障礙, 以增加團隊的速度或是投入程度.
產品負責人可能打電話給顧客說 "嘿, 我們進度有點落後, 但是我相信如果把'embedded Pacman'給拿掉的話, 我們一定可以趕上期限, 因為它會花我們許多時間去建構它. 如果你接受的話, 我們可以在第一次發佈後, 再三週後的下一個發佈中, 把它加進去"
可能這對顧客來說並不是好消息, 但是至少我們是很有誠意, 並且給顧客一條容易的選擇 - 我們應該要準時交付最重要的功能, 還是延遲一段時間後交付出所有功能? 通常這不是很困難的選擇 :o)
留言列表
