12. 我們如何做發佈計畫和處理固定價格的合約
估算速度
好的，所以我們對於最重要的故事，已經有了一些粗略的估算。 下一步就是估算每個Sprint平均的速度。
這意味著我們需要去決定我們的投入程度。請參見"團隊如何決定哪些故事要被放到Sprint中"。
噢，不，不要再提到該死的投入程度 …
投入程度基本上表示："團隊有多少時間，可花在目前所承諾的故事上"。它不可能是100%，因為團隊會花時間，在做一些沒有規劃到的項目，或是切換工作內容，幫助其他團隊，檢查mail，修理他們出問題的電腦，在茶水間討論一些政治等等。
假設我們決定團隊的投入程度是50%(相當低，我們一般都是70%左右)。並且Sprint的長度假設是3周(15天)長，然後團隊是6個人。
每個Sprint都是90人天，但是只能被預期產出45人天的故事 (因為投入程度是50%)。
所以我們估算的速度是45個故事點數。
忽略投入程度。要求團隊查看這個列表，根據經驗來猜在一個 sprint 內可以做多少，然後算出點數。那會比投入程度還快，不管準確或不準確。大致對會比 … 好 – 噢，等等，我已經講過了。
如果每個故事的時間估算都是5天(但實際上不是)，那團隊差不多能在一個Sprint中完成9個故事。
在發佈計畫中考量所有因素
現在我們有時間估算和速度(45)，我們可以很容易把產品backlog中拆解到sprint中：
在沒有超過45的估算速度下，每個Sprint盡可能塞下很多的故事。
現在我們知道我們大約需要三次Sprint，才能完成所有"必須要做"和"應該要做"的。
3個Sprint = 9 個星期 = 2 個月。這是我們要承諾客戶的最後期限嗎？ 這要視合約的性質而定，以及範圍有多固定，等等。我們通常會增加蠻多的緩衝，來保護糟糕的時間估算，無法預期的問題，以及無法預期的功能等等。所以在這種狀況下，我們可能會同意會"保留"1個月，然後設定交付日期在三個月後。
這裏有另一個替代方案，也運作得不錯。用一個範圍（30-50 點）來評估速度。把 backlog 分成三堆：
所有：這些故事都要被做完，即使我們的速度不快 (30) 。
某些：某些故事將要被完成，但不是全部。
沒有：沒有一個故事要被完成，即使我們的速度很快 (50) 。
最棒的事情是，我們能每三個星期，展示一些有用的事情給客戶。並且在我們進行中，邀請他們更改需求(當然啦，這要看這是什麼合約而定)。
調適發佈計畫
現實不會調整自己去適應計畫，所以我們必須削足適履。
在每個Sprint後，我們會檢查一下這個Sprint的實際速度。如果實際的速度和估算速度差距很大，我們會調整下一個Sprint的估算速度，並且更新發佈計畫。如果這會帶來麻煩，產品負責人會開始和顧客談判，或是檢查一下是否可以在不違反合約下調整範圍。或者他跟團隊想出一些方法，藉由消除在Sprint過程中，所發現的某些嚴重障礙，以增加團隊的速度或是投入程度。
產品負責人可能打電話給顧客說 "嘿，我們進度有點落後，但是我相信，如果把'embedded Pacman'給拿掉的話，我們一定可以趕上期限，因為它會花我們許多時間去建構它。如果你接受的話，我們可以在第一次發佈後，在三週後的下一個發佈中，把它加進去"。
可能這對顧客來說並不是好消息，但是至少我們是很有誠意，並且給顧客一條容易的選擇 - 我們應該要準時交付最重要的功能，還是延遲一段時間後交付出所有功能？ 通常這不是很困難的選擇 ：o)
我做了一個十五分鐘的視頻，叫做 “Agile Product Ownership in a Nutshell”。它包含了一堆有用的提示和技巧，是和 Scrum 的發佈計畫和 backlog 管理有關的。來看看吧！ http://tinyurl.com/ponutshell
全站熱搜
留言列表
