Пользовательская история — дизайн базы данных

Мне нужно создать продукт, который будет иметь базу данных на серверной части для хранения и извлечения данных.

Я только начал собирать пользовательские истории от своих стейкхолдеров и застрял...

Если у меня есть руководитель проекта, у которого есть одна пользовательская история, например: «Как руководитель проекта, я хочу иметь возможность видеть и изменять объем своего проекта, чтобы убедиться, что мой проект актуален»

Эта пользовательская история потребует, чтобы я создал базу данных и до этого имел таблицу с данными в таблице.

Должен ли я собрать все пользовательские истории и добавить компонент базы данных по критериям приемлемости?

Должен ли я создавать пользовательские истории только для серверной части и некоторые для интерфейса?

Я не уверен, как разделить или заставить их работать вместе.


frontend database backend database-design user-stories
person DrD4rk    schedule 27.07.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Идея SCRUM заключается в том, что архитектура/дизайн будут появляться по мере вашего развития. Имея это в виду, вам по-прежнему нужен бэклог продукта, чтобы отразить, каким будет продукт. Так что где-то в бэклоге должна быть пользовательская история вроде... "Как пользователь, я хочу приложение, которое я могу использовать для управления своими проектами". Та история довольно большого (эпического) уровня. Так что это нужно разбить на более мелкие истории (например, «... приложение должно иметь способность x»). Если это действительно пользовательская история, то другой подэпопеей (которая все еще требует раскрытия) будет... «Как разработчик приложения (обратите внимание на изменение контекста здесь), мне нужна база данных для хранения данных моего приложения Project». Затем эта история раскрывается для человека, создающего сценарии db (при условии, что вы сначала создаете базу данных приложения, некоторые приложения сначала представляют собой код, а ORM генерирует схему базы данных). Суть здесь в том, что вы начинаете с большого и разбиваете его, пока не получите полный бэклог с очень маленькими историями. Тогда вы знаете, что у вас есть полный бэклог (подготовленный бэклог), и вы готовы приступить к планированию своих спринтов.

person Mike    schedule 27.07.2017
comment
Я понимаю, что вы говорите. Если пользовательская история Как менеджер по дизайну, я хочу увидеть эпическую смету расходов. Мне нужно разбить это, чтобы показать часть дизайна и серверную часть до небольших пользовательских историй, таких как «Как аналитик базы данных, я хочу создать таблицу затрат, чтобы я мог хранить смету затрат?» Имеет ли это смысл? - person DrD4rk; 28.07.2017
comment
Звучит хорошо, может быть, это будет так. Как аналитику баз данных, мне понадобится таблица затрат для хранения оценочной стоимости. Оставьте разработчику решать, как будет выполняться эта работа. Тогда критерием приемлемости для истории будет следующая таблица затрат, включающая столбцы x, y и z. - person Mike; 31.07.2017