Ваш продукт. Каскадная модель или водопад
В прошлой статье разобрали основные методы разработки IT-продуктов. Предлагаю окунуться в детали наиболее известных из них. И первый кандидат - модель "водопад".
В мире разработки продуктов каскадная модель или водопад многим известна как нестареющая классика. Да, в чистом виде сейчас она мало где используется, но гибридные модели на основе каскадной очень даже распространены и по сей дей, несмотря на то Американский ученый-информатик Уинстон Уокер Ройс придумал и описал ее еще в 1970 году. А в 1976 году ученые Томас Белл и Томас Тэйер дали ей название.
Давайте немного пофантазируем, почему они назвали эту модель именно водопад?
может быть разработчики подобно гребцам лодок преодолевают водные пороги, опасаясь сделать лишнее движение и перевернуться?!
или же капли воды подобно блокам не самого удачно кода падают в бездну проекта и ждут там годами своего рефакторинга на дне лагуны?!
Увы, не всё так прозаично. Согласно данной модели, каждый этап создания продукта, словно поток воды, продолжает предыдущий и не может начаться, пока прошлый не завершился. Отсюда и сравнение с водопадом.
Сначала проходит этап определения требований.
После того как требования полностью установлены, происходит переход к проектированию, в ходе которого создается проектная документация, описывающая план реализации указанных требований.
Далее следует этап реализации проекта и интеграция отдельных компонентов, разрабатываемых различными командами, если таковое разделение имеется.
После того как реализация и интеграция завершены, производится тестирование и отладка продукта. на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки.
После этого программный продукт внедряется и обеспечивается его поддержка
Рассмотрим основные принципы водопадной модели разработки:
Следующий этап не начинается до того, как будет завершен предыдущий.
Пропуск этапов исключен.
Нельзя откатиться на прошлый этап, чтобы что-то изменить.
Важна чёткая документированность всех этапов работы.
Если в процессе разработки требования к продукту поменялись, необходимо внести изменения в ТЗ.
Разработка происходит в рамках одного общего процесса создания продукта, итераций нет.
Заказчик не может участвовать в создании продукта, кроме этапа разработки ТЗ.
Выявление и исправление ошибок происходит только после окончания разработки на этапе тестирования.
Всё выглядит довольно строго и нет места для отступа от правил. Может пора отказаться от водопада или он никогда не засохнет под знойным солнцем? Разбираемся в плюсах и минусах этой модели.
Плюсы:
* Определенность в сроках и бюджете. Стоимость продукта и сроки сдачи проекта рассчитаны и утверждены в начале и не меняются в процессе.
* Чёткая документация и требования. Наличие инструкций и правил по всему процессу. Планы, этапы и процессы утверждаются заранее, фиксируются в документах.
* Уменьшение времени ввода новых участников в проект. Т.к. для всех процессов есть описанные правила, то ввод нового участника разработки будет более гладким и быстрым
Минусы:
* Позднее обнаружение проблем и недостатков. Тестирование начинается после окончания разработки, поэтому часто недостатки обнаруживаются слишком поздно. Нельзя совместить разработку и тестирование, чтобы найти уязвимости.
* Отсутствие гибкости. Невозможно предусмотреть все проблемы в проекте заранее.
* Заказчик не допускается до разработки и тестирования. Если изменились требования или условия, заранее учесть это невозможно.
Когда же стоит применять модель Waterfall?
Заказчик твердо знает и четко представляет, что хочет получить. Заранее продумана концепцию и понятен, каким должен быть результат.
Клиент заранее определился со сроками и знает, какой результат ожидать на каждой стадии разработки.
Команде заранее известно, какими инструментами и подходами ее участники будут пользоваться, у них имеются типовые решения, на основе которых они будут работать над продуктом.
Устраивает полное ведение проекта подрядчиком. Заказчик не собирается принимать участие в разработке, контролировать и давать обратную связь исполнителям.
Все основные недостатки данный модели заключаются в отсутствии ее гибкости. Чтобы не находить ошибки слишком поздно и адаптировать проект под изменения обстоятельств, каскадной модели добавили несколько элементов гибких подходов. Такие методологии имеют большее распространение в наши дни и называются гибридными… Но это уже совсем другая история.
...Продолжение следует…
etime #бизнес #управление #саморазвитие #управлениепроектами
