В предыдущей статье мы рассматривали этапы разработки программного обеспечения. В этой же статье я хочу поговорить про методологии, которые используются при разработке ПО, обсудить их и выделить слабые и сильные стороны каждой из них.
Существует большое количество различных подходов к процессу разработки ПО. Какой из них выбирать и какому следовать зависит от специфики проекта, системы бюджетирования, субъективных предпочтений.
Меня зовут Антон. Я занимаюсь front-end разработкой и сейчас я расскажу вам об основных методологиях разработки.
Waterwall
Waterwall или же каскадная модель является одной из самых старых моделей и получила свою название из-за того, что процесс разработки происходит строго последовательно и переходит из одной стадии в другой подобно водопаду.
Благодаря прямолинейности подхода основные требования к продукту, сроки и бюджет изначально определены. Однако, есть и свои минусы: нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или находится на крайней стадии завершения. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий.
Плюсы:
- Чёткая последовательность
- Стабильность требований
- Строгий контроль менеджмента проекта
- Облегчает работу по составлению плана проекта и сбора команды проекта
- Хорошо определяет процедуру по контроля качества
Минусы:
- Отсутствие гибкости
- У Заказчика нет возможности ознакомиться с продуктом на процессе разработки
- У Пользователя нет возможности привыкать к продукту постепенно
- Все требования должны быть известны в начале жизненного цикла проекта и не изменяться
- Возникает необходимость в жёстком управлении и регулярном контроле, иначе проект быстро выйдет из графиков
- Отсутствует возможность учесть переделку, весь проект делается за один раз
Эту методологию стоит применять в тех случаях, когда требования известны, понятны и зафиксированы и противоречивых требований не имеется. Также нет проблем с доступностью программистов нужной квалификации.
Incremental Model
Суть инкрементной методологии в том, что создается в несколько инкрементов (сборок) ПО, но линейно. Благодаря такой системе улучшение программного продукта выполняется беспрерывно по плану до того момента, пока жизненный цикл ПО не придет к завершению.
Требования к проекту озвучиваются перед началом работы, далее процесс создания осуществляется последовательно, где каждая версия – это законченный, готовый к работе продукт.
Плюсы
- Можно просмотреть риски, связанные с затратами и дедлайном;
- Заказчик продукта может видеть результат разработки после каждой версии
Минусы
- Структура системы может нарушаться при постоянных обновлениях;
- Чтобы сборки выделялись, функциональную систему следует определить в начале жизненного цикла;
- График выполнения может не соблюдаться из-за ограниченности ресурсов (материальных, исполнительных).
Эту методологию стоит применять, когда основные требования к системе четко определены и понятны. В то же время некоторые детали и фичи могут дорабатываться с течением времени в новых сборках. Реализация системы сборок позволяет осуществить быстрый выход продукта на рынок и последующую его доработку.
Agile ( Scrum ) методология
Гибкая методология позволяющая заказчику контролировать процесс разработки и вносить изменения в конце каждого спринта.
Все процесс разработки делиться на спринты. Примерная продолжительность каждого спринта 1-4 недели. Чем меньше длительность спринта, тем легче заказчику контролировать процесс разработки.
Так же гибкая методология подразумевает проведение постоянных митингов и встреч для обсуждения проделанных задач, проблемах, которые возникли в процессе работы и планов на будущее
Методология подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка.
Плюсы
- Команда работает короткими этапами, на каждом из которых определяет цели и пути их достижения, что ускоряет процесс работы
- Большие задачи разделяют на мелкие, поэтому внести корректировки прямо в процессе работы намного проще
- Минимизация финансовых рисков благодаря оперативной реакции на изменения и устранение ошибок
- Каждый член команды четко знает свою задачу, следовательно, повышается уровень ответственности к работе
- Присутствует открытый обмен информацией, что делает процесс работы максимально прозрачным
- Поддержание высокого уровня мотивации в команде благодаря ежедневной видимости достижений.
Минусы
- Успех проекта во многом зависит от скрам-мастера (организатор процесса), квалификации команды и их приверженности своему делу;
- Далеко не всегда можно адаптировать метод скрам под сферу деятельности, поскольку есть проекты, требующие исключительно планового подхода в работе;
- Требует регулярной коммуникации с заказчиком, что порой тормозит процесс из-за невозможности получения обратной связи;
- Сложность внедрения в масштабных и сложных проектах, так как больше подходит для малых и средних.
Agile стоит применять, когда потребности пользователей постоянно меняются в динамическом бизнесе.
Заключение
В этой статье мы разобрали основные методологии, которые применяются при разработке программного обеспечения, выделили их плюсы и минусы и определились с кем, когда их стоит применять на практике. В следующих статьях будут разобраны методологии, которые не вошли в эту статью
