Что происходит в конце Sprint

Что происходит в конце Sprint — завершающие активности и церемонии

Sprint — это итерационный цикл разработки (обычно 1-4 недели), и в конце каждого sprint'а происходит ряд важных активностей. За свой опыт работы в Agile командах я участвовал во множестве sprint'ов и хорошо знаю, что должно происходить в конце каждого.

1. Sprint Review (Demo / Show & Tell)

Цель: продемонстрировать результаты работы и получить обратную связь

Участники:

• Вся разработческая команда
• Product Owner
• Stakeholders (клиенты, менеджеры, аналитики)
• QA (важно!)

Что происходит:

• Демонстрация готовых features: разработчики показывают, что они сделали
• QA рассказывает о найденных багах: критические, высокие, которые не были закрыты
• Обсуждение результатов: что хорошо, что плохо, что изменить
• Feedback от stakeholders: они могут попросить изменения, уточнения
• Приёмка по Done Definition: проверка, что всё соответствует требованиям

Как QA участвует:

• Рассказываю о качестве сделанной работы
• Показываю найденные баги и их severity
• Объясняю, почему некоторые feature'ы не готовы
• Даю рекомендации по улучшению процесса тестирования

Пример:

Разработчик показывает: "Мы сделали новый экран профиля пользователя"
QA говорит: "Я протестировал это:
- Основной flow работает
- Нашёл 2 bug'а: кнопка сохранения не работает в Safari, и есть overlap текста на мобильных
- Рекомендую закрыть эти баги перед релизом"
PO принимает решение: "Закрывай баги, будем릴izировать это на следующей неделе"

2. Sprint Retrospective (Retro)

Цель: обсудить процесс работы и найти улучшения

Участники:

• Разработческая команда
• Scrum Master
• QA

Что происходит:

• What went well? (Что хорошо?):

  • Быстрая коммуникация
  • Хороший code review
  • Качественное тестирование

• What went wrong? (Что плохо?):

  • Слишком много bug'ов в конце sprint'а
  • Медленная локальная разработка
  • Недостаточное тестирование перед созданием PR

• What should we improve? (Что улучшить?):

  • Добавить pre-commit hook'и для проверки кода
  • Требовать, чтобы разработчик сам протестировал перед PR
  • Более частый review'нов

Как QA участвует:

• Даю обратную связь о качестве кода (сколько bug'ов, в какие моменты найдены)
• Предлагаю улучшения в процесс тестирования
• Рассказываю о bottleneck'ах в моей работе
• Прошу help от team'а для улучшения покрытия тестами

Пример:

QA говорит: "На этом sprint'е я нашёл 15 bug'ов, 10 из них были очень очевидные.
 Я рекомендую, чтобы разработчик делал базовый smoke test перед тем как создавать PR.
 Это сэкономит мне время, и мы быстрее заканчивать sprint'ы."

Теam принимает: "Хорошая идея, добавим в наш checklist для PR'ов"

3. Backlog Refinement (подготовка к следующему sprint'у)

Цель: подготовить задачи для следующего sprint'а

Участники:

• Product Owner
• Разработчики
• QA (очень важно!)

Что происходит:

• Обсуждение новых требований: что нужно разработать в следующем sprint'е
• Оценка задач: сколько story point'ов займёт каждая задача
• Уточнение acceptance criteria: что считается готовым (Done Definition)
• Выявление risks: какие могут быть проблемы, что нужно тестировать

Как QA участвует:

• Оцениваю тестовую часть: сколько времени потребуется на тестирование
• Предлагаю test plan: как я буду тестировать эту feature
• Выявляю risks: какие сценарии нужно протестировать, какие могут быть проблемы
• Уточняю acceptance criteria: что должно быть протестировано, чтобы feature считалась готовой

Пример:

PO: "Нужно сделать функцию импорта товаров из CSV"
QA спрашивает:
- Какие форматы CSV файлов нужно поддерживать?
- Что делать с некорректными строками в файле?
- Какой максимальный размер файла?
- Нужно ли валидировать данные перед импортом?

ПO отвечает, и я добавляю в acceptance criteria тест-кейсы:
- Импорт валидного файла
- Импорт с ошибочными строками
- Импорт очень большого файла (performance)
- Импорт с невалидными данными

Таким образом мы определяем, что считается "готово"

4. Sprint Planning (планирование нового sprint'а)

Цель: определить, какие задачи будут выполнены в следующем sprint'е

Участники:

• Вся команда
• Product Owner

Что происходит:

• Выбор задач из backlog'а: какие задачи возьмём в sprint
• Разбиение больших задач: на sub-tasks
• Распределение ответственности: кто за что отвечает
• Уточнение деталей: что именно нужно сделать
• Commitment: команда обещает выполнить свой commitment

Как QA участвует:

• Присутствую на планировании: чтобы понять, что будет разработано
• Планирую тестирование: какие тесты нужно написать/обновить
• Предлагаю тестовые сценарии: как я буду тестировать новые feature'ы
• Убеждаюсь что time estimate реалистичен: иногда разработчики забывают про тестирование

5. Burn-down chart review и metrics

Что это:

• Визуализация прогресса sprint'а
• Количество оставшихся задач vs времени

Как QA участвует:

• Отслеживаю, сколько задач остаётся тестировать: иногда QA может быть bottleneck
• Анализирую, когда bug'ы были найдены: в начале, в конце sprint'а
• Предлагаю улучшения: может быть, нужно тестировать раньше

Пример проблемы:

Burn-down chart показывает, что на день 5 sprint'а все разработчики завершили свои задачи,
но QA всё ещё тестирует. На день 10 (последний день sprint'а) остаётся много bug'ов.
Это значит, что нужно начать тестирование раньше, параллельно разработке.

6. Release / Deployment (если это последний sprint перед релизом)

Что происходит:

• Final QA check: последняя проверка перед production
• Smoke testing: проверка основного функционала
• Deployment: выпуск в production
• Post-deployment testing: проверка в production среде

Роль QA:

• Smoke test в staging: убеждаюсь, что всё работает
• Отслеживаю release: проверяю, что всё прошло гладко
• Готовлю release notes: документирую, что изменилось
• Post-release monitoring: следу за тем, чтобы не было новых проблем

Типичный день конца Sprint'а (пример)

10:00 - Sprint Review (1 час)
  - Разработчик показывает новый feature
  - QA показывает найденные баги
  - PO принимает решение, что ready для production

11:30 - Break

12:00 - Retro (45 минут)
  - Обсуждение процесса
  - Что улучшить

13:00 - Lunch

14:00 - Backlog Refinement (1 час)
  - Подготовка задач для следующего sprint'а
  - QA выявляет тестовые риски

15:30 - Sprint Planning (1 час)
  - Выбор задач для нового sprint'а
  - QA планирует тестирование

16:30 - Завершение
  - Первые задачи нового sprint'а начинают разрабатываться

Ключевые метрики, которые отслеживаются в конце sprint'а

Для QA:

• Bug escape rate: сколько bug'ов прошло в production
• Bug detection rate: сколько bug'ов найдено QA vs пользователями
• Time to test: сколько времени требуется на тестирование
• Test coverage: процент покрытия функциональности тестами
• Defect density: количество bug'ов на 1000 строк кода

Заключение

Конец sprint'а — это не просто завершение работы, это важная точка для:

• Оценки качества: Sprint Review показывает, готов ли продукт
• Улучшения процесса: Retro помогает найти слабые места
• Планирования будущего: Refinement и Planning подготавливают следующий sprint

Для QA инженера это особенно важно, потому что:

• Нужно убедиться, что качество достаточное
• Нужно планировать тестирование для следующего sprint'а
• Нужно улучшать процесс на основе опыта

В успешной команде все эти активности проходят гладко, и team выходит из sprint'а с новыми идеями для улучшения качества и процесса.