12. 我們如何做發佈計畫和處理固定價格的合約
有時候，一次只規劃一個Sprint要做的事情是不夠的，我們需要提前做更多計畫。尤其是處理固定價格的合約，我們必須事先規劃，否則我們將會有無法準時交付的風險。
對我們來說，發佈計畫是試圖去回答這樣的問題："最晚是什麼時候，我們才能交付這個新系統的1.0版本"。
如果你需要去學有關發佈計畫的事，我建議你跳過這個章節，去看Mike Cohn的書： "Agile Estimating and Planning"。我真的希望，我能更早就讀到這本書(我是在我自己已經解決這些問題後才讀到它)。我的發布計畫版本有點簡單，但是對於入門來說已經足夠了。
並且還需要看了Eric Ries 所寫的精實創業。最大的問題，是大多數的專案，都是企圖去打造大規模的發佈，而不是交付小的增量，然後看看是否在正確的道路上。精實創業，如果使用的合宜，可以徹底地降低風險和失敗的代價。
定義你的驗收門檻
除了一般的產品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的影響，可以讓產品負責人感到非常明顯的。所以他能理解，他們時間估算的活動是有代價的。
下面這個例子，說明了時間估算最終的結果 (用故事點數表示)：
把這個叫做 ”時間估算” 非常容易搞混。相反地，叫 ”大小估算” 比較好。我不知道 “banana” 要多久能完成，但是我相當確定它比 ”apple” 長一點，並且比 “orange” 短一點。大致對會比確定錯好多了！
全站熱搜
留言列表
