it-swarm.cn

什么是故事积分的最佳解释是什么?

我们在这里开始使用Story Points进行敏捷开发,但是我很难解释,也找不到任何明确的答案。我能做的最好的事情是指向其他站点(例如 http://blog.mountaingoatsoftware.com/tag/story-points ),并对它们进行一些模糊的概括。我正在寻找一些使用示例的良好解释,这些示例将对其他使用示例有所帮助。有没有很好的资源可以解释故事要点?

36
six8

首先,这可能会有所帮助: 故事点上的Mike Cohn 。但这要好得多: 敏捷开发团队:迈克·科恩的范围和规模

Mike对于软件估算指标的解决方案简单有效。生物学事实:

  • 人脑只是无法正确估计时间。特别是如果超过几个小时。
  • 软件开发人员的不确定性数量,管理人员的心理压力(当您估计时,您付诸实施...)以及团队技能的差异会极大地放大这一点。
  • 但是,我们比较擅长比较东西。我们在那里很准确。

这个想法是获取一个参考用户故事,然后给它任意数量的(故事)点,那么其他故事将获得与该参考相关的分数。

如果您的参考故事是100分,而另一个故事是三倍大,那么它将是300分。

要将故事点转换为计划时间,您必须知道 速度

为了获得准确的速度,您必须进行几次迭代,并计算出团队在给定时间内完成的得分。

有效.

36
user2567

我同意@Pierre 303的所有观点: 如上所述: (除了100参考点之外)。

我唯一要补充(强调)的是,我们不擅长估算任务。我们可以估计相对于其他任务的任务,只要它们的大小大致相同即可。任务之间的差异越大,我们得到的结果就越差。

因此,我不同意使用起点100。

它并不是好像您将下一个任务估计为参考任务的42%。是一半的工作等于两倍的工作,三倍的工作等等。

我们的团队使用 Planing Poker :在此,我们有2个故事点的参考任务。然后,我们使用斐波那契数列来估计任务:1,2,3,5,8,13,21,巨大,?相对于参考任务(不是斐波那契,我看到其他团队使用2的幂。1,2,4,8,16,32,巨大,?)我看到其他团队使用(small(1),Medium( 2),large(3),XLarge(4),但他们仍然可以计算速度。).

关键是,随着任务规模相对于参考任务的增加,我们变得越来越无法准确估算其成本。因此,尝试没有任何意义。这由估计轨迹末端的较大梯度反映出来。

因此,如果您的参考任务是2SP。由于任务的大小相似,因此估算1/2/3/5相对容易。一旦超过参考任务(5SP)的3倍,估计就变得更加困难(是8/9/10SP起作用了)。您所能说的是,它比5SP大且小于13SP,那么8SP符合要求。

对于sprint待办事项,任何SP值大于13/21/Huge的东西都太大了。这些是对您尚未准备好实际工作的事情的估计(因此尚未分解为较小的任务(不要在需要时再将其分解)。但是,它们确实可以为您估计产品积压中任务的大小(以便将来进行一些计划)。您将要对它们进行研究,您应该有足够的知识将它们分解为sprint待办事项的较小任务,并分别重新估计它们(注意:这是一个普遍的误解,认为各个部分的总和等于原始数量)。

  • 您估计的任何事情都需要分解为更小的任务。
  • 任何估计为?意味着它定义得不够好,无法估算
    您需要专门添加一个任务来定义任务
    (即写一些文档或演示文稿)。
5
Martin York

浪费时间。

enter image description here

http://www.Amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859/

有趣的是,这种观点现在来自撰写 Scrum and XP来自Trenches 以及公司名称(Crisp)可以在世界上许多团队使用的众多扑克牌规划卡片组中找到。

OP的最后一句话:“是否有足够的资源来解释故事重点?”是的,这本书是很好的资源。值得深思。

2
azheglov

故事点是任务难度的相对度量。这是因为人类在相对估计上实际上比精确测量要好。

使用故事点的方式是在项目上执行大约两项任务,并为其分配两个不同的故事点值。然后,使用这两个故事点近似值作为估计的基础来估计其他任务。即任务C不比任务A难,但比任务B难得多,因此任务仅比任务A多2个故事点。

当您估算出目前为止的所有需求后,您便可以估算一个Sprint中可以完成的需求量。在接下来的几个冲刺中,您估计已经完成了多少。如果满足要求,则仅将需求的故事点计为已完成。 Scrum中没有“ 80%完成”。这是因为人类实际上并不擅长估计完整性。经过几次冲刺后,您应该对每个冲刺可以处理多少个故事点有所了解。

您如何估算?您可以使用 计划扑克 来确定您的开发人员认为相对于基本需求而言需要进行多少工作。

我还建议阅读 《敏捷武士》 。在我看来,它很好地解释了这些以及其他敏捷概念。

这里有一个故事点的链接。

这里是另一个链接。

2
indyK1ng

正如其他人提到的那样,故事点是用户故事复杂度的相对度量。故事点的真正好处在于实现

  1. 分数由负责实施的单位(个人或团队)测量。
  2. 保留有关在恒定持续时间内(速度)同一单位完成多少个聚合点的度量。

在测量故事点和跟踪速度几次迭代之后,您应该能够准确估计给定时间段内可以容纳多少故事点(迭代或冲刺(如果使用Scrum))。请注意,将此技术应用于小组并尝试将这些指标用于其他团队将无法正常工作。也就是说,如果A团队可以在两周的冲刺中完成120个故事点,那么期望B团队获得相同的结果是不现实的。

就像其他人提到的那样,计划扑克对使用这种方法很有帮助,因为它将帮助确定需要进一步完善的故事(如果票数之间存在差异,则意味着要求存在不确定性)。

0
Michael Brown

我能想到的最简单的解释是使用有形的物体,并提供一个具体的例子。

带上移动房屋。如果我从事移动房屋业务,我会知道建立一个单一的宽度通常需要5个(点,青蛙,小部件...度量形式是任意的),因此建立一个双重的宽度大约需要花费两倍的努力或10个(点,青蛙,小部件)。

程序员的心态将在此时开始讨论简化的方法。由于基础架构耗费了大部分时间以及其他类似示例,因此花费的时间不会是原来的两倍。这是不可避免的。对这是对(点,青蛙,小部件)的估计这一事实之以鼻,因为我们永远无法准确地及时估计,因此对(点,青蛙,小部件)的估计消除了我们可以做到的信念。

要知道要花多长时间才能建成,我们将利用一段时间内的趋势。因此,随着时间的流逝,我们的估算值越来越准确。

当团队准备出发时,请不要忘记 计划扑克

0
Aaron McIver