Модель Agile SDLC представляет собой комбинацию итеративных и инкрементальных моделей процессов с акцентом на адаптивность процессов и удовлетворенность клиентов за счет быстрой доставки работающего программного продукта. Agile Methods разбивает продукт на небольшие инкрементальные сборки. Эти сборки предоставляются в итерациях. Каждая итерация обычно длится от одной до трех недель. Каждая итерация включает кросс-функциональные команды, работающие одновременно в различных областях, таких как —
- планирование
- Анализ требований
- дизайн
- кодирование
- Модульное тестирование и
- Приемочное тестирование.
В конце итерации рабочий продукт отображается клиенту и важным заинтересованным сторонам.
Что такое Agile?
Agile модель считает, что каждый проект должен обрабатываться по-разному, а существующие методы должны быть адаптированы в соответствии с требованиями проекта. В Agile задачи делятся на временные рамки (небольшие временные рамки) для предоставления определенных функций для выпуска.
Применяется итеративный подход, и рабочая сборка программного обеспечения доставляется после каждой итерации. Каждая сборка является инкрементальной с точки зрения возможностей; финальная сборка содержит все функции, требуемые заказчиком.
Вот графическая иллюстрация Agile Model —
Agile мыслительный процесс начался на ранней стадии разработки программного обеспечения и стал популярным со временем благодаря своей гибкости и адаптируемости.
К наиболее популярным методам Agile относятся Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), адаптивная разработка программного обеспечения, функционально-ориентированная разработка и метод разработки динамических систем (DSDM) (1995). Теперь они все вместе называются Agile-методологиями после публикации Agile Manifesto в 2001 году.
Ниже приведены принципы Agile Manifesto —
-
Индивидуумы и взаимодействия. В гибкой разработке важны самоорганизация и мотивация, а также такие взаимодействия, как совместное размещение и парное программирование.
-
Рабочее программное обеспечение. Демонстрационное рабочее программное обеспечение считается лучшим средством связи с клиентами для понимания их требований, а не просто в зависимости от документации.
-
Сотрудничество с клиентами — поскольку требования не могут быть собраны полностью в начале проекта из-за различных факторов, постоянное взаимодействие с клиентами очень важно для получения надлежащих требований к продукту.
-
Реагирование на изменения — Agile Development ориентирована на быстрое реагирование на изменения и постоянное развитие.
Индивидуумы и взаимодействия. В гибкой разработке важны самоорганизация и мотивация, а также такие взаимодействия, как совместное размещение и парное программирование.
Рабочее программное обеспечение. Демонстрационное рабочее программное обеспечение считается лучшим средством связи с клиентами для понимания их требований, а не просто в зависимости от документации.
Сотрудничество с клиентами — поскольку требования не могут быть собраны полностью в начале проекта из-за различных факторов, постоянное взаимодействие с клиентами очень важно для получения надлежащих требований к продукту.
Реагирование на изменения — Agile Development ориентирована на быстрое реагирование на изменения и постоянное развитие.
Agile Vs против традиционных моделей SDLC
Agile основан на адаптивных методах разработки программного обеспечения , в то время как традиционные модели SDLC, такие как модель водопада, основаны на прогнозном подходе. Прогнозирующие группы в традиционных моделях SDLC обычно работают с подробным планированием и имеют полный прогноз точных задач и функций, которые должны быть выполнены в течение следующих нескольких месяцев или в течение жизненного цикла продукта.
Методы прогнозирования полностью зависят от анализа требований и планирования, выполненного в начале цикла. Любые изменения, подлежащие включению, проходят строгий контроль и управление изменениями.
Agile использует адаптивный подход, когда нет детального планирования и ясность будущих задач только в отношении того, какие функции необходимо разработать. Существует функционально-ориентированная разработка, и команда динамично адаптируется к изменяющимся требованиям к продукту. Продукт тестируется очень часто с помощью итераций выпуска, что сводит к минимуму риск возникновения серьезных сбоев в будущем.
Взаимодействие с клиентами является основой этой методологии Agile, а открытое общение с минимальной документацией — типичные особенности среды разработки Agile. Agile команды работают в тесном сотрудничестве друг с другом и чаще всего расположены в одном географическом месте.
Agile Model — за и против
Agile методы в настоящее время широко распространены в мире программного обеспечения. Однако этот метод не всегда подходит для всех продуктов. Вот некоторые плюсы и минусы Agile модели.
Преимущества Agile Model следующие:
-
Это очень реалистичный подход к разработке программного обеспечения.
-
Способствует командной работе и кросс-тренировке.
-
Функциональность может быстро развиваться и демонстрироваться.
-
Требования к ресурсам минимальны.
-
Подходит для фиксированных или меняющихся требований
-
Поставляет ранние частичные рабочие решения.
-
Хорошая модель для сред, которые постоянно меняются.
-
Минимальные правила, документация легко используется.
-
Обеспечивает одновременную разработку и доставку в общем запланированном контексте.
-
Мало или нет планирования не требуется.
-
Прост в управлении.
-
Дает гибкость разработчикам.
Это очень реалистичный подход к разработке программного обеспечения.
Способствует командной работе и кросс-тренировке.
Функциональность может быстро развиваться и демонстрироваться.
Требования к ресурсам минимальны.
Подходит для фиксированных или меняющихся требований
Поставляет ранние частичные рабочие решения.
Хорошая модель для сред, которые постоянно меняются.
Минимальные правила, документация легко используется.
Обеспечивает одновременную разработку и доставку в общем запланированном контексте.
Мало или нет планирования не требуется.
Прост в управлении.
Дает гибкость разработчикам.
Недостатки Agile Model следующие:
Не подходит для обработки сложных зависимостей.
Больше риска устойчивости, ремонтопригодности и расширяемости.
Общий план, проворный лидер и проворная практика PM — необходимость, без которой это не будет работать.
Строгое управление доставкой диктует объем, функциональность, которую необходимо доставить, и корректировки для соблюдения сроков.
В значительной степени зависит от взаимодействия с клиентами, поэтому, если клиент не ясно, команда может двигаться в неправильном направлении.
Существует очень высокая индивидуальная зависимость, так как генерируется минимум документации.
Передача технологии новым членам команды может быть довольно сложной из-за отсутствия документации.