什么是用户故事

什么是用户故事

我们在做软件外包业务的时候，如果采用敏捷开发的开发，那么在需求阶段可能就会用到用户故事这样一种技术。采用用户故事这样一种技术来描述用户的需求。用户故事的固定格式为：

做为{某类用户}，我希望{系统的能力}，能实现{某个业务}。一个用户故事就是对用户有意义的一次业务操作，在完成这次操作后，用户会得到其业务价值。例如：作为一个购书者，我希望可以根据ISBN号查找一本书，这样我就可以快速的找到我想要的书。

那么我们如何生成用户故事呢？生成用户故事的时候有哪些原则呢？从理论上一个用户故事要满足几个标准

完整性：完整地交付一个用户价值。

针对性：只包含一种角色的用户。

独立性：该用户故事不依赖其他的用户故事。

我们针对以上的三个原则，来尝试解释如何生成一个用户故事。例如我们的一个用户故事是“作为一个系统管理员，我希望通过新增账号的功能，以便于我可以完成一个账号的添加工作”。在这个用户故事中，我们软件开发需要完成新增账号界面的开发、输入数据的校验、数据库操作、添加成功和失败页面的开发。这是一个完整的基本过程，这个过程中用户得到了他的业务价值。

但是如果我们把输入数据的校验作为一个用户故事，那么显然对于用户来说是没有业务价值的。因为这个用户故事，在用户的角度上是感知不到他的业务价值的。它不是一个完整的用户故事。又例如我们生成一个用户故事是：“作为公司老板，我希望能查看人员的数据统计，已便于了解目前公司的员工工作情况”。这个用户故事就“太大了”，它里面包含了多个用户价值，且依赖于其他的用户故事。因为这个用户故事中的“人员数据统计”和“员工工作情况”都不够聚焦，人员数据统计里面的“数据”有多种类型的业务数据，“统计”也有多种统计方式和维度。这种用户故事是需要我们进行拆分的，把它的大小做成只包含一个用户价值的尺寸。例如：“作为公司老板，我希望通过时间范围，部门，职位这3个条件，查看人员考勤数据，以便于掌握公司员工的旷工情况”。改成这个粒度的用户故事，就能体现作为公司老板，能通过一些查询条件，满足他掌握员工考勤中旷工的业务价值。

在前文中，多次出现了业务价值这个术语，那么什么又叫“业务价值”呢？如果我们明白了业务价值，那么我们在生成用户故事的时候，就能更好的掌握用户故事的粒度，让它刚好能表达一个完整的业务价值。

业务价值的字面意思就是：实现对用户有实际价值的业务过程。那么怎么定义业务呢？系统能实现订单管理叫业务，系统能实现订单搜索也叫业务，这个业务的粒度又如何划分呢？我个人的看法是要结合你们团队的具体人员配置，和你们自己制定的迭代周期（有些项目可能也不一定要用迭代的方式进行，可能就是每个月需要给用户演示一些进度，我们这里就姑且都称作迭代），以及整个项目周期来综合考虑。

一个用户故事的尺寸最大就是刚好在一个迭代中完成交付。例如你们团队有2个后台和2个前端加1个测试，一个迭代的周期是2周，那么你们划分的用户故事，最大就是要能保证在2周之内可以达成交付的效果。不过一般情况下我不建议在一个迭代过程中，只完成一个用户故事。因为这多半说明用户故事还是太大了，太大了就不利于尽早的进入测试和得到用户的反馈。我个人建议在结合团队人员配置和迭代周期以及项目周期的前提下，每个迭代能完成2到3个用户故事。每个用户故事有至少有1个前端和1个后端在进行，这样的话每个开发能聚焦在自己的工作范畴内，尽量减少多人之间的沟通交流，只保持完成一个业务价值的最小人员配置（一般都是1前端和1后端）。

总结上文，如何制定合适的用户故事，需要结合每个团队每个项目的实际情况。根据这些实际情况来划分业务价值，再考虑到用户故事的针对性，独立性从而把一个完整的业务价值“装进去”，最终形成一个合适的用户故事。