💡 Методология — это способ, по которому команда организует работу над продуктом.

Разные компании используют разные методы. QA-инженер должен понимать:

• как устроена команда,
• как двигаются задачи,
• когда и как тестируется продукт,
• в каком порядке происходят этапы,
• какие ритуалы и правила есть в процессе.

Ниже — самые популярные модели разработки, встречающиеся в 99% компаний.

🟦 1. Waterfall (Водопад, каскадная модель)

💧 Самая старая и самая строгая модель.

✔ Иногда встречается

🧠 Суть

Работа идёт строго по этапам сверху вниз:

1️⃣ Сначала анализ требований
2️⃣ Потом дизайн
3️⃣ Потом разработка
4️⃣ Потом тестирование
5️⃣ Потом релиз

Буквально как было описано в SDLC.

Вернуться назад нельзя ❌

Это как строительство дома:
сначала фундамент → стены → крыша → отделка.
Если на этапе крыши выяснилось, что хотели другую планировку — поздно 🙂

✔ Плюсы Waterfall

• чёткий порядок
• легко управлять сроками
• легко считать стоимость
• Исчерпывающая документация

❌ Минусы Waterfall

• почти невозможно изменить требования
• ошибки во время анализа всплывают только в конце
• тестирование начинается слишком поздно
• исправления очень дорогие
• Нелтзя вернуться к предыдущему этапу или перескочить на следующий раньше

📍 Когда используется

• требования известны заранее
• проект небольшой
• проект на неконкурентном рынке (госка и всё, что с ней связано)
• изменений не будет
• заказчик хочет фиксированный бюджет

🟦 Agile (Гибкие методологии)

🌿 Аджайл — это не модель, а скорее философия.

Agile — это набор принципов:

• люди важнее процессов
• изменения — норма
• работающее ПО важнее документации
• сотрудничество с заказчиком — постоянное
• продукт развивается итерациями

Agile — это как образ мышления:
гибко, по чуть-чуть, маленькими шагами, быстро и постоянно улучшая продукт.

Scrum и Kanban — это методологии, которые следуют философии Agile. Им мы уделим основное внимание

🧩 Kanban: что это и как работает

🧩 1. Что такое Kanban

Kanban — это метод управления задачами, который помогает команде видеть весь процесс работы на одной доске и выполнять задачи плавно, без перегрузок.

✔ ✔ Встречается повсеместно

💡 Представь, что это конвейер — задача проходит путь от начала до завершения.

Основной принцип Kanban:

👉 не бежать быстрее, а убрать пробки, где процесс застревает.

Здесь важен непрерывный поток задач.

📋 2. Главная идея Kanban

🟦 Визуализация

Всё должно быть видно на доске.

🟧 Ограничение незавершённых задач

Не берём новые задачи, пока не закончили текущие.

🟩 Оптимизация потока

Постоянно улучшать процесс, чтобы задачи двигались быстрее.

🧱 3. Kanban-доска

Это главный инструмент Kanban.

Она состоит из колонок, каждая из которых — этап работы.

Простейший вариант:

По сути, Kaiten, в котором организовано наше учебное пространство — это Kanban-доска.

🎚 4. WIP-лимит — главное правило Kanban

WIP = Work In Progress
👉 это ограничение количества задач, которые находятся в работе.

Например:

• В колонке «В разработке» — максимум 3 задачи
• В «Тестировании» — максимум 2 задачи

Зачем это нужно:

• команда не перегружается
• каждая задача доводится до конца
• меньше переключений
• больше фокуса
• меньше ошибок

💡 Это как правило: «возьми только одну тарелку еды — доедай, а не набирай пять сразу».

🔄 5. Как работает Kanban (полный цикл)

1️⃣ Задача появляется → попадает в колонку To Do
2️⃣ Исполнитель берёт задачу в работу → переносит в In Progress
3️⃣ Завершает → передаёт на тестирование
4️⃣ Тестировщик проверяет → «Ready for Release»
5️⃣ После релиза → «Done»

Каждое движение задач отслеживается визуально.

🧪 6. Ритуалы Kanban (каденции)

