敏捷專案管理之計畫撲克遊戲

有效的估算是軟體開發人員在工作中面臨的最嚴峻挑戰之一。無論團隊規模如何，他們都需要在整個團隊中定義，評估和分配工作。隨著團隊的擴大，圍繞計畫和評估工作養成良好的習慣變得越來越重要。缺乏計畫和估計會降低對程式的信心，破壞團隊與業務之間的關係，並使每個人的開發工作更加困難。

根據對軟體專案實驗中個人和小組之間的工作量估算準確性的一些研究。來自同一公司的20位軟體專業人員分別估計了實施同一軟體開發專案所需的工作量。參與者具有不同的背景和角色，並且以前已經實施過軟體專案。此後，他們組成了五個小組。每個小組都通過討論和合併其中的知識來達成乙個估計。

結果–基於小組討論的估算比單個估算更為準確。

規劃撲克（也稱為scrum撲克）是一種基於共識的，估算的遊戲化技術，主要用於估算軟體開發中的工作量或開發目標的相對規模。

規劃撲克的步驟

該小組的團隊成員通過在不顯示其估計值的情況下正面朝下打牌來進行估計（斐波納契值：1,2,3,5,8,13,20,40）

卡同時顯示

然後討論估計值，並解釋高和低估計值

根據需要重複，直到估計收斂

通過以這種方式隱藏數字，小組可以避免錨定的認知偏差，因為大聲說出的第乙個數字為後續估計提供了先例。

估計不過是有根據的猜測。我們利用手頭的所有知識和經驗來估算所需的時間。因此，為什麼不將其與之前完成的工作專案進行比較，而不是分別檢視每個新工作專案？對於人類而言，與類似物品相關聯要比猜測事物的實際大小容易得多。

例如，它是否更接近這個很小的東西？還是更像這個正常尺寸的物品？還是真的像我們上個月完成的一件作品那樣巨大？進行相對估計不僅會減少估計工作所花費的時間，還將大大提高估計的準確性。

我們的大腦無法進行絕對估算；我們總是把我們需要估計的新事物與我們已經知道的事物聯絡起來。

planning poker使用fibonacci序列為功能或使用者故事分配點值。斐波那契數列是數列的數學序列，在13世紀被引入，用於解釋自然的某些形成方面，例如樹木的分支。通過將兩個先前的數字相加得到序列中的下乙個值，以生成序列：0、1、1、2、3、5、8、13、21，依此類推。

為了進行敏捷估計，已更改了一些數字，從而形成了以下系列：1、2、3、5、8、13、20、40、100，如下圖所示：

下表中列出了分配給撲克牌的積分的解釋：

那麼，為什麼要使用故事點而不是時間值呢？故事指點使團隊可以專注於完成工作的複雜性和時間。團隊將新工作與他們已經完成的工作進行比較。他們將新任務的複雜性與過去的挑戰進行了比較，並對難度和所需時間進行了排名。

例如，我們通常不會考慮「經商成本」。具有時間值的會議，電子郵件，**審查等。但實際上，所有這些都是我們日常生活中必不可少的做法，但實際上並不算作「工作」。故事點將軟體開發工作與相關的物流工作項隔離開，因此使用基於點的估計比基於小時的方法更一致。