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

Разница между Kanban и Waterfall

Это два принципиально разных подхода к управлению проектами. За 10+ лет работы я использовал оба и вижу плюсы и минусы каждого. В современной разработке Waterfall почти исчез, но Kanban остался актуален.

Waterfall (Водопад)

Философия: Проект делится на последовательные фазы. Каждая фаза полностью завершается перед началом следующей. Нет возврата назад.

Фазы Waterfall:

Требования → Дизайн → Разработка → Тестирование → Deployment → Maintenance
    ↓          ↓          ↓            ↓             ↓              ↓
  1-2 недели 2-3 недели  4-6 недель  2-3 недели   1 неделя      Постоянно

Процесс:

Месяц 1: Сбор требований
  - Встречи со stakeholders
  - Создание спецификации (SRS document)
  - Согласование
  - Никакой разработки!

Месяц 2: Дизайн
  - Архитектура
  - Database schema
  - UI/UX mockups
  - Дизайн документ
  - Никакой разработки!

Месяцы 3-4: Разработка
  - Кодирование по спецификации
  - Никаких изменений требований
  - Сдача кода

Месяц 5: Тестирование
  - QA находит баги
  - Разработчики исправляют
  - Регрессионное тестирование

Месяц 6: Deployment
  - Release notes
  - User training
  - Go live

Дальше: Maintenance
  - Поддержка
  - Исправление ошибок

Характеристики Waterfall:

# Документация — главное
# Software Requirements Specification (SRS) — 50+ страниц
# Design Document — детально описывает каждый класс и метод
# Database Schema Document — полная таблица со всеми индексами

# Требования фиксируются в начале
REQUIREMENTS = {
    "user_registration": "Users can register with email and password",
    "password_reset": "Users can reset password via email link",
    "admin_dashboard": "Admin sees 5 KPIs on dashboard",
    # Если потом нужно 10 KPIs? Слишком поздно!
}

# Изменения требований стоят дорого
# Change Request Process:
# 1. Заявка на изменение
# 2. Оценка impact (1-2 недели)
# 3. Согласование с stakeholders (1 неделя)
# 4. Обновление документации
# 5. Изменение расписания и бюджета
# 6. Переработка дизайна, кода, тестов

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

• Требования полностью известны в начале
• Конструкция, физический продукт (можно ли изменить план во время постройки дома?)
• Regulatory projects (медицина, авиация, финансы)
• Фиксированный бюджет и сроки
• Большая команда, нужна координация

Плюсы Waterfall:

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

Минусы Waterfall:

• Неподвижность к изменениям
• Долгий feedback loop
• Баги находят в конце (дорого исправлять)
• Клиент видит результат только в конце
• Риск: если требования неверны, вся работа впустую

Kanban

Философия: Работа течёт непрерывно. Задачи движутся через доску (To Do → In Progress → Done). Фокус на flow и WIP (Work In Progress) лимиты.

Визуальная доска:

┌─────────────────────────────────────────────────┐
│ KANBAN BOARD                                    │
├────────────┬────────────┬────────────┬──────────┤
│ TO DO      │ IN PROGRESS│ REVIEW     │ DONE     │
│ WIP: ∞     │ WIP: 3     │ WIP: 2     │ WIP: ∞   │
├────────────┼────────────┼────────────┼──────────┤
│ Auth       │ Add user   │ Password   │ Login    │
│ DB schema  │ Register   │ reset      │ Dashboard│
│ API design │ Email send │            │          │
│            │            │            │          │
└────────────┴────────────┴────────────┴──────────┘

Процесс:

# День 1: Стартап
# Создаём Kanban доску с первыми задачами
Backlog = [
    Task("User registration", points=5),
    Task("Email verification", points=3),
    Task("Login", points=3),
    Task("Dashboard", points=8),
    Task("User profile", points=5),
]

# Каждый день: Standup (15 минут)
# - Что я вчера сделал?
# - Что я сегодня делаю?
# - Какие блокеры?

dev_alice = {
    "yesterday": "Закончила регистрацию пользователя",
    "today": "Буду делать верификацию email",
    "blockers": "Нужна помощь с SMTP конфигом"
}

# Каждую неделю: Refinement
# - Добавляем новые задачи
# - Уточняем требования
# - Переоценяем

Backlog_updated = [
    Task("Dark mode", points=5),  # Клиент запросил
    Task("Export data", points=8),  # Новое требование
    Task("API rate limiting", points=3),  # Техдолг
]

# Каждый день: Pull from To Do → In Progress
# Никакого плана на месяц вперёд
# Фокус на том, что перед вами

Характеристики Kanban:

# Минимум документации
# Требования в виде User Stories (5-10 строк)
USER_STORY = """
As a user
I want to reset my password
So that I can regain access if I forget it

Acceptance Criteria:
- User enters email
- Email with reset link sent
- Link works 24 часа
- Password можно сменить
"""

# Требования развиваются
Initial_Requirement = "User can register"
After_Week_1 = "User can register with email or phone"
After_Week_3 = "User can register with email, phone, or Google OAuth"
# Это нормально для Kanban!

# Непрерывная разработка
# Sprint → Что это? Нет спринтов
# Поток задач просто идёт

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

• Требования меняются часто
• Стартапы, быстро развивающиеся продукты
• Maintenance, Support (постоянный поток задач)
• DevOps, Infrastructure
• Можно выпускать часто (множество малых фич)

Плюсы Kanban:

• Гибкость к изменениям
• Быстрый feedback loop
• Меньше документации
• Непрерывная доставка (CD)
• Упор на качество процесса, не на документы

Минусы Kanban:

• Сложнее с плаированием
• Может быть хаос без правил
• Сложнее управлять большой командой
• Требует дисциплины и культуры

Scrum vs Kanban

Важно: Scrum часто путают с Waterfall, но это не так.

Scrum:

• Sprint (2-4 недели)
• Sprint Planning, Daily standup, Sprint Review, Retrospective
• Commitment на спринт
• Predictability
• Hybrid между Waterfall и Kanban

Kanban:

• Непрерывный поток
• Только Daily standup
• Нет commitment на период
• Flexibility
• Pull-based (не push)

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

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

Проект 1: Waterfall (2010-2012)

Период разработки: 8 месяцев
Типичный день:
  - Пишу код по спецификации
  - Никто не знает, нравится ли клиенту
  - Баги находим в конце → переделка
Результат: Бюджет превышен на 40%, проект позже на 2 месяца

Проект 2: Kanban (2015-2017)

Период разработки: 4 месяца, но непрерывная разработка
Типичный день:
  - Стендап 15 минут
  - Берём задачу из To Do
  - Готово → сразу в продакшн
  - Клиент видит результат неделю спустя
Результат: Бюджет в плане, очень доволен клиент, постоянный feedback

Мои рекомендации

Для Python разработчика:

1. Научись Kanban — это современный стандарт
2. Пониай Scrum — используется 60% компаний
3. Знай Waterfall — для очень крупных проектов
4. Адаптируй под проект — нет одного идеального способа

В моей практике:

• Стартапы: Kanban + быстрые релизы
• Средние компании: Scrum (2-недельные спринты)
• Большие корпорации: SAFe (Scaled Agile) + элементы Waterfall для planning

Вывод

Waterfall — это последовательный, план-ориентированный подход. Kanban — непрерывный, гибкий поток. Современная разработка предпочитает Kanban/Agile, потому что требования меняются быстро, а feedback циклы должны быть коротким.