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

Проект отличается от обычной операционной работы двумя признаками: у него есть начало и конец, и он создаёт уникальный результат — новый сервис, отчёт, миграцию базы данных, внедрение CRM. Поддержка работающей системы — это операционная деятельность, а её перенос в облако к концу квартала — уже проект.

Модель управления проектом — принятый в проекте порядок выполнения работ: определения требований, разработки и проверки результата.

Треугольник ограничений

Любой проект ограничен тремя взаимосвязанными параметрами:

• Объём (scope) — что именно должно быть сделано.
• Сроки (time) — когда результат нужен.
• Бюджет (cost) — сколько денег и людей доступно.

В центре треугольника обычно помещают качество. Изменение одного параметра требует изменить хотя бы один из двух других, иначе снижается качество. Расширение объёма при тех же сроках невозможно без дополнительных людей или бюджета, сокращение бюджета — без переноса сроков или сокращения объёма.

Модели управления различаются тем, какие параметры считают фиксированными. Водопад фиксирует объём, а сроки и бюджет планирует под него. Scrum фиксирует сроки и бюджет — длину итерации и состав команды, — а объём оставляет гибким. В Kanban итераций нет: вместо сроков ограничивается объём незавершённой работы.

Жизненный цикл проекта

Независимо от модели, проект проходит через пять групп процессов. Это классическая схема PMI (Project Management Institute) — крупнейшей международной ассоциации проектных менеджеров. PMI выпускает стандарты и проводит сертификацию PMP (Project Management Professional) — одну из самых известных сертификаций проектных менеджеров. До 6-го издания включительно на этой схеме было построено руководство PMBOK (Project Management Body of Knowledge — свод знаний по управлению проектами). В 7-м издании (2021) руководство перестроили вокруг принципов и областей деятельности, а в 8-м (2025) пять групп вернулись под названием «фокусные области» (Focus Areas)^[5].

1. Инициация — зачем проект нужен, кто заказчик, каковы цели и критерии успеха; всё это фиксируется в уставе проекта.
2. Планирование — объём работ, расписание, бюджет, риски, коммуникации.
3. Исполнение — работа команды по утверждённому плану.
4. Мониторинг и контроль — сравнение факта с планом и корректировка курса.
5. Завершение — приёмка результата, расчёты с подрядчиками, разбор итогов проекта.

Модели отличаются тем, проходит ли проект этот цикл один раз целиком или повторяет его многократно короткими итерациями.

Водопадная, или каскадная, модель (Waterfall)

Водопад — последовательная модель: работа делится на фазы, и каждая следующая начинается только после завершения и приёмки предыдущей.

Типичные фазы в разработке ПО:

1. Сбор и анализ требований — техническое задание, согласованное с заказчиком.
2. Проектирование — архитектура, модель данных, интерфейсы.
3. Реализация — написание кода по спецификации.
4. Тестирование — проверка соответствия требованиям.
5. Внедрение — развёртывание и передача заказчику.
6. Сопровождение — исправление ошибок и мелкие доработки.

Статью, которую считают первоисточником водопада, — работу Уинстона Ройса 1970 года — автор писал как критику. Ройс изобразил последовательную схему и сразу назвал её рискованной, потому что проблемы обнаруживаются только на тестировании, в самом конце. Он предлагал обратные связи между фазами и прототип, который делается «дважды». Слово «водопад» в статье не встречается — термин появился позже^[1].

Сильные стороны

• Предсказуемость: сроки и бюджет известны до старта работ.
• Понятный договор: объём зафиксирован в ТЗ, удобно для тендеров и контрактов с фиксированной ценой.
• Полная документация, которую легко передать другой команде или аудитору.
• От заказчика не требуется постоянного участия: достаточно согласовать ТЗ и принять результат.

Слабые стороны

• Изменение требований в середине проекта стоит дорого: нужно возвращаться на несколько фаз назад.
• Заказчик видит работающий продукт только в конце, и расхождения с его ожиданиями выявляются слишком поздно.
• Ошибки проектирования обнаруживаются на тестировании, в конце проекта, когда исправлять их дороже всего.
• До тестирования прогресс измеряется завершёнными фазами, а не работающим продуктом. Проект может идти по графику, пока тестирование не выявит незапланированные доработки, — и тогда сроки срываются, когда резерва времени уже нет.

