3

我试图弄清楚何时使用用户故事是合适的。总是与否？

例如，考虑一个团队从头开始工作，比如电影票预订服务。为该功能想出用户故事很容易，例如：“作为最终用户，我希望能够浏览在 X 影院放映的电影”等等。

但在实现这些之前，需要设计系统：必须设计架构，必须设计数据库，为 GUI 和业务逻辑选择技术。

这些任务应该如何出现在 backlog 中？它们也应该是用户故事吗？如果是这样，他们如何遵守 INVEST 助记符？它们并不单独为最终用户提供任何东西，但是在实现任何功能之前都需要它们。

4

2 回答 2

4

但在实现这些之前，需要设计系统：必须设计架构，必须设计数据库，为 GUI 和业务逻辑选择技术。

不太同意。由于故事是一个功能，它几乎需要架构的每一层来实现故事，同时构建架构。检查 Alistair Cockburn 的步行骨架定义。

关于问题

您可以将大多数故事定义为“作为用户......”作为故事可能具有 UI 工作的功能。因此，为了清楚起见，您可以将故事分成子任务。尽管有些工作很难在 INVEST 用户故事中呈现。例如错误，技术。部门等等。它们仍然以特殊类型的故事（错误、技术故事）的形式呈现。您无法在 Demo 上展示它们，但是您可能会提到。

于 2012-11-02T10:10:46.903 回答
1

(...) before those can be implemented, the system needs to be designed: Architecture must be designed, database must be designed, technologies chosen for the GUI and business logic. (...)

不完全是。例如，您不需要为实现冲刺、特定版本或任何给定时间的功能而设计的整个数据库。你可能需要一些共同点。

这是敏捷的一位美女（与瀑布相比）生活的地方，欢迎变化。

现在，回答您的问题：意识到用户故事中的角色不一定是最终客户的角色。可能是您的开发人员、系统管理员等。因此：

AS A server administrator,
I WANT to upgrade our webserver
SO THAT it will handle better the memory consumption

因此，您可以要求说服您的 PO 在待办事项列表中添加或优先考虑用户故事（或多个），以便为未来的发展奠定基础。但是，在创建此类故事时，请再次记住响应变化的敏捷价值。

附言

保持产品待办列表清晰和可访问，并在 PO 和开发团队之间提供适当的交互也很重要。这应该由 Scrum Master 指导。

这样，团队可以从技术角度提供更好的反馈/警告 PO，一个故事如何相互影响，以及为什么故事 X 应该在故事 Y 之前完成。

于 2012-11-07T16:06:09.667 回答