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

Взаимосвязи методологий

Самое важное, что нужно тут понять:

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

Давайте разберем краткие идеи каждой

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

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

Waterfall (Водопад)

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

Scrum

• Конкретная методология, реализующая Agile
• Чёткие роли, артефакты и церемонии
• На пальцах (будто бы это ресторан):
  • Владелец Продукта – говорит, какие блюда готовить
  • Скрам-мастер – следит, чтобы на кухне был порядок и все инструменты
  • Команда Разработки – повара, которые всё это готовят
  • Бэклог Продукта – меню ресторана со всеми возможными блюдами
  • Бэклог Спринта – список блюд, которые готовим за смену
  • Инкремент – готовые блюда, которые можно подавать
  • Спринт – готовим часть блюд
  • Ежедневный Скрам – утром обсуждаем, кто что будет готовить
  • Обзор Спринта – дегустация приготовленных блюд
  • Ретроспектива – обсуждаем, как в следующий раз готовить лучше

Scrum цикл и его смысл:

1. Бэклог Продукта → Планирование Спринта
   Берем задачи из общего бэклога и планируем спринт
2. Планирование Спринта → Бэклог Спринта
   Формируем список задач на спринт (2-4 недели)
3. Бэклог Спринта → Ежедневный Скрам
   Ежедневно обсуждаем прогресс
4. Ежедневный Скрам → Инкремент
   Работаем 2-4 недели и получаем готовый результат
5. Инкремент → Обзор Спринта
   Показываем что сделали
6. Обзор → Ретроспектива → Новый спринт
   Обсуждаем как улучшить процесс

LeSS (Large-Scale Scrum)

• Масштабирование Scrum для больших команд
• Тот же Scrum, но для 2+ команд, работающих над одним продуктом
• Сохраняет все принципы Scrum, но добавляет механизмы синхронизации между командами
• На пальцах (продолжая аналогию с рестораном):
  • Один Product Owner для всего ресторана
  • Несколько команд поваров (2-8 команд в LeSS, более 8 в LeSS Huge)
  • Общий Product Backlog для всех команд
  • Синхронизированные спринты одинаковой длительности
  • Общая демонстрация результатов (Sprint Review)
  • Координация между командами через “Scrum of Scrums”

LeSS цикл:

• Общий Product Backlog → Общее Sprint Planning 1
• Команды выбирают задачи из общего бэклога
• Каждая команда проводит свой Sprint Planning 2
• Параллельная работа команд в течение спринта
• Ежедневная координация между командами
• Общий Sprint Review для всего продукта
• Отдельные и общие ретроспективы

Kanban

• Конкретная методология, может использоваться как в рамках Agile, так и отдельно
• Фокус на визуализации работы и ограничении WIP (работы в процессе)
• Главное правило: не хватай больше, чем можешь унести
• Как конвейер: каждый этап имеет ограничение на количество задач

Kanban цикл:

1. Бэклог → В Очереди (например, лимит не более 5 задач)
   Задачи попадают в очередь на выполнение
2. В Очереди → В Работе (например, лимит 3 задачи на человека)
   Берем в работу только когда есть свободные руки
3. В Работе → Проверка Качества (лимит 2)
   Проверяем качество выполнения
4. Проверка Качества → Готово (лимит 2)
   Завершаем задачу

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

• Как парное фигурное катание, только в программировании
• Реализация принципов Agile с фокусом на качество кода
• Отличия от Scrum:
  • Технический фокус: инженерные практики важнее процессов
  • Инженерная дисциплина: конкретные технические практики
  • Гибкость планирования: изменения в любой момент
  • Тесное взаимодействие с заказчиком: постоянное присутствие
  • Качество кода превыше всего: технический долг недопустим

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

1. Планирование
   • Истории пользователей (User Story)
   • Приоритизация
   • Оценка сложности
2. Проектирование
   • Принцип YAGNI (Вам это не понадобится)
   • Простота решений
3. Кодирование
   • Парное программирование
   • Стандарты кода
   • Непрерывная интеграция
4. Тестирование
   • Сначала тесты (TDD)
   • Автоматизация тестирования
5. Выпуск
6. → И снова к Планирование, потому что разработка – это непрерывный процесс улучшений

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

• Философия Toyota, адаптированная для разработки ПО
• Отличия от Scrum:
  • Фокус на устранении потерь: борьба с неэффективностью
  • Непрерывный поток: без фиксированных спринтов
  • Гибкость процесса: нет жёстких ролей и церемоний
  • Визуализация процесса: канбан-доски для выявления проблем
  • Оптимизация целого: весь процесс, а не только разработка

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

1. Ценность: Наконец-то поняли, что клиенту важен работающий сайт, а не наши 8 часов холиваров о выборе фреймворка.
2. Потери: Выкинули из процесса 15 согласований макета с тёщей заказчика и бесконечные правки “подвиньте на 2 пикселя влево”.
3. Поток: Дизайнер сразу передает готовые блоки разработчику, не дожидаясь финальной версии всего макета. Разработчик начинает верстку, пока дизайнер работает над следующими блоками. Тестировщик проверяет готовые компоненты по мере их появления. Никто не простаивает и не блокирует работу других.
4. Вытягивание: Перестали клепать фичи “на всякий случай” и писать код, который никто не заказывал (но “вдруг понадобится”).
5. Совершенство: Каждую пятницу за пивом обсуждаем, как в следующий раз меньше факапить и быстрее делать то же самое.

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

