Что такое гибкая методология (Agile)

Agile, или гибкая методология ― это подход к управлению проектами. Сегодня по этой методологии работают многие российские и международные компании, особенно в сфере диджитал и IT.

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

Дисклеймер: Agile ― это целая философия, о которой написаны десятки книг. Мы не ставим целью объять все аспекты гибкой методологии — скорее дать выжимку самого основного, чтобы вы могли понять, подходит ли она вашему бизнесу.

Сегодня подход Agile используют в двух значениях. Так называют:

• Философию управления проектами, которая появилась в IT-сфере в начале 2000-х годов. В этом случае говорят о гибких ценностях и принципах.
• Семейство гибких методологий разработки, которые появились на базе этой философии. В этом случае имеют в виду инструменты и регламенты, которые помогают планировать время и налаживать коммуникацию в команде.

До появления гибкой методологии проектами в IT часто управляли по принципу Waterfall, или каскадной модели. Важно отметить, что Agile шире, чем просто метод или набор инструментов. Здесь мы сравниваем только основные принципы, а не напрямую один метод с другим.

В Waterfall команда составляет техническое задание и согласовывает с заказчиком. А затем двигается строго по плану.

На первый взгляд кажется, что всё удобно и упорядоченно: сначала собирают требования к продукту и проектируют, потом разрабатывают и тестируют. Для некоторых направлений такой подход отлично работает. Например, сюда относится разработка для государственных структур, где продукт строится на основе регламентов, продиктованных законодательством. Его нет необходимости систематически править и дорабатывать — продукт в любом случае будет востребован. Плюс такой подход используют там, где велика стоимость ошибки, например, при запуске космического спутника.

В Waterfall-подходе команде не обязательно всё время взаимодействовать лично или по Zoom — каждый может сосредоточиться на своей части проекта. И уровень компетенций в команде может быть разным.

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

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

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

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

• соберёт все бизнес-требования;
• спроектирует и разработает приложение;
• приступит к внедрению.

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

Например, регистрация и авторизация пользователей, просмотр меню ресторанов, корзина ― без этих функций в приложении просто нет смысла. Чтобы спроектировать, сделать дизайн и написать код, уйдёт несколько недель или месяцев. В результате получится MVP ― неидеальная версия продукта, пусть и без некоторых функций, но уже работающая. Команда может выпустить приложение и дорабатывать его по обратной связи от пользователей. Например, добавить интеграцию с приложением для курьеров, сторис с актуальными предложениями, возможность добавлять блюда в избранное.

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

Agile-манифест написала группа разработчиков со всего мира в 2001 году. В нём они зафиксировали основные ценности подхода. Вот они.

Люди и взаимодействия важнее процессов и инструментов.

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

Работающий продукт важнее точной и подробной документации.

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

Сотрудничество с заказчиком важнее условий договора.

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

Готовность к изменениям важнее следования изначальному плану.

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

Помимо ценностей в манифесте также записали 12 принципов. Они описывают, как правильно работать над проектами по гибкой методологии.

Главный фокус не на плане, а на клиенте. Цель команды — обеспечить его удовлетворение за счёт быстрого и непрерывного предоставления полезного продукта. Регулярная презентация результатов клиенту помогает получать обратную связь на ранних этапах и адаптировать продукт под его нужды.

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

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

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

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

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

Главное — это результат. Неважно, сколько документации создано или сколько задач выполнено, пока нет работающего продукта.

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

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

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

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

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

В Minervasoft мы работаем согласно подходу Agile, чтобы постоянно совершенствовать продукт, добавлять новые фичи и улучшать существующие. Также мы всегда учитываем пожелания наших клиентов к системе (КМС) и оперативно на них реагируем. А каждый член нашей команды может вносить любые предложения, к которым прислушиваются остальные. Поэтому принципы аджайл нам так близки.

Что нужно делать: ключевое правило — не перегружать! Первый день на новом месте и так стрессовый. Постарайтесь сделать его максимально комфортным: познакомьте новичка с командой, проведите небольшую экскурсию по офису или, если это удалёнка, по рабочему пространству.

Как мы уже упоминали, Agile — это скорее философия работы над проектами, чем строгое руководство к действию. Она задаёт общее направление, где главные приоритеты — гибкость, команда и продукт.

Конкретные методы и инструменты предлагают фреймворки Agile. Вот самые популярные из них.

Scrum — один из самых известных фреймворков Agile. В его основе лежат следующие элементы:

• Роли. В Scrum есть три главные роли — владелец продукта, Scrum-мастер и команда разработки. Владелец продукта отвечает за видение продукта, Scrum-мастер помогает всем участникам следовать Agile-принципам и общаться, а команда разработки работает над созданием продукта.
• События. В Scrum регулярно проводятся встречи (мероприятия) — планирование спринта, ежедневные встречи (Daily Scrum), обзор спринта и ретроспектива. На них участники собираются вместе, синхронизируют работу и обновляют требования.
• Артефакты. В Scrum важны такие артефакты, как бэклог продукта, бэклог спринта и инкремент продукта.

В скрам много деталей, и внедрить его может быть нелегко. Часто компании используют только какую-то часть фреймворка, например, проводят планирование и дейли, но не ретроспективы. Хотя на начальных этапах это может работать, лучше использовать все инструменты фреймворка для максимальной эффективности.

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

Главная особенность Kanban — визуализация задач с помощью доски (Kanban Board), где задачи распределяются по трём колонкам: «Запланировано», «В работе», «Готово».

В отличие от Scrum, где работа делится на итерации (спринты), Kanban предполагает непрерывный процесс выполнения задач без чётких временных рамок.

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

У Agile много плюсов, которые делают её популярной среди современных компаний.

Agile имеет и недостатки.