Водопад уместен там, где требования стабильны и понятны заранее, а цена ошибки высока: строительство, производство оборудования, госзаказы с жёстким ТЗ, миграции с чётко определённым объёмом.

V-модель

V-модель — развитие водопада, в котором каждой фазе разработки сопоставлен свой уровень тестирования. Левая ветвь буквы V идёт вниз — от требований к коду, правая поднимается вверх — от проверки мелких частей к проверке всей системы.

Главная идея — тест-кейсы пишутся одновременно с соответствующей фазой проектирования, а не после написания кода. Модель по-прежнему последовательная, но ошибки в требованиях обнаруживаются раньше. Её выбирают вместо обычного водопада, когда стандарт или регулятор требует документированной проверки каждого уровня: автомобильная электроника, медицина, оборонные системы. Без такого требования V-модель избыточна: планирование тестов на каждом уровне и трассировка требований (связь каждого требования с проверяющим его тестом) обходятся в дополнительное время.

Итеративная и инкрементная модели

Эти термины часто путают, хотя они обозначают разное:

• Инкрементная модель — продукт собирается частями. Сначала выпускается ядро, затем к нему добавляются новые модули. Каждый инкремент — законченная часть функциональности.
• Итеративная модель — продукт многократно перерабатывается целиком. Первая версия приблизительная, каждая следующая итерация уточняет и улучшает уже сделанное с учётом обратной связи.

На практике гибкие подходы сочетают оба принципа.

Спиральная модель

Спиральную модель описал Барри Боэм в 1986 году^[2]. Проект проходит по спирали несколько витков, и каждый виток состоит из четырёх шагов:

1. Определение целей, альтернатив и ограничений.
2. Оценка альтернатив, выявление и снижение рисков — например, через прототип.
3. Разработка и проверка результата этого витка.
4. Планирование следующего витка.

Ключевое отличие — модель управляется рисками: на каждом витке команда в первую очередь занимается тем, что сильнее всего угрожает проекту. Если главный риск — непонятная технология, первый виток посвящают прототипу на ней. Спираль подходит для крупных, дорогих и рискованных проектов, но требует опытного менеджмента.

Agile-манифест

В феврале 2001 года семнадцать практиков разработки собрались на горнолыжном курорте в Юте и сформулировали Манифест гибкой разработки^[3]. Agile — не методология, а набор ценностей, из которых выросли конкретные фреймворки. Манифест утверждает, что:

• люди и взаимодействие важнее процессов и инструментов;
• работающий продукт важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее согласования условий контракта;
• готовность к изменениям важнее следования первоначальному плану.

Важная оговорка из самого манифеста: процессы, документация, контракт и план тоже ценны — просто первое в каждой паре ценится больше. Agile не отменяет документацию и планирование, а меняет приоритеты.

Scrum

Scrum — самый распространённый Agile-фреймворк. Работа идёт короткими итерациями фиксированной длины — спринтами (не больше месяца, чаще две недели). В конце каждого спринта должен получиться рабочий инкремент продукта, который можно показать пользователям^[4].

Роли

• Product Owner — отвечает за ценность продукта: ведёт бэклог и решает, что делать в первую очередь.
• Scrum Master — помогает команде работать по Scrum и убирает препятствия. Это не руководитель команды и не классический проектный менеджер.
• Developers — все, кто создаёт инкремент: разработчики, тестировщики, аналитики, дизайнеры. Команда сама решает, как выполнить работу.

События

Артефакты

• Бэклог продукта (Product Backlog) — упорядоченный список всего, что может понадобиться в продукте.
• Бэклог спринта (Sprint Backlog) — задачи, которые команда взяла в текущий спринт, и план их выполнения.
• Инкремент (Increment) — готовый результат спринта, соответствующий критериям готовности (Definition of Done).

Kanban

Kanban перешёл в IT из производственной системы Toyota^[11]. В отличие от Scrum, в нём нет спринтов и обязательных ролей — это метод управления потоком задач^[8]. Три базовых принципа:

• Визуализация — все задачи на доске, разбитой на колонки по этапам: «Бэклог → В работе → Код-ревью → Тестирование → Готово».
• Ограничение незавершённой работы (WIP-лимиты, от Work In Progress) — например, в колонке «В работе» не больше трёх задач. Новую задачу нельзя взять, пока не освободится место.
• Управление потоком — команда измеряет время прохождения задачи (lead time) и ищет узкие места, где задачи скапливаются.

На доске колонки «В работе» и «Код-ревью» заполнены до лимита. Разработчик, который закончит задачу, не сможет передать её на код-ревью и не возьмёт новую из бэклога — вместо этого он поможет с проверкой кода. Так WIP-лимит выявляет узкое место: работа не накапливается перед ним, а команда занимается тем, что задерживает поток.

WIP-лимиты кажутся искусственным ограничением, но за ними стоит закон Литтла — результат теории очередей, доказанный Джоном Литтлом из MIT в 1961 году: среднее время выполнения задачи равно количеству задач в работе, делённому на пропускную способность^[10]. Если команда закрывает 10 задач в неделю и держит в работе 30, каждая задача в среднем проходит путь за три недели. При сокращении незавершённой работы до 10 задач та же команда выдаёт результат за неделю, не работая быстрее.

Kanban хорошо подходит для потока задач без чётких границ: поддержка, техническая эксплуатация, аналитические запросы, контент.

Lean и шесть сигм

Lean и шесть сигм стоят особняком: это не модели жизненного цикла проекта, а подходы к улучшению процессов. Они не отвечают на вопрос, в каком порядке вести проект, — они отвечают на вопрос, как сделать повторяющийся процесс быстрее, дешевле и стабильнее. Их используют и внутри проектов, и как основу для проектов по улучшению.

Lean

Lean — обобщение производственной системы Toyota, которую строил Тайити Оно в 1950–1970-х годах^[11]. Сам термин «lean production» появился в конце 1980-х в исследованиях MIT, сравнивавших японский и западный автопром^[6]. Главная идея — устранение потерь: всего, что расходует ресурсы, но не создаёт ценности для заказчика.

На производстве выделяют семь видов потерь. Мэри и Том Поппендик перенесли их в разработку ПО^[7]:

Основной инструмент Lean — карта потока создания ценности (value stream map): весь путь задачи от запроса до результата с указанием, сколько времени задача находится в работе, а сколько — в ожидании.

Отношение времени работы к общему времени прохождения называют эффективностью потока. У команд разработки, которые не управляют потоком намеренно, она обычно составляет 5–15 %^[13]: большую часть срока задача ожидает в очередях, поэтому сокращать выгоднее ожидание, а не саму работу. Kanban с его WIP-лимитами — прямое применение этой идеи.

Шесть сигм

Шесть сигм (Six Sigma) — метод снижения разброса процесса, разработанный в Motorola в 1986 году и ставший известным после внедрения в General Electric в 1990-х. Если Lean борется с потерями времени, то шесть сигм — с дефектами и нестабильностью. Цель — не более 3,4 дефекта на миллион возможностей^[12].

Отступление о названии: 3,4 дефекта на миллион соответствуют не шести, а 4,5 стандартного отклонения от среднего до границы допуска. Метод исходит из того, что за длительное время среднее значение процесса смещается примерно на 1,5 сигмы — из-за износа оборудования, смены партий сырья и других медленных изменений, — и заранее закладывает этот запас^[12]. В IT так же ведёт себя, например, задержка ответа сервиса: на часовом нагрузочном тесте она почти всегда лучше, чем через полгода работы, когда вырастут данные, изменится нагрузка и выйдут новые релизы.

Улучшение ведётся по циклу DMAIC^[9]:

1. Define — определить проблему, заказчика и измеримую цель.
2. Measure — измерить текущее состояние процесса.
3. Analyze — найти корневые причины дефектов по данным.
4. Improve — устранить причины и проверить эффект.
5. Control — закрепить результат: стандарты, мониторинг, контрольные карты.

