关于 JIRA 7 里 story point（故事点）的用法解释

[Livid]

https://softwareplant.com/jira-story-point/

一种方式就是，先选择一个足够简单的任务，然后假定这个任务的 story point 是 1，然后再用其他任务和这个任务做比较，由此得出整个 backlog 里所有任务的 estimate。

[smilingsun]

哇，竟然有讨论 Scrum 的帖子！

Story point 确实有其优越性，我的理解是，不管 junior 还是 senior 的 dev，man day 的 estimation 不一样，但 story point 应该（理论上）差不多。

我们 scrum team 曾经考虑过，但是感觉很难做这种相对的比较啊，应该是对 task 很熟悉才能完成？

[Livid]

@smilingsun 我理解这件事情里的难点是，假设一个后端系统要加一个新功能，让维护了几年的原始开发者来做，还是让刚上手的新人来做，那么花的时间会很不一样，老人难说半天就搞定，新人可能会卡一个星期。

[Jalinzqj]

我们的做法是按团队平均水平来估算，时间长了最后还是流于“经验主义”，而且出现了组与组之间的数值相差很大，跨组时数据的参考性就大大降低了

[AltairT]

早知道有这个节点我之前那个询问如何配置审核的帖子就发这了...

[flowfire]

为什么不选择一个一般简单的任务，然后规定这个任务的 1/12 的 story point 是 1(感觉玩了一个很冷的梗…………

[Livid]

@AltairT 看到了，那个帖子已经移动到了这个节点。

[jadec0der]

其实还是换算成时间比较直观。我们试过一天，半天，1/4 天（两小时），两小时似乎是个合适的单位。

[AltairT]

@Livid #6 那个问题是总监说的可以加审核流程(他说在苏宁见过),我网上搜了一圈,把 jira 功能看了一圈没找到他要的那种,最多针对问题类型加工作流.L 大有啥经验嘛.

[asj]

不同的团队做法差异很大，涉及到对 Scrum 的理解和工作方式。有几点：
1. 故事点的用意是隔离“复杂度”和“工时”两个概念。避免简单的把复杂度映射为工时。这样做的目的，一是方式估算时间成为硬的承诺时间；二是取得独立于成本投入的产出指标，比如团队交付的故事点数可以翻番，但是工时翻番就不太可能（当然 996 不算）
2. 进一步而言，背后的理念是关注于产出而不是成本。如果在计划的时候，成员关注点在于怎样可以达成某个成果，而不是我要干多少活。
3. 这个不是单纯的计量单位的转变，很多团队和老板不论是否采用故事点都会最终把它映射为工时。这种情况下可以尽可能弱化背后的工时，逐步向 Scrum 倡导的理念转变（当然前提是团队和老板确实希望如此）。总而言之估算只是估算，不论是点数还是工时都不必太纠结于具体数字，尽可能保持相对大小稳定即可。

[shanghai1998]

错误但好用的方式：
1 个点一天

[Sivan]

希望能直接有个 Scrum 的节点 :P

[Livid]

@Sivan 2011 年的时候就有了：

/go/scrum

[Sivan]

关于工作量的评估差异，我在组里推行的方式是开发人员自己评估，然后组长修正得出最终人天。

[celeron533]

理论上 story point 是找一个比较小的工作 story 作为基准点。然后其他的 story 根据这个基准点再写 point。但是 story point 一般以复杂的为主要依据，而不是工作所要花的时间。

“我给你讲一个简单的故事：双击打开文件” 这个故事 = 2 story point

“我再给你讲一个复杂的故事：用户右击弹出菜单，如果是 win7 系统，则有 ABCD 四个选项；如果是 win10，那么仅有 BCD 三个选项，其中第三个选项点进去会根据用户的连网方式判断后面的二级菜单....然后 xxx...接下来 yyy...” 这个故事 = 13 story point，可以考虑再次拆分成若干个小的 user story

[66beta]

上次公司请人培训，听下来觉得 CRUD 法蛮好的，不过故时的痛点在于迭代中的需求，全新的项目用哪个方法都行得通
有估算师证书考一个也不错哦，现在好像只有国外有

[sea516]

最近采用了 jira 作为工作流，对于 story point 我们也是先认为一天是 1 个 point

[smilingsun]

@asj 武老师好！