Методологии управления проектами

Представление взаимосвязей

graph TD
  A[Подходы к управлению проектами]
  B[Waterfall]
  C[Agile]
  D[Scrum]
  E[Kanban]
  G[XP]
  H[Lean]
  I[RAD]
  
  A --> B
  A --> C
  A --> H
  A --> I
  C --> D
  C --> E
  C --> G

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

• Это НЕ конкретный инструмент, а ФИЛОСОФИЯ или подход к разработке
• Это набор принципов и ценностей, описанных в Agile-манифесте
• Основные ценности Agile:
  • Люди и взаимодействие важнее процессов и инструментов
  • Работающий продукт важнее исчерпывающей документации
  • Сотрудничество с заказчиком важнее согласования условий контракта
  • Готовность к изменениям важнее следования первоначальному плану

Waterfall (Водопад)

• Классический (линейный) подход “шаг за шагом” к управлению проектами
• Полностью самостоятельная методология, НЕ является частью Agile
• Идеален для проектов, где требования высечены в камне

erfall
  graph LR
      A["Требования"] --> B
      B["Проектирование"] --> C
      C["Разработка"] --> D
      D["Тестирование"] --> E
      E["Поддержка"]

Scrum

• Это КОНКРЕТНАЯ методология
• Является РЕАЛИЗАЦИЕЙ принципов Agile
• Имеет четко определенные роли (Scrum Master, Product Owner, Development Team)
• Определяет конкретные церемонии (Daily Standup, Sprint Planning, Retrospective)
• На пальцах (будто бы это ресторан):
  • Product Owner – говорит, какие блюда готовить
  • Scrum Master – следит, чтобы на кухне был порядок и все инструменты
  • DevTeam – повара, которые всё это готовят
  • Product Backlog – меню ресторана со всеми возможными блюдами
  • Sprint Backlog – список блюд, которые готовим за смену
  • Increment – готовые блюда, которые можно подавать
  • Sprint – готовим часть блюд
  • Daily Scrum – утром обсуждаем, кто что будет готовить
  • Sprint Review – дегустация приготовленных блюд
  • Retrospective – обсуждаем, как в следующий раз готовить лучше

Scrum цикл:

1. Product Backlog → Sprint Planning
   • Берем задачи из общего бэклога и планируем спринт
2. Sprint Planning → Sprint Backlog
   • Формируем список задач на спринт (2-4 недели)
3. Sprint Backlog → Daily Scrum
   • Ежедневно обсуждаем прогресс
4. Daily Scrum → Increment
   • Работаем 2-4 недели и получаем готовый результат
5. Increment → Sprint Review
   • Показываем что сделали
6. Review → Retrospective → Новый спринт
   • Обсуждаем как улучшить процесс
   • Начинаем новый цикл

graph TD
  PB[Product Backlog] --> SP[Sprint Planning]
  SP --> SB[Sprint Backlog]
  SB --> DS[Daily Scrum]
  DS --> |2-4 недели| I[Increment]
  I --> SR[Sprint Review]
  SR --> R[Retrospective]
  R --> |Новый спринт| SP
  
  PO[Product Owner] -.-> PB
  SM[Scrum Master] -.-> DS
  DT[Dev Team] -.-> DS

Kanban

• Это также КОНКРЕТНАЯ методология
• Может использоваться как в рамках Agile, так и независимо
• Фокусируется на визуализации работы и ограничении количества задач в работе (WIP limits)
• Главное правило – не хватать больше, чем можешь унести

Kanban цикл:

1. Backlog → To Do (лимит 5)
   • Задачи попадают в очередь на выполнение
2. To Do → In Progress (лимит 3)
   • Берем в работу только когда есть свободные руки
3. In Progress → Quality Check (лимит 2)
   • Проверяем качество выполнения
4. Quality Check → Done (лимит 2)
   • Завершаем задачу

graph TD
  B[Backlog] --> |Лимит 5| TD[To Do]
  TD --> |Лимит 3| IP[In Progress]
  IP --> |Лимит 2| QA[Quality Check]
  QA --> |Лимит 2| D[Done]
  
  PO[Product Owner] -.-> B
  TM[Team Members] -.-> IP
  QAT[QA Team] -.-> QA

