本文主要是介绍软件工程 用户故事地图 是什么 怎么用 实例，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
用户故事地图是一种将用户故事可视化的方法
用户故事地图的方法主要用于解决敏捷需求分析过程中的问题：
- 用户需求难以排列优先级。
- 很难了解不同粒度故事（史诗故事、主题故事以及故事）之间的关系。
- 不能方便地了解系统提供的功能的完整性。
- 不能方便地了解系统提供的工作流。
- 不能方便地利用递增和迭代的方式去确定发布计划以及发布目标。
在精益中有MVP（Minimum Viable Product，最小化可用产品）的概念。MVP的目的是以最小的投入发布对用户有价值的产品，快速试错，并通过不停的迭代最终找到产品的正确方向。
这个思路很好，但如何确认backlog中的内容是“最小的”而且“可用”的产品却是件很困难的事情。
使用Story来描述需求的目的是为了协助团队进行讨论，以便最终确认需求（也就是Specification）。
用户故事地图的作用就是将User Story的简单描述：As a .... I want to ... so that ...，用可视化的方式展现在团队面前，让团队可以仔细梳理、讨论、确认这个Story包含的内容，最终产出Specification进行开发。
用户故事地图的结构
每个用户故事地图代表一个完整的用户故事：
- 地图的核心是一条从左到右的时间线。
- 时间线的上部放置最大粒度的内容（可以理解为Epic）。
- 时间线的下部的第一行放置二级粒度内容（可以理解为Backlog Item），并在每个一级粒度下按照从左到右的优先级进行放置。
- 每个二级粒度内容的下面，自上而下放置三级粒度内容（可以理解为Task）。
最终绘制出来一个完整的端到端的用户故事。
用户故事地图规范
- 蓝色便签表示用户任务（User Tasks）。
- 绿色便签表示用户行为（User Activies）。
- 黄色便签表示用户故事（User Stories），在每个用户任务下自上而下排列，便于我们确定优先级
一般来说用户会按照从左到右的顺序来使用你的系统（用户故事地图）。
用户故事地图样例
下图是一个蛋糕制作及心得分享系统的用户故事地图：
第三行所包含的内容就是“大家在电子邮件系统所要做的事情”，包括：注册、配置信息、发布、下单、支付等。
第二行对这些事情进行了分组。
与一般用户故事地图不同的是，这张图当中增加了第一行的角色划分，以使整个流程更加清晰明了。
黄色的便签的第一行包含了最小化的用户故事，如：“蛋糕小白”的注册只包括手机注册和验证码登录，其他如微信绑定则不在此行，放入更靠下的便签中。
现在如果我们专注于从左到右完成第一行的黄色便签，就可以确保很快发布一款包含了最基本功能的蛋糕制作及心得分享系统，这样就可以验证我们的系统整体架构可行。
同时也可以帮助我们对系统的功能进行端到端的测试，确保我们可以从用户处获取到反馈，知道我们是否解决了它们的问题（提供了商业价值）。
https://support.huaweicloud.com/reference-devcloud/devcloud_reference_020201.html
这篇关于软件工程 用户故事地图 是什么 怎么用 实例的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
