David Ko的學習之旅

不少團隊在執行 Scrum 時, 常常無法在 sprint 內完成原先規劃的東西, 因此他們想拋棄 Scrum, 轉向 Kanban 的陣營, 這是對的嗎? Sprint 是不好的嗎? 讓我們來聊聊這個問題.

很多人之所以無法在 sprint 內完成原先規劃的東西, 不外乎有以下主要原因:

大家在做估算(estimation)時, 最就要的是要有人跟你討論, 問問看他們對你的結果是不是有意見, 他們可能會想到一些你沒注意的面向, 讓你的估算變得比較準確.

這個道理, 其實已經有很多估算的方法採用. 例如Delphi Method. 便是這個概念的始祖. 但是今天我不是要講這個方法, 如果你對 delphi method 有興趣, 可以去看下面這篇文章, 寫得十分詳細.
http://wiki.mbalib.com/zh-tw/%E5%BE%B7%E5%B0%94%E8%8F%B2%E6%B3%95

我要談的是 playing poker, 敏捷社群常用的一種評估方式. Agile 很多方法並不是新創, 但是常常會把它改的更好玩, 更簡易, playing poker 便是如此. 它也是利用了眾人的智慧, 來評估這些功能需要多時間完成. 因此在使用 playing poker 時, 有幾件事情要特別注意的:

Wiki中對Playing Poker的介紹

http://en.wikipedia.org/wiki/Planning_poker

Planning poker是以共識為主的評估方法. 在軟體開發上, 來評估工作的effort和相關的size.

它通常在agile軟體開發方法中被使用到, 特別是Extreme Programming.

這個方法是由James Grenning在2002時所提出來的( http://renaissancesoftware.net/papers/14-papers/44-planing-poker.html). 後來由Mike Cohn在Agile Estimating and Planning一書中發揚光大.

在Planning Poker中, 是由一堆數字的牌所組成的. 通常他們是依費式數列來產生的:0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89.

Playing Poker二三事

Agile團隊中進行release planning時, 常拿playing poker來進行estimation. 最近在一次workshop中, 我們得到以下的經驗

1. Playing poker不只只是做評估而已. 因為在這過程中, 若是大家所評估的數字有差距, 需要釐清之間的差距. 這時候便是一個機會, 可以讓大家對需求做個探討.

2. 若是要挑選一個User story來當起始點, 我們覺得能挑一個size/effort是中間大小的user story是比較好的. 若是一開始挑最小的, 接下來會遇到的問題, 是當你遇到很多很大的的user story, 你不容易講出這些大的user story, 到底他的size/effort是這個最小的user story的幾倍

3. 當你的user story 的story point值很大時, 13, 20 or 無限大時, 這個user story是需要在進一步拆解, 或是做feasibility study. 否則這些這麼大的評估, 對整體來說可能意義不大.

4. 需要不同角色的人來加入, 否則你容易遺漏某個面向的工作, 這樣才能讓你的評估比較正確.