Гибкая методология разработки – Agile модель
История
В течение 1990-х годов ряд легких методов разработки программного обеспечения развивался в ответ на преобладающие тяжелые методы, которые критики называли чрезмерно регулируемыми, планируемыми и микроуправляемыми. К ним относятся: быстрая разработка приложений (RAD) с 1991 года; унифицированный процесс и метод разработки динамических систем с 1994 года; Scrum, с 1995 года; Crystal Clear и экстремальное программирование (XP), как с 1996 года; и функционально-ориентированная разработка, начиная с 1997 года. Хотя все они возникли до публикации Манифеста гибкой методологии разработки программного обеспечения, теперь они все вместе называются гибкими методами разработки программного обеспечения.
В феврале 2001 года в штате Юта США был выпущен «Манифест гибкой разработки программного обеспечения». Он являлся альтернативой управляемым документацией «тяжеловесным» практикам разработки программного обеспечения, таким как «метод водопада», являвшимся золотым стандартом разработки в то время. Данный манифест был одобрен и подписан представителями методологий: экстремального программирования, Crystal Clear[en], DSDM, Feature driven development, Scrum, Adaptive software development, Pragmatic Programming. Гибкая методология разработки использовалась многими компаниями и до принятия манифеста, однако вхождение Agile-разработки в массы произошло именно после этого события.
Принципы
Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto. Agile не включает практики, а определяет ценности и принципы, которыми руководствуются команды.
Agile Manifesto разработан и принят 11—13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты. Agile Manifesto содержит 4 основные идеи и 12 принципов. Примечательно, что Agile Manifesto не содержит практических советов.
Основные идеи:
- люди и взаимодействие важнее процессов и инструментов;
- работающий продукт важнее исчерпывающей документации;
- сотрудничество с заказчиком важнее согласования условий контракта;
- готовность к изменениям важнее следования первоначальному плану.
Основополагающие принципы Agile Manifesto:
- наивысшим приоритетом признается удовлетворение заказчика за счёт ранней и бесперебойной поставки ценного программного обеспечения;
- изменение требований приветствуется даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
- частая поставка работающего программного обеспечения (каждые пару недель или пару месяцев с предпочтением меньшего периода);
- общение представителей бизнеса с разработчиками должно быть ежедневным на протяжении всего проекта;
- проекты следует строить вокруг заинтересованных людей, которых следует обеспечить нужными условиями работы, поддержкой и доверием;
- самый эффективный метод обмена информацией в команде — личная встреча;
- работающее программное обеспечение — лучший измеритель прогресса;
- спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
- постоянное внимание к техническому совершенству и хорошему проектированию увеличивают гибкость;
- простота как искусство не делать лишней работы очень важна;
- лучшие требования, архитектура и проектные решения получаются у самоорганизующихся команд;
- команда регулярно обдумывает способы повышения своей эффективности и соответственно корректирует рабочий процесс.
Преимущества Agile
Преимущества гибкой разработки очень убедительны. Вот лишь несколько причин, почему эти принципы так широко применяются:
- Увеличение прибыли. Добавляя некоторые преимущества в следующих релизах, вы продолжаете развивать продукт.
- Продукты выходят на рынок быстрее, релизы выходят раньше и регулярно, соответственно, клиенты получают отдачу от своих инвестиций раньше.
- Качество продукта обеспечивается с помощью встроенного тестирования и регулярных проверок рабочего продукта на всем протяжении разработки.
- Улучшение прозрачности для заинтересованных сторон, так как гибкая методология разработки поощряет вовлечение пользователей для совместных согласованных усилий.
- Снижение риска, так как команда выявляет и исправляет любые проблемы на ранней стадии.
Недостатки Agile
Наряду с преимуществами Agile, имеются и некоторые недостатки. С Agile легко потерять чувство равновесия. В разработке программного обеспечения нет волшебной пилюли или бесплатного сыра. Если вы хотите принять гибкие принципы, вы должны быть уверены, что менеджмент и команда понимают все правила. Они должны также признать, что требования заказчика могут быстро стать подводными камнями. Вот пять главных недостатков.
1. Меньше предсказуемости
Для некоторых программных продуктов разработчики не могут в полной мере количественно оценить требуемые усилия, особенно в начале жизненного цикла разработки крупных продуктов. Команды, не имеющие опыта гибкой разработки, боятся этих неизвестных. Этот страх приводит к разочарованию, плохим практикам и часто к плохим решениям. Более регламентированный каскадный процесс (или процесс водопада) позволяет легко определить количество усилий, времени и стоимости поставки конечного продукта.
2. Больше времени и приверженности
Тестировщики, клиенты и разработчики должны постоянно взаимодействовать друг с другом. Потребуются многочисленные беседы лицом к лицу, так как они являются лучшей формой общения. Все участвующие в проекте люди должны тесно сотрудничать. Ежедневно клиенты должны быть доступны для оперативного тестирования и утверждения на каждом этапе, так чтобы разработчики смогли отметить его как выполненный, прежде чем перейти к следующей функции. Благодаря этому продукт лучше соответствует ожиданиям пользователей, но процесс является обременительным и отнимает много времени. Он требует больше времени и энергии всех участников.
3. Повышенные требования к клиентам
Принципы Agile требуют тесного сотрудничества и активного участия пользователя. Хотя это интересная и полезная система, она требует большего участия клиентов для успешного завершения проекта. Клиенты должны пройти обучение, чтобы помочь в разработке продукта. Любой недостаток участия клиента будет влиять на качество программного обеспечения и конечный успех.
4. Отсутствие необходимой документации
Поскольку требования к программному обеспечению уточняются как раз во время разработки, документация не слишком подробна. Это означает, что если к команде присоединятся новые члены, они не будут знать подробностей, некоторых особенностей или как они должны действовать. Это создает недоразумения и трудности.
5. Проект легко сбивается с пути
Этот метод не требует подробного планирования для начала работы и предполагает, что потребности заказчика постоянно меняются. Такие недостаточные исходные данные могут ограничить использование Agile. Затем, если обратная связь заказчика не ясна, разработчик может сфокусироваться на разработке в неправильном направлении. Кроме того, имеется опасность неконтролируемого расширения границ проекта, и постоянно меняющийся продукт становится бесконечным.
Спиральная модель процесса разработки
История
Спира́льная модель, предложенная Барри Боэмом в 1986 году, стала существенным прорывом в понимании природы разработки ПО. Она представляет собой процесс разработки программного обеспечения, сочетающий в себе как итеративность, так и этапность.
Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нём уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Каждый виток разбит на 4 сектора:
- определение целей,
- оценка и разрешение рисков,
- разработка и тестирование,
- планирование следующей итерации.
На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт.
| Преимущества | Недостатки |
| Дополнительные функции или изменения могут быть внесены на более позднем этапе. | Риск несоблюдения графика или бюджета |
| Оценка стоимости упрощается, так как создание прототипа выполняется небольшими фрагментами. | Спиральное развитие лучше всего подходит только для крупных проектов и требует экспертизы оценки рисков. |
| Непрерывное или повторяющееся развитие помогает в управлении рисками | Для его бесперебойной работы необходимо строго соблюдать протокол спиральной модели. |
| Разработка идет быстро, а функции в спиральной разработке систематически добавляются. | Документация – это нечто большее, поскольку она имеет промежуточные этапы |
| Всегда есть место для обратной связи с клиентами | Разработка программного обеспечения по спирали не рекомендуется для небольших проектов, это может дорого им обойтись. |
Сравнение моделей
| Agile | Спиральная | |
| Меньшая критичность | Более высокая критичность | |
| Участие старших разработчиков | Участвуют также младшие разработчики | |
| Частое изменение требований | Требования меняются не часто | |
| Небольшое количество вовлеченных разработчиков | Привлекается большое количество разработчиков | |
| Философия, которая реагирует на изменения | Философия, требующая порядок |