Что такое ретроспектива?

Что такое ретроспектива?

В контексте гибких методологий разработки (Agile), особенно Scrum и Kanban, ретроспектива (Retrospective) — это регулярная, структурированная встреча команды, целью которой является анализ последнего завершённого рабочего периода (спринта, итерации) и выработка конкретных улучшений для следующего. Это не просто «разбор полётов» или собрание для жалоб. Это ключевое инспекционно-адаптационное мероприятие, основанное на трёх главных вопросах:

1. Что прошло хорошо? (Что следует продолжать делать?)
2. Что можно улучшить? (Какие проблемы или помехи возникли?)
3. Какие конкретные шаги мы предпримём? (Создание плана действий по улучшению — Action Items)

Основная философия ретроспективы заключается в непрерывном совершенствовании (Continuous Improvement, Kaizen) процессов, инструментов и взаимодействий внутри команды.

Цели и ценности ретроспективы

• Безопасная среда: Создание пространства, где каждый член команды (разработчики, тестировщики, аналитики, скрам- мастер, продакт— оунер) может открыто высказать своё мнение без страха осуждения.
• Фокус на процесс, а не на людей: Анализ того, как команда работает, а не поиск виноватых.
• Генерация инсайтов: Выявление коренных причин (Root Causes) проблем, а не просто симптомов.
• Конкретные обязательства: Превращение идей в измеримые и назначаемые элементы плана действий (Action Items) с дедлайнами и ответственными.
• Усиление команды: Совместное решение проблем повышает доверие, взаимопонимание и чувство собственности (Ownership) за процесс.

Типичная структура проведения ретроспективы

Ретроспектива длится обычно 1–3 часа (для двухнедельного спринта) и часто проводится по определённому формату (формату).

Классический формат «Что хорошо / Что можно улучшить / Action Items»:

### Ретроспектива спринта №10 (01.04 — 12.04)

**Что прошло хорошо:**
*   Успешно внедрили автоматизацию регресса для модуля оплаты.
*   Отличная коммуникация с продакт-оунером по уточнению требований.
*   Все критические баги были найдены и зафиксированы на этапе тестирования.

**Что можно улучшить:**
*   Частые пересборки на тестовом стенде ломали процесс тестирования.
*   Нехватка данных в тестовой БД для проверки edge-кейсов.
*   Задержки в ревью пул-реквестов от старших разработчиков.

**Action Items (план улучшений):**
1.  **Задача:** Настроить стабильный тестовый стенд с откатом данных.
    *   **Ответственный:** DevOps-инженер (Василий)
    *   **Срок:** К середине следующего спринта.
2.  **Задача:** Создать и поддерживать скрипт генерации тестовых данных.
    *   **Ответственный:** QA Lead (Анна)
    *   **Срок:** Взять в бэклог следующего спринта.
3.  **Задача:** Обсудить и зафиксировать SLA на ревью кода (макс. 24 часа).
    *   **Ответственный:** Scrum-мастер (Дмитрий)
    *   **Срок:** Провести обсуждение на следующем планировании.

Популярные креативные форматы для разнообразия:

• «Море радости и море грусти» (Sailboat / Speedboat): Команда определяет, что было «ветром в паруса» (двигало вперёд), а что — «якорями» (тормозило).
• «Старт / Стоп / Продолжить» (Start / Stop / Continue): Более директивный формат, фокусирующийся на действиях.
• «4L» (Liked, Learned, Lacked, Longed for): Структурированный анализ эмоций и ожиданий.
• «Mad, Sad, Glad»: Быстрая ретроспектива, оценивающая эмоциональное состояние команды.

Роль QA Engineer на ретроспективе

Для инженера по обеспечению качества ретроспектива — это критически важная площадка для влияния на процесс. Вот ключевые точки приложения сил:

• Поднимать проблемы качества: Донести до команды, как нестабильная среда, неполные требования или поздние сборки влияют на риск выпуска и качество продукта.
• Предлагать улучшения: Выступать с инициативами по внедрению новых инструментов тестирования, улучшению тестовых данных, оптимизации процесса приёма-передачи функциональности.
• Анализировать баги: Обсудить, есть ли повторяющиеся паттерны в дефектах (например, ошибки в одном модуле), и что в процессе можно изменить, чтобы ловить их раньше (сдвиг качества влево — Shift Left).
• Отмечать успехи: Подчеркнуть, что сработало хорошо в тестовой деятельности (например, новые тест

• кейсы помогли найти серьёзный дефект), чтобы закрепить эту практику.

• Взять ответственность: Добровольно становиться ответственным за Action Items, связанные с качеством (настройка CI/CD пайплайна для тестов, написание скриптов и т.д.).

Заключение

Ретроспектива — это «сердце» гибкого цикла улучшений. Без эффективных ретроспектив команда рискует скатиться в рутину, повторяя одни и те же ошибки и упуская возможности для роста. Успешная ретроспектива заканчивается не просто списком «что было плохо», а конкретным, осязаемым планом, который делает следующий рабочий цикл немного более эффективным, предсказуемым и комфортным для всей команды. Для QA это прямой инструмент для проактивного управления качеством на всех этапах жизненного цикла разработки ПО.