什么是敏捷中的故事点以及如何估算？

敏捷中的故事点是什么？

故事点是一种衡量通过实施敏捷框架（如 Scrum 和极限编程）执行的工作的度量。

用户故事的实现是一项艰巨的任务。 团队可能面临风险； 开发过程中的复杂性等。 这个难度级别是由开发团队通过使用称为故事点的抽象度量来衡量的。 因此，敏捷中的故事点被用作敏捷开发中的度量。 它告诉团队故事的实施有多困难。

产品待办事项梳理会议执行对故事点的估计，然后由产品开发和测试团队进行评估。 这样做是为了提高冲刺计划的效率。 产品积压梳理是检查的粗略估计：

• 冲刺计划是否准备好有效执行。
• 信息是否足以完成事项。
• 基于用户故事的 sprint 计划是否合理。

敏捷故事点估计有三个主要组成部分：

• 风险：对于一个特定的项目，与之相关的风险是模糊的需求、过程中的变化以及对第三方的依赖。
• 复杂性：它代表开发功能的难度级别。
• 接待：它决定了团队成员对该功能的熟悉程度以及开发中某些任务的单调程度。

结合这三点可以准确规划冲刺，包括对不确定性的缓冲、与更好估计相关的问题以及避免在时间承诺上过度学习。

敏捷中的故事点估计

估计敏捷故事点的步骤

在估算敏捷故事点时，开发人员、设计师、测试人员等的参与被认为是关键因素。 由于每个团队成员对推进工作和交付产品都有不同的看法，因此有效的协作很重要。 例如，任何设计的变更不仅需要设计团队的努力，还需要开发部门和 QA 部门的参与。

从敏捷中的故事点估计开始，团队应该有一个基线故事，不一定要求很小，但可以在团队中很好地引起共鸣。 接下来是基于基线故事的故事大小。 在参考故事的帮助下，应该给故事打分。 每个故事都分配了一个点值。

上浆的好处

敏捷交付团队执行更容易估算的规模调整过程。 通过上浆

• 可以查看工作范围的概述。
• 工作的大小可以通过多个角度来确定。
• 任何错误的假设都可以纠正。
• 不能准确的东西都被清除了。

大小调整考虑以下因素：

• 要做的工作量
• 工作的复杂性
• 工作中的风险或不确定性
• 时间/持续时间

通过遵循列出的过程，可以更准确地计划冲刺：

估计故事点的三步过程是：

1. 使用斐波那契数列。

• 传统的人日评估已被替换为通过斐波那契数来估计故事点，即 1、2、3、5、8……
• 不使用线性标度，因为它提供的项目差异不足以定义估计值。 然而，斐波那契数列可以估计问题中的微小跳跃。
• 斐波那契数列表示一个数字序列，其中序列中的下一个数字是前两个数字的总和。 为了估计敏捷中的故事点，斐波那契数列被修改为 0.5, 1, 2, 3, 5, 8, 13, ...

2. 矩阵的确定

• 确定每个故事点的基线。
• 基线作为值 1 包含在矩阵中。这被设置为最小风险、重复等的标准。

3. 规划扑克

通过计划扑克，团队同意每个项目的正确故事点近似值。

计划扑克的工作是

• 在 sprint 计划期间，每个开发人员和测试人员都会收到一组卡片。 这些卡片描绘了一个斐波那契数列。
• 从积压表中选出一个项目进行质疑和澄清项目的特征。
• 在讨论结束时，由测试人员和开发人员私下选出一张反映项目评估的卡片。
• 卡片然后由估算器显示。 如果达成共识，他们将继续进行净项目。 对于不同的卡片，由领导人进行讨论，直到达成共识。

一个完整的矩阵对于估计者在规划扑克期间用作参考是有用的。 这允许在任务之间实现更大的一致性。 此外，估计的最大限制是 13，如果超过 13，那么将任务分解为更小的项目是有效的。 此外，如果估计任务小于 1，则建议将其合并到另一个任务中。

敏捷中成功估计故事点的另外 8 个步骤估计是：

1. 确定基础故事

• 在敏捷中估计故事点的重要步骤之一是确定一个基本故事，该故事用作积压工作的相对规模的参考。
• 基线故事是从开发团队执行的早期故事或当前产品积压中挑选的。
• 每个团队成员对基线故事的理解应该是相同的。 换句话说，团队应该对基线故事充满信心。

2. 讨论要求

• 故事的细节必须讨论，与用户故事相关的解释将由产品负责人或业务分析师提供。

3. 记下重要的事情

• 任何重要的事情都应该记下来。
• 在正在进行的讨论中，Scrum Master 最好地完成这项工作。

4. 要问的重要问题

有几个问题太重要了，开发团队不得不问自己。

• 在开始设计之前，团队成员需要学习什么？
• 故事的代码要求是什么？ 需要多少长度，开发团队之前有没有写过类似的代码。
• 为了让客户接受，涉及多少工作？
• 故事是否有任何外部依赖关系？
• 团队中是否有人有任何专业知识或经验在同一个故事中工作？
• 无论是从业务逻辑的角度还是从技术的角度来看，这个故事是否有任何简单性或相关的复杂性？
• 及时获得依赖关系的确定性有多大？

5. 相对比较的点

• 比较的相对点应该分配给故事。
• 应该为故事分配相同数量的点，即 1，对于具有与已调整大小的故事相同数量的工作的故事。
• 对于更困难的故事，应分配相应的更高值。
• 如果故事由于从前一个故事中可获得的学习而不太复杂，但与该故事几乎相似，则分配较低的值。

6. 根据故事的大小，在整个团队中达成共识。
7. 应该验证故事之间存在内部一致性的事实。
8. 应确保在重复的时间间隔内所有 1 相同或所有 2 匹配等。

敏捷故事点估计的好处

将估计应用于敏捷中的故事点可为开发人员和产品所有者带来好处。

为开发人员提供的好处是：

• 估算的应用使开发人员可以知道冲刺需要多少计划，因此可以以可持续的速度推进工作。
• 避免过度规划冲刺。
• 通过讨论和阐述，可以很好地理解产品所需的实施策略和要求。

为产品所有者提供的好处是：

• 可以专注于产品的长期交付。
• 可以评估项目的“物有所值”或“投资回报”。
• 大项目的技术风险对产品所有者来说是可见的。

从世界顶级大学在线学习软件课程。 获得行政 PG 课程、高级证书课程或硕士课程，以加快您的职业生涯。

概括

就像敏捷方法涉及实践一样，估计本身也是一种随着时间的推移会变得更好的实践。 估计敏捷点的实施对开发人员和所有者都有好处，最终会产生有效的解决方案。

如果您想掌握软件开发方面的知识，请前来查看 upGrad 提供的软件开发执行 PG 计划 - 全栈开发专业化课程。

专业化课程将有助于将任何入门级专业人员的隐藏创造力转变为他们未来的软件开发。 如果需要任何帮助，您可以联系我们的帮助团队。