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

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

Термин agile используется в двух разных значениях:

• Философия и ценности, которых придерживается команда. Мы здесь говорим не о конкретных инструментах и практиках, а о принципах, на которых основана работа.
• Собирательное название нескольких разных гибких методологий, для которых общими являются ценности Agile.

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

Подход Agile возник после того, как ИТ-индустрия устала от чрезмерной бюрократии и строгости. Разработчики поняли, что создавать инновационные продукты, используя старые строгие методы, просто невозможно, поэтому в 2001 году 17 разработчиков со всего мира собрались в американском штате Юта и подписали манифест о новых передовых принципах разработки, которые легли в основу Agile.

Манифест и принципы Agile

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

1. Удовлетворение потребностей клиентов является приоритетом при разработке продукта. Клиенты должны получать высококачественное программное обеспечение и обновления своевременно и в полном объеме.
2. Изменения в процессе разработки приветствуются. Гибкие процессы позволяют придать продукту конкурентное преимущество для клиентов.
3. Рабочее ПО нужно доставлять клиенту часто, в рамках 2–16 недель.
4. Руководители и разработчики должны трудиться вместе на протяжении всего рабочего процесса.
5. В основе проекта — мотивированные люди. Обеспечьте им необходимые условия работы, поддержку и доверие.
6. Лучший способ передачи информации в команде — личная беседа.
7. Основное мерило прогресса — работающее ПО. А не часы, трудозатраты и другие критерии.
8. Гибкие процессы — основа устойчивого развития. Они позволяют поддерживать нужный рабочий темп как на спринтерской, так и на марафонской дистанции.
9. Важно уделять внимание техническому совершенству и качественному дизайну продукта.
10. Важно сокращать до минимума лишнюю работу и не переусложнять проект и рабочие процессы.
11. Самые лучшие продукты рождаются у самоорганизующихся команд. Нет микроменеджменту, да — свободе управления.
12. Команда должна регулярно оценивать работу и корректировать своё поведение.

Из этих двенадцати принципов выделяют четыре ценности системы Agile:

• Люди и взаимодействия важнее процессов и инструментов.
• Работающий продукт важнее точной и подробной документации.
• Сотрудничество с заказчиком важнее условий договора.
• Готовность к изменениям важнее следования изначальному плану.

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

Преимущества и недостатки Agile

Плюсы:

• Гибкость и открытость к любым изменениям. Можно быстро внести новые требования заказчика, оперативно ответить на действия конкурентов, работать в условиях неопределенности.
• Сниженные риски провала. Тестирование, анализ результатов и общение с заказчиками есть в конце каждого цикла, так что можно быстро понять, что что-то идёт не так, и исправить это. Ситуации, что в конце получился никому не нужный продукт, точно не возникнет.
• Устойчивость к срыву сроков. Их можно гибко адаптировать в зависимости от того, растянулась ли разработка какой-то фичи. В том числе можно отказаться от каких-то функций прямо в процессе работы, чтобы в срок выпустить готовый продукт.
• Большая вовлечённость команды. Отсутствие микроменеджмента, тесная работа с руководством и самоуправление помогают разработчикам работать эффективнее и видеть своё влияние на проект.
• Высокая скорость реакции на проблемы. Если появится баг — его можно быстро устранить в новом цикле. Не нужно полностью перекраивать проект, сдвигать сроки или откладывать исправление ошибки на потом.
• Минимум рутины. Разработчики тратят меньше времени на документацию и отчёты — то, что они обычно не любят больше всего.

Минусы:

• У проекта нет чёткого плана и структуры. В конце может получиться совсем не то, что в начале. Это минус скорее для заказчиков, которым важна определённость и чёткое следование определённым требованиям. Например, для государственных компаний.
• Потребность в тесном общении. Заказчику нужно постоянно общаться с командой, обновлять требования, смотреть промежуточные результаты.
• Завязанность на команду. В процессе работы сложно бывает сменить разработчика или руководителя, так как его придется погружать в подробности всех прошлых циклов и в уже отработанные процессы.
• Слишком большой фокус на мелочах. Иногда за обновлением, дополнением и исправлением функций можно потерять глобальную цель проекта, удариться в доработку мелочей и забыть о главном.
• Сложности с внедрением. Если в компании работали по другой методологии, построить Agile может быть сложно. Потребуется отдельный сотрудник либо менеджер проекта, который хорошо разбирается в гибких методологиях. И переход может занять много времени.