Kanban более гибкий, чем Scrum: обязательных встреч меньше.
Но есть 7 типов встреч, которые помогают улучшать поток.

📍Не запоминай их, просто ознакомься

🟦 1. Daily Meeting — Ежедневная встреча

Кто над чем работает, что блокирует, нужна ли помощь.

🟧 2. Replenishment Meeting — Пополнение задач

Решают, какие новые задачи можно добавить, а какие — лучше подождут.

🟩 3. Delivery Planning — Планирование поставки

Команда оценивает, готова ли партия задач к выпуску.

🟨 4. Service Delivery Review

Обсуждают качество выполнения задач и сроки.

🟪 5. Operations Review

Менеджеры обсуждают, как работают команды и где улучшить.

🟫 6. Risk Review

Команда анализирует ошибки и риски.

🟫 7. Strategy Review

Обсуждаются долгосрочные цели и направление продукта.

💡 В реальности компании часто объединяют эти встречи, чтобы не тратить много времени.

📏 7. Метрики Kanban

Метрики нужны, чтобы понимать, насколько эффективно движется поток задач. 📍Не запоминай, просто прочитай

⏱ 1. Lead Time или Time to Market, TTM — Время поставки

Сколько времени проходит от появления задачи до готовности.

🚧 2. Cycle Time — Время выполнения

Сколько времени задача находится в работе.

📦 3. Throughput — Пропускная способность

Сколько задач команда делает за неделю/месяц.

📊 4. Tasks in Progress — Количество задач в работе

Если их слишком много — команда перегружена.

💸 5. Cost of Delay — Цена задержки

Какие потери возникают, если задача задерживается.

8. Преимущества Kanban

• 🚀 быстрее выводит задачи в продакшен
• 🔄 легко адаптируется под изменения
• 🔍 даёт полную прозрачность
• ❤️ снижает стресс (нет гонки за спринтом)
• 🎛 улучшает управляемость процессов
• 💡 помогает улучшать прогнозы сроков

⚠️ 9. Недостатки Kanban

• ❌ сложно оценивать сроки заранее
• ❌ нет чётких ролей — нужна дисциплина
• ❌ можно легко нарушить баланс задач
• ❌ неопытным командам тяжело ограничивать WIP

Канбан может использоваться не только как отдельная методология, но и как инструмент, который используется в других методологиях.

Например, канбан можно встретить даже в Waterfall разработке, и тем более вы всегда встретите канбан в SCRUM'е.

SCRUM: что это, как работает и зачем нужен QA

Scrum — это один из самых популярных способов организации работы в IT-командах.
90% QA-инженеров работают именно в Scrum, поэтому понимание этого подхода — обязательный навык.

🧩 1. Что такое Scrum

Scrum (скрам) — это методология, в которой команда делит работу на короткие отрезки — спринты (обычно 1–2 недели).

✔ ✔ Встречается повсеместно

Каждый спринт команда делает небольшой, но готовый кусочек продукта.

💡 Представь сериал, который выходит по сериям.
Каждая серия — законченная часть истории.
Также и в Scrum — каждая итерация создаёт мини-продукт.

Главные черты Scrum:

• 🟢 короткие итерации (спринты)
• 🔄 постоянные улучшения
• 🧑‍🤝‍🧑 самоуправляемая команда
• 🎯 работа по приоритетам
• 💬 много общения и прозрачности

🧱 2. Роли в Scrum

Каждая роль отвечает за свой кусок ответственности.
Ролей только три — и это делает систему простой.

👨‍🎨 1. Product Owner (PO) — Владелец продукта

Кто это: человек, который понимает, что нужно бизнесу и пользователю.

📌 Что он делает:

• собирает требования
• выставляет приоритеты
• управляет бэклогом продукта
• принимает готовую работу от команды
• отвечает за то, что мы делаем, и зачем

💡 Пример:
Если команда — ресторан, то PO — это человек, который решает, какое меню нужно клиентам.

На практике роль владельца продукта часто выполняет ПМ (проджект менеджер)

🧑‍🏫 2. Scrum Master

Кто это: человек, который помогает команде правильно использовать Scrum.

📌 Что делает:

