Каскадная модель (англ. waterfall model, иногда переводят, как модель «Водопад») - модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

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

Для классической модели разработки программного обеспечения выделяют следующие этапы:

1. Анализ требований проекта. Определяются программные требования для информационной предметной области системы.
2. Проектирование. Разрабатывается и формулируется логически последовательная техническая характеристика программной системы. Детализация системы.
3. Реализация ПО. Воплощение полноценного проекта.
4. Тестирование продукта. Тестовая эксплуатация продукта
5. Интеграция системы. Включает установку и официальную приёмку продукта.
6. Поддержка. Предоставление технической помощи по продукту после запуска а коммерческую эксплуатацию.

Эта модель подразумевает строго последовательное и однократное выполнение каждой фазы проекта. Переход от одной фазы к другой возможен только после успешного завершения предыдущего этапа. Каждый этап подразумевает детальное планирование и полную корректность результата этапа.

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

ПРОЕКТ И ДОКУМЕНТАЦИЯ

Обратная сторона «медали» данного метода, это необходимость поддержки и постоянной актуализации документации разработки продукта. Любое изменение необходимо обязательно согласовывать с Заказчиком. А не достаточный уровень проработки требований несёт за собой увеличение бюджета и сроков проекта, которые довольно сложно оценить.

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

Каскадная модель подходит при разработки сложных и больших проектов и систем со строго определённой функциональностью. Использовать при разработке больших гос.заказов или научных разработках. Использовать данную методология для разработки бизнес-приложений крайне не желательно.

Мета информация

• Количество процессов - 6
• Команда - десятки человек

Минусы

• Watrefall проект должен постоянно иметь актуальную документацию. Обязательная актуализация проектной документации. Избыточная документация
• Очень не гибкая методологии
• Может создать ошибочное впечатление о работе над проектом (например фраза «45% выполнено» не несёт за собой никакой полезной информации, а является всего лишь инструментов для менеджера проекта)
• У Заказчика нет возможности ознакомиться с системой заранее и даже с «Пилотом» системы
• У Пользователя нет возможности привыкать к продукту постепенно
• Все требования должны быть известны в начале жизненного цикла проекта
• Возникает необходимость в жёстком управлении и регулярном контроле, иначе проект быстро выйдет из графиков
• Отсутствует возможность учесть переделку, весь проект делается за один раз

Плюсы

• Высокая прозрачность разработки и фаз проекта
• Чёткая последовательность
• Стабильность требований
• Строгий контроль менеджмента проекта
• Облегчает работу по составлению плана проекта и сбора команды проекта
• Хорошо определяет процедуру по контроля качества

Применение

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

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

Разработки ПО. Сегодня речь пойдёт о самой популярной из них – Waterfall, или каскадной методологии.

Общая концепция подхода была представлена доктором Уинстоном Ройсом ещё в 1970 году. В его основе лежит логическая последовательность шагов, которые должна быть предприняты на протяжении жизненного цикла разработки ПО. Каждый этап согласовывает компетентными сотрудниками, документируется и передаётся дальше.
Хотя популярность модели Водопада за последние годы ослабела, природа последовательного процесса, используемого в методе водопада, интуитивно ближе разработчикам, и потому доминирует в IT.

Как падает вода

Модель, предложенная Ройсом, предельно проста и понятна. Она состоит из 7 блоков, каждый из которых охватывает свою область ответственности.

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

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

Мы также сократим указанную модель до 6 блоков, объединив операции «Инсталляция» и «Поддержка» в одну – «Развертывание». Теперь взглянем на исполняемые функции:

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

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

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

Воплощение . Исполнительский этап, на который, как правило, приходится большая часть разработки. Если классическая модель допускает свободное взаимодействие с предыдущими этапами, то на практике допускается лишь внесение незначительных правок в «Конструирование».

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

Развертывание . Когда приложение создано, его можно предъявлять заказчику и выпускать на волю. Так как данный этап включает ещё и поддержку, поэтому взаимодействие с предыдущими фазами неизбежно.

Преимущества каскадной модели

В последние годы модель водопада уступает свои лидирующие позиции более гибким методологиям. Это связано с общей динамикой в IT, когда за разработку ПО отвечают команды из 5-9 человек, а дедлайн может быть легко сдвинут из-за наращивания функциональности.

Тем не менее, каскадная модель всё ещё актуальна для крупных проектов и организаций. И вот почему:

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

Недостатки каскадной модели

