敏捷实践 | 好的用户故事怎么写？
在《敏捷开发中的「史诗」到底是什么？》这篇文章中我们详细解释了如何写好一个大型用户故事「史诗」的方法，本期文章，我们从「写好“小”的用户故事」视角着手，更深入、准确的理解敏捷开发~
开卷有益，我们先来聊一聊「用户故事」。
用户故事
敏捷是一种基于产出价值的开发方法，「以客户为中心」要求其所有产品功能在得到客户需求、认可后，优先开发。
找出谁是用户，尤为重要。一旦所有的用户被识别出来，为他们产出和增加价值的需求就会被记录下来，这样的需求被叫做「用户故事」。
层序分明。编写「用户故事」背后的逻辑与规则是什么？它们是如何被执行的？
规则
写好「用户故事」，其结果影响自不必说。通常来说，便于开发者创建、跟踪和测试用户需求的格式应该是以下这种：
作为<用户角色>，我需要<某项功能>以便获得<一些好处>
这里的用户指的是角色，如经理、文员、开发人员、图书管理员、业主等等。
好处，指用户将获得的价值，如：
经理只需单击一下即可查看审计报告，好处—节省他的时间；
店员可以搜索报告，好处—节省时间；
图书管理员可以按类别搜索书籍，好处—他可以彻底改善客户服务；
业主可以订购设备，好处—省去很多麻烦。
作为管理员，我希望我能在需要时为团队创建新用户
作为一名律师，我希望在主屏幕上看到我所有活跃的案件
作为一名学生，我想在黑板上看到我的历史成绩和当前成绩的汇总
作为司机，我希望我的GPS语音被激活
作为一名研究人员，我想看到我所做的最近几次搜索
作为用户，我希望能够恢复我的密码
作为收银员，我希望看到收银机中显示的总金额
作为一名飞行员，我想知道在当前条件下的最佳飞行高度
作为一名警察，我想看看由我开具的历史罚单
作为一名邮递员，我想知道今天投递邮件的估计时间
作为一名吉他手，我想知道我的手指在琴弦上的速度
作为割草机，我希望它能避免将刀片撞到坚硬的东西
作为一名跑步者，我希望心跳不规则时能被警告
作为一个盲人，我希望在路上遇到障碍的时候能被提示
作为信用卡用户，我希望当花费超过设定金额的时候会被提醒
作为一个孩子，我想把不活跃的玩具店都关掉
作为一名司机，我希望得到轮胎压力最大值时的报警
作为一名学生，我希望每天早上都能提醒我的课程表
作为一名经理，我想在计划时进行假设分析
作为测试人员，我希望看到分配给我的所有错误状态
作为机票预订者，我希望在飞机满载的第一时间就能收到通知
作为一名作家，我希望我的作品每隔几秒钟就能自动保存
作为读者，我希望看到过去2周内最畅销的书籍列表
作为一名厨师，我想看看访问量最大的食谱
以上这种编写用户故事的方式能让大家更直观的看到彼此的工作效益，然后根据用户故事的大小、需求内容、价值排序等预先排期，安排工作量。掌握清楚这些，团队小组才能顺利开展接下来的工作。
细心的小伙伴已经发现，用户故事在编写和传递信息的过程中遵循着 INVEST 原则，它经常出现在描述与用户故事特征有关的文章中。INVEST 到底是什么？它背后又包含了哪些规则？
解析 INVEST
INVEST 由6个英文单词的首字母拼在一起而成，它们分别是：
I–Independent–独立的：每一个用户故事都应尽可能独立以保证它们可单独开发和交付。
N–Negotiable–可协商的 ：应有可协商的空间，便于进一步讨论。
V–Valuable–有价值的 ：用户故事以为客户增加价值为结果导向。
E–Estimable–可估计的： 用户故事应可以被划分为不同大小的工作量。
S–Small–小的 ：不宜过大，每一个用户故事通常应该在40小时的工作内完成。
T–Testable–可测试的 ：必须要有可验收完成的标准来确保其可被测试和确认完成。
抽丝剥茧，用户故事传达了哪些信息？
信息传达
这是一张动画版的用户故事示例图，在图中它标注了以下几项信息：
故事的唯一标识-story number，表明其在产品需求文档中的位置
完整的需求描述-description，参照上面的撰写格式
预估故事点数-estimated story points，方便开发团队评估工作量和排列优先级
变化因素-exploration factor，描述了需求的不确定性程度，这个值可以是完整的、不完整的、动态的、稳定的等等
故事类型-story type
除了图中标注出来的信息，完整的用户故事文档还应包含责任人、执行人、截止日期、需求反馈等这些关键信息。每一个用户故事卡片写好后，就可以按照未开始、进行中、已完成等节点，展示在项目开发的进度看板上，以便让团队更好地完成协作。
如何写好一个用户故事相信大家都已经知道了，想要了解更多敏捷之道、项目管理等知识可以扫描下方二维码，获取最新资讯~
文章来源： Yodiz