Гибкие модели разработки Agile

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

Основная цель модели Agile — способствовать быстрому выполнению проекта. Быстрота достигается за счет адаптации процесса к проекту, удаления действий, которые могут не иметь значения для конкретного проекта.
В Agile-модели требования разбиваются на множество мелких частей, которые можно выполнять постепенно. Каждая часть разрабатывается в течение одной итерации (спринт). Каждая итерация должна быть небольшой и легко управляемой и может быть завершена за пару недель. За один раз планируется, разрабатывается и развертывается для клиентов одна итерация.

Шаги, связанные с гибкими моделями SDLC:
  • Сбор требований
  • Анализ требований
  • Проектирвоание
  • Кодирование
  • Модульное тестирование
  • Приемочное тестирование
Принципы гибкой разработки
Чтобы установить тесный контакт с заказчиком во время разработки и получить четкое представление о различных требованиях, каждый Agile-проект обычно включает в команду представителя заказчика. В конце каждой итерации заинтересованные стороны и представитель заказчика анализируют достигнутый прогресс и повторно оценивают требования.

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

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

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

Рекомендуется, чтобы размер команды разработчиков был небольшим (от 5 до 9 человек), чтобы помочь членам команды осмысленно участвовать в личном общении и иметь совместную рабочую среду.

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

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

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

Люди — не процесс. Люди и взаимодействия имеют более высокий приоритет, чем процессы и инструменты.

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

Гибкая разработка больше ориентирована на код и создает меньше документации.

Гибкая разработка сильно зависит от вклада клиента. Если у заказчика есть неясность в его видении конечного результата, высока вероятность того, что проект собьется с пути.

Общение лицом к лицу сложнее в крупных организациях.

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

Общие моменты проекта:
- Срок выполнения задачи 10 месяцев.
- Определены две команды: Команда А и Команда B.
- Команда А работает по модели "Водопад".
- Команда Б работает по модели Гибкой разработки Agile.
План развития Команды А:

  • Анализ и сбор требований – 1,5 месяца
  • Дизайн системы – 2 месяца
  • Фаза кодирования – 4 месяца
  • Системная интеграция и тестирование – 2 месяца
  • Приемочное тестирование пользователей – 5 недель
План развития команды Б :

  • Проект был разбит на несколько итераций.
  • В конце каждой итерации должен быть создан рабочий продукт с новой функцией.
  • Определяются основные функции, которые требуются в продукте и реализуются в первой итерации.
  • Любые оставшиеся функции, которые не могут быть предоставлены в первой итерации, будут предоставлены в следующей последующей итерации в зависимости от приоритета.
  • В конце первых итераций команда предоставит работающее программное обеспечение с основными базовыми функциями.
Влияние изменений
Из-за быстро меняющейся среды руководитель компании определил совершенно новый набор функций и хочет, чтобы его внедрили как можно быстрее.

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

Команда Б есть рабочий продукт с реализованными основными требованиями с момента первого спринта. И им проще внедрить новые требования. Необходимо запланировать эти требования для следующего шага, а затем реализовать их.
Экстремальное программирование
Одна из наиболее важных сред разработки программного обеспечения моделей Agile.Данная модель программирования рекомендует довести лучшие практики, которые хорошо зарекомендовали себя в прошлом в проектах разработки программ:

  • Code Review: Проверка кода позволяет эффективно обнаруживать и исправлять ошибки.
  • Тестирование. Тестирование кода помогает устранить ошибки и повысить его надежность. Модель предлагает разработку через тестирование (TDD) для непрерывного написания и выполнения тестовых случаев. В подходе TDD тестовые примеры пишутся еще до написания кода.
  • Итерационная разработка: разработка итерациями позволяет собирать обратную связь заказчика, и на ее основе планировать разработку в новой итерации.
  • Простота: Написания кода простыми структурами. Чем проще - тем понятнее.
  • Проектирование: Качественное проектирование при разработки ПО.
  • Интеграционное тестирование: помогает выявить ошибки в интерфейсах различных функций. Разработчики должны добиваться непрерывной интеграции, создавая и выполняя интеграционное тестирование несколько раз в день.