Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
Burndown chart如何運作
讓我們來看一個這張burndown chart:
這張圖表可以告訴我們:
# 在sprint的第一天 , 8月1日, 團隊評估大約有70個故事點數的工作要完成. 這就是實際上整個sprint的估算速度.
# 在sprint的第十六天, 團隊評估大約剩15個故事點數的工作要完成. 虛線顯示出他們目前進度大約是在控制中, 也就是, 以這樣的速度, 他們在sprint結束前, 會完成每件事情.
我們沒有把週末放到X軸上, 因為很少人會在週末工作.
我們曾經把週末放進去, 但這將使得burndown chart看起來很奇怪, 因為在週末都是平的, 看起來會好像是一個危險的徵兆.
任務板上的警訊
在任務板上快速瀏覽一下,應該就可以知道, 目前sprint進行的狀況如何. Scrum master應負責確認團隊會對這些警訊採取行動:
嘿, 要如何追蹤?
在這種狀況下, 如果你需要可追蹤性, 我所能提供的最佳可追蹤性的方法, 就是每天對任務板拍一張數位照片. 我有時候這樣做, 但是我從來沒有用到這些照片.
如果可追蹤性對你是非常重要, 那任務板可能不適合你.
但是我會建議你嘗試去評估一下詳細的sprint可追蹤性對你的真實的價值是什麼. 一旦sprint完成, 可以運作的程式碼被交付, 文件也被 checked in. 那還有人會關心有多少故事
在sprint的第五天被完成? 又有誰會真的關心"為Deposit實作測試先行"這個故事原先估算的時間是多少?
用天數來評估 v.s. 用小時來評估
在大部分有關Scrum的書籍或是文章, 你會看到任務大部分是用小時來做時間的評估的. 我們曾經也這樣做過. 我們一般的作法是: 一個有效的人天 = 大約是6個人時(man-hours)
現在我們已經不這樣做, 至少在我們大部分的團隊已經是這樣, 原因如下
# 人時的評估太過精細了, 這會導致很多1~2小時的任務, 因而引發微觀管理(micromanagement)
# 通常結果證明是人們的思考始以人天為單位, 只是把它乘以6 得到了人時. "嗯....這個任務需要花大概一天. 哦, 我必須要寫小時數, 那我寫6小時就好了"
# 兩個不同單位會導致混亂, "這是使用人天還是人時評估的呢?"
所以我們現在使用人天當做所有時間估算的單位(雖然我們叫它故事點數). 我們最小的值是0.5, 也就是, 只要任何任務小於0.5, 要不把它移掉, 要不然就是把他和其他任務合在一起, 或者就是給它0.5的估算值(稍微超過估算不會有太大的影響). 這樣比較單純, 比較好.
留言列表
