【精品报告】用户故事地图-JeffPatton
什么是用户故事（UserStory）和验收标准（AcceptanceCriteria）
什么是用户故事（UserStory）和验收标准（AcceptanceCriteria）一个非常完美的基于现实场景的用户故事验收标准指南：在软件开发行业中，“需求”一词决定了我们的目标是什么，客户真正的需求是什么，以及是什么可以使公司业务快速增长。
无论是作为开发软件产品的产品型公司还是以提供各种领域服务为主的服务型公司，最基本的、最主要的是需求，对于成功的定义就是如何更好满足需求。
在不同的项目方法论中，“需求”一词都有不同的名字。
在瀑布模式，它指的是“需求和spec文档”，在敏捷、SCRUM 中它被定义为“Epic”,'用户故事'。
在瀑布模式下，需求文档是很多的，在一个产品阶段都有200页甚至更多。
但是敏捷是不同的，因为需求都是小的功能或者模块（feature）的，产品都是循序渐进一步一步的方式去准备的（sprint）。
在这边文章中，我将以一种相对简单且容易理解的方式分享有关用户故事和他们验收标准的一些经验。
那么什么是用户故事呢？一个用户故事就是一个功能或者feature的需求（requirement），被写出了也就一两行字，最多5行。
一个用户故事通常是最简单的可能性需求，有且只能是一个功能或feature。
最常见使用的标准格式的用户故事如下：作为一个用户/客户角色，我想要达到的目标是什么，以及达到目标的原因e.g:作为社交工具微信的用户，我想要在聊天对话框中有一个拍照图标去自拍和发照片，那么我就可以和朋友一起相互发照片。
什么是验收标准？验收标准就是一系列可以接受的条件或者业务规则，且与功能或feature相互匹配和满足，同时也能被产品负责人和相关人接受。
这是用户故事完成很重要的一部分，它需要被产品负责人和业务分析人员认真的学习，因为错失一个很小的标准都会损失惨重。
这是简单的编号或者编号列表。
格式如下：在我做某些动作（action）之前请赐给一些先决条件，然后期望结果发生。
举个栗子：1. 假设我正在和朋友聊天，我应该能够拍照2. 当我点击照片时，我应该可以在照片上添加一些文字，然后发给朋友3. 如果我的手机照相机有问题，一条错误信息，如“摄像头无法打开”...，相应的也应该出现因此，用户故事为任何功能或feature定义了需求，另一方面，验收标准为用户故事或需求定义了“完成标准的定义”。
用户体验地图-客户旅程地图PPT模板
DEFINITION
Keywords
Touchpoint
The contact between a customer and a company representative, brand messaging, and/or product.
This interaction takes place at a specific time, in a specific context, and with the intention
of fulfilling a specific customer need.
Channel
The medium of interaction between customer and company, such as a website, print ad,
telephone call, mobile app and physical store.
70%
of app users place more value on the app’s functionality than its design.
75%
of consumers have already used comparison apps for
products or services.
The channel defines both the possibilities and limitations of a touchpoint.
DEFINITION
Customer Journey / Experience Map
Awareness
Interest
Deliberation
Evaluation
1.用户故事篇
如何写好用户故事一、格式规范-什么是用户故事？用户故事=用户+故事=人+故+事。
那就是一个人因为什么原因要做什么事，提炼出来三要素就是who、why、what。
角色（who）：谁要使用这个活动（what）：要完成什么活动价值（value）：为什么要这么做，这么做能带来什么价值举例：作为一个运维管理者，我需要平台能推送给我数据库的监控异常信息短信，为了能及时发现并处理数据库的异常情况。
二、要素完整-用户故事的3C原则卡片(Card)：写在一张卡片上，包含故事的简短描述，规则和验收标准。
我们可以在TAPD的需求应用中创建一条需求。
故事的描述即为标题，将规则和验收标准写在需求的详细描述里。
对话(Conversation)：和客户或产品经理不断的交流获取需求细节。
确认(Confirmation)：通过验收测试确认用户故事被正确完成。
三、定义原则-INVEST原则Idependent（独立的）：用户故事间保持独立性不仅便于排列和调整优先级，使得发布和迭代计划更容易制定，便于独立地理解、跟踪、实现、测试以及频繁交付，也使得用户故事的大小估算所涉及的范围更清晰，从而估算偏差更小。
问：故事间存在依赖时怎么办？答：合并或分解故事。
Negotiable（可讨论的）：用户故事不是具体的需求本身，是一个提醒关于客户或产品和开发之间关于需求的对话。
具体的细节在口头沟通或TAPD需求状态流转的评论中产生。
注：一些重要的细节最好在TAPD讨论流转中记录下来，方便回顾核对。
Valuable（有价值的）：用户故事是对用户或客户而言有价值的功能，应当尽可能避免变成对用户界面和技术方面的定义（这也是我们产品在当前项目编写用户故事中经常会犯的错误）。
这个特点促进团队的开发和测试成员由传统的指令式工作方式向自驱动的价值导向工作方式转变，使团队中的每个人知道自己每天做的工作价值。
问：用户界面和技术方面的定义该放在哪里？答：用户界面要求放在用户故事下的详细描述里，必要时可以附上产品原型和UI设计图显示和链接；技术方面的定义在Wiki里建一个技术规则页面进行管理。
应用型用户故事地图,让产品的头脑风暴事半功倍
颜色编码标签记号笔若干一面平整的墙一名会议主持人所需时间10-15人需要45-40分钟。
每多加10个人，就增加10分钟和一名主持人。
例如：10-15名与会者：1名主持人，50分钟15-25名与会者：2名主持人，60分钟第一步：讲故事整个头脑风暴的主干就是讲故事。
这个故事就是按时间顺序，列出针对假想用户所做的设计的步骤或行为。
例如，如果我们正在讨论为体育爱好者设计一款新闻阅读器，哪天有比赛，我们就会在哪天讲这个故事。
或者如果我们正在为经常打飞的的人设计一个新的高级服务，我们就会把故事从订票扩展到飞行本身的问题。
如何讲故事所有与会者人手准备一些黄色的便利贴和一支记号笔。
每个人7分钟，按时间顺序写出所有能想到的用户行业。
（每人10-25张便利贴即可）每个人行为的粒度不同，这没关系。
时间一到，大家都要把自己的便利贴按时间顺序和步骤贴在墙上，而且要按同一水平时间线贴。
可能很多人的步骤相似，可以把它们摞在一起贴。
第二步：将用户行为分组保持墙面整洁，现在开始在时间线上对行为进行分组。
如果你的故事要跨好几天，这对你很有帮助。
分组后，就能很快明白要关注故事中的哪些行为。
这步很简单，由主持人完成即可。
如何对用户行动分组主持人按时间线进行分组，如「早晨准备阶段」、「上班路上」、「工作」、「午餐」、「下班回家」、「晚餐」等等。
用橙色便利贴作为分组标签，并写上「早晨准备阶段」、「上班路上」等等，把它们贴在每个时间段的首部。
一般分四到五组即可，当然也可以根据自身的需要第三步：头脑风暴！有趣的来了。
与会者要尽可能多的想出每个时间点上相关的想法。
这个想法是对应时间线上的步骤的，如「起床」，并且产品是如何契合或影响用户此时此刻的行为。
比如一个新闻阅读器app应该长这样：每人只有15分钟发言时间，但足够了。
重要的是主持人要告知想法的数量重于质量，不管是可行的还是奇葩的。
一定要鼓励大家多说。
如何进行头脑风暴所有与会者准备一些蓝色便利贴和一支记号笔。
用户故事(一)：什么是用户故事？
用户故事（一）：什么是用户故事？用户故事在软件开发过程中被作为描述需求的一种表达形式；为了规范用户故事的表达，便于沟通；包含角色、活动、价值三个要素。
一、用户故事的概念概念这种东西我喜欢说文解字的方式去理解和阐述；用户故事=用户+故事=人+故+事，那就是一个人因为什么原因要做什么事，提炼出来三要素就是who、why、what。
从需求角度描述就是一个用来确认用户和用户需求的简短描述。
二、用户故事的三要素用户故事在软件开发过程中被作为描述需求的一种表达形式。
为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：作为一个用户角色 , 我想要完成活动 , 以便于实现价值。
一个完整的用户故事包含三个要素：角色（who）：谁要使用这个活动（what）：要完成什么活动价值（value）：为什么要这么做，这么做能带来什么价值三、3C原则用户故事的描述信息以传统的手写方式写在纸质卡片上，所以RonJeffries(2022)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。
（1）卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，规则和完成标准。
卡片的正面书写故事的描述，格式为：作为一个角色 , 我想要完成活动 , 以便于实现价值描述需求；卡片背面书写完成用户故事的规则和完成标准，格式为：Given…When…Then。
（2）交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通；确保各方对故事的理解正确。
（3）确认（Confirmation）：通过验收测试确认用户故事被正确完成。
四、INVEST原则好的用户故事除了格式规范，要素完整外，还应该遵循INVEST原则：Idependent（独立的）；Negotiable（可协商的）；Valuable（有价值的）；Estimatable（可评估）；Small（小的）；Testable（可测试的）。
pmp中用户故事
pmp中用户故事（最新版4篇）目录（篇1）1.用户故事的定义和重要性2.用户故事的基本要素3.如何编写用户故事4.PMP 中用户故事的应用正文（篇1）在项目管理中，用户故事是一种描述软件或产品功能的方法，它从用户的角度出发，以用户的需求为核心，详细描述了用户需要实现的功能。
用户故事的重要性在于，它可以帮助项目团队更好地理解用户需求，明确开发方向，以及评估开发进度。
用户故事的基本要素包括三个部分：用户、目标和行动。
其中，“用户”指的是使用产品的人；“目标”是指用户希望通过使用产品实现什么；“行动”则是指用户为了实现目标需要执行的操作。
这三个要素共同构成了一个完整的用户故事，它们可以帮助项目团队清晰地理解用户的需求，以便进行后续的开发工作。
编写用户故事时，需要注意以下几点：首先，用户故事应该简洁明了，易于理解；其次，用户故事应该具有可操作性，即团队可以根据用户故事进行开发；最后，用户故事应该具有可测试性，即团队可以根据用户故事进行测试，以确保产品的功能符合用户需求。
在 PMP（项目管理专业）中，用户故事被广泛应用于软件开发和产品设计。
通过编写用户故事，项目团队可以更好地理解用户需求，明确开发方向，以及评估开发进度。
目录（篇2）1.用户故事的定义和重要性2.用户故事的分类和要素3.如何编写用户故事4.PMP 中用户故事的应用和实践正文（篇2）用户故事（User Story）是一种在软件开发过程中用于描述用户需求和功能的简短描述。
它是敏捷开发方法中的一种重要工具，可以帮助团队更好地理解用户需求，明确开发目标，以及提高开发效率。
在 PMP（Project Management Professional）项目管理中，用户故事同样具有重要意义。
本文将详细介绍用户故事的定义、分类、要素和编写方法，并探讨其在 PMP 项目中的应用和实践。
首先，用户故事的定义是指以用户的视角来描述一个功能或需求。
它通常包含三个基本要素：一个主人公（Actors），一个目标（Goals）和一个可达到的结果（Results）。
敏捷：什么是用户故事（UserStory）
敏捷：什么是用户故事（UserStory）摘要:一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。
这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。
本文描述了敏捷开发的技巧：如何以用户故事管理项目.什么是用户故事(user story)假定这个项目的客户是个饮料自动售货机的制造商。
他们要求我们为他们的售货机开发一款软件。
我们可以找他们的市场经理了解这个软件的需求。
因此，我们的客户就是他们的市场经理。
谈需求的时候，有一回他这样说：“用户往售货机每塞一个硬币，售货机都要显示当前该客户已经投了多少钱。
当用户投的钱够买某一款饮料时，代表这款饮料的按钮的灯就会亮。
如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给他。
”上面的话描述的是一件事情，一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。
这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。
也就是说，上面我们的客户所说的话，就是在描述一个用户故事（user story）。
(我解释一下为什么用故事这个词，没兴趣也可以忽略。
在一个系统面前，每个用户要完成同样的目标，都要做这个系统设定的例行的事，这件事情不是一个例子，所以不叫事例，这也不是故事，也不能算一段历程，而是一个例行的事。
)如果我们想要记下这段用户故事，我们可能会用这样的格式：名称：卖饮料事件：1. 用户投入一些钱。
2. 售货机显示用户已经投了多少钱。
3. 如果投入的钱足够买某种饮料，这种饮料对应的按钮的灯就会亮。
4. 用户按了某个亮了的按钮。
5. 售货机卖出一罐饮料给他。
6. 售货机找零钱给他。
注意到，一个用户故事里面的事件可以这样描述：1. 用户做XX。
2. 系统做YY。
3. 用户做ZZ。
4. 系统做TT。
5. ...用户故事只是描述系统的外在行为一个用户故事只是以客户能够明白的方式，描述了一个系统的外在行为，它完全忽略了系统的内部动作。
优秀用户故事范例
优秀用户故事范例用户故事是敏捷开发中常用的一种需求表达技术，它能够帮助团队更好地理解用户需求，从而更好地开发产品。
优秀的用户故事能够清晰、简洁地表达用户需求，并且有助于激发团队的创造力和协作精神。
下面将为您制作一份关于优秀用户故事范例，希望能够帮助您更好地理解并应用用户故事。
# 一、用户故事简介假设我们正在开发一个名为“TripPlanner”的旅行规划应用程序，用户可以使用该应用程序规划自己的旅行路线、搜索景点、预订酒店等功能。
以下是一个关于TripPlanner的用户故事：## 用户故事名称：查找周边景点- **角色**：旅行者- **愿景**：作为一名旅行者，我希望能够在到达目的地后，通过TripPlanner应用程序方便地查找周边的景点，以便更好地规划我的行程。
# 二、用户故事详情通过上述简介，我们可以进一步分解用户故事，以便更好地理解用户的需求和期望。
以下是对用户故事的详细描述：## 用户场景小明是一名热爱旅行的大学生，他计划在寒假期间去某个南方城市旅行。
到达目的地后，他希望能够方便地查找周边的景点，以便更好地规划自己的行程。
此时，他打开TripPlanner应用程序，进入“周边景点”功能页面。
## 用户操作1. 小明在TripPlanner应用程序中选择“周边景点”功能，系统显示出周边的景点列表，并且提供了筛选和排序功能，使他可以更快地找到自己感兴趣的景点。
2. 小明可以在景点列表中查看每个景点的具体信息，包括名称、介绍、地址、营业时间等，以便更好地了解每个景点。
3. 小明可以通过地图功能查看每个景点的位置，以便更好地规划自己的行程路线。
## 用户期望小明期望TripPlanner应用程序能够提供全面、准确的周边景点信息，以便他更好地规划自己的旅行行程。
他希望能够方便快捷地查找到自己感兴趣的景点，并且能够在应用程序中获取到详细的景点信息和地图定位。
小明也希望TripPlanner应用程序能够提供个性化的推荐功能，根据他的偏好和兴趣推荐适合他的景点，以便更好地享受他的旅行。