XP (Экстремальное программирование) Wiki

• Как парное фигурное катание, только в программировании
• Является РЕАЛИЗАЦИЕЙ принципов Agile
• Упор на качество кода и командную работу
• Фишки:
  • Парное программирование (один пишет, второй подсказывает)
  • Постоянное тестирование
  • Простота в коде (никаких наворотов)
  • Частые обновления (лучше маленькими порциями, чем один большой релиз)

Цикл XP и его смысл:

1. Planning (Планирование)
   • Команда и заказчик определяют, что нужно сделать
   • Разбивают большие задачи на маленькие истории
   • Оценивают сложность и приоритеты
2. Design (Проектирование)
   • Простые решения без лишних усложнений
   • Следуем принципу YAGNI (You Ain’t Gonna Need It)
   • Фокус на текущих потребностях
3. Coding (Кодирование)
   • Парное программирование (четыре глаза лучше)
   • Следование стандартам кода
   • Непрерывная интеграция изменений
4. Testing (Тестирование)
   • Сначала пишем тесты, потом код (TDD)
   • Автоматизированное тестирование
   • Все тесты должны проходить всегда
5. Release (Выпуск)
   • Частые небольшие релизы
   • Быстрая обратная связь
   • Возможность быстро исправить проблемы

→ И снова к Planning, потому что разработка – это непрерывный процесс улучшений

graph TD
  PL[Planning] --> D[Design]
  D --> C[Coding]
  C --> T[Testing]
  T --> R[Release]
  R --> |Новая итерация| PL
  
  PP[Pair Programming] -.-> C
  TDD[Test Driven Development] -.-> T
  CI[Continuous Integration] -.-> R
  S[Simple Design] -.-> D

Lean (Бережливая разработка)

• Философия “не делай лишнего”
• Убираем всё, что не добавляет ценности
• Постоянные улучшения процесса
• Минимизация потерь (времени, ресурсов, нервов)

Цикл и его смысл:

1. Value (Ценность)
   • Customer Need: Что реально нужно клиенту?
2. Waste (Потери)
   • Eliminate Muda (по-японски муда – мусор): Убираем всё лишнее
3. Flow (Поток)
   • Smooth Process: Работа без остановок
4. Pull (Вытягивание)
   • On Demand: Делаем только когда нужно
5. Perfection (Совершенство)
   • Kaizen: Улучшаем каждый день

→ И снова к началу (процесс постоянный)

graph TD
  V[Value] --> W[Waste]
  W --> F[Flow]
  F --> P[Pull]
  P --> PF[Perfection]
  PF --> |Continuous| V
  
  C1[Customer Need] -.-> V
  C2[Eliminate Muda] -.-> W
  C3[Smooth Process] -.-> F
  C4[On Demand] -.-> P
  C5[Kaizen] -.-> PF

RAD (Быстрая разработка приложений)

• Короткий цикл разработки (60-90 дней)
• Активное участие пользователей/заказчика
• Много прототипирования
• Параллельная разработка компонентов
• Меньше документации, больше кода

Цикл и его смысл:

1. Requirements (1-2 нед)
   • Быстрый сбор ключевых требований
   • Согласование с пользователями
2. Design (2-3 нед)
   • Сделали прототип
   • Итеративное улучшение прототипов
3. Construction (2-3 мес)
   • Быстрая разработка на основе прототипов
   • Параллельная работа над компонентами
   • Непрерывное тестирование
4. Cutover (2-3 нед)
   • Финальное тестирование
   • Обучение пользователей
   • Развертывание системы

graph TD
  V[Value] --> W[Waste]
  W --> F[Flow]
  F --> P[Pull]
  P --> PF[Perfection]
  PF --> |Continuous| V
  
  C1[Customer Need] -.-> V
  C2[Eliminate Muda] -.-> W
  C3[Smooth Process] -.-> F
  C4[On Demand] -.-> P
  C5[Kaizen] -.-> PF