• убирает препятствия (блокеры)
• организует встречи
• следит, чтобы команда соблюдала Scrum
• улучшает процессы
• помогает команде работать эффективнее

💡На западе скрам-мастер — это чаще отдельный человек. Но на территории СНГ эта роль не прижилась, так как это человек, который "нифига не делает и деньги получает". Поэтому чаще всего роль скрам-мастера у нас достаётся тому же ПМу или тимлиду.

🧑‍💻 3. Development Team — Команда разработки

Сюда входят:

• разработчики
• тестировщики (QA)
• дизайнеры
• аналитики (иногда)

📌 Что делает команда:

• берет задачи в спринт
• оценивает работу
• выполняет задачи
• сама решает, как именно работать
• несёт ответственность за результат

💡 В Scrum все равны и самоорганизуются.
Нет начальников, нет приказов сверху.

🧺 3. Артефакты Scrum

Это ключевые элементы, которые помогают команде понимать, что делать и куда двигаться.

📌 1. Product Backlog — Бэклог продукта

Это список всех задач и требований, которые нужно реализовать.

Пример:

• регистрация пользователя
• страница корзины
• поиск товаров
• фильтры

Бэклог всегда живой: задачи добавляются, меняются, удаляются.

📌 2. Sprint Backlog — Бэклог спринта

Это список задач, которые команда берёт на ближайшие 1–2 недели.

💡 Эти задачи уже зафиксированы — менять их нельзя.

📌 3. Increment — Инкремент

Это результат работы за спринт: маленький, но готовый кусочек продукта.

Например:

✔ работает форма регистрации
✔ можно добавить товар в корзину
✔ реализована сортировка

Инкремент должен быть:

• рабочим
• протестированным
• потенциально готовым к релизу

🔄 4. Основные ритуалы Scrum (мероприятия)

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

🗂 1. Sprint Planning — Планирование спринта

⏱ 1–2 часа

Команда решает:

• какие задачи берём на спринт
• что является целью спринта
• как будем выполнять задачи

Product Owner говорит:
👉 «Вот приоритеты. Самое важное — вот это.»

Команда отвечает:
👉 «Мы можем взять вот эти задачи. Этого — хватит на спринт.»

📅 2. Daily Standup — Ежедневный стендап

⏱ 15-30 минут, каждый день

Каждый участник отвечает на 3 вопроса:

1️⃣ Что сделал вчера?
2️⃣ Что буду делать сегодня?
3️⃣ Есть ли блокеры?

💡 Это не отчёт перед начальником.
Это синхронизация команды.

🧪 3. Sprint Review — Обзор спринта

Команда показывает, что сделано.
Владелец продукта принимает или отклоняет работу.

💡 Это не экзамен, а демонстрация результата.

📈 4. Sprint Retrospective — Ретроспектива

Команда обсуждает:

• что получилось хорошо
• что мешало
• что нужно улучшить

Цель — не ругать, а улучшать процесс.

🏃 5. Спринт

Это сама итерация — обычно 1–2 недели.
Во время спринта команда:

• делает задачи
• тестирует
• документирует
• готовит инкремент

🧠 5. Принципы Scrum, которые должен понимать QA

📌 Принцип 1: маленькие шаги

Не всё и сразу → выпускаем кусками.

📌 Принцип 2: постоянная обратная связь

Чаще показываем продукт — меньше ошибок.

📌 Принцип 3: прозрачность

Доска задач открыта для всех.

📌 Принцип 4: саморганизация

Каждый отвечает за результат.

📌 Принцип 5: гибкость

Изменения — нормальная часть работы.

🔍 6. Почему Scrum важен для QA

QA играет ключевую роль:

• проверяет инкременты
• уточняет требования у PO
• участвует в планировании
• оценивает задачи
• помогает команде заранее находить риски
• следит за качеством всего спринта

В Scrum QA — не «тот, кто проверяет».
Он — участник создания продукта.

🎯 7. Преимущества Scrum

✔ Для бизнеса:

• быстрее выводит продукт на рынок
• даёт гибкость
• уменьшает риски

✔ Для команды:

• прозрачность
• понятные процессы
• быстрые результаты

✔ Для QA:

