Урок 26 — Scrum и Kanban: методологии разработки для QA

Люди важнее процессов
Работающий продукт важнее документации
Сотрудничество с клиентом важнее контракта
Реагирование на изменения важнее следования плану

SPRINT (1–2 недели)
├── Sprint Planning (планирование, ~2–4 часа)
│   └── Выбираем задачи из Product Backlog в Sprint Backlog
├── Daily Scrum (ежедневный стендап, 15 минут)
│   ├── Что сделал вчера?
│   ├── Что сделаю сегодня?
│   └── Есть ли препятствия?
├── Sprint Review (демо, ~1–2 часа)
│   └── Показываем stakeholders, что сделали
└── Sprint Retrospective (ретро, ~1–2 часа)
    ├── Что шло хорошо?
    ├── Что шло плохо?
    └── Что улучшим в следующем спринте?

┌──────────┬──────────┬──────────┬──────────┬──────────┐
│ BACKLOG  │  TO DO   │   WIP    │  REVIEW  │   DONE   │
├──────────┼──────────┼──────────┼──────────┼──────────┤
│ Story 5  │ Story 1  │ Story 2  │ Story 3  │ Story 4  │
│ Story 6  │ Task 1.1 │ Task 2.1 │          │          │
│ Story 7  │ Task 1.2 │          │          │          │
│ Bug #12  │          │ Bug #10  │ Bug #11  │ Bug #9   │
└──────────┴──────────┴──────────┴──────────┴──────────┘

Статусы задачи:
Backlog → To Do → In Progress (WIP) → Review/Testing → Done

Числа Фибоначчи: 1, 2, 3, 5, 8, 13, 21...
Простая задача: 1–2 SP
Средняя задача: 3–5 SP
Сложная задача: 8–13 SP
Слишком большая: нужно разбить

1. PO описывает задачу
2. Каждый участник тайно выбирает карточку (1, 2, 3, 5, 8...)
3. Все открывают карточки одновременно
4. Обсуждаем расхождения
5. Голосуем снова до консенсуса

Sprint 1: завершено 30 SP
Sprint 2: завершено 28 SP
Sprint 3: завершено 32 SP
Velocity = ~30 SP/sprint

Планируем следующий спринт: берём задачи на ~30 SP

Задача считается DONE, если:
□ Код написан и прошёл code review
□ Unit тесты написаны (coverage > 80%)
□ QA выполнил ручное тестирование по тест-кейсам
□ Все найденные баги исправлены или отложены с обоснованием
□ Автоматические тесты написаны (если применимо)
□ Smoke тесты прошли на Staging
□ Документация обновлена (если нужна)
□ Product Owner принял задачу

Без DoD:
Dev: «Я закончил» (имеет в виду «код написан»)
QA:  «Ещё не тестировал»
PO:  «На демо не готово»

С DoD:
Все понимают, что «Done» = весь чеклист выполнен
QA имеет право голоса в том, что входит в DoD

1. Визуализируй работу → доска
2. Ограничь Work In Progress (WIP) → не берём больше, чем можем сделать
3. Управляй потоком → минимизируй время выполнения задачи
4. Сделай правила явными → у каждой колонки чёткий критерий
5. Улучшай совместно и непрерывно

┌──────────┬──────────────┬──────────────┬──────────┐
│ BACKLOG  │  IN PROGRESS │    REVIEW    │   DONE   │
│          │   (WIP: 3)   │   (WIP: 2)   │          │
├──────────┼──────────────┼──────────────┼──────────┤
│ Task 5   │ Task 1       │ Task 3       │ Task 6   │
│ Task 7   │ Task 2       │ Task 4       │ Task 8   │
│ Task 9   │ Task X       │              │          │
│ Task 10  │              │              │          │
└──────────┴──────────────┴──────────────┴──────────┘
            ↑                ↑
         Лимит = 3        Лимит = 2
         (нельзя брать     (нельзя брать
         4-ю задачу)       3-ю задачу)

Если WIP = 3, то в колонке "In Progress" максимум 3 задачи.
Нет свободного слота → нельзя начать новую задачу.

Зачем: многозадачность снижает эффективность.
Лучше закончить 3 задачи, чем начать 10.

QA участвует в оценке задач:
- «Эта история слишком большая для одного спринта — её нужно разбить»
- «На тестирование этого функционала нужно 3 дня — учтите при планировании»
- «У этой задачи нет критериев приёмки — нельзя начать тестирование»

QA отвечает:
- «Вчера протестировал AUTH-05 и AUTH-06, нашёл баг BUG-342»
- «Сегодня тестирую AUTH-07, жду исправления BUG-340 от Димы»
- «Блокер: нет доступа к тестовой среде (второй день)»

QA участвует в демо:
- Показывает, какие сценарии были проверены
- Демонстрирует найденные и исправленные баги

QA поднимает вопросы:
- «Задачи попадали в Review без покрытия unit-тестами — это нарушает DoD»
- «Нам нужно больше времени на тестирование — сейчас QA — узкое горлышко»
- «Предлагаю: QA вовлекается в разработку раньше (Shift Left)»

ТРАДИЦИОННО (Shift Right):
Требования → Дизайн → Разработка → Тестирование → Релиз
                                        ↑
                                   QA входит здесь

SHIFT LEFT:
Требования → Дизайн → Разработка → Тестирование → Релиз
     ↑            ↑        ↑
  QA участвует с самого начала

✓ QA проверяет требования до начала разработки («А что если пользователь введёт пустую строку?»)
✓ Баги находятся на этапе дизайна → их дешевле исправить
✓ QA пишет тест-кейсы параллельно с разработкой (не после)
✓ Разработчики пишут unit-тесты с осознанием QA-перспективы

Burndown Chart: сколько SP осталось выполнить до конца спринта
Bug Rate: количество багов, найденных на разных стадиях
Test Coverage: % функциональности, покрытой тестами
Defect Leakage: баги, найденные в production после релиза

Lead Time: время от появления задачи до её завершения
Cycle Time: время от начала работы до завершения
Throughput: количество задач, завершённых за единицу времени
WIP: текущее количество задач в работе

SCRUM
├── Спринты: 1–2 недели
├── Роли: PO + Scrum Master + Team
├── Церемонии: Planning → Daily → Review → Retro
├── Артефакты: Product Backlog + Sprint Backlog + Increment
└── QA: участвует во всех церемониях, поднимает DoD

KANBAN
├── Непрерывный поток без спринтов
├── WIP Limit: ограничивает количество задач в работе
├── Доска: постоянная, задачи не сбрасываются
└── QA: мониторит cycle time, предотвращает накопление задач

ОБЩЕЕ:
✓ Оба — Agile подходы
✓ Оба используют доску для визуализации
✓ QA — полноправный член команды, а не «приёмщик работы в конце»
✓ Shift Left: вовлекай QA с самого начала, а не в конце