• Быстрое создание прототипов и компонентная разработка
• Отличия от других методологий:
  • Фокус на прототипировании: быстрые прототипы вместо документации
  • Активное вовлечение заказчика: постоянное участие
  • Компонентная разработка: переиспользование кода
  • Сжатые временные рамки: жёсткий timeboxing
  • Параллельная разработка: несколько команд одновременно

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

1. Планирование: Вместо 100-страничного ТЗ, которое никто не прочитает, провели двухчасовой митинг с заказчиком и записали на салфетке 10 главных “хотелок”.
2. Дизайн: Нарисовали в Фигме прототип за день, показали заказчику.
3. Конструирование: Фронтендщик достал свою заначку готовых компонентов из 50 прошлых проектов.
4. Тестирование: Дали потыкать сайт секретарше заказчика. Она нашла 15 багов за 10 минут, чем посрамила наш отдел QA, который “всё проверил”.
5. Внедрение: Выкатили на бой в пятницу в 18:55, потому что “какие могут быть проблемы с таким простым сайтом?” Тимлид уже в баре, а джун спит с телефоном все выходные.

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

• Waterfall — строго по рецепту, менять ничего нельзя. Клиент хотел пиццу с ананасами? Но в ТЗ было с грибами! Переделка = новый проект 🤷‍♂️
• Agile — даём пробовать клиенту кусочки и меняем начинку. Слишком остро? Сейчас добавим сыра! Хотите больше пепперони? Запишем в бэклог на следующую итерацию.
• Scrum — готовим пиццу партиями по 2 недели. На дейли стендапе: Вчера замесил тесто, сегодня буду делать соус, блокеров нет. Ретро после дегустации.
• LeSS — несколько команд поваров готовят пиццу по одному меню с общим шеф-поваром. Филиал в Москве делает основу, в Питере — начинку, а в Казани — соус. На общем демо пробуем всё вместе.
• Kanban — делаем столько пицц, сколько помещается в печи. В колонке В работе уже 3 пиццы? Новую не берём, пока хоть одна не переедет в Готово! Лимиты WIP – священна корова
• XP — два повара у одной печи, постоянно улучшают рецепт. А давай напишем тест на хрустящесть корочки ПЕРЕД тем, как печь – в этом вся суть.
• Lean — убрали всё лишнее с кухни, оставили только нужное. Зачем нам 20 видов специй, если используем только 10? Почему пицца идёт к клиенту 30 минут, а готовится 20?
• RAD — быстро испекли прототип, показали, доработали, продали. Вот картонный макет пиццы с нарисованными ингредиентами! Нравится? Давай деньги. К вечеру испечём настоящую!

Где что лучше применять?

• Waterfall — идеален для проектов с чёткими, неизменными требованиями. Разработка бортового ПО для самолёта Boeing — сначала всё спроектировали до винтика, потом 5 лет кодили, потом 3 года тестировали.
• Agile — для продуктов в постоянно меняющейся среде. Spotify так и работает: выкатили фичу рекомендаций, собрали метрики, увидели что слушают на 5% меньше — откатили.
• Scrum — когда нужна предсказуемость в хаосе. В Яндексе половина команд на скраме сидит: каждые 2 недели демо новых фич начальству, ретро с нытьём и поиском виноватых.
• LeSS — для крупных продуктов с несколькими командами. Сбер внедрял это для своих цифровых продуктов — 8 команд в трёх городах делали один суперапп.
• Kanban — для сервисных команд с непредсказуемым потоком задач. Техподдержка в любой IT-компании: сегодня 5 тикетов, завтра 500. Попробуй тут спланируй спринт.
• XP — для технически сложных проектов с высокими рисками. Знаю финтех-стартап, где пишут софт для трейдинга — там два программиста на один комп, TDD как религия, и рефакторинг каждый день. Когда баг стоит миллион не рублей, это единственный путь.
• Lean — для зрелых продуктов, требующих оптимизации. Amazon постоянно оптимизирует свои склады: убрали лишние перемещения, сократили время ожидания, автоматизировали рутину.
• RAD — для прототипов и проверки гипотез. Почти любой стартап на ранней стадии: сляпали MVP за месяц на коленке, показали инвесторам, собрали предзаказы. PROFIT!!11

⭐️ Нюансы всего этого ⭐️

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

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

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

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

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

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

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

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

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

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

И напоследок, капитан очевидность

Помните: Любая методология, даже самая современная – это не более, чем инструмент. Такой же как молоток или отвертка. Берите что работает у вас, безжалостно выкидывайте что не приживается. Хороший процесс – это тот, при котором продукт получается, а команда не хочет выйти в окно уволиться. Всё остальное — просто модные слова.

Всё!