Вы читаете перевод статьи “Theme, Epic, Story, Task”. Над переводом работали: Ольга Жолудова и Ринат Шайхутдинов.
В чем разница между эпиком и темой? Что такое история? Можно ли протестировать задачу в отрыве от других задач? Можно ли проработать эпик за спринт?
На открытой сессии лондонской дискуссионной группы по Agile (LADG) мы обсуждали базовые термины, чтобы убедиться, что все понимают их одинаково. Мы почти пришли к единому мнение, а еще в процессе обсуждения возникло несколько интересных идей. Вот небольшое резюме тех выводов, к которым мы пришли (с примерами):
Истории
(aka задачи из продуктового бэклога, единицы работы)
История — это отдельная функция или требование, которое выдвигает бизнес. Иногда историю можно пустить в продакшн за один спринт. История должна быть составлена по принципу INVEST — расшифровка в предыдущем посте:
Хорошая пользовательская история соответствовать следующим критериям:
I — независимая (independent),
N — обсуждаемая (negotiable),
V — несет ценность для бизнеса (business value),
E — достаточно информации для оценки(estimate),
S — компактный размер (size),
T — трестируемая (testable)
Но мы также пришли к выводу, что история — это только начальная точка для обсуждения; в истории представлена далеко не вся информация, которая может потребоваться команде для завершения работы.
Истории часто пишут в конкретном формате:
- Как [конечный пользователь требуемой функции]
- я хочу, чтобы… [реальное действие, которое пользователь сможет выполнять, когда мы запустим фичу],
- чтобы… [почему им нужна эта функция / какую ценность несет эта функция]
Хотя этот формат уже прижился и стал нормой, это не единственный возможный подход. Одна из команд подчеркнула, что они выносят ценностную часть (“чтобы [….]”) вперед. Я думаю, это толковая идея, потому что мы всегда должны руководствоваться четкой бизнес-причиной: поэтому, мне кажется, разумно начинать историю с ценности.
Пример истории: “Как клиент, я хочу иметь возможность сохранять товар в список желаний, чтобы можно было снова посмотреть его позже”.
Эпики
Эпик — это большая история. Это требование, слишком большое чтобы реализовать его за один спринт. Эпики нужно разбивать на более мелкие работы (истории). Благодаря этому эпики вписываются в принципы agile (регулярная отгрузка софта, готового к выпуску, постоянная готовность к запуску на ранних этапах, регулярная ретроспектива).
Пример эпика: “Как клиент, я хочу иметь возможность добавить товары в список желаний, чтобы можно было вернуться и купить их позже”.
Темы
Коллекция историй по категориям. Корзина или ведро историй. По своей сути, эпик может также быть и темой.
Интересная фишка: одна из продуктовых команд решила, что темы обязательно должны соотноситься с бизнес-целями. Мое мнение: цель должна быть всегда (иначе зачем вы это делаете?!)
Пример темы: “Список желаний”
Задачи
Элементы истории. Ступеньки по которым история переходит в состояние “Готово”. Задачи часто составляются по модели SMART:
S — конкретные (specific),
M — измеримые (measurable),
A — достижимые (achievable),
R— значимые (relevant),
T — с четкими временными рамками (time-boxed) — хотя по поводу последнего ведутся оживленные споры.
Многие команды не разбивают истории на задачи. Я заметил, что разбивка историй на задачи стимулирует команды разбивать работы по горизонтали, в то время как мы пытаемся разбивать по вертикали.
Пример задачи: “Добавить кнопку “В список желаний” на каждую продуктовую страницу”.