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的估算值(稍微超過估算不會有太大的影響). 這樣比較單純, 比較好.

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()