UML中的用户故事
用户故事
用户故事是与UML用例图是强相关的， 用户故事与UML两者均被用于敏捷软件开发上下文。 两种类型的图表被用于研究和编写用户需求， 他们标识了不同的用户组和他们的目标， 但是他们通常以不同的方式使用。
用例图
一个用力展示了所有的结束方式——用户与你的系统进行交互，可以通过所有的前置，后置条件， 异常，备选路径等。 这些图表可以被用来建立你的系统需求， 无论他是否是一个软件系统或者与其他团队或者个人进行互动。
UML用例图不用于调度或广泛的计划目的，因为它们是高度技术性和具体的，而是作为系统技术文档的基础。
用户故事或者故事地图
用户故事捕捉的是用户需要做什么和为什么这么做， 是站在用户的视角。使用自然语言是很简单的写出来的。
作为一个[扮演者] 我想要做[动作] 去完成 一个 [目标].
As an [actor] I want to do [action] to achieve a [goal].
例如：
- 作为制造商，我希望尽量减少刀具更换，以优化生产线，从而降低成本。
- 作为一名顾客，我想在网上订购食品(以避免去商店，可以享受我的饭菜)。
- 作为一个软件开发者， 我想要远程办公，节省路上的时间，写出更好的代码。
作为一个客户， 是不会对你的系统的技术实现细节感兴趣的，用户故事不是用来细化系统需求， 是为你留出时间和空间，用来研究备选解决方案（多个路径解决方案）为了能更好的满足客户的需求。
多个不同类型的团队发现用户故事映射是非常灵活和有用的计划工具可以保持持续的改进，保持开发完全聚焦在客户排优先级的需求上。
- 软件开发——确定编码任务的优先级和时间表。
- 市场——策划吸引客户的广告活动。
- HR——改进招聘和入职流程和系统。
- 工厂管理者——优化装配站或整条生产线。
- 产品设计者——计划对现有产品的增量改进。
- ITS——提高数据和网络的安全性和稳定性。
- ...
例如客户聚焦的故事在敏捷开发中非常流行，而用户故事（epics[史诗]），会被分解成更小的任务（故事）或者实现步骤。 这些可以让敏捷开发团队评估和计划开发项目。小一点的任务能够更容易的排优先级，和按照时间表分配到backlogs中或者一个冲刺中（短跑）。
传统上，故事映射是用某种网格布局的白板上的便利贴来完成的，当您在分布式团队中工作时，这并不真正有用。
在当今的远程世界， 你可以复制白板和故事映射到drawon.cn中， 在drawon.cn中，可以使用表格映射， 容器和泳道（例如这些用于交叉功能流程图）， 或者仅仅在看板上放置矩形来表示。
故事地图是一个活动， 客户想要去完成（某件事情），不应该包含更多的技术实现细节。 这个故事映射是以跨职能的方式进行构建。
如何构建一个故事地图
-
理解你的客户：标识他们的目标和他们想要实现目标的广泛活动。这些在你的地图中顶层，是大的故事——动作要领是有很多步骤。从高级图形库中找出一个名字为： 表格图像或者携带泳道跨职能流程图。
例如， 作为一个【客户】， 我想要【在网上订购食品】。
-
把这些活动分解成小一些的步骤： 客户必须完成这些小任务以实现他们的目标： 浏览商品， 添加商品到购物车， 选择配送货物地质， 进入支付细节，等等。也许可以或者不可以定义工作量，任务能够被分解成更小一些的子任务，如果他们太大的话。
-
按照序列组织任务和子任务： 将较小的任务和子任务按照从左到右的顺序排列在它们的活动下面（或者用你喜欢的方式来阅读图表）。这可以显示客户完成活动和任务的顺序。
- 排列任务和子任务的优先级： 通过垂直排列指示任务/子任务的优先级——更重要的任务位于故事地图的较高位置。
Tips
- 那些不需要按任何顺序执行的任务，或者那些具有同等优先级的任务，可以按照对你和你的团队最有意义的方式来组织。
- 不要把技术细节放在图表中——技术细节使用UML来描绘，或者其他更详细的图表。
这是一个想要在线订购食品的顾客的故事地图，使用了通用图形库中的简单图形。
贯穿整个开发过程中不断的跟新你的故事地图
你的故事地图可以作为一个可视化的路线图，显示你已经完成的工作，剩下的和计划的工作，以及超出范围的工作。
将未实现的任务和子任务分发到版本中， 故事地图中的迭代和冲刺， 注意由它们的左右位置或依赖关系箭头指示的依赖关系，以及由它们的垂直位置指示的优先级
通过将任务和子任务拖到新的位置，或泳道中的新位置来重新确定优先级。
在您的故事地图中跟踪开发，就像您使用它计划您的项目一样。当您完成每个任务的实现时，添加一个图形、工具提示、颜色或标签，以显示任务已经完成(或正在测试、记录等)。
用特定的颜色表示超出发布范围的任务，添加一个形状来表示计划的冲刺以及任务是否已经实现。
和你的客户一起贯穿整个故事地图
与他们一起浏览故事地图，检查活动细节并从客户那里获得见解。