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

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

Источник: <a href="https://api.vc.ru/v2.8/redirect?to=https%3A%2F%2Fwww.freepik.com%2Fauthor%2Frawpixel-com&postId=623089" rel="nofollow noreferrer noopener" target="_blank">Rawpixel.com</a>, Freepik
Источник: Rawpixel.com, Freepik

Предыстория 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-решений.

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

План-график во внутренней системе управления проектами. Источник: ALP Group
План-график во внутренней системе управления проектами. Источник: ALP Group

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

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

Канбан-доска во внутренней системе управления проектами. Источник: ALP Group
Канбан-доска во внутренней системе управления проектами. Источник: ALP Group

Вывод

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

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

1515
5 комментариев

Отлично)
Практика наших клиентов говорит о том, что лучше себя показывает именно Waterfall+SCRUM, но в любом случае нужно тестировать, какое решение подойдет именно вам. Своим клиентам мы советуем использовать более современные решения, чем 1С. У них проще интерфейс и внедрение.

1
Ответить

Да, конечно, интерфейс — не Jira 😅

1
Ответить

Тезисно согласен. Но тема имплементации Agile слабо раскрыта, только в последнем абзаце становится хоть немного понятно.

Гибкие методологии позволяют выпускать быстрые инкременты продукта, при этом не заморачиваясь с документацией (в том числе и с детальным ТЗ). В ситуации интегратора мне совершенно непонятно, как это происходит. Гигантская система и с плохой документацией? Быстрые релизы, когда куча взаимосвязей и распределение "в масштабах всей страны"?
Как ведется работа с заказчиками? То, что они требования формируют и прорабатывают уже на ходу - это рассказано в последнем абзаце. Но не ломает ли это "водопад"? Как они понимаю, что надо изменить, если они не получили предыдущего релиза? Или они не имеют шанса на HADI/переделку? Как их держать "в узде"?

Как происходит синхронизация между командами/узнали, когда доработка требуется во многих места?. Одна команда выдаст результат через два спринта, другая сможет взять в спринт только через 5 следующих спринтов. Демо клиент увидит через 6 месяцев?

Нужна еще одна статья)

1
Ответить

принято, при случае дополним

1
Ответить