敏捷开发，是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。在敏捷开发的众多产品中，经常被提到的用户故事地图
用户故事地图的作用
一般我们提到地图都会想到什么？大概是两种：一是寻找路径，二是了解全貌。
比如生活中，我们想去一个地方都会使用电子地图，输入起点和终点，APP会自动帮你规划出路径。以前使用纸质地图的时候，也是在地图上要起点和终点，然后自己谋划一下路径。这个应该是我们比较常用的功能。
而在我们上学的时候，一般地理老师都会拿出来世界地图或者中国地图，给我们讲解大洲、大洋、地质情况等等，我们在这些地图上了解了地球是圆的，中国的轮廓是一只雄鸡等等，这就是了解全貌。
在敏捷开发中，用户故事地图也是一样大到底，它存在的价值就在于，一个是找到整个产品的主干，也就是路径；再一个就是了解整个产品的全貌。
在这里石榴君想请大家记住，使用用户故事的目的并不是为了写出更好的用户故事，就像产品开发的目的也并不是开发出产品。停止你对故事模版的追求，就像停止你对完美文档的追求一样。
用户故事地图是一种建立共识的机制，之所以叫“用户故事”，因为故事是要讲的，就像文档只是为了备忘一样。
好的用户故事地图讨论的永远是为谁做和为什么做，而不仅仅是做什么。
什么是用户故事地图？
用户故事是需求的表达形式。表达形式这种词汇，通常代表着多样性。但是，用户故事是确定形式的表达形式。即「3W」来对需求进行描述。
3W，指的是 who、what、why。
who 代表【用户是谁？】，这是人；
what 代表【用户要做什么？要用什么功能？等】，这是事情；
why 代表代表【为什么用户产生这个需求？为什么要用这个功能？】，这是原因。
人 + 事 + 原因，就构成了对需求的简短而全面的描述。
如果要写出一个好的用户故事，需要满足 3C 原则。即，卡片(Card)、交谈(Conversation)和确认(Confirmation)。
Card卡片，用来简要描述软件特性或改进点。
描述的内容简洁、词汇含义统一，项目成员不会对同一内容有差异性理解；
这些卡片用于后续的沟通、对需求内容的组织和排列优先级；
Conversation 交谈 ，与Product Owner（或客户）交谈来明确细节。
卡片的内容是由团队在沟通中获得，而非由同一个人输出或更新的，不然它与传统的需求分析方法无异；
项目成员需要一起就卡片内容进行讨论。在复杂逻辑中，梳理出清晰的需求脉络，并在这一过程中，达到共识和理解的统一。
Confirmation 确认，每个故事应具有验收标准（验收条件），能够确认被正确完成。
以始为终，先行确认以怎样的结果，来判断开发任务的完成；
它保证每个故事都是独立的、完整的逻辑，可以单独交付；
它为驱动测试驱动开发、行为驱动开发和持续集成提供可能。
用户故事地图是一种组织和管理用户故事的方法。即以地图产品从开始到达成预期目的预设路线，将用户故事组织成地图。通过构建简单的故事地图，来使产品的使用过程中的用户体验图形化和可视化。从而提升团队的效率。
谁来描绘故事地图？
一般在做敏捷开发的团队中，是产品经理来写所有的故事和开展所有故事对话，但是对于产品经理来说，精力是有限的。所以做用户故事地图的一定是有一个核心团队互相协助完成的，
一般核心团队人数不超过4人，包括用户体验专家、设计专家和技术专家这些角色。
我们了解到了用户故事地图的作用，什么是用户故事地图，以及谁来描绘用户故事地图，那么接下来就看看如何创建用户故事地图。
如何创建用户故事地图
第一步：找到契机
首先，你要找到市场机会，尽快形成机会待办事项，尽可能与核心团队成员就每个机会展开对话。每个机会都要问我们自己几个问题：
对象是谁
我们要解决什么问题
我们的构思是什么
为什么要这么做
视觉上估算机会大小
这一步其实就是给产品定义，由产品经理主导产出，主要有几点内容：产品的目标用户。解决了哪些问题。用户目标。产品目标。
第二步：梳理骨干故事
写出不同颗粒度的故事，需要设计师把控故事的大小，这段故事可以再往下梳理一层颗粒度更小一点的故事。这样骨干故事就有两层，一级故事和二级故事，故事的发生从左至右是一个叙事流。
第三步：拆分故事
在刚刚梳理的每一个二级故事下面做停留，去拆分二级故事获取更多细节内容。项目组会围绕这个故事写出很多细节来。按照以下几个维度对细节进行归类，分别是：故事细节、想法、痛点、机会、情绪。其中情绪可以通过固定的问题获得，也可以通过用户想法、用户的痛点结合主观判断。
第四步：沟通确认
*关于建立用户故事卡
在这里重点提示一下，我们要明白建立用户故事卡的目的：
①卡与迭代的关系
②卡是迭代开发的一个工具
③卡代表了一个可以的工作单位
④帮助我们跟踪一个功能的生命周期
然后我们要对这个故事卡片进行管理：
①估计工时
②分配工作
③追踪进度
如何使用用户故事卡？
①书写故事卡；
②将卡放在墙内（物理墙/数字墙）
③领卡需要与QA/BA澄清需求(一人不能有两张正在做的卡)
故事卡完成后需要做Desck Check（block里的卡片要尽快消灭）
*关于产品迭代
IPM：Iteration Plan Meeting，迭代计划会议主要是跟客户保持沟通与信息更新的会议。目的是为了确认以下内容：
①下一个迭代的Story。
②对下一个迭代的期望。
③团队的人员可用性。
④风险的评估总结。
以上就是敏捷开发中的用户故事地图，你都get其中的知识点了吗？如果还有疑问可以致电石榴科技，欢迎交流！
石榴科技
石榴科技专注企业级服务十八年，致力于为客户提供和打造优秀的互联网产品，用科技的力量为企业的发展助力。通过产品+解决方案+用户体验+咨询+实施+技术研发的模式，满足客户的需求。客户名单包括海尔，海信，kidsland，松下，雷士，山东移动，皇明太阳能，青岛市政府等知名客户。
售前QQ：1427668977
售前微信：shiliukeji007
