Questions tagged «user-story»

用户故事是敏捷软件开发的核心概念之一。

15
为什么估算用户故事时我们使用故事点而不是工时？
在敏捷方法（例如SCRUM）中，用户故事所需的复杂性/工作量是在故事点中衡量的。故事点用于计算团队在一次迭代中可以获取多少个用户故事。 引入一个抽象概念（故事点）有什么好处，在这里我们可以使用一个具体的度量，例如估计的工时？我们还可以使用估计的工时来计算速度，估计迭代的覆盖范围等。 相反，故事点更难使用（因为概念很抽象），也很难向涉众解释。它提供什么优势？
8
错误修复任务的故事要点：它适合Scrum吗？
我只是想知道我们是否应该将故事点分配给错误修复任务。我们的问题跟踪软件JIRA没有Bug类型问题的故事点字段（仅适用于Story和Epic）。 我们是否应该将Bug问题类型添加到Story Points字段的适用问题类型中？优缺点都有什么？它适合Scrum吗？
50 agile  scrum  bug  user-story 
5
如何处理共享功能的故事
我有两个故事（我知道他们缺少福利部分） 作为信用管理用户，我可以查看Office的当前和以前的工资差异。 作为信用管理用户，我可以收到一封电子邮件，其中包含Office当前和以前的工资差异的PDF。 两者是相关的，因为它们将具有相同的查询/过滤条件。唯一的区别是，在“查看”故事中，结果显示给用户，在“电子邮件”故事中，结果被写入PDF，然后通过电子邮件发送给用户。 我正在努力将这两个故事的共同方面分开，或者我什至应该这样做。 例如，它们都将具有相同的查询，它们对结果的处理方式是不同的。 我是否应该将查询分为另一个纯技术的故事？ PDF的创建和电子邮件的发送应该脱机完成，这是否应该成为技术故事？ 我可以看到将这两个故事分解为2个功能故事和2个技术故事。 作为系统，我可以计算Office当前和以前的薪资差异。 作为信用管理用户，我可以查看Office当前和以前的薪资差异。 作为系统，我可以创建一个Office当前和以前薪资差异的PDF文档。 作为信用管理用户，我可以要求接收一封电子邮件，其中包含有关Office当前和以前薪资差异的PDF。 我一直回想的问题是，这四个故事不是独立的，也不是“切蛋糕”。 所以我不太确定如何处理这两个问题。
8
在Scrum中，是否应该将诸如开发环境设置和功能开发之类的任务作为子任务管理在实际用户故事中？
有时在项目中，我们需要花时间在以下任务上： 探索替代框架和工具 学习为项目选择的框架和工具 设置服务器和项目基础结构（版本控制，构建环境，数据库等） 如果我们正在使用用户故事，那么所有这些工作应该去哪儿？ 一种选择是使它们全部成为第一个用户故事的一部分（例如，制作应用程序主页）。另一个选择是对这些任务执行加急操作。第三种选择是使任务成为问题 / 障碍（例如，尚未选择的开发环境）而不是用户故事的一部分。
5
您如何跟踪敏捷团队的需求文档？
我知道用户故事在敏捷世界中占主导地位，但是如何存储这些工件，以便加入团队的新开发人员可以赶上需求？ 如果用户故事稍后更改，该如何更新并将其保留为工件呢？我已经看到许多团队只是打开一个新的票证/功能请​​求/错误报告，而不是跟踪原始故事。
7
您可以推荐哪些电子用户故事映射工具？[关闭]
按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 敏捷软件开发严重依赖于称为用户故事的工作项类型。例如，您有一个积压的用户故事，您可以选择其中一些在下一个冲刺期间进行处理。 但是，您在哪里以及如何找到要添加到待办事项列表中的用户故事？有一种流行的技术叫做故事映射。杰夫·帕顿（Jeff Patton）发明了它，这是有关如何做的权威指南。 问题是，那里有哪些电子工具可以支持Patton的故事映射技术？ 我进行了一些研究，找到了Pivotal和Rally插件（但我都不是两者的客户），并且我目前正在尝试SilverStories。 还有哪些其他工具？你用了什么？您（不）推荐什么？为什么？ 更新：一些发表评论的人似乎倾向于一个答案，即使用电子工具根本不可能应用这种技术，我们应该接受这一点。有人不能写出来作为答案吗？ 更新（根据亚历克斯·费曼的评论来澄清问题）：问题在于确定故事映射的选项。由于Jeff Patton的技术显然可以在带有胶粘物的白板上完成，因此问题集中在电子工具可能提供的其他选项上。（过早）对任何特定工具或工具类别的承诺不是这个问题的重点。
6
如何处理比平均冲刺差50％的速度？
如果我正确理解Scrum，这就是我确定团队在下一个冲刺中可以从事的工作的方式： 我平均了过去几个冲刺的完成点数。 这个量是我们的平均速度。在下一个冲刺中，我们要讲很多故事。 这是一个平均数，因此，如果历史重演，则此冲刺是我们承担的故事点过多的可能性为50％，而我们承担的故事点过多的可能性为50％。 在50％的情况下，我们承担了太多的故事要点，我们可以： 无法完成冲刺。这意味着我们将有一半时间无法实现冲刺承诺。 额外工作以赶上。问题在于，棘轮只有一种方式。我们将完成冲刺，完成的故事点数将反映出这一点。由于我们总是会结束，所以随着时间的流逝，我们的平均水平将趋于上升，直到我们总是完成大量的故事点并熬夜。 我对平均速度和冲刺承诺的理解正确吗？ 如果是这样，对于落后于平均水平的50％的冲刺，我们应该怎么做？ 如果没有，我怎么了？
5
Scrum可以使用产品待办事项列表中的技术规范而不是用户案例吗？
在我目前在公司工作的我们开始进行Scrum项目。说服经理们从瀑布式迁移到Scrum并不难。我们正在做一个从头开始重建平台的项目。因此，（大多数）功能是已知的，大多数改进都是技术性的。 在这种情况下，拥有技术任务而非用户故事是合理的。我们的积压工作涉及各种技术任务，例如： 将数据库类从MySQL重写为PostgreSQL。 实施系统日志记录。 重写对象缓存。 站立时出现的事情包括需要长时间的“研究任务”，但它们从未完成。此外，团队成员在冲刺中声称需要添加计划外任务。 Scrum Master应该如何处理？难道对于这样的项目来说，Scrum不是要走的路吗？
3
使用单元测试讲故事是个好主意吗？
因此，我有一段时间前编写的身份验证模块。现在，我看到了自己的错误并为此编写了单元测试。在编写单元测试时，我很难想出好名字和好地方进行测试。例如，我有类似的东西 需要Login_should_redirect_when_not_logged_in 需要登录时登录_通过_登录_登录 Login_should_work_when_given_proper_credentials 就个人而言，即使看起来“适当”，我还是觉得它有点丑陋。我也难以通过仅扫描测试来区分测试（我必须至少读取两次方法名称才能知道失败了）。 因此，我认为也许不编写纯粹测试功能的测试，而是编写一组涵盖场景的测试。 例如，这是我想出的一个测试存根： public class Authentication_Bill { public void Bill_has_no_account() { //assert username "bill" not in UserStore } public void Bill_attempts_to_post_comment_but_is_redirected_to_login() { //Calls RequiredLogin and should redirect to login page } public void Bill_creates_account() { //pretend the login page doubled as registration and he made an …
4
文档是用户故事吗？[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我们需要为过去几次冲刺中一直在开发的产品做一些用户文档。我们现在在下一个冲刺中开始一个新项目，采购订单正在将先前生产的产品的文档用作该冲刺的用户故事。 我只是想知道您对这种方法的看法。就个人而言，我不同意文档是Scrum中的用户故事，因为它不会产生任何代码。 编辑：谢谢您的意见。我的脑海里有一个冲刺是要实现一系列正在运行的软件，但是您的看法改变了我的看法。感谢您的所有答复。
13 scrum  user-story 
5
如何将敏捷应用于涉及复杂处理的应用程序？
关于敏捷的大多数文献似乎偏向于CRUD类型的业务应用程序，在该应用程序中，用户非常了解幕后情况。（这很好，因为所编写的大多数代码可能都属于此类。） 对于这种类型的应用程序，用户故事（需求）和开发任务之间的关系通常很简单：只需将用户故事分成几个任务即可。 但是还有另一种类型的应用程序，其中大多数代码必须处理用户不直接可见的复杂处理。例如： 编译器 自动驾驶汽车图像分析系统 流体模拟系统 在这里，将任务和用户案例联系起来确实非常困难。是否有克服这一问题的技术，或者仅仅是我们必须接受并充分利用的技术？
5
项目开始时的敏捷方法和数据库
敏捷的新手，我不确定如何开始。这个想法是在sprint中创建项目的一小部分。但是，我正在处理的项目需要一个数据库，并且该数据库必须具有几乎可以正常运行的功能才能对该项目执行任何操作。 那么，敏捷项目如何处理这个问题，首先要创建数据库吗？ 您将如何操作，例如，如果使用Scrum，您将如何处理用户故事并测试数据库。 您是否愿意在还需要代码的故事中做数据库的一部分。 假设您有一个故事“作为用户，您必须能够注册...”，您是否会在数据库中创建user表作为该故事的一部分？ 敏捷如何帮助您设计数据库？
5
Scrum中允许使用“技术用户故事”吗？
Scrum中允许使用技术用户故事吗？如果是这样，在Scrum中编写技术用户故事的标准模板是什么？一样As a <user> I want to do <task> so that I can <goal>吗？ 我在一些博客中读到，“ 开发人员不是用户故事”，但我也读到Scrum并没有强制要求这些。在有些情况下，他们有共同的一些博客用户故事与系统用户，它像as a <user who is not end user> i want to <system functionality> so that <some techinical thing>。那么哪个是标准？ 例如，有一些用户故事，例如： 作为评论者，我想上传任何酒店/食物的照片，以便其他用户可以看到并喜欢它们 作为用户，我想添加照片评论，以便更好地解释我的观点 现在，对于这两个用户故事，都有一个重要的技术项目-保存和检索图像 因此，我可以添加带有以下描述的标题为“图像存储和检索机制”的技术故事吗？ 作为开发人员，我想开发一种存储和检索图像的机制，以便用户可以在需要时添加/查看图像
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.