如何将业务流程工作流分解为用户故事

Question

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

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

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

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

缺点 它变成了史诗般的

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

赞成 纯粹的Scrum。易于确定优先次序/估算/计划

缺点 正如您所看到的，即使是简短的业务流程工作流也会轻易地分解为很多用户故事。

Answer 1

如果此业务工作流程与大多数业务工作流程类似，则每个步骤都将包含大量规则。这些规则应该映射到这些故事的验收标准，理想情况下，自动化测试以证明代码按预期工作。由于可能有很多验收标准，我倾向于第二种选择。

Answer 2

我倾向于在早期使用核心最终用户/利益相关者增值功能转向功能/史诗，例如在“发布文章以便订阅者可以获取最新消息”的示例中。然后，一旦功能越来越接近实现，我将根据需要将其拆分为实现大小的故事。

大多数非平凡的业务工作流程都会受益于在实施过程中被拆分，以便可以不断地部署和验证它们，以便从利益相关者那里获得早期反馈。将所有内容作为一个大爆炸实现的重要方面是后期验证。我认为早期的反馈超过了处理多个故事所增加的行政负担。

关于如何将史诗分成故事的提示：Lasse Koskela a great writeup关于如何以不同方式分裂故事。

Answer 3

我同意pma_。做有意义的事情。在这种情况下，您有一些很棒的用户故事。

“作为一名编辑，我希望在提交文章时得到通知，以便我可以对其进行审核。”

如果你有很多这些，那么它们可能太小了。他们都将是1-2小时。这可能不是一件好事。在这种情况下，请尝试对它们进行分组。也许 “作为编辑，我希望能够管理文章”。那将包括你已经拥有的几个。

请记住用户故事的目标......

• 跟踪燃尽图表上的项目
• 提供功能齐全的工作（不是无法使用的工作子集）
• 有可估量的部分

如果你能实现这些目标，那就很好。如果没有，请再试一次。

哦，还有最后一件事 - 保留流程图，不要把它扔掉以利于故事。但用它补充故事。

Answer 4

对我来说，所有敏捷都是关于使用常识。在这种情况下，你有完美的设计，所以只需实现一个，不要寻找不必要的东西。

Answer 5

我们目前正在构建基于业务流程的内容管理系统。我们根据您的第二选择将流程分为故事。

但是，当然，我们保持流程图方便。事实上，我们将它打印出来并贴在墙上。我们甚至保留了它的每个旧版本，所以我们将自己的基于纸张的版本控制粘在我们的墙上（除了使用git作为电子版;-)）

Answer 6

  

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

你提到的两个选项并不是真正的选项，它们是连续的阶段，恕我直言。在敏捷需求收集或产品规划期间，第一步是创建EPIC故事。拥有这些史诗后，你需要将它们分解成更小的块。

如果没有EPIC，你很可能会遇到创建随机故事的问题，而无法掌握故事的归属感​​。您可以通过某种方式在“用户故事”中创建层次结构。如果不了解这一点，一切都只是随机的，因此它更难以包围你的头脑或以故事的形式管理故事。

在所有这些中，除了上面提到的内容之外，还有更多内容。这就是为什么你可能需要一个经验丰富的Scrum教练，或者在敏捷规划和用户故事写作上做很多勤奋的阅读/实施。

希望这是有道理的。我建议阅读Mike Cohn的敏捷评估和规划，以便任何甚至远程想到担任PO角色的人。运气最好！

Answer 7

工作流程是编写用户故事和史诗的有趣入口，但用户故事不映射到工作流程，它们映射到业务功能。所以你从一开始就在这个问题中加入了一些谬误。工作流程是对话的一个很好的工具，但它将独立于工作流程，因为它们与功能有关，而非时间。时间存在于业务规则中。 在这方面，业务规则不是接受标准，它们是验收标准（可以由产品所有者演示的功能）和测试用例之间的连接。同样，接受标准是关于特征，而不是行为。行为存在于业务规则中。 例如，我可能有一个自动取款机的用户故事说＆＃34;作为用户，我可以查看我的帐户余额。＆＃34;接受标准可能是＆＃34;如果我被抽选，我会收到警告通知。＆＃34;什么构成过度草案的规则（我的账户中有1000美元并存入我的2500美元支票，但在我的1500美元抵押贷款支付之前未能清除，等等）不验收标准。它们是业务规则，其执行导致验收标准的可证明行为。请注意，此用户故事可以通过工作流分析捕获，但可能存在于许多工作流程中（或者没有）。