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

Осознаете вы это или нет, но вы, вероятно, работали над проектом на каком-то уровне, который напоминает методологию водопада. В традиционном методе водопада шаги должны выполняться в последовательном порядке. После завершения одного этапа команда может перейти к следующему этапу. Существуют разные интерпретации того, сколько должно быть стадий, но обычно их 5–8. Большинство водопадных проектов состоят из следующего: Требования, проектирование, внедрение, тестирование и обслуживание. Дополнительные этапы, которые люди добавят в свою структуру, включают этапы явного замысла и инициации в начале, а также этап развертывания. На этапе требований цель состоит в том, чтобы создать документ, содержащий все требования, которые должен выполнить проект. Это включает определение масштаба проекта и понимание того, какими должны быть результаты проекта. Требования могут быть собраны посредством интервью с конечными пользователями, мозгового штурма и общения с клиентом. Окончательные требования хранятся в специальном документе под названием «Спецификация требований к программному обеспечению» (SRS), который действует как контракт между разработчиком и заказчиком. Этот документ проверяется и утверждается как командой разработчиков, так и заказчиком, прежде чем перейти к следующему этапу процесса.

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

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

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

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