В чем разница между Kanban, Scrum, Waterfall и Agile?

# Разница между Kanban, Scrum, Waterfall и Agile

Основное разделение

• Waterfall - последовательная разработка, все фазы по очереди
• Agile - итеративная разработка, множество малых циклов
• Scrum - framework внутри Agile с 2-4 недельными спринтами
• Kanban - система управления потоком работы (может быть в Agile или отдельно)

1. Waterfall (Водопад)

Принцип

┌──────────┬──────────┬────────┬─────────┬──────────┐
│ Planning │ Analysis │ Design │ Coding  │ Testing  │ Deploy
└──────────┴──────────┴────────┴─────────┴──────────┘
     ↓          ↓         ↓        ↓         ↓          ↓
   1 месяц   2 месяца  3 месяца 2 месяца 1 месяц    

Одна фаза → следующая фаза (вернуться нельзя)

Как работает

1. Requirements (1 месяц) - собираешь все требования
2. Design (1 месяц) - проектируешь архитектуру (окончательно)
3. Development (3 месяца) - пишешь код согласно плану
4. Testing (1 месяц) - тестируешь всё
5. Deployment - одноразово выпускаешь

Преимущества

✅ Понятна стоимость, время и объём с начала ✅ Хороший для проектов где требования ясны (строительство, embedded systems) ✅ Легко отчитываться перед management ✅ Все документируется

Недостатки

❌ Если требования изменились - нужно переделывать всё ❌ Проблемы находятся в конце (тестирование) ❌ Медленный feedback от клиента ❌ Клиент видит продукт только в конце (9+ месяцев) ❌ Нет возможности адаптироваться

Пример проблемы

Относительно: Через 6 месяцев заказчик говорит "подожди, а нам нужна интеграция с Facebook!" → нужно переделывать архитектуру → задержка на месяцы.

---

2. Agile (Гибкая разработка)

Принцип

Rapid iteration с частым feedback:

Iteration 1 (2 недели)  → Release MVP
    ↓ feedback
Iteration 2 (2 недели)  → Release v1.1
    ↓ feedback
Iteration 3 (2 недели)  → Release v1.2
    ↓ feedback

Manifesto (4 основных ценности)

1. Люди и взаимодействие > процессы и инструменты
2. Работающий продукт > полная документация
3. Сотрудничество с клиентом > переговоры по контракту
4. Реагирование на изменения > следование плану

Как работает

Each iteration (обычно 2 недели):

Ежедневные standup (15 мин)
    ↓
Разработка (6 дней)
    ↓
Demonstration (с клиентом)
    ↓
Retro (что улучшить в процессе)
    ↓
Новая итерация

Преимущества

✅ Клиент видит результат каждые 2 недели ✅ Быстрый feedback и адаптация ✅ Проблемы находятся рано ✅ Команда мотивирована (видят результаты) ✅ Меньше риск (не 9 месяцев неопределённости)

Недостатки

