Как объединить Agile и Waterfall в проектном управлении

Предыстория: восхождение Agile-подхода

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

В 2001 году появился «Манифест гибкой разработки программного обеспечения». Отчасти это был ответ на закостенелый подход «водопада». В основе гибкой разработки (Agile) лежат четыре идеи:

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

Строго говоря, Agile-подход — это целое семейство методологий, большинство из которых сводят разработку к серии коротких циклов (итераций) длиной примерно в две недели. К ним относятся, в частности, практики экстремального программирования, адаптивной разработки, а также подходы DSDM, Scrum и Kanban.

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

Тем не менее, поезд было уже не остановить: во второй половине 2010-х годов гибкие методологии окончательно захватили умы проджект-менеджеров и превратились в своеобразный карго-культ.

Комбинированный подход

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

Практика же показывает, что в случае рабочих процессов компании-интегратора, которая работает с большими заказчиками в масштабах целой страны, идеальный и даже самый естественный подход — гибридный. На крупных проектах методологии Agile и Waterfall не просто можно, а нужно совмещать, чтобы добиться успеха.

Когда мы строим большие корпоративные системы (например, внедряем заказчику кастомизированную систему класса ERP), мы осуществляем планирование на двух уровнях:

• Верхний уровень — стратегическое планирование по методологии Waterfall.

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

• Нижний уровень — планирование спринтов по методологии Agile.

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

Система в основе

Чтобы реализовать такой гибридный подход к разработке, нам нужна была соответствующая внутренняя автоматизированная система. Поскольку на тот момент на российском рынке ничего подобного не существовало (это было около 15 лет назад), мы начали задумываться о собственном решении. Изначально система создавалась как подручный инструмент для учета рабочего времени и взаимодействия с заказчиками на всех этапах жизненного цикла внедряемого продукта, но с годами она разрослась до полноценной интегрированной системы управления проектами по внедрению, поддержке и развитию сложных ИТ-решений.

Текущая версия системы позволяет заводить план-график, вносить текстовые описания задач как этапов и добавлять обращения (тикеты, которые создает заказчик — либо в классическом виде как требования с приложенной документацией и комментариями с отчетами по этапам выполнения, либо в виде канбан-доски с карточками для перетаскивания по колонкам-этапам).

Функциональность позволяет членам команды ставить друг другу поручения (в отдельных случаях, когда отработка обращений идет строго по стандарту, этот процесс вообще автоматизирован в соответствии с заданным алгоритмом). Здесь же ведется учет рабочего времени (кто что и за сколько часов сделал), учет отпусков и другие HR-истории. Помимо этого, в системе хранится вся корпоративная база знаний, а также присутствует раздел форумов.

В системе имеются настраиваемые процедуры контроля качества, средства управления рисками и ресурсными ограничениями, инструменты отслеживания и сопровождения всех процессов DevOps, включая контроль качества релизов, и гибкие возможности проектной аналитики. В 2019 году платформа обогатилась инструментами по взаимодействию со средой разработки, что позволяет отслеживать программный код по каждой конкретной задаче.

Не гибрид, а здравый смысл

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

Заказчику такой комбинированный подход тоже на руку. Продумывая систему, клиент идет с нами стратегически по «водопаду», а отдельные задачи и бизнес-кейсы обсуждает на регулярных летучках. Так клиент лучше понимает, что хочет получить на выходе, четче формулирует требования и добивается своих целей быстрее, чем при классическом каскадном внедрении. Другими словами, заказчик получает выгоду от обеих методологий разработки: с одной стороны, это высокая адаптивность внедрения и оперативная обратная связь, а с другой, контроль над сроками, бюджетами и достижением основных целей проекта.

При этом, на мой взгляд, руководителям проектов нет смысла все время проговаривать, на какую методологию команда опирается в конкретный момент и маркировать каждое управленческое решение как принадлежащее к инструментам Agile или Waterfall. Строго говоря, владельцам бизнеса все равно, делаются ли их проекты по «водопаду» или по гибким методологиям, — им важно, чтобы нужные результаты достигались в заявленные сроки (а лучше раньше). Кажется, руководителям ИТ-проектов тоже пора перестать мыслить по шаблону и цепляться за учебники с описанием методологий управления — реальный мир и реальные бизнес-задачи гораздо интереснее и сложнее.