在《敏捷开发中的「史诗」到底是什么？》这篇文章中我们详细解释了如何写好一个大型用户故事「史诗」的方法，这里我们从「写好“小 ”的用户故事」视角着手 ，更深入、准确的理解敏捷开发~
敏捷是一种基于产出价值的开发方法 ，「以客户为中心」要求其所有产品功能在得到客户需求 、认可后，优先开发。找出谁是用户，尤为重要 。一旦所有的用户被识别出来 ，为他们产出和增加价值的需求就会被记录下来 ，这样的需求被叫做「用户故事」 。层序分明。编写「用户故事」背后的逻辑与规则是什么？它们是如何被执行的？
二、规则写好「用户故事」，其结果影响自不必说。通常来说 ，便于开发者创建、跟踪和测试用户需求的格式应该是以下这种：作为<用户角色> ，我需要<某项功能>以便获得<一些好处>这里的用户指的是角色，如经理 、文员 、开发人员、图书管理员 、业主等等 。好处 ，指用户将获得的价值 ，如：经理只需单击一下即可查看审计报告，好处—节省他的时间；店员可以搜索报告 ，好处—节省时间；图书管理员可以按类别搜索书籍 ，好处—他可以彻底改善客户服务；业主可以订购设备，好处—省去很多麻烦 。这里有24个用户故事示例 ，它们描述出不同平台/系统下每个需求对标的用户价值：
作为管理员 ，我希望我能在需要时为团队创建新用户作为一名律师，我希望在主屏幕上看到我所有活跃的案件作为一名学生，我想在黑板上看到我的历史成绩和当前成绩的汇总作为司机 ，我希望我的GPS语音被激活作为一名研究人员 ，我想看到我所做的最近几次搜索作为用户，我希望能够恢复我的密码作为收银员 ，我希望看到收银机中显示的总金额作为一名飞行员 ，我想知道在当前条件下的优异飞行高度作为一名警察，我想看看由我开具的历史罚单作为一名邮递员 ，我想知道今天投递邮件的估计时间作为一名吉他手 ，我想知道我的手指在琴弦上的速度作为割草机，我希望它能避免将刀片撞到坚硬的东西作为一名跑步者 ，我希望心跳不规则时能被警告作为一个盲人 ，我希望在路上遇到障碍的时候能被提示作为信用卡用户，我希望当花费超过设定金额的时候会被提醒作为一个孩子 ，我想把不活跃的玩具店都关掉作为一名司机 ，我希望得到轮胎压力最大值时的报警作为一名学生，我希望每天早上都能提醒我的课程表作为一名经理，我想在计划时进行假设分析作为测试人员 ，我希望看到分配给我的所有错误状态作为机票预订者 ，我希望在飞机满载的名列前茅时间就能收到通知作为一名作家，我希望我的作品每隔几秒钟就能自动保存作为读者 ，我希望看到过去2周内最畅销的书籍列表作为一名厨师 ，我想看看访问量最大的食谱以上这种编写用户故事的方式能让大家更直观的看到彼此的工作效益，然后根据用户故事的大小 、需求内容、价值排序等预先排期 ，安排工作量。掌握清楚这些 ，团队小组才能顺利开展接下来的工作 。细心的小伙伴已经发现，用户故事在编写和传递信息的过程中遵循着 INVEST 原则 ，它经常出现在描述与用户故事特征有关的文章中 。INVEST 到底是什么？它背后又包含了哪些规则？
三 、解析 INVESTINVEST由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
