Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
12. 我們如何做發佈計畫(release planning)和處理固定價格的合約(fixed price contract)
有時候, 一次只規劃一個sprint要做的事情是不夠的, 我們需要提前做更多計畫. 尤其是處理固定價格的合約, 我們必須事先規劃, 否則我們將會有無法準時交付的風險
一般對我們來說, 發佈計畫是試圖去回答這樣的問題"最晚是什麼時候, 我們才能交付這新系統的1.0版本"
如果你需要去學習有關發佈計畫的事, 我建議你跳過這個章節, 而是去看Mike Cohn的書 "Agile Estimating and Planning". 我真的希望我能夠更早之前就能讀到這本書(我是在我已經自己解決這些問題後才讀到它). 我的發布計畫的版本有點簡單, 但是對於入門來說已經足夠了
定義你的驗收門檻
除了一般的產品backlog外, 產品負責人需要定義一些驗收門檻, 它是從合約的角度, 將產品backlog的重要性層級, 做出簡單的分類.
這裡有些驗收門檻規則的範例:
# 所有重要性 >=100的項目, 都需要被放到1.0版本中, 否則我們將會罰款到死
# 所有重要性在50-99間的項目,應該要被放到1.0版本中, 不過我們可能可以在, 下一個快速緊接發行的版本中完成他們.
# 重要性在25-49之間的項目也是需要的, 但是他們可以在緊接的1.1版本中被完成.
# 重要性 < 25的項目是不確定的, 可以永遠不會需要
這裡有一個產品backlog的範例, 根據上面的規則, 上了顏色來標示
紅色 = 必須被包含在1.0版本中 (banana – pear)
黃色 = 應該在1.0版本中 (raisin – onion)
綠色 = 可能可以之後完成 (grapefruit – peach)
所以如果我們可以在期限前, 交付從banana到onion的每個項目, 我們就安全了. 如果時間不夠用, 我們可能跳過raisin, peanut, donut 或 onion. Onion以下的東西都是額外的.
對最重要的項目作時間的估算
為了要去產生發佈計畫, 產品負責人需要估算, 至少對於合約中所包含的所有故事都要算. 就像sprint規劃會議一樣, 需要產品負責人和團隊一起共同完成 - 團隊一起估算, 產品負責人描述項目內容, 並回答問題.
如果事實證明這樣可以更接近正確的結果, 那這個時間估算是有價值的. 但如果結果證明是有所差距的, 例如像是偏差了30%, 這樣會比較沒價值. 可是如果他跟事實一點關係都沒有, 那就完全沒有用了.
這裡, 我根據做估算的人, 做估算所用的時間, 以及估算的價值, 三者間的關係畫了一張圖
若是用文字來說,這會是一個長篇大論:
讓團隊來說估算
不要讓他們花太多時間
確定他們了解到時間估算只是粗略的估算, 並不是承諾.
通常產品負責人會把團隊放到一個房間中,提供一些點心飲料, 並且告訴他們這個會議的目的, 是產品backlog中前20個(或多少都可以)故事作時間估算. 他會把所有故事講過一遍, 然後在讓團隊開始工作. 產品負責人會待在房間裡, 去回答大家的問題, 有需要時釐清每個項目的範圍. 就像在做sprint規劃會議一樣, "如何展示"這個欄位是非常有用的方法, 去減低產生誤解的風險.
這個會議必須嚴格控制時間長度, 否則團隊會試圖花太多時間, 在少數的故事上.
如果產品負責人要他們花更多時間, 他可以之後再安排另一個會議. 團隊必須確保, 這個會議對於目前這個sprint的影響, 可以讓產品負責人感到非常明顯的. 所以他能理解, 他們時間估算的活動是有代價的.
下面是一個例子, 說明的時間估算最終的結果 (用故事點數表示)
留言列表
