【问题标题】:User Story - Database design用户故事 - 数据库设计
【发布时间】:2018-01-03 18:22:28
【问题描述】:

我需要构建一个在后端有一个数据库来存储和检索数据的产品。

我刚开始从我的利益相关者那里收集用户故事,但我陷入了困境......

如果我的项目负责人有一个用户故事,例如: “作为项目负责人,我希望能够查看和修改我的项目范围,以确保我的项目是最新的”

这个用户故事需要我已经创建了数据库并在表中包含数据之前有一个表。

我应该收集所有用户故事并在验收标准上添加数据库组件吗?

我应该只为后端创建用户故事,而为前端创建一些用户故事吗?

我不确定如何将它们分开或使它们一起工作。

【问题讨论】:

    标签: database database-design frontend backend user-stories


    【解决方案1】:

    SCRUM 背后的理念是架构/设计将随着您的开发而出现。考虑到这一点,您仍然需要产品 backlog 来反映产品的内容。所以在积压的某个地方应该有一个用户故事,比如......“作为用户,我想要一个可以使用管理我的项目的应用程序”。那个故事相当大(史诗)级别。所以这必须分解成更小的故事(比如“......应用程序必须具有能力 x”)。如果这确实是用户故事,那么另一个子史诗(仍然有很大的需求爆发)故事将是......“作为应用程序开发人员(注意这里的上下文更改),我需要一个数据库来存储我的项目应用程序数据”。然后这个故事被打破了制作数据库脚本的人(假设您首先创建应用程序数据库,一些应用程序是代码优先并且 ORM 生成数据库模式)。这里的要点是,你从大处着手,然后将其分解,直到你得到一个包含非常小的故事的完整积压。然后你知道你有一个完整的待办事项(整理过的待办事项),你已经准备好开始计划你的冲刺了。

    【讨论】:

    • 我明白你在说什么。如果用户故事是“作为设计经理,我想查看成本估算”,那就是史诗。我需要将其分解以显示设计部分和后端,直到小的用户故事,例如“作为数据库分析师,我想创建一个成本表以便我可以存储成本估算”?这有意义吗?
    • 听起来不错,也许像“作为数据库分析师,我需要一个成本表来存储估计成本”。让开发人员决定如何完成这项工作。那么故事的验收标准将是“现在有一个成本表,其中包括 x、y 和 z 列。”
    猜你喜欢
    • 2011-06-25
    • 1970-01-01
    • 2012-09-17
    • 2017-01-04
    • 1970-01-01
    • 1970-01-01
    • 2019-04-17
    相关资源
    最近更新 更多