所以我们是一家基于库存管理系统产品的公司,我们使用并且仍然使用敏捷中的用户故事来编写需求并将其传达给开发团队。在初始阶段,我们没有过多考虑正确的文档方法,因此我们只有每个冲刺的文档,其中包含该冲刺的所有故事。
但是,我们现在正在扩展,我们认识到旧的方法是错误的,有很多重复的故事,并且很难根据 sprint 找到您需要的信息(因为文档是基于 sprint 的)
我们决定采用一种新的文档方法,因此我们决定采用基于系统结构的文档,因此系统中的每个模块都会有一个页面和子页面来描述该模块中的功能。我们从旧文档中转移了故事,并根据其与模块的相关性将其分布在模块中。
我现在的问题是,这是正确的文档方法吗?我们应该使用故事作为系统文档吗?或者还有别的办法吗?
谢谢
用户故事是关于需求以及系统如何解决用户需求的。如果您的系统具有明确的模块,并且大多数用户故事确实与一个模块相关,那么按照您的计划按模块组织它们是有意义的。
但是,用户找到逻辑会更加困难,因为您必须导航许多模块页面才能返回用户视角。此外,用户故事是增量的。因此,即使模块发生故障,您迷路也只是时间问题。
您可以这样做: