下载文档原格式
什么是用户故事（UserStory）和验收标准（AcceptanceCriteria）一个非常完美的基于现实场景的用户故事验收标准指南：在软件开发行业中，“需求”一词决定了我们的目标是什么，客户真正的需求是什么，以及是什么可以使公司业务快速增长。
无论是作为开发软件产品的产品型公司还是以提供各种领域服务为主的服务型公司，最基本的、最主要的是需求，对于成功的定义就是如何更好满足需求。
在不同的项目方法论中，“需求”一词都有不同的名字。
在瀑布模式，它指的是“需求和spec文档”，在敏捷、SCRUM 中它被定义为“Epic”,'用户故事'。
在瀑布模式下，需求文档是很多的，在一个产品阶段都有200页甚至更多。
但是敏捷是不同的，因为需求都是小的功能或者模块（feature）的，产品都是循序渐进一步一步的方式去准备的（sprint）。
在这边文章中，我将以一种相对简单且容易理解的方式分享有关用户故事和他们验收标准的一些经验。
那么什么是用户故事呢？一个用户故事就是一个功能或者feature的需求（requirement），被写出了也就一两行字，最多5行。
一个用户故事通常是最简单的可能性需求，有且只能是一个功能或feature。
最常见使用的标准格式的用户故事如下：作为一个用户/客户角色，我想要达到的目标是什么，以及达到目标的原因e.g:作为社交工具微信的用户，我想要在聊天对话框中有一个拍照图标去自拍和发照片，那么我就可以和朋友一起相互发照片。
什么是验收标准？验收标准就是一系列可以接受的条件或者业务规则，且与功能或feature相互匹配和满足，同时也能被产品负责人和相关人接受。
这是用户故事完成很重要的一部分，它需要被产品负责人和业务分析人员认真的学习，因为错失一个很小的标准都会损失惨重。
这是简单的编号或者编号列表。
格式如下：在我做某些动作（action）之前请赐给一些先决条件，然后期望结果发生。
举个栗子：1. 假设我正在和朋友聊天，我应该能够拍照2. 当我点击照片时，我应该可以在照片上添加一些文字，然后发给朋友3. 如果我的手机照相机有问题，一条错误信息，如“摄像头无法打开”...，相应的也应该出现因此，用户故事为任何功能或feature定义了需求，另一方面，验收标准为用户故事或需求定义了“完成标准的定义”。
如何写好用户故事一、格式规范-什么是用户故事？用户故事=用户+故事=人+故+事。
那就是一个人因为什么原因要做什么事，提炼出来三要素就是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中用户故事（最新版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）摘要:一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。
这样的过程就叫“用户案例(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应用程序能够提供个性化的推荐功能，根据他的偏好和兴趣推荐适合他的景点，以便更好地享受他的旅行。
用户故事的编写用户故事是敏捷开发方法中用于描述软件产品功能需求的一种方法。
用户故事通常以用户的视角来描述，用简短的语句概括了用户的需求及其背后的价值。
下面我将通过一个例子来说明如何编写用户故事，并介绍用户故事的一些常用模板和技巧。
假设我们正在开发一个在线购物平台，用户可以在平台上浏览商品、下订单、进行支付等操作。
我们将通过四个用户故事来描述这个平台的功能需求。
用户故事1：浏览商品作为一个买家，我希望能够在购物平台上轻松浏览各类商品，以便我能够了解市场上的热门商品和最新上架的商品。
用户故事2：搜索商品作为一个买家，我希望能够通过关键字搜索特定的商品，以便我能够快速找到我需要的商品。
用户故事3：下订单作为一个买家，我希望能够将心仪的商品添加到购物车或直接购买，并填写收货地址和其他相关信息，以便我能够下订单购买商品。
用户故事4：进行支付作为一个买家，我希望能够选择我喜欢的支付方式，并完成支付流程，以便我能够购买商品并等待收货。
以上四个用户故事分别描述了用户的需求和期望，可以作为产品开发的基础。
此外，用户故事通常还会包括一些附加条件和验收标准，以便更好地理解用户的需求。
下面是一个用户故事的通用模板：作为<一个角色>，我希望<实现的目标>，以便<获得的价值>。
在上面的用户故事中，角色就是用户的身份，目标是用户希望实现的需求，价值是用户从实现这个需求中获得的好处。
通过这个模板，我们可以更清晰地描述用户的需求。
用户故事还可以使用更详细的模板，以提供更多关于用户需求的信息。
下面是一个常用的详细模板：作为<一个角色>，我希望<实现的目标>，以便<获得的价值>。
作为一个<一个角色>，当我<某个条件>时，我希望<实现的目标>，以便<获得的价值>。
详细模板中的条件可以用来描述用户需求的特定情境。
通过使用这个模板，我们可以更具体地描述用户的需求，并更准确地理解用户的期望。
用户故事描述用户故事，听起来好像是个很神秘的东西，其实啊，就是把用户那些事儿给讲出来。
这就好比咱村里的老人们坐在大树下唠嗑，讲自己家孩子的那些事儿一样。
就说有这么个事儿。
有个小年轻，我们叫他小李吧。
小李是个特别爱网购的人。
每天一有空就刷各种购物网站。
有一回啊，他想买双运动鞋。
他打开那个购物APP，就像打开了一个装满宝藏的箱子一样兴奋。
他在搜索栏里输入“运动鞋”，好家伙，一下子出来了好多好多的鞋子。
图片看着都特别好看，就跟一个个小妖精似的在勾引他。
他看中了一双看着特别酷炫的鞋子，那图片上的鞋子闪闪发光，鞋带的设计也很独特。
他就赶紧点进去看详情。
这时候问题就来了。
详情页里的尺码表写得特别复杂，什么欧码、美码、中国码的，他看得是一头雾水。
就像进了一个迷宫，找不到出口。
他想找个客服问问吧，找了半天那个客服入口，好不容易找到了，点进去等了老半天也没人回复。
这可把小李急得啊，就像热锅上的蚂蚁。
这就是一个用户故事，从小李的角度看，他只是想开开心心地买双鞋，可这个过程中遇到了这么多让他头疼的事儿。
再讲一个故事。
王大妈，她年纪大了，不太会用智能手机。
但是她儿子在外地，为了能和儿子视频聊天，就硬着头皮学。
她儿子给她下了个聊天软件。
王大妈一开始连怎么打开这个软件都不知道。
她在手机屏幕上点啊点，就像在黑暗里摸索一样。
好不容易打开了，看到那个注册登录页面，又是要填手机号，又是要设密码的。
王大妈的眼睛本来就不太好，看那些小字看得眼睛都花了。
她就很无奈，心里想这东西咋这么复杂呢。
这也是一个用户故事，王大妈代表了很多不太熟悉新科技产品的老年人。
他们在使用这些产品的时候会遇到很多在我们年轻人看来很简单，但对他们来说却像大山一样难以跨越的障碍。
还有小张，他是个上班族。
他每天都要坐地铁上下班。
他经常会用手机上的一个乘车码软件。
有一天啊，他的手机突然死机了。
他当时站在地铁闸机口，后面排着长长的队伍。
他特别着急，想重新打开那个软件，可手机就是不听话。
一、写在前面其实我一直在考虑一个问题，就是敏捷执行一段时间后，如何能保证不偏离当初设定好的目标？有人说，我们就没目标。
是，可能刚开始做产品并没有一个非常清晰的目标，比如我要做个共享单车，比如我要做个共享女友。
但是总会有个愿景或者是想要解决的问题：我想要解决从家到地铁的500米距离的问题，我想要结束单身狗的命运……而且在评估一个需求或者用户故事是否重要的时候，也很纠结。
连产品经理或者需求负责人都有这种感受的话，就更别说其他干系人了。
这种只见树木，不见森林的方法，想想可能引发的后果，就有点“不寒而栗”。
最近很巧的，看了三本书，介绍了三种方法，从三个不同的角度，都是为了解决同样的这个问题：“只见树木，不见森林”。
那我这边会结合我的理解来和大家分别说一下这三种方法。
这篇先谈谈第一种。
二、用户故事地图敏捷里面有个很重要的概念叫做“用户故事”。
用户故事，是从用户的角度来描述自己渴望得到的特性以及带来的价值。
现在流行的模板是：英文：As a, I want to, so that.中文：作为一个<角色>, 我想要<活动>, 以便于<商业价值>。
（关于用户故事应该怎么写，这又是一个很大的命题了，如果感兴趣我们可以另外开一系列的文来写。
）我们今天想要讨论的是，如果在你们的开发流程中已经使用了用户故事，怎样做才能“又见树木，又见森林”呢？用户故事地图，顾名思义就是使用用户故事组成一个地图。
1、地图的作用是什么呢？地图一般的作用有两个：寻找路径，了解全貌。
寻找路径我们一般想要去一个地方，现在都会使用电子地图，输入起点和终点，APP会自动帮你规划出路径。
这个应该是我们比较常用的功能了。
了解全貌上学那会儿，地理课老师用世界地图也好，中国地图也好，来给我们讲解几大洲几大洋，地质情况等等。
我们在知道了地球是圆的基础上，还知道了中国就是雄鸡，意大利是靴子…这就是了解全貌。
我之前刚工作的时候做的就是GIS（地理信息系统），所以对于上海市（区县合并以前）的各个区的方位以及轮廓铭记于心。
用户故事的优先级划分与管理用户故事是敏捷开发中的重要工具，它是一种描述用户需求的简短故事，强调用户的视角与价值。
在项目开发过程中，为了更好地管理和组织用户故事，我们需要对其进行优先级划分与管理。
本文将介绍用户故事的概念与特点，讨论用户故事的优先级划分原则，并提供一些用户故事管理的实践方法。
一、用户故事的概念与特点用户故事是敏捷开发方法中以用户为中心的需求描述方式。
它主要由三个要素构成：角色、目标和收益。
角色代表故事中的用户或利益相关者，目标描述了用户希望实现的目标，而收益则是用户在实现目标后所获得的价值。
用户故事通常以简单的语句或表述形式呈现，以便于理解与讨论。
用户故事的特点如下：1. 简短：用户故事应该尽可能简短，一般不超过两三句话。
2. 可理解：用户故事应该以用户的语言描述，避免使用专业术语，以便于团队成员理解。
3. 可估算：用户故事应该具备可估算性，即在时间和成本上能够进行合理的评估。
4. 可独立：用户故事应该具备独立性，能够独立地进行开发和测试。
5. 可验收：用户故事应该能够进行验收测试，以确保用户需求的满足程度。
二、用户故事的优先级划分原则在开发过程中，为了更好地管理用户故事，我们需要对其进行优先级划分。
以下是一些常用的用户故事优先级划分原则：1. 业务价值：根据用户故事的业务价值，将其划分为高、中、低三个优先级。
高优先级的用户故事应该具备明显的业务价值，能够为用户带来重要的收益或优势。
2. 风险与依赖：根据用户故事的风险和依赖关系，将其划分为紧急、重要和普通三个优先级。
紧急优先级的用户故事可能存在较高的风险或严重的依赖关系，需要优先处理。
3. 用户满意度：根据用户的需求与满意度，将用户故事划分为关键、重要和可选三个优先级。
关键优先级的用户故事对用户的满意度有重要影响，应该优先考虑。
4. 时间与成本：根据用户故事的时间与成本要求，将其划分为紧急、一般和可推迟三个优先级。
紧急优先级的用户故事具有较高的时间与成本压力，需要尽快解决。
注脚：我的同事兼朋友Jeff Patton即将出版一本关于用户故事和故事图谱的新书。
我被邀请为该书好的团队从他们的KPI记录中寻找灵感、从观察用户的不爽中寻找灵感、从用户使用产品的记录数据中寻找灵感、从持续尝试挖掘新技术来解决产品问题的过程中获取灵感……不好的团队从销售团队和用户那里直接搜集需求。
好的团队了解每一位重要股东是谁，他们还清楚这些股东给他们的商业束缚是什么，他们致力于找到那些不仅对用户有用的方法，而且这些方法还能跟商业束缚相协调。
不好的团队则从股东那里获取需求。
好的团队一般精通很多技术，他们能快速验证产品想法，并找到值得深耕的那一个。
不好的团队老是开会商讨产品路标的优先级。
好的团队喜欢跟公司里任何部门的聪明Leader进行头脑风暴。
不好的团队在听到外部人员建议时会觉得不爽。
好的团队里，产品、设计、开发总是坐得很近，他们一起在功能、用户体验和技术可行性上协商取舍。
不好的团队他们自顾自，不停地要求其他人给出规范文档或者安排会议。
好的团队会不断尝试新想法并想办法创新，但他们会考虑保护产品的营收和形象。
不好的团队还在等领导批准这个测试。
好的团队强调要有齐备的技能组合，这样他们才能打造优秀的产品，比如交互设计。
不好的团队连交互设计师是干啥的都不知道。
好的团队每天都会给攻城狮时间去使用新版本，这样攻城狮也能为产品的打磨贡献思想。
不好的团队在敏捷开发计划时把原型扔给开发团队，让他们估计成本。
好的团队每周都会与用户（使用产品的人）和客户（付钱的人）沟通，以便能更好理解他们，并获取他们对产品新功能的看法。
不好的团队认为自己就是用户。
好的团队知道很多自己喜欢的想法最终对用户无用，即便有些想法已经迭代了多次并有些效果。
不好的团队按路标规划开发产品，并满足于按时按质交付产品。
好的团队明白执行速度和快速迭代对于产品创新的重要性，同时也明白速度源自正确的技术而不是强制加班。
不好的团队总是抱怨同伴不够努力导致进度延后。
用户故事(三):用户故事该范文用户故事模板原标题：用户故事（三）：用户故事该范文？实际的开发过程中，我们运用如禅道、TAPD等团队协作软建立管理用户故事，对于故事我们就可以进行更加丰富的记录。
一个完整的用户故事需要写的内容包含：展现形式如下：一、故事标题用户故事的描述在列表中进行管理时，不利于快速理解，也不能一行展示。
为每个故事取个标题（名字）就很有必要，而且像禅道、TAPD软的需求表述格式中标题也是必填项。
就行邮的主题，用户故事的标题是为了让读者能快速了解这个用户故事的要点和大致范围；范文好标题也是有章可循的。
常见的做法有：1.用户角度的动宾短语如：创建商品、输入名称、修改头像等等这是动作+对象形式，擅长描述从用户看到的活动或功能。
2.系统角度的动宾短语此处的系统是指待开发的对象。
如，toast提示网络异常，记录用户访问次数，显示搜索结果，显示倒计时。
擅长描述系统要执行的反馈和操作。
3.主谓宾短语有时动宾短语不能推断主语时使用主谓宾短句，或者可能有可能混淆时需要明确主语，此时就需要增加动作主语，如，超级管理员重置普通管理员的口令；A系统推送批量客户和合同信息。
随着时间推移，新增的用户故事有不少是基于原有的功能来再提升修改，这时往往要在标题里加上状语来区分，比如根据客户所在城市来查询客户列表，在客户没有登记电话号码时强制客户登记号码。
状语要清晰得说明用户故事所处的情况，能够区分类似的用户故事。
4.差劲标题举例（1）外访业务处理点评：处理是万金油词语，没有突出重点。
（2）设计资产逾期流入流出报表点评：主语既不是用户，也不是待开发的系统，而是开发人员，这更像是一个任务的标题。
（3）角色分配资源点评：要做什么呢？不能快速理解故事核心。
二、故事描述固定格式“作为……（用户角色），我想要……（完成活动），以便于……（实现价值）”的格式。
故事描述一这种三段式表述，相比较于传统需求表述，体现了需求方和需求价值的重要性，也为保证了需求描述的可协商性。
用户故事地图（3）：故事与卡片“用户故事”在交互设计中，常常用于分析用户遇到的问题、所在的场景，帮助设计师增强对用户的同理心，将焦点收敛于问题本身。
在用户故事地图中，“用户故事”的内含和使用方法是否相同？它是体现于哪种形式，从而被团队更好的使用？它需要如何被组织，从而形成“地图”？这一篇文章，将会解决以上问题——开始认识“用户故事”。
一、用户故事是指用户来描述用户渴望获得的功能，是具有一定价值的端到端交付。
它包括三个部分：角色、用户需求、产品价值。
我们常常使用一句话来描述用户故事，某<角色>，通过完成<用户需求>，实现<产品价值>。
“用户故事”源于1996年Kent Beck提出的极限编方法（《Agile Development》，中译名《敏捷开发的艺术》）。
在2004年，敏捷大师Mile Cohn在《User Stories Applied For Agile Software Development》(中译名：《用户故事与敏捷方法》)一书中，正式定义“用户故事”这一概念，并提出著名的“INVEST”特点。
而本系列文章，则是来自于2014年出版的的又一著作《用户故事地图》。
今天，无论是Scrum还是看板，用户故事都作为需求的基本形态被广泛运用。
传统需求中，只描述具体要做的内容，如果遇到想得多的产品人员，还会直接罗列出详细方案。
这对于项目团队（不同知识结构、不同思维方式）而言，在短期内搞清楚要做什么是很困难的。
用户故事除了需求内容外，还加入了“谁”、“为什么”，这样便于成员在同一频道内对话——大家都从用户角度沟通，利于对内容达成共识。
值得一提的是，用户故事还是敏捷开发的前提和基础。
我曾遇到过的项目，将长周期切分为短周期，以此来加快进度，但这并不是敏捷。
压力最终还是落在团队上，而每个阶段没有成型的交付物，也无法阶段性查验方案的适用性，最终最还是全部上线后验证效果。
