Гибкий водопад: гибрид Agile и Waterfall в проектном управлении

Руководитель корпоративных практик ALP Group Александр Казеннов рассказывает, как компания-интегратор создала собственную систему для управления проектами, которая берет лучшее из двух методологий и превосходит по функционалу Jira.

Предыстория Agile-хайпа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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