在一起（最好是单数），围绕在一个需求人员的周围；需求人员邀请开发人员在桌上的卡片中挑选出一个可以被认为是基准工作量的卡片，不要过大，也不要过小，我们的经验是一对Pair在10个小时能够完成的用户故事（包含测试）。
当找到这个基准点之后，我们要做的是由需求人员对每张卡片进行讲解，具体描述这张卡实现之后，作为用户我可以做的1，2，3点，目的是让开发人员了解范围。基于这个范围，需求人员可以鼓励开发人员提问，当遇到当时无法澄清的问题时，由需求人员把这个问题转化假设写在卡片上，让开发人员基于假设进行估算。
估算值的大小采用费贝纳切数列1，2，3，5，8，13+，注意有三点：
- 这里只有层级的概念，而没有倍数的关系，2点的故事不代表工作量两倍于1点的故事；而是只要认为这个故事大于基准故事卡而小于一个3点的故事卡时，那么这个故事的点数就是2。所以在一开始如果发现有一张卡片远远高于当前被估算最小点数的卡片，可是暂时不估，等待一个最相似工作量的卡片被估计出来继续；
- 原则上不应该出现8个点以上的故事，如果出现，那么证明这个故事应该被拆分。这样的故事可以被估计为13+，之后由需求人员继续拆分；
- 对于不能估计的故事，打上问号，由需求人员之后澄清后再进行补充；
Mike Cohn发明了用卡片游戏进行估计的方法，考虑到成本较高，我们采用“猜拳法”。当大家已经明确卡片里的内容后，由需求人员喊：1，2，3！开发人员按照自己的想法用手指把点数表达出来，出拳之前大家不要商量，不要影响别人的判断，像杀人游戏里投票的规则一样“不能跟票”。规则是：
－ 重大差异双方PK后重新出拳：如果结果相差两个数量级，比如1和5，双方进行PK，让大家充分考虑不同意见，然后重新出拳；
－ 少数服从多数：如果出现相差不大的情况，少数服从多数，有特别需要提出的，可以给予机会提出，酌情考虑重新出拳；
－ 平票估多不估少：如果出现平票，比如3个3，3个5（因此尽量避免偶数人参加）时，按照估算量大的来算；
需求人员要作为主持人控制整个工作量预估的节奏，防止过度陷入细节，酌情给予重新出拳的机会。
注意，工作量点数应该写在卡片背面。
迭代计划
迭代计划首先需要明白的是到底整个团队能够在一个迭代里交付多少。我们的实践是，把之前准备的卡打散，由需求人员对核心开发人员（参加估计工作量的）说：“既然大家都已经完成了工作量预估，也对需求有了大致的了解，那么大家看一看估计两周的时间里，我们团队能差不多做些什么东西？请在这些卡里挑”。
这里需要注意的是，如果团队是新建团队，大家对团队能力没有一个经验的参考，可以让大家选择自己估计能在两周内完成卡片，之后的规则也基本类似。
这样的挑卡活动大概进行6到8轮，每轮都把卡片重新洗过，由需求人员记录每轮收集卡片的总工作量（这也是为什么把工作量放在卡后，这样可避免开发人员有意识地挑选工作量大或小的卡片），然后除以轮数，得到一个大概的团队单迭代（两周）最大交付能力的数字。
因为永远只能看到昨天的天气，这个数字一定是不准确的，它将会在两周后根据第一迭代的交付情况进行适当的调整。
至此，我们已经得到了一个团队极限交付能力值，假设这个值是30。那么接下来要做的事情便是设计迭代计划。
迭代计划需要考虑的两个进入标准是：
－ 优先安排技术风险较大的技术任务在刚开始的迭代；
－ 每个迭代的一系列故事聚合在一起应该有一个明确的业务目标，体现一种明确的业务场景，而不是零零散散的功能点；
我们做的实践是给需求人员和核心团队与团队极限交付能力相等数量的“筹码”（我喜欢使用曲别
针），我们的例子里是30个。把30个筹码按照上述的进入标准，分别放与工作量相等数量的曲别针在卡上。当30个全部用完，那么第一迭代的故事卡片就被确定。接下来是第2个迭代的需求，以同样的方法，直到所有卡片被排完。注意越到后面迭代的卡片越不准确，因此可酌情考虑只做迭代1，2的计划。
到此为止，我们至少直到了迭代1和迭代2计划安排的工作内容，接下来的工作便是按照迭代泳道把这些卡片贴在墙上，当第一个迭代需求分析完毕后，全体开发人员进行Kickoff会议，快速开始迭代。
版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://yizhituzei.blogbus.com/logs/70698391.html