敏捷撲克是什么？

其實應該叫“估算撲克”更準確一些，本質上是撲克牌，基于Delphi估算原理，可以快速估算出需要的數(shù)字。

關于撲克牌上的數(shù)字

估算撲克牌上的數(shù)字，有的牌是自然數(shù)排列，有些是斐波納契數(shù)，有些則是不連續(xù)自然數(shù)。具體選用哪種撲克，要根據(jù)被估算的內容的跨度大小而定，如果估算值跨度在10倍以內，那么采用順序自然數(shù)比較好，如果數(shù)值跨度較大，達到10倍以上，那么采用斐波納契數(shù)比較好。一般而言，估算軟件開發(fā)工時的話，自然數(shù)可能更好一些，畢竟數(shù)值都不大，跨度也不會很夸張。

撲克估算的意義與價值

第一點，自然是要獲得一個相對較為準確的數(shù)字。

和其他估算方法比，使用撲克牌的方法，能夠帶來一個額外的好處：促進團隊成員間的交流，讓大家共享、了解更多的信息。撲克牌估算中，有一條規(guī)則是：當估算值差距大于可接受范圍內的時候，估算數(shù)值大的人和估算數(shù)值小的人，要各自陳述自己的意見，陳明是什么原因/根據(jù)促使自己做了相應的估算。通過這種方法，可以讓所有人都有機會發(fā)言，分享自己所了解到的知識，而其他人則在這個過程中了解到了很多其他人的知識，這些知識在接下來的開發(fā)工作中，都是很有用的。

會不會有人從來不發(fā)言呢？

答案是，不會的，不可能有人每次都能夠估算出平均值，因此而避免發(fā)言。如果這有這么一個人的話，哈哈，那千萬不要放跑這個人，也別打牌了，全由他一個人估算就好了，又快又準，哈哈～～（發(fā)白日夢中……）

在線免費申請敏捷撲克

點擊此處，申請免費的敏捷撲克

如何使用敏捷撲克？

項目組成員

Scrum Master：Lily，后排左側，QA出身，工作細心踏實。

Product Owner：勇哥，后排右側，資深ITer，做軟件無數(shù)。

成員共有四名：前排，從左至右：陳師傅，開發(fā)組的老大哥；小潔，新人，表現(xiàn)相當出色；阿典，開發(fā)組里的帥哥；Pan，真正的高手。

分牌

每名參與估算的成員分得相同花色的一組牌，兩張Joker不參與估算

敏捷撲克和普通游戲撲克一樣，也有54張牌，也擁有4種花色（每種各13張）和兩張Joker。敏捷撲克的每種花色均是一組13張牌組成的估算撲克牌，牌正面上印刷有供估算用的數(shù)字與符號，數(shù)字分別是1/2，1~10和20，符號為“！”，代表一些未知情況，如無法提供準確估算值等。

一副估算撲克可供四人使用，如果參與估算的人員多于4人，可以使用多副撲克。關于參與估算的人數(shù)方面，一般我們推薦4到8人參與估算；人數(shù)太少，會使估算結果偏差很大，人數(shù)太多，會拉長估算時間，降低估算效率。

講解Backlog

產品負責人勇哥從Backlog中選擇一個條目，為大家詳細講解該條目

團隊成員針對該條目進行討論并提出問題，勇哥逐一解答大家的問題；阿典思路敏捷，總能想到很多大家意想不到的東西來。

這個步驟是團隊和產品負責人之間的交互的環(huán)節(jié)，幫助團隊和產品負責人共同加深對條目的理解。同時產品負責人也會根據(jù)大家的反饋，及時修改條目，完善條目。

在講解條目過程中，千萬不要制定該條目的負責人或明顯的傾向于某些人來做這個條目，這樣會大大降低不負責該條目的團隊成員的積極性，甚至會擾亂估算的秩序與結果。

估算

當團隊成員確認已經對該條目完全了解、無任何重大問題后，大家開始對該條目進行估算，同時選出代表自己估算值的紙牌，但不可立即亮牌。在估算過程中，為避免干擾估算結果，團隊成員之間不可以互相商討；

估算時，我們經常會估算相對值，而不是絕對值，如一個功能的開發(fā)難度或者代碼規(guī)模，估算單位經常使用點，而不是絕對的時間或者數(shù)量，這時我們需要選擇一個估算的標準。最簡單的方法就是我們選擇一個規(guī)模中等，大家都比較容易理解的條目，將其設定為一個標準值，比如5，然后再將其他條目和他進行比較，得出其他條目的相對點數(shù)。每次估算時，最好使用相同的標準條目，這樣對于整個項目的統(tǒng)計有很大幫助。使用相對值進行估算，可以有效的監(jiān)控團隊的生產能力。

選擇牌時，牌中央的數(shù)字和符號代表了你的估算值，受到紙牌數(shù)量的限制，牌面數(shù)字不可能包含了全部的可能性，遇到特殊的數(shù)字時，我們可以采取組合牌的形式，比如您的估算值為3.5，那么我們可以使用一張3，再加上一張1/2來表示3.5。

+=3.5

當所有成員選牌完畢，大家可以同時亮牌

大家估算的結果是：陳師傅，7；小潔，9；阿典和Pan，3。

同時亮牌的好處是，不會有人跟風出牌，每個人的估算都有其獨立思考，這也是撲克估算的精華所在。

爭議與討論

對比每張牌估算值之間的大小，若估算值差距明顯，代表大家對該條目的價值沒有獲得共識，團隊需要對該條目價值評估結果進行討論；

VS

第一輪出牌的結果分別是3，3，7，9；這四個數(shù)字差別很大了，兩個個偏小，兩個偏大，4個數(shù)字的平均值是5.5。這時我們需要讓估算值是3的阿典說明為什么他認為只有3點，為何會如此簡單；之后我們需要選擇9的小潔說明為何她認為數(shù)值會比較大；選擇7的陳師傅最接近平均值，可以選擇發(fā)言或者不發(fā)言均可。

之后大家可以針對每人的發(fā)言進行簡單的討論，討論過程中，隨時可以向產品負責人提問，產品負責人需要回答相應的問題，同時向團隊成員的估算發(fā)出質疑。在討論過程中，Scrum Master要維護活動秩序，不要讓大家討論跑題了，也不要深入研究代碼編寫細節(jié)，這些是實際開發(fā)是再去解決的問題；還有一點很重要，那就是鼓勵所有人都發(fā)言，千萬不要讓老手們或強勢的人控制了局勢。

共識

重復步驟3、4、5，對該條目重新進行估算，直到團隊對于該條目的評估數(shù)值達成一致。

一般情況下，最多3輪就可以得出一個比較統(tǒng)一的意見。

第二輪，大家出牌的結果是6，7，5，5，雖然有人很不情愿，但是畢竟大家達到了一個不錯的共識：估算結果是6~~

如果3輪之后依然沒有得到一個統(tǒng)一的意見，比如第四輪出牌結果依然是2，5，5，8；那么Scrum Muster應當立即中斷該條目的估算，取平均值或其他大家比較能接受的值作為估算結果。沒有任何一種估算是高可靠度的，撲克也不例外，撲克估算的目的就是為了能夠在一個盡可能短的時間內，讓團隊成員更加多的了解需要做的工作，同時順帶得到一個可接受的估算結果。