问题标签 [user-stories]

用户故事传统上被写成“作为一个[用户类型]我想要[功能]以便[一些好处]”的表达。在书籍和在线资源中，[用户类型]通常对应于人类的角色。然而，在描述系统内部特性时，通常更容易将一些无人值守的服务代替用户，例如“作为 ServiceX，我希望定期刷新一些数据，以便我可以使用最新信息进行 XYZ”。

这种形式可以直接为系统的相关部分编写易于理解的验收测试。但这在概念上正确吗？用户故事不应该基于赋予商业价值的功能，并且由于系统和服务对获得商业价值不感兴趣，它们不应该成为用户故事的参与者吗？

If I am grooming the backlog and I see a user story that is completely valid but is ultra low priority should it be deleted? Is the backlog supposed to be just the user stories that have a chance of getting worked on or should they be all user stories that are related to a product even if it is just some idea we got while brainstorming. What if the idea came from in as a customer request but it isn't a high priority item from the product owner's point of view?

我刚刚完成了监督学习算法的原型实现，自动为我们公司数据库中的所有项目（大约 500 万个项目）分配分类标签。

结果看起来不错，我已获准计划生产实施项目。

我以前做过这种工作，所以我知道软件的功能组件如何。我需要一组网络爬虫来获取数据。我需要从抓取的文档中提取特征。这些文档需要被分成“训练集”和“分类集”，并且需要从每个文档中提取特征向量。这些特征向量自组织成簇，簇通过一系列的再平衡操作。等等等等等等等等。

所以我制定了一个计划，其中包含大约 30 个独特的开发/部署任务，每个任务都有时间估算。开发的第一阶段——忽略一些我们希望长期拥有的高级功能，但还没有足够高的优先级将其纳入开发计划——预计需要大约两个月的工作时间. （请记住，我已经有了一个工作原型，所以最终实现比从头开始项目要简单得多。）

我的经理说这个计划对他来说很好，但他问我是否可以将任务重新组织成用户故事，原因如下：（1）我们的项目管理软件完全围绕用户故事进行组织；(2) 我们所有的调度都是基于将整个用户故事融入到 sprint 中，而不是单独调度任务；(3) 其他团队——比如 Web 开发人员——已经充分利用了敏捷方法，他们从将所有软件功能建模为用户故事中受益。

所以我在项目的顶层创建了一个用户故事：

作为系统的用户，我想按类别搜索项目，以便在庞大、复杂的数据库中轻松找到最相关的项目。

或者，这个功能的更好的顶级故事可能是：

作为内容编辑器，我想为我们数据库中的项目自动创建分类名称，以便客户可以在我们庞大而复杂的数据库中轻松找到高价值数据。

但这不是真正的问题。

对我来说，棘手的部分是弄清楚如何为机器学习架构的其余部分创建从属用户故事。

恰当的例子......我知道该算法需要两个主要的架构细分：（A）训练和（B）分类。而且我知道架构的训练部分需要构建一个集群空间。

我读过的所有敏捷开发文献似乎都表明，用户故事应该是“提供任何商业价值的最小可能实现”。在设计最终用户软件时，这很有意义。从小处着手，然后在用户需要附加功能时逐步增加价值。

但集群空间本身提供零商业价值。爬虫或特征提取器也没有。部分系统没有商业价值（对最终用户或公司内部的任何角色都没有）。训练有素的集群空间只有使用爬虫和特征提取器才有可能，并且只有当我们还开发了一个随附的分类器时才相关。

我想可以创建用户故事，其中系统的从属组件充当故事中的用户：

作为监督学习的集群空间构建例程，我想使用来自特征提取器的数据，这样我才能存在。

但这似乎真的很奇怪。作为开发人员（或我们的用户，或任何其他利益相关者），对我的用户故事进行建模有什么好处？

虽然主要故事可以很容易地沿着架构组件边界（爬虫、训练器、分类器等）划分，但从用户的角度来看，我想不出任何有用的分解。

你们有什么感想？您如何为复杂的、不可分割的、非面向用户的组件规划敏捷用户故事？

产品所有者对产品应如何在复杂的业务流程工作流（批准和不批准）中支持用户有特定的要求。记录需求的最简单方法是以流程图/流程图的形式。

然而，在 Scrum 中，建议要求采用用户故事的形式。解决这个问题的最佳方法是什么？

选项 1 包含包含工作流的通用用户故事，并将流程图作为支持文档附加。例如，作为作者，我希望能够提交我的文章以供审批，以便发表。

优点 人们更容易理解和消化——而不是阅读 10-20 个用户故事。

缺点 它变成了史诗

选项 2将复杂的流程图分解为自己的用户故事。例如，作为作者，我希望能够提交我的文章。作为编辑，我希望在文章提交时收到通知，以便我对其进行审查。作为编辑，我需要批准一篇文章 作为编辑，我希望能够请求更多信息...

赞成 纯 Scrum。易于确定优先级/估计/计划

缺点 如您所见，即使是简短的业务流程工作流也很容易爆发成大量用户故事。

