开发中的Story Points —— 是什么、评估标准和应用
Story Points（故事点） — 是敏捷开发方法论中衡量任务复杂程度的相对单位。与小时不同，故事点不仅考虑时间，还考虑任务的复杂性、风险和不确定性。根据Scrum.org，2023的数据，使用故事点进行相对评估的团队比使用小时评估的团队错过冲刺截止日期的几率低25%。
要点
- 故事点 — 任务复杂性的相对单位，不与时间挂钩。
- 主要衡量标准 — 斐波那契数列（1， 2， 3， 5， 8， 13， 21）和线性标准（1， 2， 3， 4， 5）。
- Velocity（速度） — 团队在一个冲刺中完成的故事点数量，用于预测。
- 主要优势 — 故事点不依赖于特定开发人员，反映的是团队面对的复杂性。
- 关键规则 — 基准任务确定尺度：团队约定1个故事点代表什么。
什么是故事点？
故事点 — 是在Scrum和其他敏捷方法论中使用的任务复杂性度量。团队不是以小时为单位，而是以相对单位评估每个任务：“这个任务比基准任务复杂两倍”。这种方法消除了不同开发人员速度差异，专注于复杂性本身。
术语起源
故事点的概念随着Scrum的普及在21世纪初出现。最早描述这种方法的是Ron Jeffries，他在极限编程（XP）框架中提出了这个概念。其理念是从总是存在偏差的“人时”评估转向由团队集体确定的相对复杂性。如今，故事点是敏捷团队的行业标准。
故事点中考虑的因素
在使用故事点进行评估时，团队考虑三个因素：工作量（代码量、屏幕数量、逻辑复杂度）、复杂性（技术挑战、新技术）和不确定性（模糊需求、风险）。一个故事点可能意味着“没有风险的简单任务”，而8个则意味着“高风险的高度复杂任务”。
故事点衡量标准：如何选择
选择故事点衡量标准会影响评估的准确性和规划的便利性。最流行的标准是斐波那契数列，但也有替代方案。
| 标准 | 数值 | 优点 | 缺点 |
|---|---|---|---|
| 斐波那契 | 1， 2， 3， 5， 8， 13， 21 | 大任务自然增加分散度 | 对新团队较复杂 |
| 线性 | 1， 2， 3， 4， 5 | 简单易懂 | 大任务没有分散度 |
| 幂次 | 1， 2， 4， 8， 16， 32 | 大任务具有最大分散度 | 大任务难以区分 |
| T恤尺寸 | S、M、L、XL | 快速粗略评估 | 不精确，需要转换 |
为什么是斐波那契？标准背后的心理学
斐波那契数列并非随意选择。1和2之间的差异最小（50%），而13和21之间的差异则显著（62%）。这反映了现实情况：小任务评估更精确，大任务则具有更大的分散度。当一个任务被评估为21个故事点时，团队明白：“我们不知道这需要多长时间，但肯定超过13个”。斐波那契标准防止了虚假的精确性。
基准任务 —— 标准的基础
为了使标准发挥作用，团队需要就基准任务达成一致：“任务X = 1个故事点”。通常选择简单且熟悉的任务作为基准：“在屏幕上添加一个文本字段”或“修复一个打字错误类型的bug”。所有其他任务都相对于基准进行评估。没有基准，故事点就失去了意义 —— 每个人对单位的理解都不同。
团队速率与预测
Velocity（速率） — 团队在一个冲刺中平均完成的故事点数量。这是预测项目截止日期的关键指标。
如何计算速率
速率基于已完成的任务计算：累加团队成功完成的所有任务的故事点（满足完成的定义）。未完成的任务不计入。为了准确性，取最近3-5个冲刺的平均值。例如，如果团队在过去4个冲刺中完成了20、22、18和24个故事点，则速率为21个/冲刺。
通过速率进行预测
知道了速率和产品待办列表中故事点的总量，就可以预测发布所需的冲刺次数。例如，如果产品待办列表中有210个故事点，速率为21，则需要10个冲刺。这是一个粗略的预测，随着工作的进行会变得更加精确。重要提示：速率是平均值，不是承诺。按下限（18个/冲刺）而不是平均值进行规划。
如何提高速率
速率不能通过命令来提高 —— 它是流程健康状况的表现。速率的可持续增长通过以下方式实现：减少技术债务、改善代码审查流程、减少上下文切换、自动化测试和CI/CD。重要提示：不同团队的速率不能相互比较 —— 每个团队都以自己的方式定义故事点。
故事点与小时：何时使用什么
故事点和小时有不同的目的，选择取决于具体场景。经验丰富的团队针对不同任务使用两种方法。
故事点何时更有效
故事点在冲刺规划中不可或缺：它们不依赖于谁将执行任务。初级开发人员每天可以完成2个故事点，高级开发人员可以完成4个，但任务的评估对两者都是2个故事点。故事点允许在不比较开发人员的情况下跟踪团队生产力。这减少了政治压力，改善了团队氛围。
何时需要小时
小时对于外部承诺是必需的：合同、预算、客户报告。客户想知道的不是“8个故事点”，而是“3周”。要将故事点转换为小时，需要使用历史转换率：团队知道1个故事点大约相当于4小时的工作。转换必须透明且基于数据，而不是猜测。
组合方法
许多团队采用组合方法：任务在冲刺规划中用故事点评估，然后管理者将其转换为小时/天用于外部报告。重要的是不要在同一个流程中混合两个系统：要么用故事点评估并从速率推算出时间，要么直接用小时评估。
使用故事点时的常见错误
引入故事点通常会伴随一些错误，这些错误抵消了相对评估的优势。以下是最常见的错误。
将故事点与时间挂钩
最常见的错误 — 团队约定：“1个故事点 = 4小时”。在这种情况下，故事点失去了意义，变成了换了个名字的小时。故事点应该是相对的，不与时间挂钩。如果任务A比任务B复杂两倍，它就应该得到2个故事点，无论需要多少小时。
事后评估
当任务在完成之后才被评估 —— 这不是评估，而是事实确认。故事点应该在开始工作之前、在最不确定的时刻分配。事后评估会扭曲速率，对规划没有益处。而且，它会产生虚假的精确感。
比较不同团队的速率
比较团队A和团队B的速率 —— 毫无意义的练习。每个团队都以自己的方式定义基准和标准。对一个团队来说，1个故事点是一个一小时的简单任务，对另一个团队来说则是一天的任务。只能比较同一团队在动态中的速率：上升或下降。
不一致的标准
当不同任务具有相同的复杂性却得到不同的故事点，而更复杂的任务得到更少的故事点时，标准就失去了作用。团队应该定期校准标准：每3-6个冲刺回顾性地检查评估与真实复杂性的匹配程度。这可以提高评估的一致性。
常见问题
一个故事点等于多少小时？
故事点没有固定的小时等值换算。它是一个相对单位：1个故事点 = 基准任务的复杂性。要转换为小时，请使用您团队的历史转换率：将一个冲刺中的平均工作小时数除以速率。通常1个故事点 = 4-8小时，但这是每个团队特有的。
可以在Kanban中使用故事点吗？
是的，故事点可以在Kanban中使用，但有限制条件。Kanban没有固定的冲刺，因此速率不是按冲刺计算，而是按周或月计算。Kanban团队通常使用周期时间（Cycle Time）—— 任务从开始到结束的通过时间 —— 来代替故事点。选择取决于团队的具体情况。
如果团队无法就评估达成一致怎么办？
如果评估出现分歧（一个人给3个故事点，另一个人给13个），这表示任务没有被很好地理解。将任务分解为更小的部分。讨论不同开发人员看到的的风险和不确定性。如果任务很大 —— 将其评估为Spike（2-4天的研究）而不是故事点。
如何停止使用小时评估并转向故事点？
过渡需要3-6个冲刺。从选择标准开始（斐波那契是最安全的选择），确定基准任务。进行2-3次Planning Poker会议。每个冲刺后计算速率。不要将故事点转换为小时 —— 让团队适应新系统。3个冲刺后，您就会看到规划有了多大改善。
任务完成后的故事点评估会改变吗？
不，评估不会改变。故事点是在开始工作之前进行的初步复杂性评估。任务完成后，评估保持不变，即使实际投入的时间不同。事后更改评估会扭曲统计并使预测失去意义。在回顾中分析差异，但不要事后更改评估。
总结
- 故事点 — 复杂性的相对单位，不与时间挂钩，是Agile评估的基础。
- 主要标准 — 斐波那契（推荐）、线性、幂次、T恤尺寸法。
- 速率 — 每个冲刺的故事点数量；预测截止日期的关键指标。
- 故事点与小时 — 故事点用于冲刺规划，小时用于外部承诺。
- 常见错误 — 与时间挂钩、事后评估、比较团队、标准不一致。
- 基准任务 — 标准的基础；没有它，故事点就失去了意义。
- 关键优势 — 故事点不依赖于执行者，可以专注于团队生产力。
我们将开发一款交钥匙移动应用程序
IT Sectr自2017年以来为初创企业和企业打造iOS和Android应用程序。我们将为您提供咨询并提出最佳解决方案。
另请阅读