Как писать пользовательские истории в проекте хранилища данных

Question

В моем хранилище данных (больше похоже на логистику данных, потому что мы просто переносим данные с минимальным преобразованием в центральный HUB) (который, как говорят, Agile - SCRUM), команда писала истории пользователей вроде

1. Как аналитик, я хочу подготовить лист спецификаций, чтобы можно было начать разработку
2. Как разработчик, я хочу разработать слой Transformation, чтобы можно было загружать HUB
3. Как тестер, я хочу протестировать таблицу, чтобы ее можно было перенести в производство.

Теперь я точно знаю, что вы пишете пользовательские истории не так, поскольку ни один из них представляют функциональность, они просто представляют техническую задачу.

Я предложил что-то вроде

• Как потребитель данных, я хочу, чтобы таблица была протестирована, чтобы не было никаких проблем во время потребление

И для этого у меня возникли вопросы типа «Потребитель никогда не просил проверить таблицу, мы проверяем ее из-за процесса, которому мы следуем. Потребитель запрашивается только данные, так почему мы должны говорить как пользователь в пользовательской истории "

Я не знаю, как на это ответить, и я также чувствую, что пользовательские истории все еще могут быть составлены лучше, но все еще придерживаются принцип, что "User stories are chunks that can be completed within 1-2 days"

Мне нужна помощь, чтобы понять, как это делают другие в проекте SCRUM Data logisti c, и любые предложения о том, как это можно составить лучше

Answer 1

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

Я могу подумать о двух возможных подходах, и тот, который вы выберете, будет зависеть от настроек вашего организация.

Пишем истории для функций конечного пользователя

Я предполагаю, что хранилище данных будет использоваться для отчетов, et c. Таким образом, пользовательская история может выглядеть примерно так:

Как директор по продажам, мне нужен отчет о ежемесячных продажах, чтобы я мог планировать свою стратегию продаж

Эта история может иметь несколько подзадач, например:

Импорт данных о продажах с использованием SQL script

Создание схемы хранилища

Проверка данных

... и т. Д.

Задача здесь заключается в том, чтобы работа, выполняемая вашей командой, была отделена от функций конечного пользователя. Другими словами, вы внедряете компонент хранилища данных, и он не включает интерфейс для отчетности.

Перефразируйте истории, чтобы сосредоточиться на пользователях хранилища данных

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

Например:

Как автор отчетов, я хочу, чтобы данные в хранилище данных были надежными чтобы я мог писать свои отчеты с уверенностью, что данные действительны

Это может иметь подзадачу, такую ​​как:

Убедитесь, что все таблицы протестированы