Waterfall — что это и как совместить водопад с agile в проекте

Водопадная модель: этапы

Классическую последовательную схему описал Уинстон Ройс в статье 1970 года о разработке больших программных систем. Слово «waterfall» он не использовал, а саму схему без обратных связей считал рискованной. Название закрепилось позже, а модель стала стандартом госзаказов и крупных контрактов.

Этапы идут один за другим, как ступени водопада:

• сбор и анализ требований;
• проектирование;
• разработка;
• тестирование;
• внедрение;
• поддержка.

Где водопад работает

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

Почему заказчику нравится водопад

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

Agile и waterfall: в чём разница

Agile вырос из Манифеста гибкой разработки, который в 2001 году подписали 17 разработчиков. Вместо одного большого плана — короткие итерации, обычно от одной до четырёх недель, после каждой — работающий результат и решение, что делать дальше.

Почему чистый waterfall ломается в заказной разработке

Стандартное желание клиента — сразу понять, сколько будет стоить проект. При этом чёткого понимания, что должно получиться на выходе, у него, как правило, нет. И это нормально. Сложно заранее представить, как всё будет выглядеть, что будет нажиматься и как поведут себя ваши покупатели.

Проект B2B-платформы может идти год. За это время у клиента многое меняется. Если вы скрепили всё контрактом с фиксированной стоимостью, сроком и результатом, подрядчик не даст поменять проект, и вы будете заведомо делать продукт на выброс.

Бывает и наоборот: подрядчик вписывается в фиксированную цену на серьёзном контракте и уходит в минус. У нас тоже такое было. После одного проекта я мог бы купить квартиру, если бы его не делал.

Agile внутри waterfall

Мой ответ — agile внутри waterfall. Клиенту нужна прогнозируемость, проекту нужна вариативность. Поэтому общая цель, границы и бюджет фиксируются наперёд, как в водопаде, а работа идёт короткими циклами со сверкой каждую неделю. Большие компании со зрелыми ИТ-службами это понимают: какой бы срок ни обещал подрядчик, фиксированным подходом гарантированного результата не получить.

Такой гибрид часто называют agile-waterfall. В 2011 году аналитики Forrester описали его как Water-Scrum-Fall: требования и бюджет — по водопаду, разработка — по Scrum, выпуск — снова по регламенту.

Как это выглядит на проекте

Схема из трёх шагов, которую мы применяем на проектах B2B-платформ.

Предпроектное обследование

Сейчас его модно называть discovery-фазой. Вы говорите с клиентами о том, что они ждут от продукта и нужен ли он им. Говорите с ИТ-службой об ИТ-ландшафте и интеграциях. Прописываете, как пользователь будет себя вести, какие кнопки нажимать, где возможны сбои и возражения. Это занимает недели, иногда месяцы, и стоит в среднем от 0,5 до 1,5 млн рублей.

ИТ-служба клиента говорит одно, коммерческий директор — другое, логист — третье. Кто-то должен их соединить. Иногда у клиента есть такой человек, и это не должность, а роль, product owner. Если его нет, нужен кто-то снаружи, кто проведёт встречи, а аналитик потом выпишет ТЗ: здесь числовые значения, здесь текстовые, процесс работает так.

Коридор бюджета 20%

Обследование даёт коридор стоимости с вилкой около 20%. Это честнее, чем фиксированная цифра без понимания задачи, и точнее, чем «посчитаем по ходу». Внутри коридора задачи приоритизируют: если появилось важное, что-то менее важное уходит во вторую очередь, а общая сумма остаётся в рамках.

Еженедельные встречи

Когда проект идёт, каждую неделю смотрим: что сделано, какие есть проблемы, то ли мы делаем. Даже если всё выписано в документе, важнее понять, будут ли этим пользоваться ваши клиенты и удобно ли им. Если пошли не туда, в коридоре есть место, чтобы доделать и подпилить так, чтобы устроило логистов, финансы и конечного покупателя.

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

Методологии управления проектами, которые совмещают подходы

Гибридная схема придумана не нами. Александр Пашигрев в подкасте вспомнил клиентов из ИТ-топ-менеджмента крупного ритейла, которые продвигали PRINCE2. Эту методологию в 1996 году выпустило правительство Великобритании. Проект в ней делится на управляемые этапы: общая цель и обоснование задаются наперёд, а на границе каждого этапа решают, продолжать ли и как.

В нашей практике гибрид особенно нужен, когда в проекте много участников со стороны клиента: коммерческая служба, логисты, финансы, ИТ. Каждый видит продукт по-своему, и только регулярная сверка не даёт проекту уйти в сторону одной службы.

Другие известные методологии: PMBOK от PMI, Scrum с итерациями до месяца, Kanban с непрерывным потоком задач. На практике большинство ИТ-подрядчиков смешивает их, и важнее не название, а договорённость с заказчиком о том, как вы вместе управляете изменениями.