В 1970-х годах идеи Ройса были актуальны. Но спустя почти 50 лет метод каскадной разработки всё меньше подходит для IT. Вот почему:

• Неадаптивная структура ПО. На первых этапах модель водопада может быть гибкой, но если на фазе тестирования выявляются проблемы в общей структуре – это влечёт за собой плачевные последствия в виде сорванных сроков и даже отказов заказчика. Таким образом, возрастает роль руководителей и ответственных разработчиков, с уровнем компетентности которых в любой компании часто бывают проблемы.
• Игнорирует конечного пользователя. Чем ниже продвигается процесс в водопаде, тем меньше в нём роль заказчика, не говоря уже о клиентах, которых он представляет. Внесение каких-либо изменений в функциональность ПО запускает всю цепочку этапов заново, поэтому продукты полученные по каскадной модели далеки от ориентации на массового пользователя.
• Позднее тестирование. Из описания выше легко выявить самый проблемный этап методологии – тестирование. Именно здесь чаще всего выявляются ошибки, допущенные на каждом из этапов. Более гибкие методологии используют тестирование в качестве фундаментальной операции, происходящей непрерывно. «Водопад» же допускает низкую квалификацию сотрудников на каждом этапе и плохое качество исполнения, ведь при запоздалом тестировании проблемы невозможно решить фундаментально, только при помощи «заплаток».

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

1. При ориентации ПО на заказчика, требующего прозрачность работ и исполнение в назначенные сроки.
2. При наличии в штате руководителей соответствующей квалификации.
3. При исполнении проекта, не имеющего конкуренции на рынке.

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

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

В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке:

1. Определение требований
2. Проектирование
3. Конструирование (также «реализация» либо «кодирование»)
4. Воплощение
5. Тестирование и отладка (также «верификация»)
6. Инсталляция
7. Поддержка

Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей

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

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

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

Критика каскадной модели и гибридные методологические решения

Методику «Каскадная модель» довольно часто критикуют за недостаточную гибкость и объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству. Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным . Поэтому даже в PMBOK 3-ей версии формально была закреплена только методика «каскадной модели» и не были предложены альтернативные варианты, известные как итеративное ведение проектов .

Начиная с PMBOK 4-ой версии удалось достичь компромисса между методологами , приверженными формальному и поступательному управлению проектом, с методологами, делающими ставку на гибкие итеративные методы . Таким образом, начиная с 2009 года, формально предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «Водопада», так и достижения итеративных методологов.

См. также

Примечания

Ссылки

• Royce, Winston (1970), Managing the Development of Large Software Systems (англ.)

Wikimedia Foundation . 2010 .

Смотреть что такое "Каскадная модель" в других словарях:

В компьютерных вычислениях Модель хаоса это способ разработки программного обеспечения. Ее создатель Л.Б.С.Ракун отмечает, что такие модели управления проектами, как спиральная модель и каскадная модель, хотя и хороши в управлении расписаниями и… … Википедия

В классической теории баз данных, модель данных есть формальная теория представления и обработки данных в системе управления базами данных (СУБД), которая включает, по меньшей мере, три аспекта: 1) аспект структуры: методы описания типов и… … Википедия

Запрос «CSS» перенаправляется сюда. Но у этой аббревиатуры могут быть и другие значения см. CSS (значения). CSS (англ. Cascading Style Sheets каскадные таблицы стилей) технология описания внешнего вида документа, написанного языком разметки.… … Википедия

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

Это процесс ее построения и развития. Жизненный цикл информационной системы период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из… … Википедия

Жизненный цикл информационной системы это процесс ее построения и развития. Жизненный цикл информационной системы период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в… … Википедия

- (ЭИС) представляет собой совокупность организационных, технических, программных и информационных средств, объединённых в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации, предназначенной для выполнения функций… … Википедия

Экономическая информационная система (ЭИС) представляет собой совокупность организационных, технических, программных и информационных средств, объединенных в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации,… … Википедия

Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование … Википедия

Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия

Необходимо хорошо понимать основные принципы жизненного цикла ПО, требования заказчика к создаваемому продукту, а также учитывать его финансовые возможности.. Существует несколько моделей жизненного цикла (каскадная модель, спиральная модель, быстрое прототипирование и т.д.). Выбор определенной модели жизненного цикла зависит, в основном, от содержания и целей проекта, а также от размера его финансирования.

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

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

Давайте поочередно рассмотрим все этапы жизненного цикла:

