Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
團隊如何決定哪些故事要放到這個sprint中?
我們這裡使用兩種技術:
1. 憑感覺
2. 團隊速度的計算
憑感覺來評估
# Scrum Master: "嘿, 大夥們, 我們能在這次sprint中完成故事A嗎?" (指向產品backlog中最重要的項目)
# Lisa: "嗯, 當然可以, 我們有三週, 這只是微不足道的功能
# Scrum Master: " OK, 如果我們加上故事B呢?" (指向第二重要的項目)
# Tom 和Lisa一起回答: "應該沒問題"
# Scrum Master: "好的, 那故事A, B, C 一起呢?"
# Sam (對產品負責人說) : "故事C需要包含一些複雜的錯誤處理嗎?"
# 產品負責人: "不, 你現在可以先跳過它, 只需要有一些基本的錯誤處理"
# Sam: "那故事C應該沒有問題"
# Scrum Master: "好的, 那我們加上故事D呢?"
# Lisa: " "嗯..."
# Tom: "我想我們應該可以"
# Scrum Master: "90%的信心? 或是50%?"
# Lisa和Tom說: "大約90%"
# Scrum Master: "好的, 那D也包含在裡面, 那如果加上E呢?"
# Sam: "或許吧"
# Scrum Master: " 90%或50%?"
# Sam: "我認為差不多50%"
# Lisa: "我很懷疑"
# Scrum Master: "好, 那先不去管它. 我們要做完A, B, C, 和D. 如果還有空的話, 當然我們我們可以做完E. 但是沒人認為它應該被算到這次裡面, 所以我們會先把它排除在這次sprint計畫外, 大家覺淂如何?"
# 所以人: "沒問題"
對於小的團隊或是短的sprint來說, 憑感覺的評估方式還運作的不錯
利用團隊速度的計算來評估
這個技術包含兩個步驟:
1. 決定預估的速度
2. 在沒有超過預估的速度下, 計算有多少故事你可以加入
速度是指"已經完成的工作的總量", 這裡每個項目是根據原始估算來進行衡量的
在下面的圖形中, 有一開始評估的速度和Sprint最後實際的速度. 每個長方形代表一個故事, 裡面的數字代表這故事初始的估算
注意, 這裡實際的估算是根據初始估算為基礎的, 在sprint過程中, 任何有關故事時間的更新都被忽略了
我已經可以聽到你的抱怨了, "這怎麼會有用? 速度的快或慢可能取決於一大堆的因素! 愚笨的程式設計師, 不正確的初步估算, 範圍的改變, 或是在sprint期間無預警的干擾等等"
我同意, 這不是準確的數字. 但是它仍然很有用, 尤其是跟什麼都沒有比的話. 它可以給你一些不容懷疑的事實: "不管原因為何, 我們以為我們可以完成的, 和真正我們做的完的, 還是有些差別的."
在sprint中, 若是有個故事幾乎快要完成, 那又該如何處理? 為什麼我們不能因此加部分點數到我們的速度中? 呵呵, 這裡必須要強調Scrum的精神(事實上, 這也是敏捷開發和lean manufacturing造所強調的), 那就是要全部做完, 可以出貨, 才算是真正做完. 事情做一半, 它的速度只能算是0 (也許還可能是負值). 你可以參考Donald Reinertsen所寫的"Managing the Design Factory", 或是Poppendieck的書, 便可以知道為什麼會這樣說
所以, 我們是透過什麼神秘的魔力來估算速度？
有一個非常簡單的方法去評估速度, 那就是查看團隊的歷史資料. 在過去幾個sprint中, 他們的速度是多少? 然後再假設下一個sprint的速度也差不多.
這個技術就是有名的昨日氣象(yesterday’s weather). 團隊若要使用這項技術, 必須滿足兩個條件: 團隊已經做過幾個sprint(所以有些統計資料可以得到). 以及在下個sprint用大致相同方式來開發(也就是相同的團隊大小, 相同工作狀況等等). 當然啦, 並不是每次都能如此.
另一個較複雜的方法, 是去做簡單的資源計算(resource calculation). 假設我們規劃一個由四個人組成的團隊, 要去進行一個為期三週的sprint. 其中Lisa將會請兩天假, Dave只能投入50%並且會休一天假. 所以讓我們把這些加在一起....
....將會得到這個sprint會有50個可用的人天
那這是我們所估出來的速度嗎? 不是的, 我們估算的單位是故事點數, 雖然是可差不多對應到"理想化的人天". 一個理想化的人天是指能工作有效率, 不受打擾的一天. 但是這種狀況太少見了. 我們還需要進一步考慮一些事情, 像是把沒有規劃到的工作進去, 員工生病不能工作等等.
所以我們的估計的速度一定小於50, 但是到底少多少呢? 我們利用了"投入程度" (focus factor)來解決這個問題
投入程度是指能投入多少精力的估算. 投入程度低, 表示團隊預計將有許多干擾, 或預期自己的時間估算是樂觀的
想要決定一個合理的投入程度, 最好的方法是去看看上一次sprint的狀況 (或是前幾次 sprints的平均值更好)
把上次sprint中, 所有故事的初始估算的值的總和, 就是真實速度的值.
假設上次sprint中, 由Tom, Lisa和Sam三個人所組成的團隊, 在三個星期內工作了45個人天, 一共完成18個故事點數. 現在我們試圖要算出下一個sprint的估算速度(estimated velocity), 為了更複雜一點, 有一個新的同事Dave要加入這個sprint. 把假期和新成員一起加起來, 我們在下一個sprint會有50個人天
所以根據上面的公式, 下一個sprint的估算速度是20個故事點數. 這意味著這個團隊, 在這次的sprint中, 所能做的故事點數總和不能超過20
在這個狀況下, 團隊可能選了前四個故事, 加起來一共19個故事點數. 或是選了前五個故事, 加起來一共24個故事點數. 假設他們選了四個故事, 因為最靠近20. 如果沒有保握, 那就再選少一點
因為這四個故事加起來一共19故事點數, 所以最後他們所估算的速度就是19.
"昨日氣象"是一個方便使用的技術, 但是需要一點常識. 如果上一個sprint, 因為大部份的成員都生病了一周, 是一個run的很糟的sprint. 你可以安全的假設你應該不會這麼慘, 所以你可以評估下次的sprint會有較高的投入程度. 如果團隊最近安裝了新的CI (cintinuous integration)系統, 你可能可以假設投入的程度會比較高. 如果有新人邀加入這次sprint, 你就需要考慮會因要訓練他, 因而減低投入程度.
只要狀況允許, 你應該看看前幾個sprint, 計算出平均值, 這樣會得到更合理的估算
但如果是全新的團隊, 你沒有任何之前的統計數據, 那該怎麼辦呢? 你可以看一下其他有類似狀況的團隊, 他們投入的狀況是怎樣.
如果你沒有其他團隊可以參考呢? 那就隨便猜一下. 好消息是你所猜的值, 只用在第一次的sprint. 之後你就會有歷史資料可以分析, 以用來不斷地分析和改進你的投入程度和估算的速度
我自己對於新的團隊, 所使用的預設投入程度是70%, 因為大部分其他團隊都能達到相同的數值
那我們用哪一個評估的技術呢?
上面我們提到好幾個技術: 憑感覺, 根據昨日氣象來做團隊速度的計算, 以及根據人日和投入程度來做團隊速度的計算
所以我們到底用哪一個?
我們通常的是結合起來使用, 並不會花我們太多時間
我們會檢查上個sprint的投入程度和真實的速度. 接著, 我們會檢查我們這次sprint中所有可用的資源, 並估算投入程度. 然後, 我們會討論這次投入程度之間的差別, 必要時作出適當的調整.
一旦我們根據上次的速度和投入程度, 算出這次sprint該包含哪些故事, 接著我會用"憑感覺"的方法再做一次檢查. 我會要求團隊忘記之前算出來的數字, 只要想像一下, 是否這些這東西在一次的sprint中, 吃下著些故事不會感到難以下嚥. 如果感覺太多了, 我們就移掉一兩個故事. 反之亦然.
在這天結束以前, 只要決定出哪些故事要在這個sprint內完成, 我們就算達成目標. 投入的程度, 可使用的資源, 以及評估速度的方法, 這些都是達成目標的手段.
留言列表
