Что происходит с задачей после декомпозиции и добавления в бэклог до её попадания в спринт?

Жизненный цикл задачи после декомпозиции до включения в спринт

После того как крупная фича или требование декомпозируется (разбивается на меньшие части) и добавляется в бэклог продукта, задача проходит несколько критических этапов перед тем, как попасть в спринт.

1. Приоритизация в бэклоге

После добавления в бэклог задача не сразу готова к выполнению. Она должна быть приоритизирована относительно других задач:

Высокий приоритет   → Выше в бэклоге
Средний приоритет   → В середине
Низкий приоритет    → В конце

Приоритизация учитывает:

• Ценность для бизнеса — приносит ли задача доход или привлечет клиентов?
• Зависимости — от других задач или фич
• Риски — техдолг, критичные ошибки имеют высокий приоритет
• Усилия — сложность реализации

2. Уточнение и refinement

Этап, когда задача становится конкретнее. Product Owner и команда разработки проводят backlog refinement (грумминг бэклога):

# Пример трансформации задачи:

# ДО (расплывчато)
Title: "Улучшить производительность базы данных"
Description: "БД работает медленно"

# ПОСЛЕ (уточнено)
Title: "Добавить индексы на таблицу users по полям email и created_at"
Description: """
Фоновый анализ показал, что 70% медленных запросов — это SELECT по email
и фильтрация по created_at. Нужны индексы.

Acceptance Criteria:
1. Индекс на (email) — уникальный
2. Индекс на (created_at) — для сортировок
3. Тесты на производительность показывают улучшение ≥50%

Tasks:
- Написать миграцию
- Измерить EXPLAIN PLAN до и после
- Обновить документацию БД
"""

3. Оценка (estimation)

Команда оценивает объем работы. Обычно используется планирование покером (Planning Poker):

Задача → Оценка в story points (1, 2, 3, 5, 8, 13, 21...)
или в часах (4, 8, 16, 24...)

Что влияет на оценку:

• Сложность техничеcки
• Новизна (непредсказуемо новые технологии обычно оценивают выше)
• Зависимости (нужен ответ от другой команды?)
• Чья очередь брать задачу (разные члены команды работают с разной скоростью)

# Пример оценки
Task: "Добавить аутентификацию через OAuth"
Estimate: 13 story points
# Это означает: сложная, требует интеграции с внешним сервисом,
# рисков много, но команда видела подобное

4. Подготовка критериев приема (Definition of Done)

Для каждой задачи уточняются условия завершения:

# Definition of Done для задачи
1. Код написан и пройден code review
2. Тесты (unit + integration) покрывают ≥90% кода
3. Документация обновлена
4. No breaking changes для публичного API
5. Протестировано на staging
6. Performance не деградировал (если критично)
7. Security review пройден (для security-related tasks)

5. Готовность к спринту (Sprint Readiness)

Перед спринтом Product Owner и Scrum Master проверяют, что задачи действительно готовы:

✓ Задача приоритизирована
✓ Она уточнена и понятна команде
✓ Зависимости идентифицированы
✓ Оценена по времени/points
✓ Нет блокеров

Если задача не готова → остается в бэклоге на следующие спринты.

Состояния задачи в Jira/Linear

BACKLOG PRODUCT  →  READY FOR SPRINT  →  SPRINT BACKLOG  →  IN PROGRESS
   ↓                     ↓                     ↓                   ↓
Создана,         Приоритизирована,   Включена в        Разработка
разложена        уточнена,           спринт            началась
                 оценена

Практический пример полного цикла

День 1: Добавление в бэклог

• Product Manager создает задачу: "Реализовать экспорт отчетов в PDF"
• Статус: BACKLOG
• Приоритет: Низкий (интересно, но не срочно)

Дни 2-5: Уточнение

• Проведен backlog refinement сессия
• Определены: форматы, размеры файлов, интеграция с S3
• Написаны acceptance criteria
• Выявлены зависимости: нужна библиотека reportlab

День 6: Оценка

• Команда оценивает на планировании: 8 story points
• Понимают: нужна работа с PDF + дизайн шаблонов + тесты

День 7: Готовность

• Задача перемещена в "Ready for Sprint"
• На спринт-планировании (день 8) её берет разработчик
• Переходит в SPRINT BACKLOG

Почему это важно

Этот процесс предотвращает:

• Лишние переделки — уточнение в начале экономит время
• Surprises во время спринта — неожиданные сложности
• Перегруз спринта — команда берет посильное количество
• Неясные требования — разработчик точно знает, что делать

Резюме

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