1. Анализ требований

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

Обратите внимание: Чем больше информации о проекте вы соберете, тем меньше времени потратите на исправление ошибок, доработку проекта, пересмотры бюджета, обсуждения и решение других вопросов.

Видение проекта

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

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

Сбор требований

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

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

2. Проектирование программного обеспечения

Следующим этапом жизненного цикла ПО является создание документа, описывающего масштабы и границы проекта. Данный документ включает в себя мокапы или скетчи интерфейса будущего приложения, а также подробную спецификацию требований программного обеспечения. Необходимо отметить, что в некоторых случаях документ видения (образа) проекта и документ о масштабах и границах проекта могут быть представлены как единый документ “Об образе и границах проекта”.

Масштабы и границы проекта

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

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

Спецификация требований программного обеспечения

Спецификация требований программного обеспечения (SRS) описывает требования, которым должно отвечать создаваемое программное обеспечение. Она должна быть логичной, последовательной, доступной и полной. Требования могут выражаться в разных формах, например, в виде традиционных утверждений долженствования (н-р, “Система Staff Manager должна поддерживать следующие браузеры: Google Chrome, Apple Safari, Mozilla Firefox, Opera, IE 8+”) или в виде пользовательских историй (н-р, “поскольку я являюсь менеджером, мне необходим доступ к персональной информации всех сотрудников”).
Существует большое количество шаблонов спецификаций. Выбор определенного шаблона зависит от специфики проекта. В большинстве случаев, спецификация включает в себя описание продукта, классы пользователей, функциональные и нефункциональные требования к разрабатываемому программному обеспечению. Иногда в шаблон также входит прототип. Главное — сделать спецификацию понятной, лаконичной и полезной для разработчиков.

Для создания прототипа вам необходимо выяснить следующее:

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

Мокапы (или прототипы) передаются UI/UX-дизайнерам, которые превращают их в красочные шаблоны.

3. Разработка программного обеспечения

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

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

4. Тестирование программного обеспечения

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

5. Техническая поддержка программного обеспечения

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

Заключение

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

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

Данная статья была подготовлена под руководством опытных бизнес-аналитиков компании XB Software.

The following two tabs change content below.

Знаете ли вы, что существуют различные методологии управления проектами? Каждый из них включает в себя все основные рабочие циклы:

• Разработка требований
• Планирование
• Проектирование
• Кодирование
• Тестирование
• Оптимизация.

Сегодня мы поговорим о двух из них. Тех двух, что мы активно используем на своих проектах. Читаем, анализируем, выбираем. Перед вами сравнение двух методологий — Agile и Waterfall.

Agile

Эта методология базируется на 12 принципах (так называемый Agile манифест). Давайте познакомимся с ключевыми практическими постулатами Agile:

• Заказчик может изменять или корректировать свои требования на любом этапе разработки.
• Лучшим показателем эффективности команды является рабочее решение.
• Самым продуктивным способом общения является личное общение.
• Новые версии продукта выходят либо после каждой итерации, либо каждые несколько месяцев (в зависимости от проекта).

В 2015 году было проведено масштабное профессиональное исследование . Под его прицел попал 601 проект из сферы IT. Результат показал, что именно Agile сегодня является самым распространенным подходом к управлению проектами.

Agile: преимущества

• Возможность переделать проект полностью даже после прохождения нескольких итераций.

• Проект разделяется на короткие и прозрачные отрезки (итерации), в Scrum они называются спринтами.

• Гибкость Agile сводит все возможные риски к минимуму.

• Agile идеально подходит для разработки MVP.

Agile: недостатки

• Расчет бюджета проекта существенно усложняется постоянно меняющимися требованиями.
• Команда разработчиков должна быть не только высококвалифицированной, но и клиентоориентированной.
• Новые требования зачастую вступают в конфликт с текущей архитектурой проекта.
• Постоянные корректировки требований иногда приводят к ощущению, что проект никогда не закончится:)

Waterfall

Методология Waterfall базируется на принципе последовательного развития. Вкратце, схема управления проектом выглядит следующим образом:

1. Анализ требований
2. Планирование
3. Реализация
4. Тестирование и оптимизация
5. Развертывание
6. Поддержка

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

Waterfall: преимущества

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

Waterfall: недостатки

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

Что же выбрать?

Ваш выбор это Agile, если:

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

Ваш выбор это Waterfall, если:

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

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

Agile и Waterfall: заключение

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

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