敏捷 撲克上的時間估算（轉）

摘自：http://www.uml.org.cn/SoftWareProcess/201108264.asp 

 

敏捷撲克是什麼？

其實應該叫「估算撲克」更準確一些，本質上是撲克牌，基於Delphi估算原理，能夠快速估算出須要的數字。

關於撲克牌上的數字

估算撲克牌上的數字，有的牌是天然數排列，有些是斐波納契數，有些則是不連續天然數。具體選用哪一種撲克，要根據被估算的內容的跨度大小而定，若是估算值跨度在10倍之內，那麼採用順序天然數比較好，若是數值跨度較大，達到10倍以上，那麼採用斐波納契數比較好。通常而言，估算軟件開發工時的話，天然數可能更好一些，畢竟數值都不大，跨度也不會很誇張。

撲克估算的意義與價值

第一點，天然是要得到一個相對較爲準確的數字。

和其餘估算方法比，使用撲克牌的方法，可以帶來一個額外的好處：促進團隊成員間的交流，讓你們共享、瞭解更多的信息。撲克牌估算中，有一條規則是：當估算值差距大於可接受範圍內的時候，估算數值大的人和估算數值小的人，要各自陳述本身的意見，陳明是什麼緣由/根據促使本身作了相應的估算。經過這種方法，可讓全部人都有機會發言，分享本身所瞭解到的知識，而其餘人則在這個過程當中瞭解到了不少其餘人的知識，這些知識在接下來的開發工做中，都是頗有用的。

會不會有人歷來不發言呢？

答案是，不會的，不可能有人每次都可以估算出平均值，所以而避免發言。若是這有這麼一我的的話，哈哈，那千萬不要放跑這我的，也別打牌了，全由他一我的估算就行了，又快又準，哈哈～～（發白日夢中……）

在線免費申請敏捷撲克

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

如何使用敏捷撲克？

項目組成員

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

Product Owner：勇哥，後排右側，資深ITer，作軟件無數。

成員共有四名：前排，從左至右：陳師傅，開發組的老大哥；小潔，新人，表現至關出色；阿典，開發組裏的帥哥；Pan，真正的高手。

分牌

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

敏捷撲克和普通遊戲撲克同樣，也有54張牌，也擁有4種花色（每種各13張）和兩張Joker。敏捷撲克的每種花色均是一組13張牌組成的估算撲克牌，牌正面上印刷有供估算用的數字與符號，數字分別是1/2，1~10和20，符號爲「！」，表明一些未知狀況，如沒法提供準確估算值等。

一副估算撲克可供四人使用，若是參與估算的人員多於4人，可使用多副撲克。關於參與估算的人數方面，通常咱們推薦4到8人蔘與估算；人數太少，會使估算結果誤差很大，人數太多，會拉長估算時間，下降估算效率。

講解Backlog

產品負責人勇哥從Backlog中選擇一個條目，爲你們詳細講解該條目

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

這個步驟是團隊和產品負責人之間的交互的環節，幫助團隊和產品負責人共同加深對條目的理解。同時產品負責人也會根據你們的反饋，及時修改條目，完善條目。

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

估算

當團隊成員確認已經對該條目徹底瞭解、無任何重大問題後，你們開始對該條目進行估算，同時選出表明本身估算值的紙牌，但不可當即亮牌。在估算過程當中，爲避免干擾估算結果，團隊成員之間不能夠互相商討；

估算時，咱們常常會估算相對值，而不是絕對值，如一個功能的開發難度或者代碼規模，估算單位常用點，而不是絕對的時間或者數量，這時咱們須要選擇一個估算的標準。最簡單的方法就是咱們選擇一個規模中等，你們都比較容易理解的條目，將其設定爲一個標準值，好比5，而後再將其餘條目和他進行比較，得出其餘條目的相對點數。每次估算時，最好使用相同的標準條目，這樣對於整個項目的統計有很大幫助。使用相對值進行估算，能夠有效的監控團隊的生產能力。

選擇牌時，牌中央的數字和符號表明瞭你的估算值，受到紙牌數量的限制，牌面數字不可能包含了所有的可能性，遇到特殊的數字時，咱們能夠採起組合牌的形式，好比您的估算值爲3.5，那麼咱們可使用一張3，再加上一張1/2來表示3.5。

+=3.5

當全部成員選牌完畢，你們能夠同時亮牌

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

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

爭議與討論

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

VS

第一輪出牌的結果分別是3，3，7，9；這四個數字差異很大了，兩個個偏小，兩個偏大，4個數字的平均值是5.5。這時咱們須要讓估算值是3的阿典說明爲何他認爲只有3點，爲什麼會如此簡單；以後咱們須要選擇9的小潔說明爲什麼她認爲數值會比較大；選擇7的陳師傅最接近平均值，能夠選擇發言或者不發言都可。

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

共識

重複步驟三、四、5，對該條目從新進行估算，直到團隊對於該條目的評估數值達成一致。

通常狀況下，最多3輪就能夠得出一個比較統一的意見。

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

若是3輪以後依然沒有獲得一個統一的意見，好比第四輪出牌結果依然是2，5，5，8；那麼Scrum                           Muster應當當即中斷該條目的估算，取平均值或其餘你們比較能接受的值做爲估算結果。沒有任何一種估算是高可靠度的，撲克也不例外，撲克估算的目的就是爲了可以在一個儘量短的時間內，讓團隊成員更加多的瞭解須要作的工做，同時順帶獲得一個可接受的估算結果。

摘自：http://www.uml.org.cn/SoftWareProcess/201108264.asp