[Tech] Planning Poker —
遊戲化的評估方式
在 software engineering 中存在不同類型的 estimation，而不同類型相對要達成精準預估的難度也有所不同，以下列出幾個最常被使用的 estimation 類型：
- Expert estimation: 這種類型的 estimation 通常存在評比的過程。然而因為根據不同經驗背景的人所得出的評比不盡相同，因此和其他類型的 estimation 相比變化程度較大，並且沒有一定的 standard 去支持最後評比的結果是否精準。
- Formal estimation model: 這種類型的 estimation 通常透過數學計算的方式衡量，而數學公式本身由過去經驗所導出。
- Combination-based estimation: 使用多個不同的 estimation 進行組合而獲得更加客觀的預估。
Planning Poker (Expert estimation)
在軟體開發的過程中，團隊往往需要處理如何預估工時才精準。對於專案或產品管理的 manager 而言，這是他們衡量專案資源與時程的一項重要資訊。
對於很多 project manager 而言，有的時候不免會採取透過 deadline 往回推算工時，這麼做有的時候會讓 programmer 無法保證是否能有品質的完成，容易導致 programmer 養成「先求有，再求好」的觀念。
另外也有一些 project manager 會認為觀察 programmer 平時工作的狀況不佳，因此當決定了初步時長後不論怎麼樣都先乘以 3 倍作為緩衝時間。然而事實上 programmer 不會因為時長變長而工作更有效率，過度的放寬 deadline 並不會提昇 programmer 的效率。
工時這件事情的確無法達到絕對精準的預估，但是可以採取一些方式達到「相對客觀」。在整個工時評估的議題上，因為工時往往與需求的複雜度呈正相關，因此需求複雜度的分析便顯的十分重要。
Background analysis
接著我們先討論一些針對工時上常常發生的議題：
- project manager 容易根據過去的經驗主觀判定當前任務 programmer 所需要付出的 effort。
- project manager 對於 programmer 要求的標準前後不一致。
- project manager 容易帶入主觀認知在需求分析上，因而忽略了一部分細節，導致 programmer 對規格需求的理解與 project manager 不同 -> 進而導致 programmer 認為需求總是在異動。
- project manager 認為 programmer 的表現與工作時長不成比例。
- project manager 產品品質和預期的有所落差。
- 相同任務類型不同成員無法有同等的工作效率。
就以上所列的而言，我們可以歸類以下幾點工時判斷的困難點：
- 角色敵對：project manager 與 programmer 不再是為了交付具有使用者效益的產品，兩者帶有自身強烈的目的以及觀點。
- 責任推託：在上面的所有敘述都指出每個團隊成員認為「工時 delay 不是我的責任」，而不是把使用者需求放在最優先的順序。
- 需求變動： programmer 容易因為 deadline 壓力會要求需求不能更改，但是這件事情不論是否執行實際上都有可能會降低使用者的滿意度。
- 品質控管：大部分團隊容易有「先求有，再求好」的習慣，但是往往會演變成「先求有，沒時間求好」的窘境。
上述所有的情況都是針對實際的工時進行評估，但是工時這件事情根據每個人不同的背景會有不一樣的結果，當我們轉移評估的對象為需求，比起工時而言需求複雜度相對客觀，評估需求複雜度而非工時的原因如下：
- 比較不會因人而異：需求大多是由客戶所提出，而一個需求複雜度往往不會因人而異，只有討論實作所需要的時間時才會。
- 相對比絕對容易評估：若以工時來評估，因為會需要評估絕對的數字，加上估算的過程中需要思考實作的細節，並且同時需要思考不同成員的能力，因此工時的評估較為複雜。然而需求複雜度分析可以透過比較不同的需求獲得。
- 評估需求壓力比評估工時小：關注在需求本身，而不用顧慮自身的資源或專案的資源，單純思考需求本身的複雜度。而這種評估在過程中，團隊成員壓力較小，甚至可以採取遊戲般地進行。
在需求複雜度分析上可以將每項需求以 story 的方式敘述，並且根據 story 拆解出多個 task，接著以 story point 來作為評估需求複雜度的單位。所謂的 story point 是 scrum 敏捷開發過程中所使用的一種概念，它代表開發團隊內部所抽象的標準工作量，而一個 story point 可以是大家熟悉的一件獨立、較簡單工作的內容。
雖然需求複雜度往往與工時正相關，但因為實作情況不同，實務上還是有可能出現 story point 高的需求，工時比 story point 低的需求來得少。
對於 project manager 而言，與其評估一個達不到的時程，不如評估較為精準客觀的時程，讓 programmer 第一時間理解離專案預計的時程還有多遠，同時如果資源有限，該如何安排需求的優先順序或尋求其他幫助。
How it works?
Planning poker 以共識為主的評估方法，用於評估工作的 effort 以及相關的 size。它通常在 agile 的軟體開發方法中被使用，特別是極限編程 (XP)。
time: 需求分析
一般而言，針對需求複雜度的工時分析會在還沒有決定需求由誰負責前、每個需求在需求分析後拆解成 story 後執行：當 programmer 還沒有實際參與需求前可以將其個人因素降到最低。也因為不知道由誰實作，所以也不存在所謂的 buffer 或考量自身身上的其他任務或 deadline 而影響預估結果。
target: 所有做事的人
大部分採取 planning poker 的團隊會讓有做事的人一起進行，這麼做的原因有三點：
- project manager 層級的需求單位所估算的工時或著需求的複雜度實際上並不準確，因為大部分的需求單位無法理解實際實作的細節。此外大部分 project manager 為了讓產品能在 deadline 前完成容易根據 deadline 而忽略了實際需求的複雜度。
- 因為在現階段還不知道由誰來做，每個團隊成員所估出來的數字經過彼此討論後比較容易取得共識。
- 團隊成員的參與可以提昇成員在團隊中的歸屬感。
tool: 點數卡牌
大部分 planning poker 進行時會分發每個團隊成員一組類似費氏數列的 card，而 card 上的點數都是由前兩個數字相加，而採取費氏數列做為每張卡牌的點數的原因在於：
- 因為在所有估計的過程中，實際上越大的數字代表估計的結果越不準確，因為有的時候當我們估計一個 story 需要 20 story point 時，那麼 21 和 20 story point 差別不大，我們沒辦法很快速且明確的指出我認為是 20 的理由或佐證。對人類而言使用比例判斷大小相對容易，當採用費氏數列的卡牌時，一旦決定從 13 選擇 21 時差距將近高達 1.5 倍，所以能避免估算時發生「到底這個複雜度是 20 還是 21 」的這種差距極小的情形。
- 同時費氏數列的特性：越大的數字與下一個數字的差距會更大，實際上是變相鼓勵團隊在估算每個 story 時將較大的 story 切成更小的 story 去評估。
- 當將所有的 story 都切成較小的 story 討論時，因為較前面的卡牌彼此之間的數值差距較小，代表可以調整的彈性相對較大。
有些卡牌設計中會出現一些特別的卡牌，像是咖啡牌代表成員認為該休息了、TFB 代表成員認為該 story “太大”、NFC 代表成員認為”沒有線索”
有部份網頁服務有提供 planning poker 的功能，比較適合 remote 團隊在評估工時時可以採用，但是大部分公司都會透過實質卡牌來進行整個 planinig poker
中心概念：創造性模糊
在 Planing poker 中便是模糊邏輯中創造性模糊的應用之一。
所謂的創造性模糊，是因為現實與理想之間大有距離，迫於先天的條件我們無法精確的去量化一件事情，因此透過創造模糊的空間以化解針對數值上不必要的分析。
在 agile 中，過早地在絕對數字上面斤斤計較討價還價，是很沒有價值的事。因此 agile 使用 story point 來代替工時預估，就是故意用「創造性模糊」給個初步的估計，但又避免陷入絕對數字的泥淖。
story point 某種程度上是一種延遲絕對數字估計的方法：在整個 plaining poker 進行的過程中團隊不斷的更新不同 story 的 task 的認知，一旦透過 story point 估計完成後，可以透過團隊所達成的共識再去根據 story point 估計出絕對工時，此時所估計出的絕對工時相對於直接評估而言更加客觀且精確。
process: iteration 評估
- 每當在估算一個 story 時，每個成員選擇一張卡片來表示他的時間估算（以 story point 方式來表示），並且把它的正面朝下放在桌子上。
- 所有的成員都放完以後，桌上的紙牌在同時掀開。
- 如果有兩個估算之間有很大的差異，這時候團隊需要討論這之間的差異，試圖讓大家對這故事的內容去達成共識。
- 接著可能會針對 story 進行拆解，然後再重新估算，直到這個估算收斂到一致。
當你要求對團隊提供一個評估的結果，通常來說最了解 story 的人會第一個發言。不過不幸的，這通常會嚴重影響其他人的估算。因此第 2 點便是為了避免個人被他人的發言或想法影響自身對於 story 的認知。此外，團隊成員評估的時候是要針對這個 story 中所有的 task 做評估，而不是只是對”他們自己擅長”或者”他們未來想做”的部份做估算。
