Какая модель разработки ПО используется в Scrum?

Модель разработки в Scrum: Итеративная и Инкрементальная

В Scrum используется итеративная и инкрементальная модель разработки программного обеспечения. Это не линейный "водопадный" процесс, а гибкий, адаптивный подход, основанный на коротких, повторяющихся циклах работы, называемых Спринтами. Ключевая цель — быстро предоставлять заказчику работающие инкременты продукта, получать обратную связь и непрерывно совершенствовать как продукт, так и сам процесс разработки.

Ключевые характеристики модели Scrum:

1. Итеративность (Iterative):

    *   Работа разбита на фиксированные по времени итерации — **Спринты**, длительность которых обычно составляет от 1 до 4 недель.
    *   Каждый Спринт представляет собой законченный цикл: планирование, разработка, тестирование, анализ и выпуск потенциально готового к поставке инкремента продукта.
    *   В конце каждого Спринта команда проводит **Обзор Спринта**, чтобы продемонстрировать результат и собрать обратную связь.

1. Инкрементальность (Incremental):

    *   По итогам каждого Спринта создается **рабочий инкремент продукта** — новая, протестированная функциональность, которая добавляется к уже существующей.
    *   Этот инкремент должен быть **"Готов"** (Definition of Done), то есть находиться в таком состоянии, чтобы его можно было потенциально выпустить пользователям.
    *   Таким образом, продукт растет постепенно, шаг за шагом, что снижает риски и позволяет рано начинать получать ценность.

Как это выглядит на практике (цикл Спринта):

• Планирование Спринта: Команда отбирает элементы из Бэклога Продукта (приоритизированного списка требований) в Бэклог Спринта — на что хватит сил в предстоящем Спринте.
• Ежедневные Скрам-митинги: Короткие 15-минутные встречи для синхронизации команды и выявления препятствий.
• Работа над задачами в Спринте: Разработка, интеграция, тестирование (включая автоматизацию) происходят параллельно и непрерывно на протяжении всего Спринта. QA-инженер является полноправным членом команды с первого дня Спринта.
• Обзор Спринта и Ретроспектива:

    *   На **Обзоре** демонстрируется инкремент, собирается фидбэк для адаптации **Бэклога Продукта**.
    *   На **Ретроспективе** команда анализирует процесс прошедшего Спринта и определяет, как улучшить свою работу в следующем.

Пример и отличие от других моделей

Для сравнения, в классической водопадной модели (Waterfall) фазы идут строго последовательно: сбор требований → дизайн → разработка → тестирование → релиз. Тестирование — это отдельная поздняя фаза. В Scrum же тестирование интегрировано в каждый день каждого Спринта.

# Упрощенная аналогия: Водопад vs Scrum
# Waterfall (последовательно, весь объем работы)
def waterfall_model(requirements, design, code, test):
    complete(requirements)
    complete(design)
    complete(code)
    complete(test)  # Тестирование только в конце!
    release()

# Scrum (итеративно, инкрементально)
def scrum_model(product_backlog):
    for sprint in sprints:  # Повторяющиеся спринты
        sprint_backlog = select_items(product_backlog, sprint.capacity)
        for day in sprint.days:
            develop(sprint_backlog)
            test(sprint_backlog)  # Тестирование постоянно и параллельно!
            integrate(sprint_backlog)
        deliver_increment()  # Поставка инкремента
        review_and_adapt(product_backlog)

Роль QA-инженера в Scrum кардинально меняется по сравнению с каскадными моделями. Он перестает быть "конечным контролером" и становится проактивным участником команды, вовлеченным в обсуждение требований на этапе планирования, пишущим автотесты параллельно с разработкой (подход Shift-Left), активно участвующим в приемочном тестировании и обеспечивающим качество на каждом этапе.

Таким образом, Scrum использует гибкую итеративно-инкрементальную модель, где работающий продукт собирается по частям в ходе коротких, строго ограниченных по времени циклов, что позволяет команде быстро адаптироваться к изменениям и регулярно получать ценность.