使用用户故事作为系统文档

问题描述 投票:0回答:1

所以我们是一家基于库存管理系统产品的公司,我们使用并且仍然使用敏捷中的用户故事来编写需求并将其传达给开发团队。在初始阶段,我们没有过多考虑正确的文档方法,因此我们只有每个冲刺的文档,其中包含该冲刺的所有故事。

但是,我们现在正在扩展,我们认识到旧的方法是错误的,有很多重复的故事,并且很难根据 sprint 找到您需要的信息(因为文档是基于 sprint 的)

我们决定采用一种新的文档方法,因此我们决定采用基于系统结构的文档,因此系统中的每个模块都会有一个页面和子页面来描述该模块中的功能。我们从旧文档中转移了故事,并根据其与模块的相关性将其分布在模块中。

我现在的问题是,这是正确的文档方法吗?我们应该使用故事作为系统文档吗?或者还有别的办法吗?

谢谢

product project documentation business-process-management requirements
1个回答
0
投票

用户故事是关于需求以及系统如何解决用户需求的。如果您的系统具有明确的模块,并且大多数用户故事确实与一个模块相关,那么按照您的计划按模块组织它们是有意义的。

但是,用户找到逻辑会更加困难,因为您必须导航许多模块页面才能返回用户视角。此外,用户故事是增量的。因此,即使模块发生故障,您迷路也只是时间问题。

您可以这样做:

  • 构建您的用户故事:目标是从用户的角度跟踪全局。这将有助于将有某种相关性的故事联系起来。最有效且被广泛接受的敏捷实践是用户故事映射史诗和主题以及用例2.0(其中用户故事称为用例切片)。
  • 使用工具来管理用户故事并独立于结构来查找它们:像 Jira 或类似的工具可以帮助您管理故事及其结构,并找到它们。在我自己的一次经历中,我使用了 Jira 的组件标记,它可以说明一个故事是否与一个或多个模块相关。然后,您可以轻松找到每个用户、每个模块,当然还有冲刺。现在您也可以像以前一样继续记录,但建议进行一些交叉引用,以便您可以通过多种方式找到相关故事(即我的模块,按角色或用户活动)。
© www.soinside.com 2019 - 2024. All rights reserved.