• стабильная загрузка
• меньше «горящих дедлайнов»
• возможность влиять на продукт

⚠️ 8. Недостатки Scrum

• нужны дисциплина и самоорганизация
• требуется активное участие заказчика
• любые изменения могут ломать сроки

💡 Главная разница:
👉 Scrum работает итерациями
👉 Kanban работает потоком

Мы разобрали 3 самых популярных методологии. Помимо них есть и другие, лучше знать их названия и примерный смысл:

🟩 V-Model (V-модель)

📐 Улучшенная версия Водопада, но ориентирована на тестирование.

🧠 Суть

Каждому этапу разработки соответствует свой этап тестирования.

Например:

• анализ требований ↔ тестирование требований
• дизайн ↔ тестирование архитектуры
• разработка ↔ модульное тестирование

Получается форма буквы «V».

✔ Плюсы

• тестирование включено с самого начала
• много типов проверки
• подходит для систем, которые не должны ломаться (медицина, авто, банки)

❌ Минусы

• мало гибкости
• сложно менять требования
• нужна сильная QA-команда

📍 Где используется

• медицина
• авиаперевозки
• автомобильные системы
• сложные корпоративные системы

🟨 Incremental Model (Инкрементная модель)

🧱 Строим продукт по кусочкам.

🧠 Суть

Продукт делится на части («инкременты»).
Каждая часть проходит полный цикл разработки:

Анализ → Дизайн → Код → Тест → Релиз

И только после этого команда берёт следующую часть.

Это как собирать конструктор LEGO:
сначала блок 1, затем блок 2 и т.д., пока не получится цельный продукт.

✔ Плюсы

• можно выпускать продукт частями
• первые функции появляются быстро
• легко добавлять улучшения

❌ Минусы

• сложнее контролировать архитектуру
• нужно заранее понимать структуру продукта

📍 Где используется

• приложения, которые нужно выпускать быстро
• проекты с понятной базовой логикой
• когда важны регулярные релизы

🟥 RAD Model (Rapid Application Development — быстрая разработка)

⚡ Очень быстрый метод для больших команд профессионалов.

🧠 Суть

Разработка идёт параллельно большими блоками.
Каждый блок — как маленький отдельный проект.

Команды работают одновременно, быстро создают прототипы, показывают их заказчику, получают обратную связь и дорабатывают.

✔ Плюсы

• очень быстро
• много визуальных прототипов
• заказчик видит результат почти сразу

❌ Минусы

• нужны специалисты высокого уровня
• нужен большой бюджет
• сильно зависит от заказчика

📍 Где используется

• крупные компании, где важна скорость
• проекты, где есть сильная команда архитекторов

🟪 6. Iterative Model (Итеративная модель)

🔄 Делаем продукт версиями, каждая версия — лучше предыдущей.

🧠 Суть

Команда создаёт первую простую версию продукта — неидеальную, но рабочую.
Потом улучшает её в следующей итерации.
И снова.
И снова.

Пример:
как рисование Моны Лизы:

1️⃣ Сначала набросок
2️⃣ Потом цвет
3️⃣ Потом детали

Эту методологию можно назвать предшественником SCRUMа.

✔ Плюсы

• продукт быстро становится рабочим
• можно постоянно улучшать
• идеально, когда требования неполные

❌ Минусы

• продукт может быть «сырая первая версия»
• постоянно требуются улучшения

📍 Где используется

• большие проекты
• проекты с неопределённой конечной целью
• исследования

🟫 7. Spiral Model (Спиральная модель)

🌀 Разработка в виде циклов с анализом рисков.

Очень похожа на инкрементную, но делает упор на:

• анализ рисков
• эксперименты
• прототипы
• безопасность
• большие сложные системы

Каждый виток спирали — это:

1️⃣ Планирование
2️⃣ Анализ рисков
3️⃣ Создание прототипа
4️⃣ Проверка и решение, двигаться дальше или нет

✔ Плюсы

• идеально для сложных систем
• можно заранее видеть опасности
• гибкое уточнение требований

❌ Минусы

• дорого
• долго
• не подходит для маленьких проектов

📍 Где используется

• банки
• государственные системы
• большие корпоративные продукты
• системы документооборота