Методология Agile в управлении проектами

Разобрались, какие преимущества и недостатки есть у гибкой методологии.

10.09.2024
Методология Agile в управлении проектами

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

Что такое Agile

Agile — это гибкая методология управления проектами, при которой люди и взаимодействие важнее процессов и инструментов. Она стала ответом на бюрократизированные и громоздкие процессы в крупных IT-компаниях.

Методологию придумали специалисты по IT из разных стран, собравшись в феврале 2001 года на горнолыжном курорте в штате Юта, США. Они сформулировали принципы и манифест Agile, и вскоре методология обросла различными ответвлениями и узкоспециализированными подходами.

У возникновения гибкой методологии были предпосылки. Ещё в начале 90-х программисты продвигали идею непрерывного и продуктивного общения внутри команды, итерационный подход и фокус на потребностях бизнеса. Мировая экономика росла, спрос на IT-продукты тоже, но на написание кода и выпуск программ уходили годы. Agile-менеджмент позволил IT-индустрии ускориться и гибко реагировать на рыночные изменения. После этого методология вышла за рамки информационных технологий и проникла в другие сферы: маркетинг, финансы, консалтинг и образование.

Как работает Agile

Вот основные особенности Agile:

  • Продукт разрабатывают как можно быстрее, чтобы им можно было начинать пользоваться практически сразу. Это называется MVP — Minimum Viable Product, минимально жизнеспособный продукт. Он всё ещё «сырой», но уже может выполнять базовые функции и решать основные задачи пользователей. Все изменения и доработки вносят в процессе, например расширяют функционал и добавляют дизайн.

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

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

В кафе заметили, что акция со скидкой на третью чашку кофе непопулярна. Поэтому заменили её на более востребованную: шестая чашка кофе в подарок.

  • Команда регулярно показывает заказчику работающий продукт, а не документы, прототипы, отчёты. Заказчик постоянно находится на связи, участвует в обсуждениях. Каждый раз после встречи заказчика и команды продукт обновляется.

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

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

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

Принципы и ценности Agile

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

Ценности:

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

Принципы:

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

Методы Agile

Гибкая методология появилась в сфере программирования, поэтому многие её направления касаются только IT-технологий и IT-продуктов:

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

Getting Real — подход к созданию приложений, где сперва создаётся интерфейс, а потом уже стоящий за ним функционал. Этот подход помогает сконцентрироваться на пользе продукта и удобстве для конечного клиента.

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

Существуют и другие направления, более универсальные. К ним относятся Scrum и Kanban.

Scrum

Работа делится на короткие спринты — итерации, которые длятся от 1 до 4 недель. Все задачи выполняет небольшая команда, обычно до 10 человек. Участники самостоятельно определяют, кто за что будет отвечать.

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

Порядок и статус спринтов нужно фиксировать на Scrum-доске — они встроены во многих рабочих сервисах, например в Яндекс Трекере.

Скриншот 418
Скрам-доска в Яндекс Трекере

Kanban

Этот подход позволяет сделать работу по проекту наглядной с помощью Канбан-доски. На ней формируют столбцы с этапами: «В плане», «В работе» и «Готово». При необходимости добавляют дополнительные — «На согласовании», «Тестирование» и другие. Затем создают карточки с конкретными задачами. По мере выполнения задач карточки перемещают из одного столбца в другой.

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

Kanban-доски тоже часто встраивают в корпоративные программы, такие как Яндекс Трекер.

Скриншот 416
Канбан-доска в Яндекс Трекере

Отличие Agile от других методов

Сравним гибкую методологию с её основным антиподом — линейным подходом Waterfall, или «Водопадом».

