Agile software development. Модель разработки программного обеспечения

Agile software development представляет собой подход и группу методов, направленных на управление процессом разработки программного обеспечения. Для него свойственны: частая проверка готовности, гибкая адаптация, работа в команде, самоорганизация, ответственность, ориентирование на цели и запросы компании-клиента. Философия Agile основана на применении малых инкрементов (итераций) при минимальном планировании. Такой подход позволяет снизить общий риск и позволяет адаптироваться к текущем изменениям наиболее быстро.

Основная концепция Agile software development изложена в манифесте. Agile как попытка создания лучшего пути разработки программного обеспечения характеризуется четырьмя ценностями:

1. Разработчики и их взаимодействие. Процессы и инструменты вторичны. Лучшие системы разрабатываются небольшой группой специалистов, не разделённых большими расстояниями. Люди и то, как они работают, вовлечены, коррелируют между собой, определяют успех.
2. Работающая программа против обширной и всеохватывающей документации. Ответ на простой вопрос даёт исчерпывающее представление: "Что является конечной целью: гора бумаг или хорошо работающее ПО?"
3. Сотрудничество клиента превыше переговоров по контракту. Клиент знает, чего он хочет. Взаимодействие с клиентом позволяет, во-первых, полно выяснить его требования, во-вторых, оперативно реагировать на изменение его нужд, а в-третьих, клиент сам вникает в суть вещей, узнаёт, что же ему действительно необходимо. Чем теснее связь разработчика с клиентом, тем продуктивнее работа.
4. Реагировать на изменения вместо следования плану. Изменение среды влечёт за собой изменения частей проекта. То же самое происходит с требованиями: меняются приоритеты или появляются новые. В таком случае план должен быть податливым, допускающим корректировку.

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

1. Главный приоритет заключается в ранней и непрерывной доставке программного обеспечения клиенту.
2. Изменять требования возможно даже на самых последних стадиях разработки.
3. Сдача проекта клиенту осуществляется со сравнительно высокой частотой: от пары недель до пары месяцев с желательно меньшим временем масштабирования/развёртывания.
4. Люди от бизнеса и разработчики должны работать вместе ежедневно в течении всей работы над проектом.
5. Создание проекта возможно вокруг заинтересованных людей. Им необходимо дать ту среду и поддержку, в каких они нуждаются, и доверить им выполнить работу так, как они сочтут верным.
6. Самый эффективный способ передачи информации и знаний внутри команды разработчиков - прямой разговор, обсуждение.
7. Работающее ПО - главное мерило прогресса в противовес количеству строк, объектов.
8. Agile-процессы стимулируют стабильную разработку. Спонсоры, разработчики и пользователи должны быть способны держать постоянный темп.
9. Постоянное внимание к техническому исполнению и хорошей архитектуре повышает "подвижность".
10. Простота, которая есть искусство преумножения невыполненной работы - существенна: или избавление от рутинных операций, или их автоматизация.
11. Самые лучшие архитектуры, требования и подходы - плоды трудов команд, предоставленных сами себе, организующихся естественно и единственно для них верно.
12. Через заданные интервалы команда размышляет, как стать более эффективной, а затем регулирует свой режим работы.

В чём отличие agile-подхода от классического, например, водопадной модели? Рассмотрим deadline для них.

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

Пусть возникла следующая ситуация: на определённом сроке работы над проектом выявляется несоответствие реальных показателей прогресса заданным (ожидаемым). Для Agile это естественно и отрабатывается сравнительно безболезненно: в конце каждой итерации расписание работ составляется заново или изменяется. Для последовательной разработки много сложнее. Поскольку план составлен (а он есть закон), то малейшее отступление грозит заморозкой проекта на определённое время. План корректируется, процесс продолжается.

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

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

Сущность Agility заключается в балансировании между требованиями рынка, что отражается в мгновенном отклике на его спрос, и требованиями со стороны клиента, который вынужден смотреть на проект как на весьма определённое и предсказуемое явление. Здесь проявляется консерватизм бизнеса: для него важнее знать как будет и какую пользу из проекта можно извлечь, но не особо волнует быстрое подстраивание под рыночную ситуацию.

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

Насколько оправдано использование описанной модели? У этого подхода очень много как сторонников, так и противников. Основной противник - психология: как отмечают, в душе все идеалисты и вроде знают "зачем", а на деле поступают неразумно.

Используемые материалы:

http://en.wikipedia.org/wiki/Agile_software_development
http://www.ambysoft.com/essays/agileManifesto.html
http://blog.gdinwiddie.com/2009/01/16/agility-and-predictability/