对于有经验的团队，有没有一种更好的估算方法?

软件估算的结果对于利益关系人进行人员和预算安排而言是很重要的。敏捷中，流行最广泛的估算技术就是基于共识的计划扑克。这种估算方式是不是太花时间了？对于有经验的团队，是不是有别的可供使用的估算方法呢？

Kane Mar 曾经介绍过一种由Lowel Lindstrom 发明的相似估算法(Affinity Estimating) 。这种方法是：委派一个成员向团队念一下故事描述，随后团队把故事卡片按照他们认为的大小顺序横向地贴在墙上，整个过程不许讨论。

Kane 提到，用这种方法，团队在很短的时间内就可以估算出 30 个用户故事。kane 分享了大家对这个流程的反馈意见：

我喜欢这种估算方法，有很多理由：快速简单；自然；整个决策过程可视化；最后，相似估算法使得估算不再是互相对抗性的，而是一种愉快的合作。

Boris Gloger 发明了一种类似的估算方法，叫做魔术估算法 (Magic Estimating) 。David Campey 提到，通过使用这种“魔术估算法”，他们能够在 10-15 分钟内估算 100-200 个用户故事。 而据 David 介绍，用计划扑克的话，每估算一个故事需要 1-3 分钟。他认为这种差别主要体现在两种方法的规则上：

计划扑克的规则是整个团队一起坦诚地讨论每个用户故事，从而希望把它们都理解透彻。这样当参阅故事卡片的时候，大家能达成一致。
魔术估算法则并行进行，每个参与者运用自己的评价方式去做估算。

David 详细描述了它的机制，并且认为利用这种方法，他们还解决了对于开放性故事 (fallout story) 的估算。所谓开放性用户故事，就是指那些估算结果争议很大或者故事点数在 100+ 的故事。团队针对这些故事进行讨论，产品负责人可以提供更多的细节内容。David 认为这一方法汲取了瞬间决定 (Blink) 理论的要义，从而让估算快速、有效起来。他提到：

在试用之前，我觉得这个方法可能还行，但从能否获得好的估算结果这一点而言，应该比不上计划扑克。现在，我觉得它并不比计划扑克差。计划扑克重在交流，而这种估算方法大家可以独立完成，就像在变魔术。
没有了玩计划扑克所作的交流，也就避免了争论。正如 Oscar Wilde 所说的:“要避免争论，争论总是俗不可耐，而常常令人信服。”

Roger Brown 认为，由于这种方法在估算过程中不允许讨论，就必然会在阐明用户故事和设计方面有所缺失。这是一个很大的缺点。作为对Roger 的回应，Kane Mar 指出虽然用这种方法前期也有某种程度上的讨论，但绝对不会像计划扑克中的那么深入。

Kane 补充道：

我觉得有些方法适用于新组建的团队，而有些方法有经验的团队用起来更好。我个人认为相似估算法就属于后者。我只会在有经验的团队中使用这种方法。

因此，尽管相似估算法和魔术估算法似乎比较快速、有趣，但它们却缺少了计划扑克中的详细讨论。

你怎么看，哪种方法适合你呢？