Шесть сигм опирается на статистику, поэтому в методе есть система квалификаций по «поясам», как в единоборствах. Пояс — уровень подготовки специалиста: Green Belt участвует в проектах по улучшению, Black Belt руководит ими, Master Black Belt обучает и курирует Black Belt.

На практике подходы объединяют в Lean Six Sigma: Lean убирает из процесса лишние шаги и ожидание, шесть сигм делает оставшиеся шаги стабильными. В IT они применяются прежде всего к повторяющимся процессам — обработке обращений в поддержку, релизному конвейеру, подготовке отчётности, — а не к разработке нового продукта, где каждая задача уникальна.

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

На практике модели в чистом виде применяются редко. Самые частые комбинации:

• Water-Scrum-Fall — требования и бюджет согласуются по-водопадному, разработка идёт спринтами, а внедрение — снова одним большим релизом. Типично для крупных компаний с годовым бюджетированием.
• Scrumban — спринты и ретроспективы из Scrum плюс доска и WIP-лимиты из Kanban. Удобен командам, которые совмещают плановую разработку и поток срочных задач.
• Водопад на верхнем уровне, Agile внутри — программа проектов с фиксированными вехами, внутри которых команды работают итерациями.

Для масштабирования Agile на десятки команд существуют отдельные фреймворки — SAFe, LeSS, Nexus, — а в классическом управлении проектами широко используются стандарты PMBOK и PRINCE2. PRINCE2 (PRojects IN Controlled Environments) — методология управления проектами, созданная по заказу правительства Великобритании.

Сравнение моделей

Как выбрать модель

Выбор модели определяется ответами на несколько вопросов о проекте:

1. Насколько хорошо известны требования? Если их можно полностью описать до старта и они не изменятся — водопад. Если заказчик поймёт, чего хочет, только увидев первую версию, — итерации.
2. Сколько стоит ошибка, обнаруженная поздно? Если очень дорого (безопасность, деньги, здоровье), нужны формальные проверки — V-модель или водопад с жёстким контролем.
3. Готов ли заказчик регулярно участвовать в работе? Scrum без Product Owner, который доступен каждый спринт, превращается в последовательность коротких водопадов.
4. Как устроен договор? Контракт с фиксированной ценой и объёмом предполагает водопад, оплата по времени и материалам — Agile.
5. Это проект или поток? Если нет понятного конца, а задачи приходят непрерывно, — Kanban.

Вывод

Модели различаются тем, когда команда узнаёт о своих ошибках. Водопад эффективен, когда требования можно спланировать заранее: он экономит на координации и даёт предсказуемость. Гибкие подходы выигрывают при неопределённости: ошибка обнаруживается в конце ближайшей итерации, а не при сдаче проекта.

Источники

1. Royce W. W. Managing the Development of Large Software Systems. — 1970.
2. Boehm B. W. A Spiral Model of Software Development and Enhancement // IEEE Computer. — 1988. — Vol. 21, No. 5. — P. 61–72. Первая версия — ACM SIGSOFT Software Engineering Notes, 1986.
3. Манифест гибкой разработки программного обеспечения. — 2001.
4. Schwaber K., Sutherland J. The Scrum Guide. — 2020.
5. Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide). — 8th ed. — 2025.
6. Womack J. P., Jones D. T., Roos D. The Machine That Changed the World. — 1990.
7. Poppendieck M., Poppendieck T. Implementing Lean Software Development: From Concept to Cash. — 2006.
8. Anderson D. J. Kanban: Successful Evolutionary Change for Your Technology Business. — 2010.
9. ГОСТ Р ИСО 13053-1-2015. Статистические методы. Количественные методы улучшения процессов «Шесть сигм». Часть 1. Методология DMAIC.
10. Little J. D. C. A Proof for the Queuing Formula: L = λW // Operations Research. — 1961. — Vol. 9, No. 3. — P. 383–387.
11. Ohno T. Toyota Production System: Beyond Large-Scale Production. — 1988. Японское издание — 1978.
12. Harry M., Schroeder R. Six Sigma: The Breakthrough Management Strategy Revolutionizing the World's Top Corporations. — 2000.
13. Vacanti D. S. Actionable Agile Metrics for Predictability. — 2015.