3

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

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

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

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

缺点 它变成了史诗

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

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

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

4

7 回答 7

3

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

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

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

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

  • 在燃尽图上跟踪项目
  • 交付功能齐全的工作(不是无法使用的工作子集)
  • 有可估计的部分

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

哦,还有最后一件事——保留流程图,不要为了故事而把它扔掉。但是用它来补充故事。

于 2011-03-02T13:46:00.947 回答
3

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

于 2011-03-02T12:39:12.193 回答
3

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

大多数重要的业务工作流程都受益于在实施过程中的拆分,以便可以持续部署和验证它们,以便从利益相关者那里获得早期反馈。将所有内容都作为一个大爆炸实现的一大缺点是后期验证。我认为获得早期反馈超过了处理多个故事所增加的管理负担。

关于如何将史诗拆分成故事的提示:Lasse Koskela 有一篇关于如何以不同方式拆分故事的精彩文章。

于 2011-03-02T12:51:42.907 回答
0

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

于 2011-03-02T12:31:31.250 回答
0

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

但是,当然,我们将流程图放在手边。事实上,我们把它打印出来贴在墙上。我们甚至保留了它的每个旧版本,因此我们将自己的基于纸质的版本控制贴在墙上(除了使用 git 作为电子版本 ;-) )

于 2011-03-02T21:09:24.737 回答
0

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

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

如果没有 EPIC,您很可能会遇到创建随机故事的问题,而无法掌握故事的归属感​​。您可以在某种程度上在用户故事中创建层次结构。如果不理解这一点,一切都是随机的,因此它会让你更难绕开你的脑袋或将故事作为 PO 来管理。

当然,这一切比我在上一段中提到的要多得多。这就是为什么您可能需要一位经验丰富的 Scrum 教练,或者对敏捷规划和用户故事写作进行大量勤奋的阅读/实施。

希望这是有道理的。我建议任何甚至远程考虑担任 PO 角色的人阅读 Mike Cohn 的 Agile Estimating and Planning 。祝你好运!

于 2011-03-03T17:48:14.580 回答
-1

工作流是编写用户故事和史诗的有趣入口,但用户故事不是映射到工作流程,它们映射到业务能力。所以你从一开始就在这个问题中加入了一些错误的想法。工作流是一个很好的对话工具,但将独立于工作流,因为它们关乎功能,而不是时间。时间存在于业务规则中。需要注意的是,业务规则不是验收标准,它们是验收标准(产品所有者可以展示的功能)和测试用例之间的联系。同样,验收标准是关于特征,而不是行为。行为存在于业务规则中。例如,我可能有一个 ATM 的用户故事,上面写着“作为用户,我可以检查我的帐户余额”。验收标准可能是“如果我透支,我会收到警报通知”。不是验收标准。它们是业务规则,其执行导致验收标准的可证明行为。请注意,此用户故事可以通过工作流分析捕获,但可能存在于许多工作流中(或没有)。

于 2015-09-30T21:40:01.757 回答