您可以推荐我使用哪个 linux 创建需求和用户故事的工具？

我想从这里解释的东西开始，但想知道有没有更好的方法。

编辑

我想我也可以只使用文本编辑器来编写需求。

所以我知道，当涉及到用户故事场景时，具体化是一件好事。然而，我经常会问自己：我的场景应该有多具体？

例如，对于用户故事：

为了让项目成员在项目上进行协作，作为项目经理，我希望能够注册新项目

我们可以有以下场景：

给定一个项目从未在系统中注册过，当项目经理注册该项目时，注册的项目应该出现在指定成员的项目列表中

或者我们可以更具体一些，比如：

鉴于Scott是项目经理，并且stackoverflow 集成项目从未在系统中注册，当Scott注册stackoverflow 集成项目时指定Jane为项目成员，则stackoverflow 集成项目应该出现在Jane的项目列表中

在编写 BDD 规范时，我发现第二个“更具体”的规范非常方便。有类似 scottTheProjectManager 而不是 projectManagerStub 的地方是：

• 更符合现实世界（我们没有作为项目经理工作的存根……还是我们？）
• 在该规范上下文中需要时更容易参考（否则，我会一直说“那个项目经理”或“注册项目的项目经理”......等等。

我的结论正确吗？当故事发生变化时，这种特殊性会伤害我吗？

非常感谢！

上面的问题不仅是关于使用人名而不是角色名，而是关于用真实实例的名称替换场景中的所有占位符。通过真实的例子，我并不是说我们实际上有一个叫 Scott 的人担任项目经理，它只是给抽象占位符命名以实现上述好处。

我将尝试通过包含以下代码来展示这些好处是如何实现的，这些代码表示使用 StoryQ 框架的完整 BDD 样式规范

假设您正在编写一段遗留代码，该代码是在您的公司开始使用像 Scrum 这样的敏捷方法之前编写的。

现在假设您在该领域发现了一个需要修复的错误，并且从未编写过该功能的故事。团队中的每个人都知道那个特别的功能是什么以及它应该如何表现，但只是没有与之相关的故事。

现在，在当前的 sprint 中，您将处理该缺陷，因为营销和支持已经厌倦了处理该问题。

您是否创建了一个回顾该缺陷的故事？您是否将缺陷重新标记为故事并修改格式以使其看起来像故事？如果您不创建故事，您是否会因缺陷而获得积分？如果您确实创建了一个故事，您是否会因修复缺陷而获得积分（通过故事的积分）？

处理这种情况的最佳方法是什么？

更新：假设安装过程突然开始在 Windows 7 64 位系统上蓝屏，并且一直要求应用程序安装在所有 Windows 平台上。新问题可能是由于 Service Pack 1 或类似的东西而出现的。

我们有一些产品，其中一种产品使用平面文件进行持久化。套件中的其他产品可以使用该数据（通过 API），但一次只能使用一个。

我们不能将整个文件作为其庞大的数据放入数据库中。20GB + ..但我们仍然找到了一个解决方案，可以将一些数据放入数据库中。例如用户解释、元信息、标记等。

所以故事是这样的：

“作为用户，我可以同时从产品 B、C 和 D 访问产品 A 数据”。这是巨大的，即大约 6-8 个月

即使我将其保留为“作为用户，我可以同时从产品 B 访问产品 A 数据”。它仍然很大.. 即大约 5-6 个月

即使像下面这样，它仍然很大。“作为用户，我可以同时从产品 B 访问产品 A 数据的功能 X”。即大约4-5个月。

问题是如果我们可以做一件事（一个功能，一个产品），我们可以快速完成所有事情。

我怎么能把这个故事分成子故事……或者我应该接受一些故事不能进一步分成可以适合一次迭代的子故事。

PS：我们使用scrum

在我的 JIRA/Greenhopper 中，当我将故事下的子任务移动到“进行中”时，我可以自动将我的故事移动到“进行中”吗？

此外，当我关闭故事中的所有任务时，它可以自动移动我的故事以关闭。

当您拥有跨多种 UI 模式通用的功能时，有什么好的方法来捕捉用户故事？

例如，想象一个商业航班信息系统，有人可能会用它来回答“UA211 航班预计何时降落？”这个问题。

通常情况下，提供日程信息的功能是常见的底层功能，即使您可能通过桌面网络浏览器、移动浏览器（您希望应用不同的样式以使其更可用）以及可能即使通过短信短代码。

现在，这当然可以是一个单一的用户故事（“ As someone meeting a traveller, I want to see flight arrival information so that I can be at the airport on time”）。但这似乎是错误的（无论如何，这可能是一个史诗般的故事）。

您可以将其分开的用户故事（“ As a desktop user...”，“ As a smartphone user...”等），我过去做过，团队只知道估计第一个包含所有功能，而后续的只估计 UI执行。

第三种选择是使底层功能成为与表示层隔离的故事，然后有 UI 故事：“ As a flight info system front end, I want to get flight status information so that I can present it to the user”、“ As a desktop user, I want to see flight arrival... etc”。但这似乎是人为的。

想法？

dwh