Технологии разработки и внедрения программ Waterfall и Agile — плюсы и минусы

Введение

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

Технология Waterfall

Waterfall - это наиболее популярная в России технология разработки и внедрения программных продуктов. Она предполагает последовательное выполнение определенных этапов проекта без возможности итерационного возвращения к предыдущим этапам. Как вода в водопаде течет только сверху вниз, так и технология Waterfall предусматривает только последовательное выполнение проекта от первого этапа до последнего.

История происхождения этой технологии не совсем обычная. Ее можно даже назвать курьезной. Дело в том, что в статье американского инженера Уинстона Ройса «Управление разработкой крупных программных систем», вышедшей в 1970 году, был описан последовательный, каскадный подход к разработке программ. Разработка начиналась со сбора и анализа требований, потом шли проектирование, кодирование, тестирование и внедрение в работу.

Рис.1. Схема разработки и внедрения программы от Уинстона Ройса

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

Курьез же ситуации в том, что ИТ сообщество восприняло диаграмму, которую критиковал Ройс, как руководство к действию. В его статье она шла первой и была наиболее простой. Подход начал активно применяться, но без использования хоть каких-то итераций. И в итоге попал в различные стандарты разработки. Диаграмма Ройса напоминала водопад, и именно под таким называнием ее стали упоминать в дальнейших публикациях. Хотя сам Ройс термин «waterfall» не использовал.

У технологии Waterfall есть следующие преимущества:

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

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

• Подробный перечень работ и результатов, жесткая последовательность их выполнения позволяют эффективно планировать выполнение работ и контролировать их результативность;

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

Однако, у технологии Waterfall есть и серьезные недостатки:

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

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

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

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

Технология Agile

Более современная технология разработки и внедрения Agile («гибкая методология разработки») - это не совсем технология. По сути это манифест, провозглашенный экспертами ИТ-отрасли в 2001 году. 17 известных специалистов, авторов книг, собрались на горнолыжном курорте в США, чтобы дать ответ на проблемы каскадного подхода в разработке. В результате многодневного мозгового штурма и родился Agile-манифест, который постепенно стали подписывать ИТ-команды со всего мира.

Рис. 2. Agile — манифест.

Из манифеста следовали 12 принципов разработки и внедрения программ.

Рис.3. Принципы Agile.

Идеям этого манифеста соответствуют конкретные технологии разработки, такие как Scrum. Если перейти к технологиям на основе Agile, можно сказать, что они предполагают:

• Формирование списка требований к продукту с установкой приоритетов;

• Разбиение разработки и внедрения на циклы (спринты), в которых реализуются требования в порядке их приоритизации;

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

Технологии на базе ценностей и принципов Agile имеют следующие преимущества:

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

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

• Возможность начать использование продукта, не дожидаясь полного окончания его разработки. Это происходит потому, что наиболее важные требования реализуются в первую очередь;

• Вовлеченность команды заказчика. Заказчик не просто формирует требования, он постоянно видит прототип, и дает обратную связь;

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

Однако, у технологий Agile есть и недостатки:

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

• Риск неуправляемого роста требований и бесконечное откладывание сроков завершения проекта. Войдя во вкус, и видя, как позитивно разработчики относятся к удовлетворению требований, пользователи придумывают новые и новые улучшения прототипа;

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

• Сложность проведения замен в команде подрядчика. Документации практически нет. Погружение специалиста в предметную область происходит медленно и требует участия, как минимум, в двух-трех спринтах;

• Высокие требования к сплоченности и дисциплине в команде подрядчика. Без навыков работы в условиях отсутствия четких требований процесс разработки может стать неуправляемым.

Сравнение технологий на основе Agile и Waterfall

В таблице ниже приведено сравнение двух подходов к разработке и внедрению программ

Параметр	Waterfall	Agile
Требования	Определяются в начале проекта и почти не меняются в процессе	Переопределяются постоянно на всем протяжении проекта
Документация	Подробная	Минимальная
Бюджет и сроки проекта	Определяются в начале проекта и почти не меняются в процессе	Не определены изначально и определяются по ходу проекта
Участие заказчика в процессе	Эпизодическое	Постоянное и высокое
Затраты	Высокие или средние	Неопределенные, зависят от степени реализации требований
Соответствие результата ожиданиям заказчика	Среднее или низкое	Высокое

 Рекомендации по выбору технологии

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

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

• Наличие команды с опытом работы по технологиям на основе Agile. Так как технология не очень распространена в России, найти хорошего скрам-мастера и сплоченную команду может оказаться большой проблемой;

• Наличие или отсутствие готового прототипа внедряемой системы. Если прототип есть, и требуется только доведение его «до ума» на конкретном объекте, то лучше применять технологии на базе Agile. Это даст быстрый результат, сократит сроки и бюджет проекта за счет отсутствия необходимости создавать большую проектную документацию.