Question

我想弄清楚何时使用用户故事是合适的。总是或不？

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

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

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

Answer 1

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

不是真的同意它。由于故事是一个功能，它几乎占用了您的体系结构的每一层，实现故事同时构建了体系结构。查看Alistair Cockburn的Walking Skeleton定义。

关于问题

您可能将大多数故事定义为“作为用户......”作为故事的特征，也可以使UI工作。所以要明确你可以把故事分成子任务。虽然一些工作很难在INVEST用户故事中呈现。比如bug，tech。部门等等。他们仍然被呈现为特殊类型的故事（臭虫，科技故事）。你无法在Demo上展示它们，但你可能会提到。

Answer 2

(...) 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. (...)

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

这是敏捷的一个美女生活（与瀑布相比），欢迎改变。

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

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

所以，你可以问说服你的P.O.在积压中添加或优先处理用户故事（或几个），为未来的发展建立一些基础。 但是，再次，在创建此类故事时，请记住响应变更的敏捷价值。

P.S。

保持Product Backlog清晰易懂，并在P.O.之间提供适当的互动也很重要。和开发团队。这应该由Scrum Master指导。

通过这种方式，团队可以提供更好的反馈/警告P.O.，从技术角度来看，一个故事如何相互影响，为什么故事X应该在故事Y之前完成。

设计任务应该是用户故事吗？

2 个答案:

关于问题