随着项目的进展，团队和客户会更多地了解系统，因此需求总会发生变化。期望项目团队计划静态需求列表，然后在几个月后交付功能软件，这是不现实的。用户故事映射是一种更好，更敏捷的方式来满足最终用户的需求。
用户故事地图可帮助您将用户故事排列成一个有用的模型，以便了解系统的功能，识别待办事项中的漏洞和遗漏，并有效地规划整体版本，通过版本为用户和业务提供价值。
通过Jeff Patton和其他人的努力，用户故事地图正在成为一种流行的用户故事管理技术。用户故事工具允许您通过用户活动，用户任务，史诗和用户故事的用户需求细分来为产品待办事项建立多个级别和维度。通常，敏捷开发团队在协作会议中使用故事地图来识别最终用户想要实现的期望结果。
Scrum团队的敏捷软件
需要灵活的软件解决方案来进行产品积压管理吗？Visual Paradigm支持强大的敏捷工具集，涵盖用户故事映射，亲和力估计，冲刺管理等。它功能强大但易于使用，直观且最重要的是AGILE。
为什么用户故事映射？
故事地图最初是由Jeff Patton在2005年推出的。故事地图背后的主要思想是，单一列表产品积压是组织和优先处理需要完成的工作的可怕方式。更丰富的结构是必要的。用户故事地图是一种功能强大的工具，可帮助敏捷团队培训产品待办事项并更有效地规划产品发布。
用户故事地图捕获客户对产品的旅程，包括他们在系统中执行的活动和任务。协作创建故事地图可确保团队成员从项目开始到新版本的持续开发都在同一页面上。
使用故事地图作为用户故事工具的好处很少：
- 使用概述和分级结构管理积压
- 通过协作方式进行头脑风暴，讨论并优先考虑用户需求
- 管理活动和任务（行走骨架），并将它们系统地划分为史诗或用户故事
- 用户活动和用户任务的安排和优先级排序，或向下钻取以将其细化为相关的史诗或用户故事
- 在线管理远程和协同定位环境中的用户故事，以使团队中的每个人都保持同一页面。
为什么你需要像Visual Paradigm这样的用户故事映射工具？
下面列出了在故事映射中需要像Visual Paradigm这样的用户故事映射工具的一些原因。
- 永远不要用完白板上的空间，
- 易于组织，更新和修改贴纸中的信息
- 通过在地图中拖放贴纸，轻松整理贴纸以确定贴纸的优先级
- 在线管理远程和协同定位环境中的用户故事，以使团队中的每个人都保持同一页面。
灵活的结构复杂或简单的项目
Visual Paradigm的故事地图支持需要收集的3级或4级层次结构，适用于复杂，中等或简单的项目。故事地图从不同来源（即用例，BPMN，WBS甚至思维导图）收集的用户特征集合开始，进入故事地图的积压，这些用户特征将实现为用户活动和相关的行走骨架（用户任务）。这些任务可以进一步细分为史诗，然后是软件开发的用户故事。
中型项目的3级故事地图
三层故事地图涉及三个隔间：活动>任务>故事（默认）
更复杂项目的4级故事地图
4级故事地图将Epics添加到3级地图中：活动>任务>史诗>故事（可配置为）
接收来自不同来源的用户需求
我们有很多方法可以识别用户需求。不同的人可能更喜欢不同的建模技术来捕获系统需求。事实上，我们不应该认为有一种主导技术可以满足不同问题或项目的所有目的。有时，我们可能会考虑用例图，但在另一种情况下，工作分解结构可能是更好的选择，或者可能是思维导图，而这一切都取决于。
为了促进敏捷开发，Visual Paradigm中的Story Map可以接收从不同来源识别的用户特征。如上所述，它可能是来自EA合同的要求，来自项目管理计划的工作包或特殊分析（例如 - 是和将来的分析），使用图中的用例与敏捷软件开发集成等等。
无缝集成故事评估功能
用户故事工具为团队提供Affinity Table，以自动化故事评估过程。此外，视觉亲和力表支持同时具有故事点和故事时间的实时估计。当您沿着桌子拖动故事时，故事点和小时将同时显示，而故事仍在四处移动。只需将故事放在网格中，您的团队就会发现估算是合适的。
可配置的用户故事地图与故事地图，scrum和sprint流程无缝集成，提供一站式解决方案。
自动亲和力表如何计算？
要了解如何在亲和力表中自动估计故事点和日期，我们需要了解水平网格代表工作努力，从左到右增加，以及故事发展的复杂性（如新技术，新域名等）从上到下增加。
因为开发用户故事的最大天数不应超过sprint的长度（如果不是用户故事要大，需要分解，或者sprint设置得太短，需要一个扩展），所以右下方网格的天数也应该等于短跑的长度。基于该假设，可以自动计算故事估计。
用户故事对估计的亲和力
用户故事的估计永远不会100％准确，事实上没有方法可以实现这一点。为了提高估算的准确性，我们首先确定冲刺长度（例如，两周或10个工作日），然后对我们在估算方面感觉最舒服的一些用户故事进行估算（例如，5天和确定性是中等的）。在这种情况下，您将把故事放在中间垂直（确定性或风险级别）和水平（工作量等于5天，或短跑长度的一半，即10天）。然后，您可以将其用作估计其他用户故事的参考点。问问自己这个用户故事是否需要比参考用户更多的努力，或更少，并且具有更多的不确定性或更少）。当您将更多用户故事放在Affinity Table上时，您可以在几个用户故事之间进行比较，以确定偏移是否合乎逻辑，然后将它们放在一起以使它们公平，就是这样。这个过程比工程学更具艺术性。这样做并在团队会议中讨论而不是任何对抗。随着团队变得更加成熟，准确性通常会得到提高。
进行穗调查
根据敏捷词典，Spike的定义是：
“这项任务旨在回答问题或收集信息，而不是生成可交付的产品。有时会生成一个用户故事，在开发团队完成一些实际工作来解决技术问题或设计问题之前，无法对其进行很好的估计。是为了创造一个“尖峰”，这是一些其目的是提供答案或解决方案的工作。“
在估算用户故事时，我们不仅要考虑开发工作，还要考虑所涉及的风险和不确定性。通常，在正式开始冲刺之前创建尖峰，以管理要执行的工作，以便公平地估计其他一些用户故事。
准备好敏捷？
想要一个能够很好地管理Scrum项目的敏捷工具吗？Visual Paradigm具有用户故事映射工具，Affinity Estimation工具，sprint管理工具和任务管理。