敏捷 扑克上的时间估算（转）

摘自：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