如何处理共享功能的故事

我有两个故事（我知道他们缺少福利部分）

1. 作为信用管理用户，我可以查看Office的当前和以前的工资差异。
2. 作为信用管理用户，我可以收到一封电子邮件，其中包含Office当前和以前的工资差异的PDF。

两者是相关的，因为它们将具有相同的查询/过滤条件。唯一的区别是，在“查看”故事中，结果显示给用户，在“电子邮件”故事中，结果被写入PDF，然后通过电子邮件发送给用户。

我正在努力将这两个故事的共同方面分开，或者我什至应该这样做。

例如，它们都将具有相同的查询，它们对结果的处理方式是不同的。

我是否应该将查询分为另一个纯技术的故事？

PDF的创建和电子邮件的发送应该脱机完成，这是否应该成为技术故事？

我可以看到将这两个故事分解为2个功能故事和2个技术故事。

1. 作为系统，我可以计算Office当前和以前的薪资差异。

2. 作为信用管理用户，我可以查看Office当前和以前的薪资差异。

3. 作为系统，我可以创建一个Office当前和以前薪资差异的PDF文档。

4. 作为信用管理用户，我可以要求接收一封电子邮件，其中包含有关Office当前和以前薪资差异的PDF。

我一直回想的问题是，这四个故事不是独立的，也不是“切蛋糕”。

所以我不太确定如何处理这两个问题。

用户故事不是系统规范或功能要求。而是，它们是可能导致此类规范或要求的对话的开始。

因此，我希望在系统实现方面有重叠。用户故事并不意味着描述或消除这种功能重叠。用户故事的目的是从用户角度捕获功能期望，而不是描述实现细节。

不要：尝试分解故事，先做一个故事，然后再讲另一个。

要做：确保开发团队了解第二个故事。

试图计划详细的任务和建立可以优雅地处理这两者的通用模型的问题是，这很困难。

用户故事的目的是完成工作。优雅是次要目标，应该留给重构。

显然，如果您最大程度地利用它并且不告诉任何其他十个需要完成的相似任务，这将非常烦人，但是完全可以想象，直到完成第一个或第二个任务时，才考虑第二或第三个任务。如果您想计划所有事情，那就去瀑布吧。

在与罗伯特·哈维（Robert Harvey）达成暴力协议后，用户故事的目的是了解用户需要具备的能力。当您进行修饰时，客户会理解并关心用户故事，但是开发人员会关心更多。一旦提出足够多的问题以理解和评估工作，就可以创建任务来支持它们。

在这种特殊情况下，您可以创建任务以使这两个用户故事的核心成为可能，并且与您首先处理的那个故事一起执行。

要添加到用户故事中的重要内容是：

• 验收标准
• 假设条件

严格来说，“用户故事”是对话的承诺，以了解所需的结果。

例如，以第二个用户故事为例

作为信用管理用户，我可以收到一封电子邮件，其中包含Office当前和以前的工资差异的PDF。

考虑以下几点：

• 推动此要求的用户“需求”是什么？（作为解决方案的电子邮件中的PDF是否来自他们？这可能无法满足需要，您的团队可以提出更好的解决方案）
• 可以满足该用户“需求”并验证您的解决方案的最低限度是多少？简短的反馈循环很有价值。

在进行故事拆分时，请记住可能的投资标准。

1. 我 ndependent
2. ñ egotiable
3. V aluable
4. 可固定
5. 小号商场
6. Ť estable

它是好的，有其中有一个自然排序的故事。考虑到这一点-通常，第一个故事会更大，因为它带来了所需的功能，第二个故事则以此为基础。

我会挑战“技术”故事，因为通常它们最有可能是帮助支持以用户结果为中心的故事的实施的任务。

TL; DR

假设两个用户故事都在同一迭代中进入范围，则团队的工作就是将故事分解为实施计划及其附带的任务。用户故事提供了上下文和范围；它们不是实现，规范或打孔列表项。

故事应分解为迭代任务

无论您遵循Scrum还是其他敏捷方法，跳过迭代的计划阶段都是一个常见的错误。在Scrum中，当产品待办事项（严格来说，不必是用户故事）被拉入当前的Sprint时，团队应该使用Sprint Planning的一部分来排除工作项之间的共性，识别依赖关系，以及然后开发Sprint Backlog来捕获任务级的工作。

正如您在帖子中所指出的，敏捷迭代包含紧密相关的用户案例并不少见（实际上是可取的）。在Scrum中，这是通过使用Sprint目标得以体现的。在Scrum框架之外，由于共享目标或共享依赖关系，引入相关故事通常仍然有意义。通过在单个迭代中提取然后处理共享的依赖关系，团队通常可以避免将来需要重构或迭代代码以实现相似但不相同的功能。

任务实施故事

这是考虑用户故事依赖关系计划的另一种方法。一般来说：

1. 史诗/主题用于长期计划或待办事项分组。
2. 用户故事用于传达目标，上下文和范围。
3. 即时计划用于开发适合单个迭代的实现。
4. 任务针对一个或多个用户案例实施符合“完成的定义”的即时计划。

大多数从业者都将用户故事视为实施计划或任务列表，认为这是一种敏捷的反模式。无论您选择哪种方式，都不要跳过敏捷框架的及时计划阶段，并确保在团队流程中的某个位置跟踪依赖关系和共享的实现细节。