❌ Сложно оценить финальную стоимость (может быть переоценка) ❌ Требует частого общения с клиентом ❌ Документация часто недостаточна ❌ Нужна хорошая команда (junior'ы могут потеряться)

---

3. Scrum (Agile Framework)

Что это

Специальный фреймворк для управления разработкой (самый популярный в Agile).

Структура

┌─────────────────────────────────┐
│ Product Backlog (куча требований│ (Требования, приоритизированы)
└─────────────────────────────────┘
        ↓ (выбираем на спринт)
┌─────────────────────────────────┐
│ Sprint Backlog (задачи на спринт│ (На 2-4 недели)
└─────────────────────────────────┘
        ↓ (работаем)
┌─────────────────────────────────┐
│ Daily Standup, Development      │ (Ежедневная работа)
└─────────────────────────────────┘
        ↓ (показываем)
┌─────────────────────────────────┐
│ Sprint Review (демо клиентам)   │ (30 мин)
└─────────────────────────────────┘
        ↓ (улучшаем процесс)
┌─────────────────────────────────┐
│ Sprint Retrospective             │ (30 мин)
└─────────────────────────────────┘

Роли

Product Owner - представляет интересы клиента, приоритизирует требования Scrum Master - удаляет препятствия, помогает команде Development Team - программисты и инженеры (5-9 человек)

Артефакты

Product Backlog - весь список требований Sprint Backlog - требования выбранные на текущий спринт Increment - готовый код (должен быть releaseable)

События (Ceremonies)

1. Sprint Planning (2 часа для 2-недельного спринта)

   • Что мы сделаем в этом спринте?
   • Как мы это сделаем?

2. Daily Standup (15 мин каждый день)

   • Что я сделал вчера?
   • Что я делаю сегодня?
   • Какие препятствия?

3. Sprint Review (1 час)

   • Демо готового кода клиентам
   • Feedback

4. Sprint Retrospective (45 мин)

   • Что прошло хорошо?
   • Что можно улучшить?
   • Что сделать в следующем спринте?

Преимущества

✅ Структурированная методология ✅ Четкие роли и ответственность ✅ Итерационный feedback ✅ Частые релизы ✅ Предсказуемый график (спринты)

Недостатки

❌ Много собраний (standup, planning, review, retro) ❌ Может быть overhead на маленьких командах ❌ Sprint может быть неправильно спланирован ❌ Требует дисциплины

Пример спринта

Спринт: 2-15 Декабря (2 недели)

Monday: Sprint Planning (2 часа)
  Выбираем задачи на спринт:
  - User authentication (5 дней)
  - Email notifications (3 дня)
  - Bug fixes (2 дня)
  Total: 10 дней (на 2 недели × 5 дней/неделю = 10 дней)

Tuesday-Friday: Daily Standup (15 мин)
  Разработка

Friday: Sprint Review (1 час)
  "Посмотрите что мы сделали!"
  Клиент дает feedback

Friday: Sprint Retro (30 мин)
  "Что можно улучшить в процессе?"
  
Monday: Новый спринт

---

4. Kanban (Система управления потоком)

Принцип

No fixed sprints, continuous flow of work.

┌──────────────────────────────────────────────────────┐
│                    KANBAN BOARD                       │
├─────────────────┬──────────────────┬────────────────┤
│      TODO       │    IN PROGRESS   │     DONE       │
├─────────────────┼──────────────────┼────────────────┤
│                 │                  │                │
│ Task 1          │ Task 3 (John)    │ Task 5         │
│ Task 2          │ Task 4 (Maria)   │ Task 6         │
│ Task 7          │                  │                │
│ Task 8          │                  │ Task 7         │
│                 │                  │                │
└─────────────────┴──────────────────┴────────────────┘

WIP limit (Work In Progress): максимум 3 task одновременно
Esли IN PROGRESS >= 3 → нельзя начинать новую

Правила Kanban

1. Visualize Workflow - доска со статусами
2. Limit WIP - максимум задач одновременно
3. Manage Flow - оптимизировать скорость
4. Explicit Policies - всем известны правила
5. Feedback Loops - регулярная аналитика

Как работает

1. Задача попадает в TODO
2. Разработчик берёт задачу → IN PROGRESS
3. Разработчик завершает → DONE
4. Новая задача из TODO

Нет спринтов, нет planning, нет ceremonies
Просто continuous flow

Преимущества

✅ Минимум overhead (нет собраний) ✅ Гибко (можно менять приоритеты прямо во время работы) ✅ Быстро видно где "узкие места" ✅ Лучше для поддерживаемого кода (maintenance) ✅ Меньше context switching

Недостатки

❌ Нет спринтов = сложнее планировать ❌ Может быть бесконечный поток задач ❌ Нет официальных демо клиентам (нужно добавлять) ❌ Требует дисциплины (WIP limit нужно соблюдать)

Пример доски

TODO (8 items)      IN PROGRESS (WIP: 3)  REVIEW (WIP: 2)  DONE
─────────────       ───────────────────   ────────────────  ─────
User auth           API endpoint          DB migration ✓    Login page
Email notify        Auth service          Email service ✓   Logout
Password reset      Unit tests
UI dashboard
Bug #234
Bug #235
Documentation
Performance tuning

---

Сравнительная таблица

---

Практические примеры

Waterfall

Используешь когда:

• Проект: авиакосмический, медицинский (жёсткие требования)
• Требования неизменяемы
• Нужна полная документация
• Нет возможности итерировать

Scrum

Используешь когда:

• Обычный веб проект
• 5-9 разработчиков
• Нужен предсказуемый график
• Хочешь частый feedback от клиента
• Нужна структура

Мой опыт: большинство моих проектов используют Scrum. Хороший баланс между структурой и гибкостью.

Kanban

Используешь когда:

• Поддержка существующего кода
• Техдолг и баг фиксы
• Continuous deployment
• Маленькая команда
• Нет определённого планирования

Agile (в целом)

Успользуешь когда:

• Требования меняются
• Нужен быстрый feedback
• Хочешь видеть результаты регулярно
• Меньше риск (итерационно)

---

Гибридные подходы

Scrumban = Scrum + Kanban

• Спринты как в Scrum
• Но работа вытекает как в Kanban
• WIP limit
• Нет фиксированного планирования

Lean = Kanban + статистика

• Минимизировать waste
• Optimize flow
• Data-driven решения

---

Мой практический совет

В начальной карьере я работал с Waterfall (долгие проекты без feedback).

Потом перешёл на Scrum (2 недельные спринты, регулярный feedback).

В последние годы использую Kanban для поддержки и Scrum для новых фич (гибридный подход).

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