敏捷/XP评估

Question

我是结对编程...how的上下文，你估计吗？一个5点的故事...split in 3 tasks...each任务被2个成员蜂拥而至。这是否意味着它可以在一半的时间内完成？

Answer 1

您可以使用点数进行估计。一个点对可达到的点数称为速度。检查这个：http://en.wikipedia.org/Planning_poker

Answer 2

我总是强调故事的规模过高。如果你可以最小化故事之间的大小差异，那么估计就会变得不那么有趣。也就是说，当任意两层之间的大小差异很小时，评估活动就失去了价值，这有助于快速团队收回评估成本，并将其用于生产(如构建产品)。

考虑到这一点，我建议尽可能主动地修剪积压的文章，并将五个点故事分成较小的故事(仍然是薄薄的垂直切片)。在你的团队有经验之前，我建议你继续使用评估团队，但对每张卡片的默认估计为1分，并进行快速的共识检查或讨论，以解释为什么会有2分或3分。对于任何明显大于3的问题，我建议挑战存在两个问题之一："1“的基准值太小，或者故事应该被分成两部分(要么更具体，要么作为史诗来跟踪)。

随着团队建立一个良好的速度，活动有望将其心态从估计转变为纯粹的故事审查。也就是说，规划中的问题“这个故事有多大？”变成“这个故事不正常吗？”回答后一个问题所需的时间要短得多。

Answer 3

大多数敏捷方法建议您应该以点为单位进行估计。然而，有许多成功的团队-包括几个先进的和高生产力的看板团队-他们在几个小时内估计。积分伴随着他们自己的游戏，反常的激励和问题。YMMV.不管怎样..。

我听说过一对人完成一项任务会多出25%的开发时间。因此，使用两个开发人员而不是一个开发人员，任务将在62.5%的时间内完成。然而，信息和知识共享的质量也经常提高。由于bug=返工和返工比第一次以正确的方式完成要花费更长的时间，结对编程通常会为自己付出代价。这对于不同的任务和技能水平是不同的，例如:简单的bug修复，新手程序员等。

根据我的经验，2/3的时间是一个相当不错的大概数字。它比1/2长，但比只有1个人的时候要短。

关于结对编程研究，是一个值得查询的好名字。你也可以查看维基百科页面上的参考文献：http://en.wikipedia.org/wiki/Pair_programming

这个数字主要由Alistair Cockburn和Laurie Williams在这份报告中的数据所证实：http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF