.jpeg)
Что такое водопадный подход
Водопадная или каскадная модель разработки программного обеспечения (waterfall, водопад) – это процесс разработки, в котором последовательно идут фазы сбора и анализа требований, проектирования и прототипирования, реализации, тестирования, интеграции и поддержки. Линейный подход к разработке программного обеспечения состоит из нескольких этапов:
- Требования. Ключевой аспект водопадного подхода заключается в том, что все требования заказчика собраны в самом начале работы. Это позволяет заранее спланировать каждую из последующих фаз следовать намеченному плану без значительных отклонений.
- Проектирование. Лучше всего фаза проектирования работает при делении на две подфазы: логическую, когда возможные решения обдумываются, и физическую, когда предложенные решения собираются в определенные требования.
- Внедрение. Эта фаза подразумевает непосредственно работу программистов в соответствии с заранее установленными на предыдущих этапах требованиями.
- Подтверждение. На этом этапе заказчик проверяет продукт и удостоверяется в том, что все требования совпадают и изначальными. Данный этап завершается выпуском продукта на рынок.
- Обслуживание. Заказчик регулярно использует продукт во время этого этапа, обнаруживает недочеты и ошибки в работе приложения. Команда разработчиков исправляет их до тех пор, пока заказчик не будет удовлетворен.
Плюсы
В водопадном проекте каждый из этих этапов представляет собой отдельный, не связный с другими, период работы, и, как правило, каждый этап завершается до начала следующего. Часто между разными стадиями разработки есть «пропускной пункт», когда заказчик рассматривает и оценивает промежуточные результаты работы. Вот несколько важных плюсов такого подхода:
- Разработчики и заказчики «на берегу» договариваются о результатах работы. Это позволяет спланировать и набросать макет финального продукта, не переживая о концептуальных изменениях по ходу работы;
- Прогресс работы легче измерить, так как итоговый продукт обозначен заранее;
- По ходу разработки разные члены команды могут заниматься другими проектами, в зависимости от стадии разработки продукта. Например, бизнес-аналитики могут подготовить документацию, пока программисты заняты другой работой, а тестировщики могут определить важные для рассмотрения и тестирования области в тот момент, когда программа еще находится в разработке, так как у них заранее есть необходимая документация, и они знают, какой продукт получится на выходе, и где возможно возникновение слабых мест;
- Присутствие заказчика необходимо только на начальных и финальных этапах.
- Наконец, программное обеспечение может быть более качественно спроектировано, основываясь на более полном понимании всех частей поставляемого продукта. Благодаря этому удается избежать так называемого «фрагментарного эффекта», когда части кода разработаны и добавлены в приложение без учета того, будут ли они хорошо в нём работать.
Минусы Waterfall
Но ни одна методология не обойдется без минусов, и в водопадном подходе есть, по меньшей мере, два существенных:
- Самый серьезный недостаток – это проблемы со сбором и подготовкой требований к финальному продукту. Оформление требований в документ, который понравится заказчику – часто самый трудный из этапов разработки. Клиенты часто путаются в деталях и особенностях, которые при Waterfall необходимо учитывать на стадии планирования. К тому же, даже с необходимой документацией, заказчик не всегда может визуализировать финальный продукт. Проекты и макеты способны помочь, но ни для кого не секрет, что большинство конечных пользователей могут испытывать некоторые сложности с сопоставлением всех элементов из документации с тем, что получится в итоге.
- Еще один потенциальный минус водопадного подхода в его чистом виде (о других видах речь пойдет ниже) в том, что заказчик, с некоторой вероятностью, может остаться недовольным конечным продуктом. Так как все требования обговариваются заранее, и присутствие заказчика на всех этапах разработки необязательно, неправильное представление результата может очень сильно увеличить стоимость разработки, ведь водопадный подход не обладает гибкостью Agile, а значит, все изменения вносятся после окончания работы, и это гораздо дороже и дольше, чем корректировка курса работ на каждом из этапов.
Sashimi Waterfall
Некоторые из недостатков водопадной модели попытались исправить в одной из ее модификаций: Sashimi Waterfall (Сашими). В ней этапы, как и в оригинальной методике, идут друг за другом, но при этом перекрываются один другим во времени. Это позволяет начать разработку дизайна еще на этапе сбора информации, а значит, добавляет так сильно недостающую гибкость в процесс. Затраты при этом растут не сильно, а сама методология не превращается в Agile.
Waterfall или Agile: какой подход выбрать?
Возможно, перед менеджерами подразделений будет стоять вопрос, какая из методологий более предпочтительна при разработке IT продуктов. Данная таблица поможет расставить все на места.
|
Особенность методологии |
Agile |
Waterfall |
Комментарий |
|
Доступность для заказчика |
Заказчик дает комментарии по ходу разработки |
Присутствие заказчика необходимо в начале и в конце разработки |
В любой из методологий вовлеченность заказчика уменьшает риски |
|
Цель / особенности |
Изменения по ходу разработки приветствуются, но требуют дополнительных затрат ресурсов и времени. Хорошо подходит для случаев, когда концепция финального продукта до конца не ясна |
Хорошо подходит, когда концепция определена с самого начала, либо с заранее установленными ограничениями по времени и смете расходов |
Перемен чаще всего не избежать, поэтому стоит прибегать к гибкости, если это возможно. Строгие условия контракта не позволяют этого достичь. |
|
Приоритеты разработки |
«Приоритет ценности» обеспечивает разработку самых нужных функций до всех остальных, что уменьшает риски получения нестабильного продукта, как только финансирование закончится. Эффективность финансирования максимальна. Уменьшает риск полного провала, так как возможен «частичный успех» |
Необходимо выполнить все, что обговаривалось вначале. Такой подход позволяет клиенту получить именно тот продукт, который был запланирован. Подход «все или ничего» увеличивает риск провала |
В условиях контрактов может быть отдельно прописано, что «частичный успех» неприменим
|
|
Команда |
Предпочтительней небольшая, обособленная команда с высоким уровнем организованности и слаженности |
Координация и слаженность команды ограничена точками передачи ответственности (при переходе с этапа на этап) |
Лучше работать сообща, но, если задания выполняются разными командами, то слаженность не является ключевой характеристикой |
|
Финансирование |
Отлично работает в случаях, когда деньги и время не имеют жестких ограничений, но работа ухудшается при появлении рамок |
Уменьшает риски при наличии фиксированной цены, так как договоренности установлены заранее |
При отсутствии финальной концепции продукта, ограничения финансирования могут помешать команде закончить работу |
|
Итог |
За отсутствием ограничений – Agile более предпочтителен |
Плановая работа обеспечивает более низкие риски в случаях, когда контракты заключаются с внешними заказчиками, например при работе с государственными компаниями |
Каждый из перечисленных факторов не равнозначен, все определяется в зависимости от проектов и обстоятельств |
Чтобы оставить комментарий пожалуйста Авторизуйтесь