有多种方法可以估算应用开发项目。一种方法是使用所谓的故事点。虽然这种类型的估算可能不是最简单的,但使用Story Points进行估算可为应用开发者和客户带来好处。
故事点方法使用历史数据将一个项目的特征与先前类似项目的特征进行比较,以生成精确估计。
上图中的齿轮具有不同的尺寸并具有独特的属性 - 就像软件开发项目中的功能一样。想象一下,没有办法测量圆的大小。我们怎样才能确定每个齿轮的确切尺寸?我们可以使用故事点!
让我们通过Story Points了解估算过程的每一步。
故事点是一个复杂的单元,包括三个要素:风险,复杂性和重复。
为了找到我们的基本故事,我们搜索一个与用户故事的完成定义的内部标准相对应的基本任务,并为其分配一个故事点。这将是我们的基础故事。
有两种类型的尺度用于创建估计矩阵:线性尺度(1,2,3,4,5,6,7 ......)和斐波那契序列数(0.5,1,2,3,5,8,13 ... )。
在RubyGarage中,我们使用Fibonacci序列号。我们这样做是因为人们非常善于比较尺寸,而不是估计绝对值,例如小时数。1和2之间的差异似乎微不足道。但是,1和5之间的差异是显而易见的。
当使用Fibonacci序列号进行估算时,我们创建一个矩阵,其中包含每个序列号及其相关故事的行。然后,我们收集所有故事并开始将它们分成几行,将故事相互比较以及与其他已完成的故事进行比较。请注意,我们的基本故事已经在第一行的此矩阵中,其值为一个故事点。
这是我们的一个矩阵:
为每个故事分配故事点,我们召开一次会议,让所有参与该项目的专家聚在一起玩规划扑克。
Planning Poker是一种基于共识的估算技术,用于估算产品积压。它可以与各种估算单位一起使用,但我们使用带有故事点的规划扑克。
以下是它的工作原理:
在规划扑克结束时,我们已经填写了整个矩阵。我们的任务按实现它们所需的故事点数分成几行。最后,我们将每个积压项放在适当的行中。一排可以有几个故事。
现在我们有一个尺寸估计,您可能想知道我们如何将这些尺寸转换为工时估算。不幸的是,在第一次冲刺完成之前我们无法做到这一点。当第一个冲刺正在进行中时,我们可以跟踪团队的速度。一旦sprint结束,我们就会知道团队每个sprint可以完成多少个Story Points。我们使用这些数字来预测团队在下一个冲刺中的表现。
当我们根据故事点估算所有积压任务时,我们可以了解完成项目需要多少冲刺。最后,我们可以将这些抽象单位转换为真实的日历时间表。
RubyGarage使用Story Points进行估算,因为它很快并且有助于我们理解我们以前从未遇到的故事所需的相对努力。故事点帮助我们为客户提供更准确的估算。经验和参考点比抽象的工时更好。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。