如何估算敏捷开发中的故事点.docxVIP

如何估算敏捷开发中的故事点（Story Points） 在以敏捷方法（Agile）开发的项目中故事点（Story Points）是实现用户故事（user story）所需工作量的抽象度量。简而言之，它是个数字，可以告诉团队故事的难度与复杂性，风险程度和需要付出的努力。 在大多数情况下，故事点使用以下尺度之一来衡量其大小： 1、2、4、8、16 XS（X-Small，特小）、S（Small，小）、M（Medium，中）、L （Large，大）、XL（Extra-Large，特大）。（称为“ T 恤尺码”） 斐波那契数列：1,2,3,5,8,13,21 但是，很难根据上述等级来确定指定故事的大小。为了做到这一点，每个团队都必须找到一个基线故事。它不一定是最小的，而是团队中每个人都能引起共鸣的。确定后，应通过将它们与基准进行比较来确定所有用户故事的大小。 在估算故事点时，我们为每个故事分配一个数值。相对值比原始值重要。分配了 2 个故事点的故事应该是分配了 1 个故事点的故事的两倍。它也应该是估计为 3 个故事点的故事的三分之二。 现在让我们详细了解故事点大小的调整方法。 首先，让我们从调整大小的重要性开始。调整大小是有益的，因为它： 给我们概述工作范围 从多个角度确定工作量 清除了一些不准确的信息 纠正错误的假设 大小的调整最好由敏捷交付团队（通常是 Scrum 团队）完成。假如有一个任务：从德里到孟买。行程的持续时间取决于运输方 式（将运输方式视为飞行 2 小时和汽车 22 小时的技术）。如果您选择沿着道路旅行，则需要您的驾驶员的路线知识（领域知识， Domain Knowledge）才能准时到达。持续时间取决于多种因素，但是两地的 距离约为 1400 Km 是恒定的，不会改变。现在，用故事点的度量值替换距离。大小很容易估计，但持续时间却不容易估计。 考虑以下因素即可确定数值大小： 工作量 工作的复杂性 工作中的风险或不确定性 时间/持续时间 与传统项目不同，在敏捷中无法估算工作量/持续时间。这是因为持续时间取决于： 技术/工具 领域知识 从事开发工作的开发人员的技能高低（技术专长） 下面概述了相对大小调整过程： 列出所有要确定大小的故事。 将它们从最小到最大按顺序排列。 记录第一个用户故事 然后看第二个用户故事 确定哪个更大，然后将更大的放到上面 然后选择下一个，并确定相对于其他两个合适的位置 然后拿下一个做同样的事情 重复此过程，直到所有故事都显示在列表中（从最小到最大的顺序） 调整故事大小 从底部开始，为该故事指定 2 个故事点。给“ 2”将为您提供一个更小的故事“ 1”的空间，如果在以后发现有更小的故事，可以分配 1 个故事点。 查看下一个故事，并确定该故事与第一个故事相比有多大。 继续，直到每个故事都确定大小为止。 在调整大小时，请使用这些数字集（如果采用斐波那契数列）： 1, 2, 3, 5, 8, 13, 21。 注意：我们也可以使用T 恤尺寸，XS = 1，S = 2，M = 5，L = 13， XL = 20，XXL = 40 现在让我们了解故事点数与小时数的对比。 故事点是对用户故事中涉及的复杂性的高层估计，通常在冲刺计划之前，发布计划期间或预计划阶段完成。故事点以及冲刺速度为即将到来的冲刺中要完成的故事提供了指南。 另一方面，基于小时的估算是一种低级估算，用于表示完成用户故事中涉及的所有任务所需的实际工时。当以小时为单位提供任务估计时，应使用基于小时的估计。 实际上，故事点和小时数在不同时间具有不同的目的，我们应该避免将它们相互关联以更好地冲刺（sprint）和发布（release）。如下图所示，我们建议您不要在冲刺计划期间着重讲故事的要点，而应着重于估计完成用户故事中涉及的所有任务所需的时间。 故事故事点故事 故事 故事点 故事 1 故事 故事点 故事 1 5 任务 小时数 UI 设计 3 开发任务 1 8 冲刺计划 故事点和小时数的估算流程 希望该文章对您有所帮助，现在您将能够为您的敏捷项目更准确地估算故事点。