Управление изменениями в «водопадных» проектах

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

Откуда вообще берутся изменения в «водопадных» проектах и почему это может быть проблемой?

«Водопадная» модель разработки в принципе не предназначена для реализации проектов в стиле «ввяжемся в бой, а там война план покажет». Водопадная методология «заточена» под хорошо прогнозируемые проекты с понятными изначально ожиданиями, а на проектах с высокой долей неопределенности она часто даёт сбои.

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

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

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

Методики работы с изменениями

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

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

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

В этом случае проект продолжает выполняться по прежнему плану (или незначительно измененному), а новые задачи прорабатываются (а часто и реализуются) параллельно с прежними. Превышение бюджета тут тоже крайне вероятно, но в сроки проект имеет все шансы уложиться.

Мелкие изменения, которые выходят за рамки проекта, чаще всего рациональнее выполнять уже после завершения основных работ. Непрерывный поток «небольших» изменений часто просто парализует выполнение работ, так как производственные ресурсы уходят на обработку входящей информации. Или изменения приводят к проблемам, если фаза анализа пропускается и полученные изменения сразу идут «в работу».

Еще можно имитировать «водопад» в рамках итеративной разработки — тут поможет чёткий общий план работ (roadmap), который, по сути, является ТЗ «водопадного» проекта, но может вполне успешно использоваться в рамках фактической итеративной разработки. При этом надо понимать, что такой подход не очень рационален, так как он в конечном счёте может иметь все минусы и той, и другой методологии.

Резюме

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

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

Водопадная модель разработки программного обеспечения — это процесс разработки, в котором все необходимые этапы проходят строго последовательно.

Разработка ПО по водопадной модели начинается со сбора и анализа требований, затем следует фаза проектирования и прототипирования. После завершения полного проектирования начинается этап программной реализации. После завершения этапа программирования разработанный продукт тестируется на соответствие требованиям. Затем осуществляется интеграция и запуск, после чего проект переходи в фазу поддержки и сопровождения.

Узнать больше →

Разработка ПО на основе водопадной модели эффективна при полном и детальном понимании целей и задач проекта. Благодаря работе по строгой спецификации, эта модель позволяет строго зафиксировать бюджет и сроки проекта.

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

Жизненный цикл проекта при итерационной разработке разбит на последовательность итераций. Каждая из этих итерации, по сути, является водопадным проектом в миниатюре, то есть включает в себя все ключевые процессы разработки ПО и результатом работы по каждой итерации обычно является пригодная для использования версия продукта.

Узнать больше →

Итеративная разработка — это оптимальный выбор:

  • для больших проектов
  • для проектов с размытыми требованиями
  • для инновационных продуктов и стартапов
  • для проверки бизнес-гипотез
  • для запуска в сжатые сроки

Cтатьи по теме:

Ошибки при разработке сайтов: старт проекта без целей, задач и проектирования
Часто, когда встает вопрос о создании сайта, цели и задачи не формулируются или формулируются нечётко. В этом случае вы никогда не получите то, что хотели, так как разработчикам просто непонятно что именно вы хотите.
Ошибки при разработке сайтов: субъективный подход к дизайну и стремление к самовыражению
Как часто можно услышать это: «Сайт должен быть стильным», «Сайт должен внушать доверие», «Мой дизайн должен быть эксклюзивным и непохожим на другие» и другие варианты необъективных критериев. «Стильное, лаконичное, внушающее доверие» — это все субъективные оценочные критерии, которые зависят от восприятия каждого конкретного человека.
Ошибки при разработке сайтов: отсутствие аналитики и развития после запуска
То, что сайт разработан и запущен, еще не означает, что можно больше ничего не делать и продажи резко пойдут вверх. Впереди еще много работы.
Наши принципы ценообразования: сколько стоит разработка, поддержка, продвижение и реклама сайта?
Мы предлагаем индивидуальные решения: в каждом конкретном случае необходим различный объём оказываемых услуг, а значит и стоимость может отличаться в очень широких пределах. Мы оказываем качественные услуги и ценим свою работу, а взаимоотношения с Клиентами строим на взаимовыгодной основе.
Сколько стоит разработка сайта?
​Ежедневно мы отвечаем на этот вопрос и не один раз. Очень часто это первый вопрос позвонившего Клиента. Мы понимаем, что Клиенты устали слушать, что всё зависит от сложности разработки этого самого сайта.
Как написать функциональное техническое задание?
Описывайте нужные функции в формате сценария использования. Такой формат позволяет сделать пункты ТЗ объективными, просто изложенными и элементарным способом проверяемыми требованиями.
Создание дизайна сайта или веб-приложения
Создание дизайна для сайта или веб-приложения — это самый субъективно оцениваемый этап разработки, часто вызывающий сложности как на этапе постановки задачи, так и на этапе сдачи-приёмки выполненных работ.

Тематические технологии:

Язык программирования Ruby
Фреймворк Ruby on Rails
PostgreSQL — объектно-реляционная СУБД
Поисковая система ElasticSearch
СУБД Redis
Язык программирования Go
Язык программирования Python
Язык разметки HTML
CSS — каскадные таблицы стилей
Язык программирования JavaScript
Библиотека React
Библиотека MobX
Библиотека MobX State Tree
Система сборки WebPack
Платформа NodeJS
Red Hat Enterprise Linux