Методология Agile: значение, преимущества, недостатки и многое другое

Гибкая методология – это разработка программного обеспечения Философия, направленная на повышение ценности для клиентов за счет сокращения циклов разработки и постоянного внесения изменений.

Разработка программного обеспечения выросла из областей математики и естественных наук. Таким образом, он изначально включал научные методы из этих областей.

Эти методы превратились в водопадный подход в 1970-х годах, чтобы удовлетворить требования дня. Компьютеры и их программное обеспечение в те дни были большими, сложными и рассчитанными на десятилетия. Таким образом, метод водопада хорошо подходит.

Но к концу 1990-х Интернет резко изменил мир, и стал необходим новый подход. Так родилась гибкая методология.

Ниже приводится более подробный обзор этого направления разработки программного обеспечения и того, как оно может помочь вам и вашей команде.

История метода разработки Agile

Гибкая разработка программного обеспечения выросла из Интернета и его ненасытной потребности в приложениях в годы бума 1990-х и начала 2000-х годов.

Это также был период, когда многие разработчики без опыта работы в области компьютерных наук переключились на веб-разработку из-за огромной потребности в веб-сайтах, ориентированных на различные группы и отрасли.

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

Чтобы противостоять ограничениям, которые модель водопада накладывала на максимально быстрый вывод продуктов на рынок, в 1990-х годах разные разработчики придумали разные методы. К ним относятся быстрая разработка приложений (RAD), Scrum, экстремальное программирование (XP), Kanban и другие.

Затем, где-то в 2001 году, 17 разработчиков, которые практиковали ту или иную форму ранней гибкой разработки, собрались в Юте, США. Затем они завершили встречу, опубликовав «Манифест гибкой разработки программного обеспечения».

Этот манифест основан на 4 ценностях и 12 принципах.

4 ценности и 12 принципов гибкой разработки

На основе опыта, который они собрали во время встречи, 17 разработчиков пришли к соглашению о наборе ценностей для более эффективного создания программного обеспечения.

Эти четыре значения следующие:

1. Лица и взаимодействия над процессами и инструменты. Это означает, что важно разрабатывать программное обеспечение с помощью инструментов, следуя определенному процессу. Но гораздо важнее, чтобы компетентные люди работали вместе более эффективно.
   
   
2. Рабочий софт над исчерпывающей документацией. Этот атакует метод водопада, когда сначала проектируют программное обеспечение и пишут для него документацию до фактического процесса разработки программного обеспечения.
   
   
3. Сотрудничество с клиентами над переговорами по контракту. Только работая в тесном контакте с клиентом или пользователем, вы можете узнать и разработать именно то, что нужно клиенту. Это создает большую ценность.
   
   
4. Реагируя на изменения из-за следования плану. После Проект план важен. Но план не должен быть слишком жестким. Он должен учитывать изменения, чтобы соответствовать ожиданиям заинтересованных сторон.

Приведенные выше ценности Agile Manifesto основаны на 12 принципах и заключаются в следующем:

1. Удовлетворенность клиентов за счет ранней и непрерывной поставки ценного программного обеспечения.
2. Приветствуйте меняющиеся требования, даже на поздних стадиях разработки.
3. Поставляйте работающее программное обеспечение часто (недели, а не месяцы)
4. Тесное, ежедневное сотрудничество между деловыми людьми и разработчиками
5. Проекты строятся вокруг целеустремленных людей, которым стоит доверять
6. Беседа лицом к лицу – лучшая форма общения (совместное размещение)
7. Работающее программное обеспечение является основным мерилом прогресса
8. Устойчивое развитие, способное поддерживать постоянный темп
9. Постоянное внимание к техническому совершенству и хорошему дизайну
10. Простота — искусство максимизировать количество невыполненной работы — имеет важное значение
11. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
12. Команда регулярно размышляет о том, как стать более эффективной, и вносит соответствующие коррективы.

Итерации или спринты

Итерации или спринты в гибкой разработке программного обеспечения — это короткие периоды, обычно от 1 до 4 недель, на которые разбивается работа по разработке. Это упрощает управление, поскольку требует меньшего планирования.

Каждая команда также обычно состоит из членов с различными функциями, которые могут включать планирование, анализ, проектирование, кодирование и тестирование.

Команда работает над программным обеспечением на каждой итерации или спринте вместе. И они производят работающий продукт в конце. Согласно Agile Manifesto, эта работающая часть программного обеспечения является мерилом истинного прогресса.

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

Преимущества гибкой разработки

Как вы можете себе представить, гибкая методология дает много преимуществ. Они следующие:

1. Более быстрое воплощение идей
2. Больше гибкости, чем метод водопада
3. Улучшенный производительность с управляемыми итерациями
4. Улучшенные продукты благодаря взаимодействию с пользователем
5. Ошибки быстро выявляются и устраняются

Недостатки методологии Agile

Есть также некоторые недостатки работы с методом гибкой разработки. И они могут включать:

1. В начале может быть сложно оценить полные затраты.
2. Это требует большого количества входных данных от клиентов
3. Включает в себя много незапланированной работы
4. Нет четко определенного конца проекта

Когда использовать гибкие методы

1. Когда вы не можете оценить, что требуется программному обеспечению
2. У вас достаточно доступа к клиентам
3. Вы разрабатываете веб-приложение или простую в обновлении систему
4. Вам нужно быстро захватить долю рынка с ранним выпуском

Популярные фреймворки Agile-разработки

Существует множество популярных фреймворков гибкой разработки. Некоторые из них появились задолго до Agile Manifesto 2001 года, а другие появились позже.

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

1. Scrum: эта структура предназначена для команд с 10 или менее участниками. Работа разбита на спринты по 2-4 недели с ежедневными 15-минутными встречами.
   
   
2. Kanban: родом из Toyota, канбан — это японское слово, которое означает рекламный щит и очень полезно для команд, которые ценят наглядные пособия. Задачи перемещаются с одного этапа на другой с помощью визуальных представлений, таких как стикеры или приложения.
   
   
3. RAD для быстрой разработки приложений: эта фраза может относиться как к гибкой разработке программного обеспечения в целом, так и к методу Джеймса Мартина. RAD фокусируется на требованиях к пользовательскому интерфейсу и в значительной степени опирается на прототипирование.
   
   
4. Lean Startup: Эта структура предназначена для тех, кому необходимо разработать продукт или услугу, но сначала необходимо определить их рыночную жизнеспособность. Это включает в себя использование экспериментов, чтобы увидеть, что работает, а что нет.

Другие известные структуры включают экстремальное программирование (XP), адаптивную разработку программного обеспечения, гибкое моделирование, метод разработки динамических систем и масштабируемую гибкую структуру.

Методологии Agile и Waterfall

Вот параллельный обзор гибких и каскадных методов разработки программного обеспечения. Это может помочь узнать, как каждый метод сочетается с другим. Таким образом, вы можете легко выбрать лучшие инструменты для своей работы.

Проворный	Водопад
Инкрементный и итеративный подход	Линейная и последовательная модель жизненного цикла
Гибкость в изменении	Жесткие реализации
Тесты и обзоры продолжаются	После завершения есть только один этап тестирования
Требования могут меняться	Требования фиксируются после планирования
Коллекция множества небольших проектов	Один единственный проект
Больше вовлеченности клиентов	Меньше вовлеченности клиентов

Адаптивная и прогнозирующая разработка

Цель гибкой разработки программного обеспечения — адаптироваться к изменениям в реальном мире. И они часто являются результатом потребностей клиента или пользователя. Адаптация резко контрастирует с предсказательной природой водопадной модели.

Тогда имеет смысл использовать гибкие методы при разработке систем, в которых вы не уверены, как все обернется. Или когда в отрасли происходят постоянные изменения и эволюция. Интернет — большой пример.

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

Мастерство программного обеспечения

Software Craftsmanship — это еще одна философия, основанная на принципах гибкой разработки и акцентирующая внимание на навыках разработчиков программного обеспечения, участвующих в проекте.

У движения Software Craftsmanship также есть манифест, в котором говорится:

Как начинающие мастера программного обеспечения, мы поднимаем планку профессиональной разработки программного обеспечения, практикуя ее и помогая другим освоить это ремесло. Благодаря этой работе мы получили: · Не только работающее программное обеспечение, но и хорошо продуманное программное обеспечение · Не только реагирование на изменения, но и постоянное добавление ценности · Не только отдельных лиц и взаимодействия, но и сообщество профессионалов · Не только клиентов сотрудничество, но также и продуктивное партнерство То есть, занимаясь вопросами слева, мы обнаружили, что пункты справа незаменимы. © 2009, нижеподписавшийся. Это заявление может быть свободно скопировано в любой форме, но только полностью через это уведомление.

Заключение

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

Каждая команда отличается. И так же, как разные команды разработали свои различные методы, чтобы адаптироваться к меняющимся временам. Вам тоже придется адаптироваться, используя уже установленную структуру или адаптируя ее под свою команду.