КритерииAgileWaterfall 
ПродуктЕсть общие требования к конечному результату, допустимо менять его в процессе Есть точное ТЗ и образ конечного результата, которому нужно следовать
Этапы работыЦикл «сбор требований — проектирование — разработка — тестирование» повторяется много раз, так как продукт создаётся «частями»Продукт создаётся за один цикл: сбор требований, проектирование, разработка, тестирование, поддержка. На каждом этапе команда делает полный список работ
ДокументацияНа документацию тратят минимум времениВедение документации обязательно на каждом этапе
Вид сотрудничестваСотрудники работают вместе, тесно и открыто общаютсяКаждый сотрудник работает над своей частью проекта, в тесном общении нет необходимости
Сфера примененияПодходит для небольших интеллектуальных проектов с нематериальной продукцией, такой как программное обеспечение, ноу-хау в маркетинге или услугиПодходит для материального производства и крупных проектов: строительства, промышленности, сельского хозяйства
Роль заказчикаЗаказчик постоянно на связи с командой и знает, что происходит в проектеЗаказчик не обязан контактировать с командой в процессе работы, его задача — принять или отклонить конечный результат
Выпуск продуктаКлиенты могут пользоваться продуктом начиная с ранних этапов проектаКлиенты увидят продукт, когда он будет полностью готов
КритерииПродуктЭтапы работыДокументацияВид сотрудничестваСфера примененияРоль заказчикаВыпуск продукта
AgileЕсть общие требования к конечному результату, допустимо менять его в процессе Цикл «сбор требований — проектирование — разработка — тестирование» повторяется много раз, так как продукт создаётся «частями»На документацию тратят минимум времениСотрудники работают вместе, тесно и открыто общаютсяПодходит для небольших интеллектуальных проектов с нематериальной продукцией, такой как программное обеспечение, ноу-хау в маркетинге или услугиЗаказчик постоянно на связи с командой и знает, что происходит в проектеКлиенты могут пользоваться продуктом начиная с ранних этапов проекта
Waterfall Есть точное ТЗ и образ конечного результата, которому нужно следоватьПродукт создаётся за один цикл: сбор требований, проектирование, разработка, тестирование, поддержка. На каждом этапе команда делает полный список работВедение документации обязательно на каждом этапеКаждый сотрудник работает над своей частью проекта, в тесном общении нет необходимостиПодходит для материального производства и крупных проектов: строительства, промышленности, сельского хозяйстваЗаказчик не обязан контактировать с командой в процессе работы, его задача — принять или отклонить конечный результатКлиенты увидят продукт, когда он будет полностью готов

До 90-х Waterfall успешно применялся в сфере IT, так как программисты заимствовали приёмы из проектирования и строительства. Позже, когда понадобилось ускорить и упростить создание программ, многие отказались от «Водопада». Сейчас многие крупные компании используют гибридную модель, в которую входят практики из обеих методологий.

Узнать больше о различиях Agile и Waterfall можно в этой статье.

Для кого подходит Agile

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

  1. Запуск стартапа и вывод на рынок новых продуктов. Гибкая методология подходит для проектов в условиях неопределённости, когда финальный результат сложно запланировать. Например, для инновационных решений, разработки и продвижения программного обеспечения — где нужно тестировать и проверять гипотезы, быстро вносить изменения.
  2. Разработка маркетинговой кампании. Гибкая методология будет полезна в маркетинге, где на первом месте стоят потребности клиентов. Agile-менеджмент позволяет адаптировать проект в зависимости от результатов аналитики, опросов и обратной связи пользователей. Например, гибкую методологию можно применять при создании рекламного контента, выходе на новую аудиторию или канал продвижения.
  3. Реализация краткосрочных проектов. Agile-менеджмент подойдёт для небольших проектов на заказ: там не очень важны чёткий план и структура, а команда за короткий период не успеет поменяться. Например, методология будет полезна для проектов дизайнерских и консалтинговых агентств.

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

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

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

Как внедрить Agile

Процесс внедрения можно разделить на несколько этапов:

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

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

3. Разработайте пилотный проект. Не стоит внедрять Agile сразу для всех проектов компании. Начинать лучше с «пилота», который будет ограничен по времени, бюджету и ресурсам. Так вы сможете понять, справилась ли команда с задачами и стоит ли применять Agile в дальнейшем.

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

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

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

Подытожим

  1. Методология Agile сформировалась как альтернатива бюрократизированным и тяжеловесным процессам в IT-сфере. Философия, принципы и идеи гибкого подхода появились в феврале 2001 года.
  2. У Agile есть несколько принципов. Продукт нужно тестировать и показывать пользователям как можно раньше. В работе нет жёсткого плана и подробного ТЗ. Продукт можно изменять под требования рынка, заказчика и ЦА на любом этапе. Заказчик и команда активно общаются и поддерживают прозрачность процессов. Команда сама распределяет роли, выбирает инструменты и методы работы.
  3. Scrum и Kanban — самые популярные и универсальные гибкие методологии управления проектами.
  4. За счёт своих принципов Agile отличается от линейного подхода Waterfall. «Водопад» предусматривает более жёсткие условия: подробную документацию, чёткий порядок этапов и следование первоначальной задумке продукта.
  5. Agile-менеджмент подходит для небольших проектов и нематериальных продуктов, а также для создания маркетинговых кампаний и стратегий. Ещё одно важное условие использования этой методологии — готовность заказчика регулярно обсуждать с командой ход работы и продукт.
  6. Чтобы внедрить Agile, необходимо определить цели и задачи этого внедрения, подготовить команду, выбрать пробный проект, реализовать его и оценить результат. Если методология вам подходит и хорошо себя показала, постепенно внедряйте её дальше.

Поделиться

Яндекс 360

Рекомендуемые материалы