4.1 Методологии разработки ПО : водопадная, V-образная, Agile модель
Для того чтоб разработать качественное программное обеспечение, нужно следовать некой последовательности, стратегии и принципам. Все данные пункты можно назвать одним словом - Методология.
Какие бывают методологии?
Методология разработки ПО – это процесс описания того, как определенный продукт будет разрабатываться, то есть один из способов организации коллективной разработки. Существует множество разных моделей такого процесса, каждая из которых описывает свой подход и нельзя сказать, что среди них выделяется одна, которую нужно использовать в каждом проекте, всё сугубо ситуативно.
Я хочу выделить 3 основных методологии, это:
Водопадная модель
Водопадная модель - каждый этап разработки последовательного цикла продолжает предыдущий. По факту это наш Жизненный цикл разработки программного продукта – SDLC, который мы обсуждали с вами ранее.
Она включает в себя следующие этапы: требования-проектирование-разработка-тестирование-релиз-поддержка
Данная модель подходит под долголетние проекты в крупных компаниях, когда есть возможность первоначально составить требования, полноценные, включить в них все и на протяжении всего процесса разработки их не менять, подготовить дизайн-проект, написать полностью код проекта и только потом его протестировать, это очень важно, тестирование идет не параллельно с разработкой, а только после ее полнейшего завершения. Далее идет релиз, всего продукта, а не поэтапно и поддержка.
+ полное документирование каждого этапа, всегда доступны требования
+ возможность распланировать сроки и затраты
- необходимо утвердить полный объем требований к системе, в случае необходимости внести новые требования, мы не можем вернуться к старым и нам необходимо переделать все заново
- увеличение затрат времени и средств, при необходимости внесения новых требований
Пример такого проекта: крупный банк решил создать внутренний чат для своих сотрудников, он может позволить потратить на это длительный промежуток времени, пока его сотрудники пользуются общедоступными приложениями, например Jabber.
Когда-то данная модель была очень популярна и применялась повсеместно, но сегодня эта модель не может удовлетворить быстро меняющиеся технические потребности
V-образная модель
V-образная модель - это модифицированная версия каскадной – тестирование начинается со стадии написания требований и происходит на каждом этапе.
Особенностью V-образной модели можно считать то, что она направлена на тщательную проверку и тестирование продукта, находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время написания кода разработчиками пишутся модульные тесты.
- отсутствие возможности внесения динамических изменений
- написание кода происходит только в середине процесса
- Если требуется тщательное тестирование продукта.
- Для малых и средних проектов, где требования четко определены и фиксированы.
- В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.
V-образная модель может быть чрезвычайно полезна в случаях, когда ошибки могут быть фатальными, и в проектах, где точность имеет решающее значение.
Итерационная модель
Итерационная модель – жизненный цикл создания продуктов разбит на ряд минициклов. И самая популярная из них это Agile.
Итерация- разработка отдельного компонента системы, после чего добавляется к ранее разработанным компонентам.
В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели.
Данная методология подходит для больших или нацеленных на длительный жизненный цикл проектов, которые постоянно адаптируются к условиям рынка и готовы изменить направление в любой момент. Соответственно, в процессе реализации проекта его требования могут изменяются.
+ раннее создание работающего ПО
+ очень гибкая, готова к изменениям на любом этапе разработки
Agile
Agile – набор методов и принципов гибкого управления проектами
12 принципов Agile
Фактически, существует 12 принципов гибкой разработки, которые сводятся к следующим ценностям:
- люди и взаимодействия важнее процессов и инструментов (если есть принципы, которые мешают нашей работе, то от них нужно избавиться. Люди должны сами выбирать инструменты и процессы). От себя хочу добавить, что на практике это не всегда возможно и заказчики могут выставить жесткие условия, что хотят, чтоб их продукт был разработан на конкретных технологиях.
- работающий продукт важнее исчерпывающей документации (большая часть времени должна уходить на функционал продукта, а не на документацию). Не стоит сбрасывать со счетов ведение документации, так как она необходима для поддержки и сопровождения продукта в целом, а также если заказчик захочет в будущем нанять иную организацию для продолжения разработки продукта.
- сотрудничество с заказчиком важнее согласований условий контракта (не должно быть избыточной привязанности с контрактом, который регулирует наши взаимоотношения с заказчиком). Думаю, здесь все понимают, что контракт есть контракт и любые юридические разбирательства будут идти именно согласно контракту.
- готовность к изменениям важнее следования первоначальному плану (мы в любом случае будем вносить изменения). Очень важно чтоб все эти изменения были задокументированы и согласованы.
12 принципов Agile
- Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения. - Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
- Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
- На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
- Над проектом должны работать мотивированные профессионалы. Чтобы
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им. - Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды. - Работающий продукт — основной показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки. - Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта. - Простота — искусство минимизации лишней работы — крайне необходима.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать
стиль своей работы.
Основная составляющая данной методологии это - Спринт – временной отрезок в 2-4 недели, в течении которого у нас создается часть продукта, которая соответствует тем требованиям, которые мы берем в начале спринта. В начале каждого спринта мы набираем часть задач, которые должны реализовать за этот промежуток времени. А после должны произвести релиз разработанного функционала, но на практике может происходить, что релизы бывают и каждый день, поэтому не всегда есть четкая привязка к спринту.
Agile включает в себя две вариации:
Kanban
Kanban – это конвейерная схема. У нас имеется общий backlog задач, своего рода список задач, которые необходимо сделать для завершения проекта и где они берутся и выполняются поочередно. Мы переносим задачу в разработку, тестируем ее и отправляем в релиз и пока она не будет выполнена, мы не берем следующую.
- Визуализация – то есть у нас с Вами есть backlog с задачами, которые требуется выполнить.
- Имеется план разработки, которому придерживается команда, составленный по приоритету. Может меняться в любой момент.
- Ограничение одновременно выполняемых задач. Как правило команды на Kanban проектах малочисленны, поэтому одновременно в разработке небольшое количество задач
- Постоянная оптимизация разработанных процессов.
Отдельно необходимо отметить, что Kanban хорошо работает в стартапах, не имеющих четкого плана, но активно работающих над разработкой.
Scrum
Scrum – это так же конвейерная схема, но в ней возможно производство одновременно нескольких задач. Scrum проекты разбиты на спринты, то есть небольшой объём работы, который необходимо выполнить в течение определённого, оговоренного заранее, периода времени. Заказчик по итогу спринта, должен получить готовый функционал. То есть передача продукта заказчику идет небольшими частями. Мы выбрали на этот спринт из backlog 10 задач, они могут разрабатываться параллельно или последовательно, в зависимости от численности нашей команды, проходить через следующие этапы:
Анализ-разработка-разработка завершена-тестирование-релиз.
После анализа задача попала в разработку, как только она завершилась она попадает в стадию разработка завершена, где ее передают тестировщику, и если мы обнаружим баг, то мы возвращаем ее на этап разработки, если нет, то отправляем в релиз. В конце спринта подводятся итоги и остатки переносятся на следующий и так далее.
Допустим наш проект состоит из 10 блоков. На разработку каждого блока нам требуется 1месяц. Мы разрабатываем первый блок, запускаем его в релиз, и наш пользователь уже может пользоваться данным продуктом, далее второй блок и т.д.
Плюсы и минусы Agile методологии:
+ не нужно ждать полного завершения проекта, чтобы он начал функционировать;
+ возможность адаптироваться к изменениям на любой стадии проекта, сделать соответствующие изменения в самом продукте и документации;
+ возможность получить обратную связь от пользователей продукта еще во время разработки и скорректировать его.
- очень быстро устаревает написанная документация, поэтому требуется постоянное ее обновление;
- сложность планирование бюджета и полного срока разработки программного продукта, так как происходят постоянные изменения.
Сравнение всех 3 методологии:
На разработку 1 блока уходит месяц, следовательно, если мы используем схему Waterfall или V-образную, то наш продукт будет готов через 10 месяцев и только после этого у нас начнут появляться пользователи, отзывы и пожелания от них, и на исправление или если мы захотим внести что-то новое, на это уйдет очень много времени.
А если мы используем Aggile, то наш продукт начнет функционировать уже со второго месяца, и к концу разработки проекта, мы будем иметь большое количество пользователей нашего продукта и иметь обратную связь от них. А также мы сможем в любой момент изменить направление нашего продукта, в ту которая будет нам выгоднее.
На практике модели разработки программного продукта многовариантны. Нельзя сказать, что какая-то определенная модель идеальна и все должны следовать именно ей. Даже столь популярная модель Aggile не может применяться на каждом проекте из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии отчасти похожи друг на друга и частично пересекаются в своих принципах и средствах.