问题标签 [user-stories]

我需要在我们的产品积压列表中添加一个对用户没有（感知）价值的项目。

上下文：每周我们都需要解析和导入我们系统的 TXT 文件。现在提供商决定将格式更改为 XML，因此我们需要重写解析引擎。

最后，用户不会看到任何好处，因为他会继续获取他的新数据，但我们仍然必须这样做才能继续导入数据。

如何将这样的项目添加到产品积压列表中？

我的项目经理让我写一个 BDD。BDD 应该写什么？我们应该为每个 Story 还是为每个 epic 编写 BDD？

我在一个包下有多个故事。有人可以给我按顺序执行所有 jbehave 故事文件的运行器代码吗？

我一直在使用 storyPaths 方法，但它不起作用

我的团队最近进行了冲刺，我们正在将用户故事分解为任务。分解用户故事的最佳实践是什么？

每项任务都应该包括开发、设计、测试等吗？还是可以单独分解任务？如果是这样，与测试无关的任务是否应该直接完成并跳过工作流程中的“验证”或“测试”列？

从我在网上阅读的内容来看，似乎没有“固定”的方式，人们的做法也不同。我很好奇人们是否对他们的方式有问题。

任何帮助都会很有用！

我们按照规定的标准编写用户故事作为 XI 想要 Y 以便 Z。现在随着 BDD 和 Gerkhin 语言格式用于指定要求的流行，是否有人有将他们的用户故事转换为 Gerkhin 格式的经验。您是否发现以这种格式从业务中获取需求更容易和直观，并且您是否体验过这样做的任何好处？

Specification By Example 一书指出可以使用示例指定非功能性需求（通常称为 NFR）。

一位同事还告诉我，可以使用以下格式使用 SBE 故事指定非功能性需求：

以下是取自wikipedia的功能性和非功能性需求示例：

系统可能需要向用户显示数据库中记录的数量。这是功能要求。这个数字需要保持多长时间是非功能性要求。如果需要实时更新数量，系统架构师必须确保系统能够在记录数量变化的可接受的短间隔内更新显示的记录计数。

问题1：非功能性需求可以指定为故事吗？

问题 2：非功能性需求是否应该被指定为一个故事？

问题3：故事会是什么样子？

假设我有一个这样的用户故事：

• "用户可以在产品机器中添加、修改或删除产品。用户可以在产品机器中配置可供客户使用的产品机器列表",

我认为这个用户故事太大了，所以我想把它分成4个：

• “作为用户，我想将产品添加到产品机器”
• “作为用户，我想从产品机器修改产品”
• “作为用户，我想从产品机器中删除产品”
• “作为用户，我想配置产品机器中可用的产品列表”

关键是：在我看来，最后一个故事依赖于其他故事，尤其是第一个，因为如果我不能添加产品，显然不可能创建产品配置。所以这些用户故事不符合 INVEST 标准，因为它们不是独立的。

我该如何处理这个事实？

我对用户故事的卡片、对话、确认公式一无所知。我不明白是否必须写下对话和确认部分，或者它们仍然作为对话，特别是对话部分。需要明确的是：在用户故事中写下所有这些内容是否正确？（见下面的例子）或者我只需要写下 CARD 部分吗？

例子：

CARD 作为咖啡机的用户，我希望能够购买饮料。

CONVERSATION - 如果用户没有向 CoffeeMaker 存入足够的钱，他们将无法购买饮料 - 如果没有足够的库存来制作饮料，用户的钱将被退回

确认 1 用户介绍购买饮料所需的金额 2 用户选择饮料 3 用户获得饮料

我试图更好地理解用户故事的 INVEST 属性。例如考虑这两个用户故事：

1. 咖啡机是可编程的，可以定义不同种类的产品。产品在产品列表中具有唯一名称、价格和一些成分（指定数量），可在咖啡、牛奶、巧克力和糖之间进行选择。咖啡机使用户能够添加、修改或删除产品，并使用客户可用的产品列表创建配置。

2. 用户可以选择产品并投入等于或大于产品价格的金额。如果金额大于价格，则咖啡机给用户找零。

在这两个故事中可以找到哪个 INVEST 属性？哪个不是？

从我的角度来看，我认为可能是这样的：

• 独立：1 = 是 | 2 = 是
• 可协商：2 = 否 | 2 = 否（太多细节？）
• 对用户有价值：1 = YES | 2 = 是
• 估计：1 = NO（太大）| 2 = YES（可能需要更多领域知识？）
• 小：1 = NO（太大）| 2 = 是
• 可测试：2 = 是 | 2 = 是

我对吗？最后你认为有可能按照 3C 的风格重写它们吗？

我继承了一个使用 gerrit 来捕获和协作处理用户故事的过程。

该过程用于捕获故事的早期阶段，与白板方法相比，它似乎非常冗长。

感觉这个过程违背了用户故事的精神，其中协作和面对面的讨论似乎受到青睐。

此外，gerrit 工具更多地针对技术用户。需要 git 知识来编辑故事，这似乎将编写故事推给技术团队。

问题：是否可以使用 gerrit 有效地捕捉和协作处理故事？如果是这样，如何做到这一点？