Откройте бэклог почти любой команды — и вы найдёте один и тот же тихий бардак. Что-то заведено как эпик, потому что в тот момент это ощущалось большим. Что-то — как история, потому что кто-то прочитал, что истории — это «правильная» единица. Половина задач должна была бы стать подзадачами чего-то, а треть эпиков «в работе» уже четыре месяца, потому что никто не договорился, что вообще значит их завершить. Типы все на месте. Не хватает общего правила: к какому типу относится тот или иной кусок работы — поэтому каждый выбирает на глаз, и иерархия перестаёт что-либо значить.
В этом и настоящая цена размытой иерархии задач. Дело не в том, что неправильный ярлык оскорбляет методологию; дело в том, что отчёты, фильтры и планирование спринтов — все читают поле типа и тихо выдают мусор, когда оно непоследовательно. Эпик, который тайно является одной задачей, раздувает ваш объём работ. История, разбитая на восемь подзадач, которые никто не закрывает, тормозит вашу скорость. Структура должна была сделать работу читаемой, а вместо этого стала ещё одним поводом для споров.
Этот пост — рабочее определение каждого уровня: для чего он нужен, а не что говорит о нём фреймворк, — и простое правило о том, насколько глубоко вкладывать, прежде чем структура станет стоить больше, чем экономит.
Для чего на самом деле нужен каждый уровень
Забудьте про церемонии. Типы задач отвечают на один практический вопрос: на какой высоте мы говорим об этой работе? Каждый уровень — это разный масштаб, и весь смысл в том, чтобы вы могли перемещаться между ними, не теряя нить.
- Эпик — объём работы, слишком большой для одного спринта, с чётким результатом. «Редизайн оформления заказа», «Готовность к SOC 2», «Миграция биллинга со старого провайдера». Эпик — это обещание стейкхолдеру, а не задача. Вы должны уметь сказать одним предложением, когда он завершён, и это предложение должно быть о ценности для пользователя или бизнеса, а не о коде.
- История — срез эпика, который приносит что-то сам по себе, размером так, чтобы комфортно уместиться в спринт. Проверка — это независимость: могли бы вы это выпустить так, чтобы пользователь хоть немного это заметил? «Оформление заказа без регистрации» — это история. «Добавить столбец в таблицу заказов» — нет, это шаг, а не срез.
- Задача — конкретная единица исполнения, обычно один человек, обычно максимум несколько дней. Задачи не обязаны приносить видимую пользователю ценность; они про «как». Не каждой задаче нужен родитель-история — масса реальной работы (починка нестабильного теста, обновление зависимости) — это просто задача, и натягивание на неё фальшивого эпика — это свой собственный вид бардака.
- Подзадача — пункт чек-листа, которому по случаю нужен собственный владелец или статус. Используйте её, когда задача действительно разделяется между людьми или днями («бэкенд-эндпоинт» / «фронтенд-обвязка» / «миграция»). Если подзадача на самом деле просто пункт «сделать», чек-лист внутри задачи легче и не будет захламлять доску.
Та же идея в виде краткой шпаргалки:
| Тип | Отвечает на | Типичный срок жизни | Владелец |
|---|---|---|---|
| Эпик | Зачем мы это делаем? | Несколько спринтов | Лид / PM |
| История | Что получает пользователь? | Один спринт | Команда |
| Задача | Что нужно построить? | Дни | Один человек |
| Подзадача | Какая часть этой задачи? | От часов до дня | Один человек |
В Задачах и досках это реальные типы, которые вы назначаете — Баг, Задача, История, Эпик и Подзадача, — и каждая доска, фильтр и отчёт читают это поле. Именно поэтому важно выбирать правильный: это не украшение, а ключ, по которому сортирует всё остальное в инструменте.
Два режима отказа: всё-это-эпик и вложенность-до-бесконечности
Команды ломают свою иерархию в одном из двух противоположных направлений.
Первый — инфляция: каждый значимый кусок работы становится эпиком, потому что он ощущается важным. Теперь ваш список эпиков длиной в сорок пунктов, половина из них — на самом деле одиночные задачи, и единственное представление, которое должно показывать руководству форму квартала, невозможно прочитать. Эпики должны быть редкими. Если у вас открытых эпиков больше, чем инженеров, они перестали значить «большая тема» и стали значить «то, что мне небезразлично».
Второй — чрезмерная вложенность: эпик → история → задача → подзадача → под-подзадача по традиции, нужно это работе или нет. Однострочная правка текста не нуждается в трёх предках. Каждый добавленный слой — это слой, который кто-то должен создать, связать, обновить и закрыть; глубокие деревья выглядят организованно и ощущаются прогрессом, но в основном порождают рутину по поддержанию статусов и доску, где ничего толком не завершено, потому что какой-то листок на три уровня ниже всё ещё открыт.
Правило, которое хорошо держится: добавляйте уровень только тогда, когда работа действительно его охватывает.
- По умолчанию всё — Задача. Большая часть работы — это задача. Начинайте отсюда.
- Повышайте до Истории, когда задача явно приносит видимую пользователю ценность и вы хотите, чтобы она заслужила отдельную строку в спринте.
- Оборачивайте истории в Эпик только тогда, когда несколько из них разделяют один результат, о котором вы отчитываетесь кому-то за пределами команды.
- Добавляйте Подзадачи только тогда, когда одной задаче действительно нужно больше одного владельца или она растягивается больше чем на день.
Если вы не можете назвать то, что живёт на уровне, этого уровня для данного куска работы быть не должно. Два хорошо подобранных типа всегда лучше пяти рефлекторных.
Сделайте так, чтобы «готово» значило одно и то же на каждом уровне
Иерархии можно доверять ровно настолько, насколько ясно в ней определено «завершено», и каждому уровню нужно своё определение.
- Подзадача готова, когда её срез работает и смёржен.
- Задача готова, когда она построена, отревьюена и соответствует критериям приёмки.
- История готова, когда пользователь действительно мог бы ею воспользоваться — протестирована, выпущена, а не просто «код написан».
- Эпик готов, когда его результат реален и вы бы закрыли его в присутствии стейкхолдера, который его просил.
Ловушка — позволять родителю автозакрываться, когда закрываются дети, или, что хуже, называть эпик «готовым», потому что задачи готовы, тогда как результат так и не вышел. Держите определение родителя про результат, а не про сумму его частей. Именно здесь общее определение готовности окупает себя: когда все согласны, что значит закрыть историю, доска перестаёт врать вашему burndown.
Согласованные типы питают всё, что идёт дальше по цепочке. Чистые эпики делают отчёты и диаграммы кумулятивного потока читаемыми. Согласованные истории делают планирование спринта честным, потому что план за 30 минут работает, только когда единицы, которые вы перетаскиваете, действительно сопоставимые срезы, а не случайная смесь тем и пунктов «сделать». Настройте иерархию один раз правильно — и остальной инструментарий станет точнее бесплатно.
Пятиминутный аудит бэклога, который у вас уже есть
Вам не нужно реорганизовывать всё. Потратьте пять минут и почините те, что вводят в заблуждение:
- Найдите эпики без детей или с одним ребёнком. Это задачи в костюме. Понизьте их.
- Найдите истории старше двух спринтов. Либо это были эпики, либо они застряли — в любом случае разбейте или закройте.
- Найдите глубокие деревья подзадач, которые никто не закрывает. Схлопните мёртвые в чек-листы.
- Договоритесь об одном предложении на уровень и закрепите его там, где люди заводят задачи. Определение, живущее у вас в голове, — причина, по которой все заводят по-разному.
Сделайте это — и поле типа снова начнёт говорить правду, а ведь ради этого оно и существует.
Ваши типы задач полезны только тогда, когда все понимают под ними одно и то же. Задачи и доски дают вам Баг, Задачу, Историю, Эпик и Подзадачу на канбан- и скрам-досках с перетаскиванием, со свимлейнами, WIP-лимитами и быстрыми фильтрами, читающими иерархию, которой действительно можно доверять. Начните бесплатно и дайте своему бэклогу структуру, которая доходит до релиза.
