故事点

文章内容

传统软件团队使用时间估算工作量，但敏捷团队一般使用故事点来估算软件规模。故事点可使用改良斐波那契数列：0，1⁄2，1，2，3，5，8，13，20，40 或 T 恤尺码：XS，S，M，L，XL 来估算。这种抽象的概念可以帮助团队围绕工作规模做出更好的决策。

CODING 项目协同支持对事项（用户故事、需求、任务、缺陷）进行故事点配置、录入、编辑、查看，还支持查看迭代的故事点总数。

故事点在创建项目时默认开启，可以在「项目设置」->「项目协同」->「协作配置」中进行配置。默认估算方式为「改良斐波那契数列」，可以更改为「T 恤尺码」。

请注意，修改故事点估算方式后，已存在事项的故事点数据将会清空，请谨慎操作。

在新建事项（用户故事、需求、任务、缺陷）时，可以为事项设置故事点。

在「待规划」、迭代详情页、事项（用户故事、需求、任务、缺陷）概览及详情页，均可以查看故事点。

「待规划」中不仅显示单个事项的故事点，也会统计并显示「Backlog」或迭代内所有事项故事点的总和。

迭代详情页与事项概览页中默认不显示故事点，可通过右上方「表格显示设置」开启并调整显示优先级。

传统软件团队使用工时估算工作量。工时是一种绝对估值的方式，它的估算方法常常会依赖于历史经验信息。

故事点是敏捷研发模式中估算软件规模的方式，是一种相对估值的方式。也就是说针对两个需求，可以估计这个需求比另一个需求更大，但不确定每个需求的准确工作量。

在实际使用中，两种估算方法没有优劣之分，只有适不适合的考量。良好的估算实践有助于团队掌握项目的成本和盈利能力，还有助于团队对要交付的需求规模、优先级以及价值达成共识，从而更好地作出业务决策。

斐波那契数列：0、1、1、2、3、5、8、13、21、34、……

该数列的递归关系可定义为：f(0)=0，f(1)=1，f(n)=f(n-1)+f(n-2) (n≥2，n∈N*)。也就是说除了 0、1 两项之外，第 n 项的值等于前两项的和：

1=0+1

2=1+1

3=1+2

8=3+5

…

敏捷研发模式中的故事点，通过使用对比的方式来估算任务规模。在改良斐波那契数列中，当数字越大，相邻数之间的间隔也会越大，使得我们更容易区分哪个任务规模更小哪个更大。例如：21 与 34 之间的差距非常能够说明差异，但过度纠结于 34 还是 35 就很不敏捷。

在实际敏捷研发过程中，由于业务本身的不确定性、经常会出现的新变化因素，以及个人主观因素等原因，导致估算的点数与最终实际情况出入较大，那么以下几个提高故事点效率的方式希望能启发到你：

让任务相关人都参与到估算中。 了解的信息越发全面，得到的结果也更加成熟。同时估算的过程让团队成员们分享各自的逻辑、经验与假设，也有助于团队的步调协同。
参考之前的实际工作。 在回顾迭代时，也回顾和反思估算的准确性，让下一次的迭代估算更加准确和容易。
选择适合的故事点估算方法。 对于不同类型、规模的项目，所适用的估算方法也不一样。比较受欢迎的估算方法包括：计划扑克（Planning Poker）、T 恤尺寸（T-shirt size）、点投票（Dot Vote）等等。

问题反馈 >

2023-10-12最近更新

感谢反馈有用

感谢反馈没用