问题标签 [user-stories]

我们的团队开始使用用户故事来收集需求。我们在如何将它们映射到任务方面遇到了一些困惑。似乎我们有几个用户故事描述了相同的基本开发任务的不同方面。例如...

用户故事：

• 作为 XYZ 用户，我想在表单中输入目标，以便跟踪目标的进度
• 作为 XYZ 用户，我希望只能为目标输入正整数，以免输入错误数据
• 作为 XYZ 用户，我想过滤可用的目标，这样我就可以只关注特定的目标

任务：

• 开发用于输入带有验证和过滤的目标的表单

这里的问题是我们正在使用 TFS，它可以防止开发任务有多个父级。这大概是因为我们首先以某种方式弄错了这种方法。

谁能建议这应该怎么做？

有什么方法可以让用户输入功能请求，以便它们出现在 TFS2010 中？

我们希望保留所有传入请求的概览，并且仅User Stories在验证这些请求后创建我们自己的请求。

我正在开发一个需要使用用户故事的项目，该项目的一部分是针对 ASP.NET 数据库执行身份验证。通过阅读这个故事将遵循类似的模式：

作为一个未注册的用户，我想注册应用程序以便创建一个帐户......等等。

从“接受”的角度来看，我将其视为完成工作的后端部分，然后是用户可以与之交互的 UI。但是还有其他不相关的项目可以使用相同的功能，因此这将成为共享框架/库的一部分。

随着代码进入一个没有前端的库，应该如何编写用户故事？即使用户不会直接使用该功能，是否仍应从最终用户的角度编写故事？

We need to determine a top level story to be considered under a selected release if any of its child (or further child stories) are scheduled to be released in the selected release. Valuable replies would greatly help.

我正在从头开始一个新项目，并编写了用户存储来描述给定用户将如何与系统交互。但是，我很难理解如何将第一个用户故事分解为任务，而不会使第一个用户故事成为史诗。

例如，如果我正在制造一辆汽车，第一个用户故事说“作为一名司机，我希望能够改变运动方向，这样我就不会撞到东西。”，这意味着用户界面（方向盘），还有运动（车轮）以及将它们连接在一起所需的一切（车轴，框架，连杆等......）。最后，第一个用户故事似乎总是代表项目的 40% 左右，因为它包含了太多关于底层架构的信息。

您如何为一个新项目分解用户故事，以使第一个不会成为代表整个底层架构的史诗？

有谁知道一个好的网络服务，在那里我可以和其他人一起编写和修改用户故事？我用过谷歌的 Wave。但截至 2012 年，谷歌确实关闭了这个项目。

根据这篇Scrum 文章：

故事点是不直接转化为特定小时数的相对值。相反，故事点有助于团队量化用户故事的总体规模。这些相对估计不太精确，因此它们需要更少的努力来确定，并且随着时间的推移它们保持得更好。通过估计故事点，您的团队现在将提供用户故事的一般规模，并在团队成员即将实施用户故事时制定更详细的工作时间估算。

谁能澄清一下：

1. 故事点的衡量标准应该是什么？它应该是 10 个、100 个还是给定产品 backlog 中分配的最高故事点？
2. （有点离题）“产品待办事项”（查看附件图片）由项目的所有用户故事组成，而冲刺待办事项包含产品待办事项中的故事子集。话说回来; 如果一个产品 backlog 就足够了，那么为什么 TFS 允许我们拥有多个产品 backlog 项目？

我正在对我们的网站进行一些冒烟测试。

我正在为现有的自动化验收测试/用户故事使用 Given/When/Then 格式。但现在我想做一个初步的冒烟测试：

Given I'm on the homepage

Then I should see "Welcome To The Site"

我错过了什么吗？没有时间是否“可以”？

使用的工具：MVC3、SpecFlow、Nunit、Watin

我正在学习如何使用敏捷方法领导一组开发人员进行 RoR 项目。我在网上找到了一些工具，例如 VersionOne 或 PivotalTracker，它们可以帮助您创建迭代、积压、故事等，因此您可以将工作与前端和后端分开，并使您的开发人员完全专注于特定任务。

我的问题是关于你开始使用这个敏捷工具之前的步骤，创建故事和迭代，你的开发人员开始让它在每一个上成长。我的疑惑是关于技术、功能和非功能软件需求规范的步骤，所以当你弄清楚之后，你就可以开始写故事了：

http://en.wikipedia.org/wiki/Non-functional_requirement。

是否有工具可以指导您如何成功地将 Web 应用程序（或移动应用程序）的想法转换为故事/迭代列表？某种状态、特征或功能（及其关系）的视觉表示，您可以在其中指定功能、非功能和技术规范，然后您就可以创建故事了？

非常感谢您提前付出的时间和耐心。

如果我在一个故事下的 JIRA 中有一堆子任务，然后我将故事（或 Bug）标记为“已解决”（来自 In Progress），我怎样才能让它将所有子任务标记为已解决？

同样，如果我有一堆子任务并且我将最后一个从 In Progress 移到 Resolved，我怎样才能使故事本身（或 Bug）被标记为 Resolved？

谢谢！