关于敏捷开发的故事点和持续时间

Posted 2021-04-25 大饼Axure产品经理

课后有同学，对于故事点和持续时间，不是特别理解，所以我就写了点东西，供大家参考！

---

最开始，我们那个小团队，用的是敏捷开发（但是没有用类似jira这种系统，只是在开发的时候借鉴了敏捷的思想，在管理需求上，还是使用excel）

由于大部分产品经理不是研发出身，所以并不能评估确切的开发时间，其实即便是研发出身，也很难给出确切的时间节点，而即便是给，研发也往多了说，比如，2天能做完的，研发往往会说，这个东西，得3到4天。

为什么会有“ 往多了说” 这种情况呢！其实不是研发“ 磨洋工”，在我接触的这些工程师中，绝大多数人，都是非常非常实在的，自己的工作做完了，主动要任务（往事不堪回首 ， 在我刚做产品经理那阵，经常出现，我规划的速度赶不上研发的开发速度），之所以往多了说，其实大部分原因是 ， 软件产品具备不确定性 ， 尤其是业务比较复杂，或者/并且产品经理需求梳理的不清楚的情况 。所以针对于这样的问题，研发为了保证有充足的时间重构代码/修复bug/应对产品经理临时改需求…… 往往是“往多了说”。

企业，为了人尽其用 / 更加精准的监测项目开发进度 / 增加开发的效率 ……等诸如因素吧，就引入了敏捷开发（故事点自然也包含在其中）。 其实所谓的故事点，就是产品经理站在用户的角度，去讲“故事”。确切的说就是讲需求。

---

举个栗子

背景及参会人员：

1、国内某大型教育培训集团，在原业务基础上，重新设计新信息系统，涉及到>财务管理-总部、财务管理（分校-财务）、学籍查询、考勤管理、班级管理（分校-班主任、教质经理）、班级管理（总部-教务）、价格体系管理（总部）、产品体系管理（总部-产品总监）、分期管理（总部-市场总监）、校区管理（总部-信息专员）、报名管理（分校-咨询、班主任）、讲师管理（分校-教质经理）、讲师管理（总部-教务）、POS机管理（总部-财务）、优惠管理（总部-市场总监）等业务模块。

2、 公司在工作群发布消息： 周五下午4点开会，此次开会集中评估，下次迭代涉及到的xx 个故事点，请相 关负责人提前准备 。

3、 参会人员有： 研发部门经理（李总 ）、技术经理（闫哥 ），后端工程师（小明，大喜 ），前端工程师（小慧），测试工程师（老冯 及助手小影）产品经理（大饼，小霞，老郭 ）

以故事点价格体系管理为例：

1、由于此次会议，评估的故事点较多，我下面以通用价格管理为例

2、用户故事：作为产品研发部的总监，我想对通用价格进行管理

3、 故事描述： 通用价格的数据展示，导出数据，通用价格的调价功能，调价的记录

4、 验收标准：

• 课时单价与学费两项都可修改，修改其中一项时，另一项根据课时，自动关联变化，

• 产品包费用=学费*20%

• 分期默认允许

• 课时单价，限定条件为正数

• 课时*课时单价=学费   学费+产品包费=总学费

• 分期首付，限定条件为正数

• 需要上传调价凭证

• 能够查看调价凭证

• 能够查看调价后的通用价格

• 漂浮定位

---

故事点评估：

1、产品经理先讲一遍“故事”，对于那些较为复杂的“故事”，可辅助原型，架构图，流程图……然后团队发表意见，小问题会议结束后，产品经理自行优化，方案没大问题，则开始评估故事点。

2、玩法有很多，我们当时采取的是，团队成员举牌（认为值几个故事点，就写几个，不能交头接耳，要全凭自己感觉）不能交头接耳这一点很重要。

3、去除最高的故事点，去除最低的故事点，举最高和最低的人，要站起来说一说自己的理由。这样做的好处是，1、研发就不敢往多说了（发明敏捷开发的真是个天才）2、举最低的人，要么是工作效率极高，要么是对项目/技术点认知不足

4、假设，价格体系管理这个故事点，最终团队投票表决是个4故事点（4个故事点，赞成的人数多，假设大家无异议），后期在开发的时候，研发花了2个工作日完成了4个故事点，那么2个工作日，就是持续时间。这样我们就可以得出一个大致结论，单个故事点的持续时间是，2/4 =0.5天

5、好！咱们再假设，后面你又评估了一个需求，这个需求的故事点是9，研发花了 3个工作日做完，那么单个故事点的持续时间就是 3/9=0.3天

6、以此类推后面，我们就可以用( 0.5+0.3+X3+X4+X5+……+XN)/N 得到一个平均数，这个平均数就是 单个故事点的持续时间（数据越多，这个平均值是就越有参考价值）

结论：

这样，当团队联手做了1~N个完整的项目之后， 我们就会根据一大堆历史数据，推算出一个相对比较准确的单个故事点的持续时间（所以说敏捷开发这件事，需要团队之间有较长的磨合时间，要不然，估算单个故事点的持续时间不准确）。

后续，产品经理描述完一个需求之后，比如，大体估算是20个故事点，那我们就可以根据以往的经验，知道要完成这20个故事点需求花费多长时间了， 这就是为什么，即便是咱们产品经理不懂技术，但是根据工作经验，我们也可以大体估算出，完成一个功能/页面需要花费多久的原因了

特别说明：

但是这个时间，仅限于当前开发团队，拿到其他团队里面，可能就不适用了，所以我在录课的时候才说，产品经理没有项目经理/技术经理的配合是很难把控项目开发进度的。