В чем разница жизненного цикла приложения в Waterfall и Scrum?

Разница жизненного цикла приложения в Waterfall и Scrum

Это одна из самых существенных разниц в подходах к разработке ПО. Я работал с обоими методологиями и вижу существенные отличия в том, как организуется работа, когда появляется feedback, и как функции доходят до пользователей.

Waterfall: Линейный, последовательный цикл

Структура:

Реквизиты → Дизайн → Разработка → Тестирование → Развёртывание → Поддержка
(3 мес)    (2 мес)   (6 мес)      (2 мес)      (1 неделя)     (годы)

Фазы Waterfall:

1. Requirements Gathering (3-6 месяцев)

• BA проводит extensive interviews и анализ
• Создание comprehensive requirements документа (100+ страниц)
• Утверждение требований у всех stakeholders
• Документирование не меняется до конца проекта

2. Design (2-3 месяца)

• Архитектура, БД дизайн, UI mockups
• Все проектируется перед началом разработки
• Предполагается, что все требования известны и правильны

3. Development (6-12 месяцев)

• Разработчики кодят всё, что в требованиях
• Часто очень далеко от конечного пользователя
• Feedback от пользователей приходит очень поздно

4. Testing (2-3 месяца)

• QA проверяет соответствие требованиям
• Часто находят проблемы, но переделывать требования поздно

5. Deployment (1-2 недели)

• "Big bang" release — всё выходит сразу
• Высокий риск (если что-то сломается, всё сломается)

6. Maintenance (годы)

• Баги фиксятся в hotfixes
• Новые требования → новый цикл Waterfall

Scrum: Итеративный, циклический цикл

Структура:

Backlog → Sprint Planning → Sprint (2 недели) → Review → Retrospective → Next Sprint
  ↑                                 ↓
  ← ← ← ← ← Feedback от users ← ← ←

Фазы Scrum:

1. Product Backlog Creation (ongoing)

• BA создаёт stories на основе customer feedback
• Prioritization на основе value и urgency
• Backlog постоянно эволюционирует

2. Sprint Planning (4 часа на 2-недельный спринт)

• Team выбирает top stories из backlog
• Разбор деталей (только для текущего спринта)
• Commitment на спринт

3. Daily Standups (15 минут каждый день)

• What did I do?
• What will I do?
• Blockers?
• Быстрое решение проблем

4. Development & Testing (в течение спринта)

• Разработка и testing происходят параллельно
• Definition of Done для каждой story
• Готовый для релиза код в конце спринта

5. Sprint Review (2 часа в конце спринта)

• Демонстрация работающего функционала customers
• Feedback от users
• Adjustment плана на основе feedback

6. Sprint Retrospective (1.5 часа)

• Team обсуждает, что сработало, что нет
• Улучшения процесса

7. Continuous Deployment (на дороге к production)

• Часто можно выпускать features в production каждый спринт
• Или даже несколько раз в неделю (continuous delivery)

Сравнение: ключевые отличия

1. Timing Requirements

Waterfall:

• Все требования собираются в начале
• Changes = change order, переделка плана
• Предполагается: требования полные и правильные

Scrum:

• Требования собираются инкрементально
• Changes = просто новые stories в backlog
• Требования могут меняться на основе feedback

2. Feedback Loop

Waterfall:

• Feedback от users → только в конце (после выпуска)
• Если feedback показывает проблему → очень дорого переделывать
• User не видит никакой работы до релиза

Scrum:

• Feedback от users → каждый спринт (2 недели)
• Feedback быстро incorporates в следующий спринт
• Users видят работающий (хоть и incomplete) продукт часто

3. Risk Management

Waterfall:

• High risk концентрирован в конце (testing, deployment)
• Если есть проблемы в requirements → найдутся очень поздно
• "Big bang" release = большое окно для каких-то неожиданностей

Scrum:

• Risk распределён равномерно
• Проблемы в requirements видны через 2 недели
• Small, frequent releases = меньше риска

4. Team & Stakeholder Involvement

Waterfall:

• BA работает с users только в начале
• Product Owner может быть далеко от team
• Developers мало видят реального use case

Scrum:

• Product Owner постоянно вовлечён (sprint review, backlog refinement)
• Team постоянно взаимодействует с requirements
• Developers понимают "why" за каждой feature

5. Quality

Waterfall:

• Quality проверяется в конце (testing phase)
• QA проверяет полный продукт
• Баги найденные поздно дорого фиксить

Scrum:

• Quality встроена в процесс (Definition of Done)
• Testing происходит параллельно с разработкой
• Баги фиксятся сразу

Таблица сравнения

Когда использовать Waterfall

✓ Embedded systems — нельзя iterate после production ✓ Hardware projects — hardware нельзя fast-iterate ✓ Fixed requirements — требования точно известны и не меняются ✓ Regulatory compliance — нужна полная документация перед началом ✓ Large teams — когда координация дороже, чем flexibility

Пример: разработка software для медицинского оборудования, где требуется FDA approval до запуска.

Когда использовать Scrum

✓ Startups — требования неизвестны, нужно быстро iterate ✓ Web/Mobile apps — можно выпускать часто ✓ Product innovation — нужен feedback от users ✓ Fast-moving markets — конкуренты быстро меняются ✓ User-centric — нужно близко работать с users

Пример: SaaS приложение, где features выпускаются каждую неделю.

Моя практика: Hybrid Approach

В реальности я часто работаю с гибридным подходом:

• Epic level требования похожи на Waterfall (планируем 6 месяцев вперёд)
• Sprint level работаем как Scrum ( 2-недельные итерации)
• Daily level очень flexible (меняем приоритеты на основе feedback)

Это позволяет иметь стратегическое направление (как Waterfall) но быть гибким в тактике (как Scrum).