问题标签 [user-stories]

在敏捷中，用户故事中的“用户”应该始终是最终用户还是指不同类型的用户？例如，是否可以这样写：“作为开发人员，我希望有一个到组件 B 的接口，以便我可以从组件 A 与它进行通信”，或者是否应该根据以下好处对其进行重组？这样的界面最终会呈现给最终用户吗？

在 SCRUM 敏捷项目中，我们使用 TFS 2010/VS2010。

在开始这个项目之前，客户已经写出了所有用例的 80%。问题是这些 UC 中的大多数都非常大，我想将它们分成用户故事。用户故事可以与用例的场景进行比较。

我现在的计划是使用敏捷过程模板并开始创建顶级用户故事作为用例。每个顶级用例将有 1 个或多个用户故事作为父用户故事下方的子级。然后在 2 级用户故事下方，我添加了一个或多个任务，开发人员可以在其中进行签到。

这是正确的方法吗？

我采用了针对 SO 上的问题而引入的用户故事模板，即

我有两个问题：

1. 我应该如何将莫斯科纳入用户故事，模板的哪一部分可以/应该改变？

2. 我正在重写需求，并且经常处理有关网站上可用内容的声明。我不确定我是否应该从阅读内容的网站用户或提供内容的广告管理员的角度来编写用户故事。任何人都可以澄清采取的最佳方法吗？

我正在寻找如何提高 Jira+GreenHopper 中用户故事进度的可见性的想法。

我们现在的工作方式：我们将所有用户故事放入 Jira，将它们分解为开发的子任务，然后我们的测试人员将 Jira 中的错误链接到适当的用户故事。在我们的项目仪表板上，我们有一个过滤器，例如“显示名称、状态、完成百分比，其中 fixVersion = current_sprint order by priority desc”。

我们的问题：为了了解标记为 100% 完成的用户故事是否真的可以向我们的客户展示，我们需要确保它是否没有严重错误并且不超过 N 个低优先级错误。但是现在我们需要手动逐个检查每个用户故事来计算这些数字。

问题：如果可以在当前 sprint 的用户故事列表中显示每个优先级的错误计数，有什么想法吗？为简单起见，我们会考虑：

• 高：未解决 Blocker + Critical 优先级的错误；
• 中：未解决主要+中优先级的错误；
• 低：未解决 Minor + Trivial 优先级的 bug；

所以，这样的列表看起来像

最简单方法的想法？任何基于标准 Jira 小工具/查询的东西？或您可能知道用于此的任何自定义插件？或者即使应该开发什么？谢谢！

我在一家大型电信公司工作，我们部门最近转向了“企业敏捷”工作模式（这一切都非常令人兴奋！）我们过去曾运行过特定的敏捷友好项目，但现在正试图交付我们的整体使用敏捷原则的程序。我们的大部分工作都是基于系统集成和配置的，我们内部运行的软件开发很少。

我现在正在尝试从我们的生命周期计划中交付功能，并尝试鼓励团队编写以客户价值为中心的故事，但是当该功能需要大量技术基础工作时，您如何做到这一点，以交付非常锁定的一部分用户功能？（第三方软件已经定义了用户可以做什么和不能做什么）

例如，我们具有通过新报告解决方案提供现有客户报告的功能。不会提供任何新功能 - 至少作为初始版本的一部分。我们已经确定了一组我们将为用户构建的标准报告。这些是我们的客户价值故事。但是要交付一个故事，我们需要部署和配置新的主机、新的业务对象数据库、新的数据收集点、新的数据聚合和提取层，并将当前客户数据导出到解决方案中并验证\调整演示文稿 - 在我们构建之前并提交实际报告。

新客户队列报告的交付是我们的 EPIC 故事，我们应该如何捕捉交付此报告所需的所有技术基础工作？主机的登台和数据库的构建可以写成用户故事还是仅仅写成技术任务。如果将其编写为非估计任务，我们将运行大约 4-5 次迭代，然后才能交付单个用户故事。即使试图提供最小的功能，这个故事也是针对拥有大量数据的大型客户，并且需要大量的技术工作来提供第一个价值故事/

我在这个优秀的网站、网络和诸如 Mike Cohn 的书籍中进行了搜索，advise 似乎主要是基于软件开发的。我很想得到一些可以应用于大型企业明智工程项目的答案。随着敏捷运动因其软开发根源而发展壮大，这对于那里的团队来说一定是一个日益严重的问题吗？

是否可以使用 Rally Web 服务 API 从迭代中的特定日期获取用户故事（分层需求）？我正在开发一个 java 应用程序，它将为迭代生成一个历史图表。例如，如果迭代为期 14 天，我需要获取该迭代中每一天的分层需求及其所有属性，例如：[day1,Hierarchical Requirements]、[day2,Hierarchical Requirements] 等等。

为了管理大型社区网站的 scrum 开发过程，我们决定迁移到 JIRA/Greenhopper/Bonfire。我创建了精心制作的史诗、故事和任务，所有这些都相互关联。

我想通过添加新的史诗、新故事到（新的或现有的）史诗等来更详细地开发“产品故事”。

为了能够正确地做到这一点，我想要对所有问题进行分层概述：史诗、故事、任务等。

问题：我们如何在 JIRA 中进行设置？

为什么？=> 我的方法是从项目管理的角度出发：让每个人都围绕同一个愿景保持一致。然而，我认为团队中的每个人——尤其是那些实际构建产品的人——都应该快速了解他们当前或计划的工作如何适应大局。

我试图弄清楚何时使用用户故事是合适的。总是与否？

例如，考虑一个团队从头开始工作，比如电影票预订服务。为该功能想出用户故事很容易，例如：“作为最终用户，我希望能够浏览在 X 影院放映的电影”等等。

但在实现这些之前，需要设计系统：必须设计架构，必须设计数据库，为 GUI 和业务逻辑选择技术。

这些任务应该如何出现在 backlog 中？它们也应该是用户故事吗？如果是这样，他们如何遵守 INVEST 助记符？它们并不单独为最终用户提供任何东西，但是在实现任何功能之前都需要它们。

我正在使用 Rally 2.0p4 API 并尝试聚合数据以获取迭代列表，其中包含每次迭代的故事点总和。我目前发现的唯一方法是查询HierarchicalRequirement模型并循环所有数据并将其填充到数组中。这似乎不太理想，有没有办法从服务器的调用中取回总数。

在敏捷过程中，故事点是复杂性而非时间的度量。这对于一个不太复杂但需要更多时间来完成的故事有什么好处。

让我举个例子，

故事 1：保存用户详细信息。

故事 2：公司名称已从 X 更改为 Y，需要在应用程序中更新。大约有 40 个屏幕，10 个报告，法律声明所有这些都应该改变。

这是简单任务的典型示例，但需要大量时间来实现（考虑到本地化应用程序，即使遵循适当的开发标准）和测试。

如果我按照传统定义，我会给出故事点 1，但是我看到的速度是错误的，即使工作做得好，速度也会下降。我看过这篇文章，它谈到了这个问题。

My question is how this task can be compared to the first story and should the effort be included in story point estimation?

我几乎对这个想法深信不疑，但想知道在这种情况下使用的最佳实践，或者是否有任何我可以阅读的好文章？