Story

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

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

В чём разница с обычной задачей?

В случае обычной задачи чаще всего описывают просто что-то сделать. В случае Story делают описание, объясняющее почему это важно сделать и какой эффект ожидают получить от реализации.

Обычная задача	Story
Добавить логирование ошибок.	Как разработчик, Я хочу видеть ошибки в логах, Чтобы быстрее находить причины сбоев.
Сделать кеширование.	Когда часто запрашиваются одни и те же данные, Я хочу использовать кеш, Чтобы ускорить отклик API.

Шаблоны Story

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

User Story

Ориентирована на пользователя и бизнес-ценность. Подходит, если есть прямой пользователь или внешний клиент.

Шаблон

Как < роль / система >,
Я хочу < действие / функциональность >,
Чтобы < получить результат / ценность >.

Критерии приёмки:

1. ...
2. ...
3. ...

Пример

Как пользователь,
Я хочу фильтровать список заказов по дате,
Чтобы находить нужные мне заказы быстрее.

Критерии приёмки:

1. Фильтр отображается на экране заказов.
2. Можно выбрать диапазон дат.
3. Результаты обновляются без перезагрузки страницы.

Job Story

Фокус на потребности пользователя при определённых условиях. Подходит и для технических задач.

Шаблон

Когда < условие / контекст>,
Я хочу < реализация / изменение >,
Чтобы < достичь цели >.

Критерии приёмки:

1. ...
2. ...
3. ...

Пример

Когда устройство теряет соединение с сервером,
Я хочу, чтобы оно автоматически перешло в оффлайн-режим и сохраняло данные локально,
Чтобы при восстановлении соединения можно было отправить накопленные данные на сервер.

Критерии приёмки:

1. При потере соединения устройство фиксирует это событие в логах.
2. Устройство продолжает собирать и сохранять данные локально во внутреннюю память.
3. При восстановлении соединения накопленные данные автоматически отправляются на сервер и данные помечаются как успешно доставленные.
4. Повторная отправка не приводит к дублированию данных на сервере.

Technical Story

Инженерный шаблон, приспособленный под технические задачи. Пишется от лица разработчика, системы, API и т.п.

Шаблон

Как < роль: разработчик / система / API-клиент >,
Я хочу < функциональность или действие >,
Чтобы < результат или причина >.

Критерии приёмки:

1. ...
2. ...
3. ...

Пример

Как инженер DevOps,
Я хочу настроить автоматическую сборку прошивки через GitLab CI,
Чтобы исключить ручные ошибки и ускорить разработку.

Критерии приёмки:

1. При пуше в ветку main запускается pipeline сборки.
2. Используется Docker-образ с нужной версией компилятора (arm-none-eabi).
3. Сборка завершена успешно, и артефакт (.hex или .bin) доступен для скачивания.
4. В pipeline предусмотрена отдельная stage для unit-тестов.
5. Ошибки сборки отображаются в UI GitLab CI.
6. Логи сохраняются не менее 7 дней.
7. Инструкция по настройке CI описана в README проекта.

Technical Task / Engineering Task

Формат для сугубо технических задач (настройка, интеграция, миграции, рефакторинг и т.д.).

Шаблон

Что нужно сделать.
Зачем это нужно (ценность или необходимость).
Критерии приёмки.

Пример

Задача:
Реализовать драйвер для SPI флеш-памяти W25Q32.

Цель:
Обеспечить возможность записи и чтения из внешней памяти.

Критерии приёмки:

1. Драйвер инициализируется успешно.
2. Запись и чтение проходят тестирование.
3. В документацию драйвера добавлено описание по функциям записи и чтения из внешней памяти.

Не нашли подходящего шаблона?

Тогда примените свою фантазию, придумав свой шаблон или скомбинировав из приведённых выше. Главное, чтобы он помогал Вам и команде легче понимать поставленную задачу.

Сравните Story с домиком Адизеса

Домик Адизеса определяет 5 вопросов, на которые нужно дать ответы при постановке задач. Давайте разберём как они будут соответствовать Story.

1. Зачем? На это даётся ответ в части "Чтобы < получить результат / ценность >".
2. Что? Это часть "Я хочу < действие / функциональность >".
3. Как? Описывается в критериях приёмки.
4. Кто? В трекере задач всегда есть поле на кого задача назначена. Это и есть исполнитель и/или ответственный.
5. Когда? Тоже решается трекером задач через планирование на ближайший Sprint, выставлением даты начала и/или окончания.