Ключевые различия

Waterfall

План → Дизайн → Код → Тест → Готово

• Как поточная линия: шаг за шагом, без возврата
• Когда всё ясно с самого начала и правок не будет

Agile

Делаем → Показываем → Правим → Повторяем

• Как конструктор: собираем продукт по частям
• Можно менять планы на ходу

Scrum

Спринт (2-4 недели) → Демо → Ретро → Новый спринт

• Как забег на короткие дистанции
• Чёткие роли и встречи

Kanban

Доска с лимитами: Бэклог → В работе → Готово

• Как конвейер в ресторане
• Берём новое только когда освободились руки

XP

Код → Тест → Рефакторинг → Повтор

• Как парное программирование на стероидах
• Качество кода превыше всего

Lean

Минимум потерь → Быстрые итерации → Автоматизация

• Как Toyota, только в софте
• Убираем всё лишнее

RAD

Требования → Прототип → Разработка → Запуск

• Как спринтер: 3 месяца и готово
• Много прототипов, мало документации

Или представь, что мы делаем пиццу:

• Waterfall — строго по рецепту, менять ничего нельзя
• Agile — даём пробовать клиенту кусочки и меняем начинку
• Scrum — готовим пиццу партиями по 2 недели
• Kanban — делаем столько пицц, сколько помещается в печи
• XP — два повара у одной печи, постоянно улучшают рецепт
• Lean — убрали всё лишнее с кухни, оставили только нужное
• RAD — быстро испекли прототип, показали, доработали, продали

❌Типичные грабли 😵

Waterfall

• “Соберём все требования заранее” (спойлер: не соберёте)
• “Документация всё предусматривает” (нет, не всё)
• “Изменений не будет” (будут, ещё как будут)

Agile

• “Документация не нужна” (нужна, но другая)
• “Планирование не важно” (важно, но гибкое)
• “Полная свобода действий” (нет, есть рамки)

Scrum

• “Ежедневные встречи по часу” (должны быть 15 минут)
• “Спринт можно прервать” (это убивает весь смысл)
• “Product Owner всё решает” (нет, это командная работа)

Kanban

• “Берём все задачи сразу” (лимиты важны)
• “Доска = методология” (доска лишь инструмент)
• “Можно без приоритетов” (нельзя)

XP

• “Код ревью не нужен, у нас же парное программирование” (нужен, это разные практики)
• “Тесты можно написать потом” (нет, TDD – сначала тест)
• “Continuous Integration можно иногда пропускать” (нет, это основа XP)

Lean

• “Автоматизируем всё подряд” (только то, что даёт ценность)
• “Максимальная загрузка = эффективность” (нет, это создаёт выгорание)

RAD (Быстрая разработка)

• “Прототип сразу идёт в продакшн” (нет, его надо переписать)
• “Заказчик сам разберётся” (нет, нужно активное участие команды)
• “Документацию сделаем в конце” (нужна с самого начала, но минимальная)

Важные нюансы всего этого

1. Методология ≠ Серебряная пуля

• Не существует идеальной методологии
• Даже Agile может быть хуже Waterfall в некоторых случаях
• Главное – понимать, когда что применять

2. Команда важнее процессов

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

3. Гибридный подход — норма (Мой пример в Ешь-Деревенское)

• Основа: Scrum-спринты
• Поддержка: Kanban-доска
• Разработка: XP-практики
• Критичные модули: элементы Waterfall

4. Адаптируйте под себя

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

5. Отслеживайте метрики эффективности команды

• Скорость разработки: Story Points (40→45 SP/спринт), выполнение спринта (90%), точность оценок (±15%), Velocity тренд (стабильный рост)
• Количество багов: Сколько багов на 1000 строк, среднее время фикса, процент возврата
• Удовлетворенность: NPS, среднее время ответа в часах, процент положительных отзывов
• Мотивация команды: посещаемость ретро, сколько улучшений/ретро, текучка, happiness index

Главное – не методология, а результат!

Всё!