3. 我們如何準備 Sprint 的規劃
是的，Sprint 規劃會議這一天很快的到來。我們有個一而再學到的教訓是：
教訓：在 Sprint 規劃會議之前，要確認產品 backlog 是井井有條的。
但願如此！我看過許多 sprint 規劃會議炸掉，是因為產品 backlog 是一個爛攤子。你知道這個名言”垃圾進 = 垃圾出”嗎？ 沒錯。
這是代表什麼意思呢？是要所有的故事都必須被完美的定義嗎？還是所有的估算都必須準確無誤？或者是所有優先順序都要被固定下來？不，不，並不是這樣的！它的意思是：
• 產品的 backlog 必須存在！(你能想像的到這一點嗎？)
• 要有一個產品 backlog 和一個產品負責人 (對於每個產品而言)。
• 所有重要的 backlog 項目，應該要被設定其重要等級，不同重要程度有不同的等級。
o 事實上，如果所有不重要的項目，有相同的評定分數，這是不要緊的。因為目前這次的Sprint規劃會議上，它們並沒有機會被提出來。
o 任何故事，只要產品負責人相信它們最終會在下一個Sprint出現，那就應該有某一特定的重要程度。
o 分數只是讓我們依重要性排序。如果A的分數是20，B的分數是100，那只是簡單說明B比A重要，並不是代表 B 比 A 重要五倍。如果B的分數是21，也是代表同樣的意義：B 比 A 重要！
o 最好在分數之間留下一些間隔，以防之後出現另一個故事 C，它比 A 重要，但是比B還不重要，可是卻沒有分數可以使用。當然啦，你可以給C評定成20.5，但是看起來有點醜陋，所以我們還是留點空隙比較好！
呸！這只是對這個清單排序，你不需要亂動重要等級。
• 產品負責人應該要知道每個故事的意義(通常他是作者，但是有時候其他人會提出一些需求，因此他需要排優先順序) 。他並不需要知道它們是如何被實踐的，但是他需要知道為什麼這個故事會出現在這裡。
註記： 產品負責人以外的人，可能也會增加故事到產品的 backlog 中，但是他們不能指定它有多重要，這是產品負責人才能有的權力。他們也不能設定時間估算(time estimates)的值，這是整個團隊的權力。
我們還嘗試，或評估過其他方法：
• 使用Jira(我們的錯誤案例追蹤系統)來存放產品的backlog。大部分的產品負責人覺得用起來太麻煩了。但是，Excel 是一個不錯和方便直接使用的工具。你可以容易去使用不同顏色表示、重新安排項目、任意增加新的欄位、添加註解、和匯進/匯出資料等等。
Google 電子表單也一樣，只不過 Google 表單是雲端版。可以多個使用者，並同時編輯。
• 像VersionOne、ScrumWorks、XPlanner等，這些Agile的輔助工具，我們還沒有嘗試過它們，不過或許以後會用吧。
全站熱搜
留言列表
