如何梳理用户需求？试试这个超好用的「用户故事地图」

文从「用户故」的概念、准则、创建用户故事地图到立用户故事卡法不，帮你完掌握「用户故事」这个知识。

概念

1. 么是户故事？

• 迭发的一种具；
• 代表了可开发的一个工作；
• 帮助我们跟踪一个功的生命周期。

2. 什么用户故事图？

• 个有风图表；
• 横轴为时间，放置延时间的用户故；
• 纵轴优先级，自下；
• 覆盖所有用户故事，表达需求全景。

3. 为什么使用用户故？

从设计赋能角度来讲，用户故地图以帮助设计师从产品计划面，提升产品用户体验，避免沉入细节；找到落地品思维法，即平衡用户价值、品价值、开发成本三者关系；关注项目和品，设计出落地、有效品案，避免理想化。

从项目管理角度，用户故地图以决以下问题：

• 见树不见森林，要内容埋没在细节，难以排列优先级；
• 无法看到版贡献功能的完整价值流；
• 无法方便的使用迭方法踪、优化内，确版本划目标。

从团协角度，用户故以降低沟通与达成共识的成，将关注力更集中在产品上。

4. 用户故简述

• 作为一个（角色）：谁要使这个功。
• 为想要（功能）：需要完成什么样功能。
• 以便（价值）：为什么需要个功能，带来什么样的价值（用户价值和组织价值）。

准则

构建户故事地图需要：时间线、户、户任务、户故事、故事地图结构。于实现目标的户功 >  > 任务 > 史诗 > 故事。

• 将用户要素从左向右拖动地图的顶行。地图顶行中的每个功能都是呼叫用户活动。
• 创建成需的许多步骤，称为户任务。
• 这些用户任务个都可以分解为多个史诗。
• 在史诗下，以定义用户故列表，其大小适合放 sprint。

1. 用户故事的3C则

3C 则是由 Ron Jeffries 提出的，它包括三个部：

• Card 卡片，用简描述软件特性或改点；
• 描述的内容简洁、词含义统一，项目成员不会对同一内容有差异性理解；
• 这些卡片于后续的沟通、对需求容的组织和列优先级。

Conversation 交谈 ， Product Owner（或户）交谈来确细节。

• 卡片的内由团队沟通中获得，非由同一人输出或新的，不然它与传统的需求分析方法无异；
• 项目成员需要一起就卡片内容进行讨论。在复杂逻辑中，梳理出清晰的需求脉络，并在这一过程中，达共识和理解的统一。

Confirmation 确认，每故事应具验收标准（验收条件），能够确认被确完。

• 以始为终，先行确认以怎样的结果，来判断开任务的完成；
• 它保证每故事都独立的、完整的逻辑，可以单独交付；
• 它为驱动测驱动开发、行为驱动开发和持续集成提供可能。

2. 用户故原则

• I 独立的（Idependent）：独立且整，依赖于他任何户故事；
• N 可谈判（Negotiable）：引导团队跟干系话和谈判介质。在任何时候，用户故事都可以被改写甚至丢弃。个用户故事不会像石头样固定不变，到它将要在接下来 Sprint 里被实现；
• V 有价值的（Valuable）：需要将价值给干系人，不论是最终用户还是采购者；
• E 可估算的（Estimable）：团队需能够粗略估算出完用户故事所需作规模；
• S 规模的（Small）：以一个大的「占位符」开始其生命周期。随着间的推移，当人对用户故事所表达的愿望的复杂度更加了解，这个较大的「占位符」就将被拆成的用户故事。当最重要的那些用户故事将进入 Sprint 被实现并交付，它需要变得足够，这才能在一个 Sprint 被完成。
• T 可测试的（Testable)）：一个户故事必须供必要的信息，清楚地界定了故事的验收标准，这样才在它成时判断是否验收。

创建用户故事地图

用户故地图是一个用需求收集的 4 级次结构。故地图从不同来源（即积压）收集的用户特征集合开始，用户特征将通执行某任务为活动来现。任务以转换为史诗，转换为软件开的用户故。

1. 品定义

般是在故事编写工作坊准备阶段，首先由 PD 主导出，主要有几内容：

• 产的目标户
• 解决了哪些问题
• 用户目标
• 产品目标

2. 梳理骨干故事

写出不颗粒度故事，需要设计师把控故事大小，这段故事可以再往下梳理层颗粒度更小故事。这样骨干故事有两层，级故事和级故事，故事发生从左至右是个叙事流。

3. 拆分故事

在刚刚梳理个级故事下做留，去拆分级故事获取更多细节内容。项目组会围绕这个故事写出很多细节来。按照以下几个维度细节进归类，分是：故事细节、想法、痛、会、情绪。其情绪可以过固定问题获，也可以过用户想法、用户痛结合主观判断。

4. 沟确认

这里我们故事已经变很丰满，甚至变臃肿，所以沟确认变极为要。我们在这步需要花费相多时，大家内容进标、充足讨论，把公认留下来，用剔除掉。时可以区分要做故事细节优先级。

建立用户故事卡

卡与迭代的系：

• 卡是迭代开发的一个工；
• 卡代表了一个可的工作单位；
• 帮助我们跟踪个功能生命期。

管卡片：

• 估计工
• 分配工作
• 追踪进度

如何使？

• 书写故事卡；
• 将卡放在墙（物墙/数字墙）；
• 领卡需要与 QA/BA 澄需求（不能有两张正在做卡）；
• 故卡完成需要做 Desck Check（block里的卡要尽快消灭）。

产品迭代

IPM：Iteration Plan Meeting，迭代计划会议主要是跟户保持沟通息更新的会议。

• 下一迭的 Story；
• 对下一个迭代的期望；
• 团队的人员可性；
• 风险评估结。

敏捷宣言里面有一条：客户协作优于合同谈判。在 Scrum 团队中有一个角色叫做产负责人，他的核心职责是确保务需求的清晰和透明，保证开发团队对务有足够的了解，并将这些待成的务需求（Story）按照优先级列来，按照任务卡的方式来驱团队的开发。

IPM 主要出是下个迭代完成 Story，这些 Story 即为下个 Story 要完成目标，过敏捷看板工具来管理它们。

Sprint：业务流，Sprint1，Sprint2，Sprint3-N，已付的故。业务流就是史诗故，每个史诗故一个泳道。Sprint1，Sprint2，Sprint3-N 里面是不同史诗故拆分出来的用户故，并且根据优先级放到不同的 Sprint 里面，横向的泳道代表的是史诗故和史诗故拆分的子故的对应关系。

burn down chart：燃尽图，一sprint 内，人/时一比较固的。这时间框架充分安排发任务，每天行时间结算，绘制时间燃尽图。项目员通过燃尽图获知时间展，若项目燃尽所用时间与预时间契合，则需求时间预估安排合理，若不契合则需下一 sprint 行调整。

Retro（回顾）：即 retrospective 的简写，队针对目前状总结，目的为保持好的方面及加，做的欠佳的方面一起讨论改进措施，并尽力落实。在实践中摸索出适队的最佳实践，引导队和个人不断完善，追求卓越。

• 确认构建安全的环境；
• 建立项总结指标（well，less well，suggestion，action）前三项列出法，第四项针对前三总结；
• 一个点写在一张利贴，分栏贴上墙；
• 将类问题归纳起来，结出相应解决措施；
• Iteration 栏中的 sticker 指派并落。

注作者微信公众号：「Design Thinker」