- 综合排序
- 最热优先
- 最新优先
- 来自专栏硬核项目经理的专栏
【敏捷5.2】用户故事的层次和用户故事地图
用户故事的层次和用户故事地图 经过上一篇的学习，你对用户故事有了一个大概的了解了吗？ 一般我们会将用户的大概念设定为特性，然后通过对特性的分析来建立用户故事，之后在冲刺计划会议上，我们确定了这次冲刺的用户故事之后，就会由具体的开发人员将用户故事再次分解为任务。 因此，用户故事一般就是在中间层级。除了普通的用户故事之外，上篇文章中我们还提到过一个概念，那就是史诗。那么史诗故事应该在什么地方呢？ 用户故事地图 既然是地图，那很明显的就是一张非常大的用户故事板，把所有的待开发的用户故事罗列在上面。我们可以根据用户的重要性、优先级以及模块的切分等进行横纵向的排列。 用户的产品体验有时候仅靠想象是很难验证的，通过用户故事地图，就可以直观地展现这些信息，并且可以想象单独的用户故事是一堆散乱的枝叶，我们通过故事间的逻辑关系将这些树叶连接起来形成一颗完整的故事树。
1K21编辑于 2023-03-03 - 来自专栏敏捷开发
用户故事编写指南：写出最贴近用户实际场景的故事
用户故事在软件开发过程中被作为“描述需求”的一种表达形式，是定义用户想要什么的简单方法。通过它可以清楚地解释产品。一个好的用户故事能帮助利益相关者理解产品的功能，并且有助于向客户介绍产品是什么。 用户故事都会写，但如何写出最贴近用户实际场景的用户故事？ 1 ）用户故事基本表达式为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。 为一个用户编写故事当只为单个用户编写故事时，故事通常更容易被理解和阅读，故事也更加具体和清晰。但并不是所有的故事都会因为用户数量的变化而产生差异。 对于很多故事来说，无论是为一个用户还是多个用户编写，故事的内容并没有太大区别。但是，对于某些故事，用户数量的变化可能会对故事产生很大的差异。比如以“求职者可以从网站上删除简历”为例。
1.3K10编辑于 2024-02-26 - 来自专栏敏捷开发践行者联盟
（十三）什么是用户故事？
image.png 用户故事（user story）是个用来确定用户和用户需求的简短描述，用户故事是从用户的角度来描述用户苛求得到的功能。 需要注意：用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来表达。 用户故事的3C原则： 卡片（Card）--用户故事一般写在小的计记事卡片上。 它包括利益相关人（客户/用户）、产品负责人及开发团队之间进行更细化的讨论用户故事的可行性。用户故事经过会话确认后，才能正式进入开发阶段（用户故事实现）。 3.确认： 用户故事确认可以理解为对用户故事是否到达验收标准的检测。用户故事需要一系列的验收测试用以保证用户故事的完成及软件按照我们的预期运行。 通长筋我们可以通过组合用户故事和分解用户故事来减少依赖性。 可协调性（Negotiable）--一个用户故事的内容钥匙可以协商的，用户故事不是合同。
8.4K56发布于 2019-12-30 - 来自专栏从码农的全世界路过
如何讲好这个“用户故事”
用户故事(User Story) 用户故事(User Story)是指做某事为某用户带来什么价值. 它强调给用户带来的价值, 同时又能评估出为这件事需要做出的任务; 1.1 用户故事的描述方式 常见的用户故事(User Story)描述方式有以下三种: (1) 我是<角色>, 我希望<功能>, 这样< INVEST原则 用户故事在具体应用时也有写注意事项, 我们称之为INVEST原则. 1.2.1 Independent -- 独立性 用户故事之间是相互独立, 更不能一个故事依赖于其他的用户故事. , 可以和相关人员沟通, 协商丰富用户故事. 1.2.3 Valuable -- 有价值 用户故事对于最终的用户是有价值的, 因此应该站在用户的角度去描述每个功能和特性而不阶段性的任务. 1.2.4 Estimable 所以, 用户故事必须定义验收测试标准, 并且通过验收后才能认为用户故事开发完毕.
83011编辑于 2022-06-27 - 来自专栏敏捷开发
用户故事地图实际应用
那用户故事地图就是一种安排用户故事的方法，它将用户旅程的基本步骤安排在水平轴（行）上，将用户故事安排在相应的步骤（列）下面，在同一列中，用户故事的优先级由上至下依次降低。 当用户故事地图完成时，我们可以在单一的逻辑视图中看到用户与产品交互的所有方式，从第一次交互到完成总体用户目标。使用用户故事地图，可以通过更全局的视角了解用户故事如何融入整体用户体验。 那在这个时候，我们可以将这些主干用户故事放在用户故事地图的最上一层。 接下来，我们需要将这些用户故事进行更加细致的拆分：洗漱我们可以拆分为洗脸、刷牙、护肤等。 这些颗粒度更细的用户故事可以放在主干用户故事的下面一层。 第三步：做好用户故事的优先级排列 既然我们的主干用户故事和更细化的用户故事已经出来了，接下来就需要对这些拆分出来的用户故事进行优先级以及自上而下的排序，优先级最高的用户故事放在上面，并依次递减。
66510编辑于 2024-03-05 - 来自专栏UML
4步曲: 如何用故事点估计用户故事?
我们可以使用故事点！ 让我们通过Story Points了解估算过程的每一步。 第1步 - 确定基础故事 故事点是一个复杂的单元，包括三个要素：风险，复杂性和重复。 为了找到我们的基本故事，我们搜索一个与用户故事的完成定义的内部标准相对应的基本任务，并为其分配一个故事点。这将是我们的基础故事。 当使用Fibonacci序列号进行估算时，我们创建一个矩阵，其中包含每个序列号及其相关故事的行。然后，我们收集所有故事并开始将它们分成几行，将故事相互比较以及与其他已完成的故事进行比较。 请注意，我们的基本故事已经在第一行的此矩阵中，其值为一个故事点。 这是我们的一个矩阵： 第3步 - 筹划扑克 为每个故事分配故事点，我们召开一次会议，让所有参与该项目的专家聚在一起玩规划扑克。 我们的任务按实现它们所需的故事点数分成几行。最后，我们将每个积压项放在适当的行中。一排可以有几个故事。
3.3K41发布于 2019-01-11 - 来自专栏PM吃瓜(公众号)
什么是用户故事（User Story）?
什么是用户故事？ 用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素： 1. 角色：谁要使用这个功能。 2. 活动：需要完成什么样的功能。 3. 独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。 通常我们可以通过组合用户故事和分解用户故事来减少依赖性。 可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。 一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。 如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
2.7K11发布于 2020-08-02 - 来自专栏敏捷开发践行者联盟
（十四）用户故事地图如何使用？
image.png 用户故事是以用户能自我代入的方式，设计产品，用产品讲述用户的故事。 用户故事是一种思维，即故事思维，是运用故事的元素进行思考和设计，以求解决某种问题，达到特定效果的思维。在用户故事设计中，核心是要通过故事来传递信息，引起共鸣，解决问题。 不同的用户故事也容易出现互不相匹配的产品部分，所以，为了避免这种管中窥豹的错误出现，人们改进了用户故事的处理方法，这种新的方法就是“用户故事地图”。 下图以其中的一个用户类型为例，写出大故事： image.png 5.深挖细节 在完成第五步的“大故事”后，“用户故事地图”的框架已经结束，下面要做的事深挖细节。 正如“用户故事地图”的作者Jeff Patton所说：“如果不需要讨论，就不必绘制用户故事地图。”
1.8K22发布于 2019-12-30 - 来自专栏腾讯云 DNSPod 团队
用户故事：不再和你擦肩而过
今天这篇推送，是一个悲伤的故事。 在上周的公众号，我们推送了.club的活动：薅羊毛党速进 D妹又送福利了 发完推送，D妹就欢快的去迎接周末了。 今天，D妹突然收到了用户的反馈： D妹，你快看，我上周用8块钱薅了好多！ 今天再注册，都要2000了欸！ D妹定睛一看，这位朋友，你可太会了，其中甚至还有6688这样的精品数字！
53620发布于 2020-07-17 - 来自专栏硬核项目经理的专栏
【敏捷5.1】规划的核心：用户故事
但凡提敏捷，必须要问用户故事。之前我们学习过的 待办事项列表 ，迭代冲刺事项列表 之类的内容，记录的都是用户故事。在冲刺中，白板、任务板上贴的，都是用户故事。那么，真正的用户故事你知道怎么写么？ 用户故事格式 用户故事（User Story）是从用户的角度来描述用户渴望得到的功能。 但是，没有以下这六个特性的 用户故事 ，就绝对称不上是一个好的 用户故事 ，也有不少人会称这六个原则为 用户故事 的基本原则。 如果用户故事之间有依赖，那么被依赖的用户故事就有了天生的优先级。 一般的用户在知道用户故事并不是确定的文档待办事项，也不是合同约束条款的情况下，都会非常愿意去尝试自己编写用户故事的。
48720编辑于 2023-03-03 - 来自专栏DevOps时代的专栏
什么是用户故事和验收标准？
在这边文章中，我将以一种相对简单且容易理解的方式分享有关用户故事和他们验收标准的一些经验。 那么什么是用户故事呢？ 一个用户故事就是一个功能或者feature的需求（requirement），被写出了也就一两行字，最多5行。一个用户故事通常是最简单的可能性需求，有且只能是一个功能或feature。 深度挖掘的用户故事： 开始之前，让我们理解对一个基本的事情“深度”学习的重要性，比如用户故事 案例#1： 三年前，我当时在为一个手机app项目工作，这个app是一个快递系统的应用。 现在假如产品负责人给你这么个用户故事“作为一个用户，我想下载我的账单以至于我可以看到我某个特定时间段的所有的交易”。 发现用户故事和验收标准差异的重要性 在开发和测试开始之前的早期阶段，做一个深入的用户故事和验收标准的研究总是非常重要的。
3K11发布于 2020-02-11 - 来自专栏云云众生s
如何编写用户故事：初学者指南
虽然我最初使用的是更“传统”的流程，但我最终发现了敏捷和用户故事。 说实话，我第一次听说用户故事时，觉得它们太简单了。然而，一旦我尝试了它们，我就意识到它们带来了清晰度并减少了团队的困惑。 什么是用户故事？ 用户故事是一个简短的陈述，它告诉你谁需要什么，他们需要什么，以及为什么它有价值。你通常可以通过句子结构来识别它： “作为一名[用户类型]，我希望[行动]，以便[目标]。” 这句话突出了用户（经常购物的顾客）、行动（保存支付信息）和原因（更快结账）。它迫使你在追求设计或技术细节之前考虑用户的目标。 为什么用户故事如此有用？ 用户故事鼓励更以用户为中心的思维方式。 用户故事简化了计划 你可以将广泛的功能分解成更小的用户故事。此外，你可以根据哪些目标最重要来优先考虑这些故事。 例如，“作为管理员用户，当我正确输入用户名和密码并登录时，我将被重定向到管理员控制台。” 过于详细的故事 相反，如果你在一个故事中塞入过多的技术细节，你可能会忽略主要用户目标。
38310编辑于 2025-01-25 从用户故事构建智能医疗AI系统
本文揭示了将大语言模型投入生产的一个关键起点：用户故事。作者通过与两家医疗机构的合作，展示了构建实用AI系统的真实过程，强调了技术实现前深入了解用户需求的重要性。 用户访谈：直接采访终端客户。流程梳理：绘制现有工作流程图。核心目标是深入理解这些AI工具在实际世界中需要支持的真实流程。
8810编辑于 2026-02-18- 来自专栏敏捷开发
如何通过相对规模来估算用户故事？
敏捷团队会估算每个用户故事，并将其写在用户故事卡上。 用户故事是对客户所需功能的简短描述，用户故事卡是根据用户故事为敏捷团队显示某一交付单元的卡片。对于敏捷团队来说，他们要估算每一个故事的大小。 为了确保我们不会花费了大把时间做计划，结果因为不能适应这个计划转回到瀑布方式中，我们需要一种更直接的方法来评估用户故事。 如果团队刚开始做用户故事估算，一般会倾向于以小时为单位进行思考。 综合这三种因素考虑出的故事大小就是故事的规模。 其次，故事的大小是相对于团队其他用户故事来说的。 也就是说，我们可以通过多个用户故事的比较来确定哪个用户故事更大或更小，而不是在没有参考的情况下单独给故事规划大小。 在实际的项目中，我们可以运用做沙拉的思维，比如哪一个用户故事可以定位中等规模的用户故事，并以此设定一个标准的用户故事规模。同时将其他用户故事与该用户故事做比较，确定其他用户故事的规模。
70721编辑于 2022-05-20 - 来自专栏敏捷开发&项目管理
敏捷项目需求拆解&发现用户故事
（描述偏业务性） 第二步，我们需要找到名词所对应的动词，动词主语是用户或者是外部系统的一般可以转化成User Story，也就是用户故事。 敏捷术语和代码的对应关系 Business Epic -->库/包 Feature -->类 User Story -->方法 一、如何防止需求遗漏 找到了所有的名字之后我们可以拿出每一个Feature建立以下表来捕捉用户故事 第一行，参考上面第二步，列出所有的主语是用户或外部系统的名词 第一列，总是写上CIDED（增查查改删），第一个查为查询所有信息，理解为列表，第二个查为查询单个详细信息 然后在对应的格子中填写是否有相应的动词对个某个实体的某个特定的操作 上面的列表可产生自粗略的需求说明，用来捕捉遗漏的需求，也可用来将需求用这个表来过渡，然后用As...I want...so that...格式描述成用户故事。 用户故事变成Task这个一般技术人员都会，这里就不再赘述。
2.2K61发布于 2018-04-12 - 来自专栏全栈程序员必看
aic准则和bic准则_用户故事准则
但是，以下文字不仅作为基础，而且还是我们所有人涉及用户故事时的指南。 有很多关于用户故事的好书和帖子。 这篇文章绝不是该领域所有良好实践的总结。 以下是有关我们如何处理用户故事的一些准则。 捕获要求 创建用户故事的主要目的是了解需要做什么。 它们记录了应用程序需要提供的预期行为。 用户故事生命周期 用户故事始于这种行为的想法。 此行为还必须与实现后将添加到业务的某些价值相关联。 最初，用户故事只是一个想法，并且仅具有描述预期行为的标题，没有详细信息。 独立 ：用户故事应该是自包含的，其方式是不固有地依赖于另一个用户故事。 可以商量的：用户故事，直到它们成为迭代的一部分，都可以随时更改和重写。 V aluable：用户故事必须为最终用户创造价值。 èstimable：您必须始终能够估计用户故事的大小。
2K11编辑于 2022-08-31 - 来自专栏TestOps云层
测开之外的提升之路-用户故事篇
不知道大家有没有关注我们周一推送的文章—— 构建基于Python的持续交付-附书单推荐 记不记得芒果给大家推荐的测试人员提升之道的几本Python相关书籍： Python编程-从入门到实践 Ansible权威指南 第一本Docker书 Kubernetes权威指南
19220编辑于 2022-04-07 - 来自专栏敏捷开发
用户故事地图怎么用？实践才能出真知
那用户故事地图就是一种安排用户故事的方法，它将用户旅程的基本步骤安排在水平轴（行）上，将用户故事安排在相应的步骤（列）下面，在同一列中，用户故事的优先级由上至下依次降低。 当用户故事地图完成时，我们可以在单一的逻辑视图中看到用户与产品交互的所有方式，从第一次交互到完成总体用户目标。使用用户故事地图，可以通过更全局的视角了解用户故事如何融入整体用户体验。 那在这个时候，我们可以将这些主干用户故事放在用户故事地图的最上一层。接下来，我们需要将这些用户故事进行更加细致的拆分：洗漱我们可以拆分为洗脸、刷牙、护肤等。 这些颗粒度更细的用户故事可以放在主干用户故事的下面一层。 第三步：做好用户故事的优先级排列既然我们的主干用户故事和更细化的用户故事已经出来了，接下来就需要对这些拆分出来的用户故事进行优先级以及自上而下的排序，优先级最高的用户故事放在上面，并依次递减。
95531编辑于 2022-10-27 - 来自专栏TestOps云层
基于用户故事地图的测试用例设计
从普通的用户故事到用户故事地图再到用户故事地图迭代计划，处处体现出了敏捷下MVP最小可交付单元的迭代规划。而在这种模式下，尽早的介入迭代，进行需求的实例化及测试用例设计势在必行。 如何针对用户故事地图进行测试用例设计，如何确保价值流被快速的识别和验证呢？ 如果你还在这样写测试用例的话
61211编辑于 2022-04-07 - 来自专栏云前端
React 测试驱动开发：从用户故事到产品
在本文中，我们将采用 测试驱动开发（TDD：test-driven development） 方法，从用户故事到产品开发一个 React 应用。 一旦完成本教程，你将能够： 基于需求创建 epic 和 user stories（用户故事） 基于用户故事创建测试 使用 TDD 开发一个 React 应用 使用 Enzyme 和 Jest 测试 React 创建一个根据所提供的 props 实现不同渲染和功能的可复用 React 组件 使用 React PropTypes 实现组件 props 的类型检查 译注：epic（史诗）、user stories（用户故事 首先，我们可以基于项目需求创建如下的史诗和用户故事： 史诗用户故事验收准则作为一个用户，我需要使用计时器以管理时间作为一个用户，我要能启动计时器以开始倒计时。 用户故事及验收准则越细致，测试用例也将越精确，那将是大有裨益的。 总结 当使用 TDD 开发应用时，不仅将项目分解为史诗和用户故事，同时也要准备好验收准则，这是非常重要的。
3.8K30发布于 2020-08-10
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号