我是配对编程的背景......你怎么估计？一个5分的故事......分成3个任务......每个任务都被2个成员蜂拥而至。这是否意味着它意味着它可以在一半的时间内完成？
答案 0 :(得分：4)
您估计使用积分。一对可实现的点数称为速度。检查一下：http://en.wikipedia.org/Planning_poker
答案 1 :(得分：2)
我总是强调故事大小调整而不是估算。如果你可以最小化故事之间的大小变化，那么估计变得不那么有趣了。也就是说，当任何两个故事之间的大小差异较小时，估算活动就会失去价值，这有助于快速团队收回估算成本并将其投入到富有成效的事物中（如建筑产品）。
考虑到这一点，我建议尽可能主动修剪积压并将五个故事分成较小的（仍然很薄的垂直切片）。在您的团队经验丰富之前，我建议您继续进行估算方，但会提示每张卡的默认估计值为1分，并快速进行一致性检查或讨论为什么有任何理由可以推测到2或3。任何明显大于3的东西，我都建议挑战出现两个问题之一：“1”的基线值太小或故事应该分开（要么更具体，要么作为史诗跟踪）。 / p>
随着团队建立一个体面的速度，活动有望将其思维从估计转移到仅仅是故事审查。也就是说，在规划“这个故事有多大？”时的问题。成为“这个故事是不正常的？”后一个问题回答的时间要少得多。
答案 2 :(得分：1)
大多数敏捷方法都表明你应该以分数来估算。但是，有许多成功的团队 - 包括几个先进且高效的看板团队 - 他们以小时计算。积分来自他们自己的游戏，不正当的激励和问题。因人而异。总之...
我听说一对完成任务的开发时间增加了25％。因此，任务将在62.5％的时间内完成，使用两个开发人员而不是一个。但是，知识和知识共享的质量也经常提高。由于错误=返工和返工比第一次正确的方式更长，因此配对编程通常会为自己付出代价。这对于不同的任务和技能水平有所不同，例如：简单的错误修复，新手程序员等等。
根据我的经验，2/3的时间是一个非常好的球场数字。它比1/2还要长，但比只有1个人的要少。
Sallyann Freudenberg是关于结对编程研究的好名字。您还可以查看维基百科页面上的参考： http://en.wikipedia.org/wiki/Pair_programming
这个数字主要由Alistair Cockburn和Laurie Williams在本报告中的数据证实：http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
答案 3 :(得分：0)
对估计需要多长时间。任何估算都是基于经验 - 团队对项目的经验越长，技术和成对合作的估计结果就越好。任何百分比增加25％的任意百分比等只是在一开始就有用 - 新项目和新技术的新团队 - 你还没有别的基础估算。一旦经验开始建立，估计将会改善。
请记住，他们只是这个 - 估计，这是我们对未来的最佳猜测，借助我们对现在的理解的经验和知识得出 。这就像天气预报 - 我们拥有的数据越多，预报员的体验就越好，但它只是一种预测，而不是现实。
这就是为什么积分如此之大，因为它们可以帮助你估算一个参数 - 手头的任务“大”。
答案 4 :(得分：0)
1）考虑估算单位的一种简单，具体的方法是完成故事所需的签到次数。
如果您正在进行TDD，持续集成和重构，您将在小块工作中工作，保持构建绿色并定期检查，因此在这些条件下，单个签入可以是一个有意义的估计单位。
2）或者，考虑一天中不间断配对时间的块，例如在喝咖啡休息后，喝咖啡休息后吃午饭，午餐后到午后休息，中午到回家的时间 - 每天说4个时段....所以说4个单位是一天。这样你就可以在一次交互中对你期望做的事情进行约束......
就个人而言，我会查看签到的数量，因为我可以粗略地勾勒出所涉及的任务，并了解登记号码。
签到次数的好处在于，无论您是否配对都没关系 - 您只是跟踪您可以完成的工作。