Методология Agile в управлении проектами
Разобрались, какие преимущества и недостатки есть у гибкой методологии.
Разобрались, какие преимущества и недостатки есть у гибкой методологии.
При запуске стартапа или нового продукта сложно заранее спланировать задачи, бюджет и сроки. Успех зависит от быстрой реакции на изменения рынка и обратную связь от заказчика и пользователей. В таких условиях помогает методология Agile. В статье рассказали, каким компаниям подойдёт гибкая методология и как её внедрить.
Agile — это гибкая методология управления проектами, при которой люди и взаимодействие важнее процессов и инструментов. Она стала ответом на бюрократизированные и громоздкие процессы в крупных IT-компаниях.
Методологию придумали специалисты по IT из разных стран, собравшись в феврале 2001 года на горнолыжном курорте в штате Юта, США. Они сформулировали принципы и манифест Agile, и вскоре методология обросла различными ответвлениями и узкоспециализированными подходами.
У возникновения гибкой методологии были предпосылки. Ещё в начале 90-х программисты продвигали идею непрерывного и продуктивного общения внутри команды, итерационный подход и фокус на потребностях бизнеса. Мировая экономика росла, спрос на IT-продукты тоже, но на написание кода и выпуск программ уходили годы. Agile-менеджмент позволил IT-индустрии ускориться и гибко реагировать на рыночные изменения. После этого методология вышла за рамки информационных технологий и проникла в другие сферы: маркетинг, финансы, консалтинг и образование.
Вот основные особенности Agile:
В кафе решили внедрить программу лояльности — по Agile её не разрабатывают целиком в течение полугода, а внедряют почти сразу простую версию и потом дорабатывают её, ориентируясь на отзывы посетителей.
В кафе заметили, что акция со скидкой на третью чашку кофе непопулярна. Поэтому заменили её на более востребованную: шестая чашка кофе в подарок.
Владелец кафе предложил запустить акцию ко Дню защиты детей: каждому ребёнку в этот день дарить фирменный лимонад. Команда оперативно обновила программу лояльности, и акция стартовала уже через пару недель.
Владелец кафе может поручить разработать программу лояльности стороннему маркетинговому агентству. В таком случае ему не придётся вникать в мелкие детали процесса: кто из команды отвечает за продвижение акций в социальных сетях, а кто — за распространение листовок.
В манифесте Agile собраны принципы и ценности методологии. Рассказываем о них.
Ценности:
Принципы:
Гибкая методология появилась в сфере программирования, поэтому многие её направления касаются только IT-технологий и IT-продуктов:
Экстремальное программирование (ХР) — включает в себя такие рабочие приёмы, как парное программирование, когда один специалист пишет код, а другой тут же его проверяет. Также это свободный доступ всех членов команды к коду и написание тестов для программы перед её созданием, а не после. Это помогает избежать ошибок на ранней стадии разработки.
Getting Real — подход к созданию приложений, где сперва создаётся интерфейс, а потом уже стоящий за ним функционал. Этот подход помогает сконцентрироваться на пользе продукта и удобстве для конечного клиента.
Agile Data Method — набор методик гибкой разработки ПО. Одна из них заключается в том, что кроме группы разработчиков есть сотрудники, которые поддерживают их. Это администраторы баз данных, архитекторы и другие специалисты. Ещё один принцип Agile Data Method — поиск золотой середины в решениях, отказ от крайностей.
Существуют и другие направления, более универсальные. К ним относятся Scrum и Kanban.
Работа делится на короткие спринты — итерации, которые длятся от 1 до 4 недель. Все задачи выполняет небольшая команда, обычно до 10 человек. Участники самостоятельно определяют, кто за что будет отвечать.
Команда ежедневно собирается для обсуждения текущих вопросов проекта. Результатом спринта может являться как рабочий продукт целиком, так и его часть, в зависимости от сложности проекта. В следующих спринтах продукт тестируют и дорабатывают.
Порядок и статус спринтов нужно фиксировать на Scrum-доске — они встроены во многих рабочих сервисах, например в Яндекс Трекере.
Этот подход позволяет сделать работу по проекту наглядной с помощью Канбан-доски. На ней формируют столбцы с этапами: «В плане», «В работе» и «Готово». При необходимости добавляют дополнительные — «На согласовании», «Тестирование» и другие. Затем создают карточки с конкретными задачами. По мере выполнения задач карточки перемещают из одного столбца в другой.
Работа над проектом организована как непрерывный поток задач. Когда участник заканчивает одну задачу, он берёт следующую. Канбан-команда часто работает с гибкими дедлайнами, так как в процессе могут возникать непредвиденные задержки. В любом случае сотрудники ориентируются на пожелания заказчика.
Kanban-доски тоже часто встраивают в корпоративные программы, такие как Яндекс Трекер.
Сравним гибкую методологию с её основным антиподом — линейным подходом Waterfall, или «Водопадом».
Критерии | Agile | Waterfall |
---|---|---|
Продукт | Есть общие требования к конечному результату, допустимо менять его в процессе | Есть точное ТЗ и образ конечного результата, которому нужно следовать |
Этапы работы | Цикл «сбор требований — проектирование — разработка — тестирование» повторяется много раз, так как продукт создаётся «частями» | Продукт создаётся за один цикл: сбор требований, проектирование, разработка, тестирование, поддержка. На каждом этапе команда делает полный список работ |
Документация | На документацию тратят минимум времени | Ведение документации обязательно на каждом этапе |
Вид сотрудничества | Сотрудники работают вместе, тесно и открыто общаются | Каждый сотрудник работает над своей частью проекта, в тесном общении нет необходимости |
Сфера применения | Подходит для небольших интеллектуальных проектов с нематериальной продукцией, такой как программное обеспечение, ноу-хау в маркетинге или услуги | Подходит для материального производства и крупных проектов: строительства, промышленности, сельского хозяйства |
Роль заказчика | Заказчик постоянно на связи с командой и знает, что происходит в проекте | Заказчик не обязан контактировать с командой в процессе работы, его задача — принять или отклонить конечный результат |
Выпуск продукта | Клиенты могут пользоваться продуктом начиная с ранних этапов проекта | Клиенты увидят продукт, когда он будет полностью готов |
Критерии | Продукт | Этапы работы | Документация | Вид сотрудничества | Сфера применения | Роль заказчика | Выпуск продукта |
---|---|---|---|---|---|---|---|
Agile | Есть общие требования к конечному результату, допустимо менять его в процессе | Цикл «сбор требований — проектирование — разработка — тестирование» повторяется много раз, так как продукт создаётся «частями» | На документацию тратят минимум времени | Сотрудники работают вместе, тесно и открыто общаются | Подходит для небольших интеллектуальных проектов с нематериальной продукцией, такой как программное обеспечение, ноу-хау в маркетинге или услуги | Заказчик постоянно на связи с командой и знает, что происходит в проекте | Клиенты могут пользоваться продуктом начиная с ранних этапов проекта |
Waterfall | Есть точное ТЗ и образ конечного результата, которому нужно следовать | Продукт создаётся за один цикл: сбор требований, проектирование, разработка, тестирование, поддержка. На каждом этапе команда делает полный список работ | Ведение документации обязательно на каждом этапе | Каждый сотрудник работает над своей частью проекта, в тесном общении нет необходимости | Подходит для материального производства и крупных проектов: строительства, промышленности, сельского хозяйства | Заказчик не обязан контактировать с командой в процессе работы, его задача — принять или отклонить конечный результат | Клиенты увидят продукт, когда он будет полностью готов |
До 90-х Waterfall успешно применялся в сфере IT, так как программисты заимствовали приёмы из проектирования и строительства. Позже, когда понадобилось ускорить и упростить создание программ, многие отказались от «Водопада». Сейчас многие крупные компании используют гибридную модель, в которую входят практики из обеих методологий.
Узнать больше о различиях Agile и Waterfall можно в этой статье.
Вот несколько примеров, когда стоит выбрать подход Agile для управления проектами:
Для длительных проектов гибкая методология не подходит. В масштабных работах, которые идут несколько месяцев, важно иметь структуру и план, контролировать каждый этап.
Не подойдёт Agile и для типовых проектов, где все этапы известны заранее и можно составить план в начале работы. Например, если компании нужно построить несколько однотипных зданий, лучше использовать другую методологию.
Некоторым заказчикам сложно участвовать в обсуждениях каждого этапа с командой, или они не хотят тратить на это время — в этом случае Agile тоже лучше не применять.
Процесс внедрения можно разделить на несколько этапов:
1. Определите цели и задачи внедрения. Необходимо проанализировать, подходит ли Agile для вашего проекта. Внедрите методологию, если необходимо быстро выпустить на рынок востребованный продукт и опередить конкурентов. Или если результат заранее неизвестен, т. е. когда вы внедряете что-то инновационное или запускаете стартап.
2. Сформируйте и обучите команду. Важно оценить, готовы ли ваши сотрудники к гибкому подходу и командной работе. Расскажите им о сути Agile, о том, как внедрение методологии изменит процессы и какие роли будут у каждого работника.
3. Разработайте пилотный проект. Не стоит внедрять Agile сразу для всех проектов компании. Начинать лучше с «пилота», который будет ограничен по времени, бюджету и ресурсам. Так вы сможете понять, справилась ли команда с задачами и стоит ли применять Agile в дальнейшем.
Диджитал-агентство решило использовать гибкую методологию, чтобы создать лендинг для своего продукта. Если Agile покажет эффективность, то её будут внедрять и на клиентских проектах.
4. Реализуйте проект. Для успешной реализации «пилота» важна слаженность работы команды. Яндекс Трекер поможет организовать весь процесс в единой среде. В нём удобно планировать спринты, отслеживать состояние задач и визуализировать их на виртуальной доске.
5. Оцените результат. После завершения проекта поговорите со всеми сотрудниками, выявите ошибки и подумайте, как их можно исправить в будущем. Если в целом работа по Agile была успешной, можно внедрить её в управление другими проектами.