1. 授权认证
  2. 获取用户个人信息
  3. 项目协同
  4. 代码托管
  5. 持续集成
  6. 制品仓库
  7. 测试管理
  8. 文档管理
  1. 项目协同
  2. 代码仓库
  3. DevOps 实践之旅
  4. 一分钟开始持续集成之旅
  5. 持续部署
  6. 制品库

故事点

功能介绍

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

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 就很不敏捷。

近似斐波那契数列和 T-恤尺码两种故事点估算方式该怎么选

  • T-恤尺码方法适合估算大型用户故事的海量需求列表,估算粒度相对粗糙,但比较快速。

  • 近似斐波那契数列的估算方法适用于用户故事较少需求列表以及小团队,估算粒度相对精准。

如何让故事点的估算更加有效

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

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

上一篇登记工时
最近更新
感谢反馈有用
感谢反馈没用

在阅读中是否遇到以下问题?

您希望我们如何改进?