Agile: что это такое и как работает гибкое управление проектами
О принципах работы по Agile и о том, для каких проектов подходит эта методология, а в каких лучше использовать другие методы.
Agile (эджайл) — методология управления проектами.
Она возникла в сфере IT и сначала использовалась для разработки ПО. Сейчас Agile используют и в других отраслях — поэтому, кроме проджектов, в методологии должны разбираться и другие менеджеры, а также руководители компаний.
В статье:
Термин Agile используют в двух значениях:
С английского agile переводится как «гибкий». Гибкость лежит в основе и философии, и методологий. Это означает, что команда, которая работает по Agile, быстро адаптируется к изменениям в работе и новым вводным. Например, к новым требованиям заказчика, новым потребностям целевой аудитории, изменениям в рыночных условиях или другим неожиданным обстоятельствам.
Agile — прямая противоположность методологии Waterfall («Водопад»). Waterfall была доминирующей методологией управления проектами во второй половине XX века.
Суть Waterfall заключается в следующем. Команда проекта составляет детальное техническое задание и согласовывает его с заказчиком. Затем занимается разработкой строго по утверждённому плану и сдаёт заказчику готовый продукт.
В системе Agile всё устроено по-другому. Продукт стараются разработать как можно быстрее — так, чтобы начать им пользоваться почти сразу. Функции продукта меняют в ходе разработки. При этом команда проекта находится в постоянном контакте с заказчиком.
Как система ценностей Agile сформировалась в 2001 году. Её придумала группа разработчиков, которые поняли, что старые способы управления проектами не всегда работают хорошо. Так появился Agile-манифест — подробнее о нём говорим в следующем разделе.
Четыре ценности гибкого управления проектами:
Кроме главных ценностей, в Agile-манифесте перечислены 12 принципов Agile:
Она возникла в сфере IT и сначала использовалась для разработки ПО. Сейчас Agile используют и в других отраслях — поэтому, кроме проджектов, в методологии должны разбираться и другие менеджеры, а также руководители компаний.
В статье:
- что такое Agile;
- в чём заключаются принципы гибкого управления проектами;
- какие есть виды Agile-методологий;
- как управляют проектом по Scrum;
- каким проектам подходят гибкие методологии, а каким не подходят;
- как узнать больше о проектном управлении.
Термин Agile используют в двух значениях:
- Это философия, система ценностей и принципов, по которым работает команда проекта.
- Это семейство методологий управления проектами, которые созданы на базе философии Agile.
С английского agile переводится как «гибкий». Гибкость лежит в основе и философии, и методологий. Это означает, что команда, которая работает по Agile, быстро адаптируется к изменениям в работе и новым вводным. Например, к новым требованиям заказчика, новым потребностям целевой аудитории, изменениям в рыночных условиях или другим неожиданным обстоятельствам.
Agile — прямая противоположность методологии Waterfall («Водопад»). Waterfall была доминирующей методологией управления проектами во второй половине XX века.
Суть Waterfall заключается в следующем. Команда проекта составляет детальное техническое задание и согласовывает его с заказчиком. Затем занимается разработкой строго по утверждённому плану и сдаёт заказчику готовый продукт.
В системе Agile всё устроено по-другому. Продукт стараются разработать как можно быстрее — так, чтобы начать им пользоваться почти сразу. Функции продукта меняют в ходе разработки. При этом команда проекта находится в постоянном контакте с заказчиком.
Как система ценностей Agile сформировалась в 2001 году. Её придумала группа разработчиков, которые поняли, что старые способы управления проектами не всегда работают хорошо. Так появился Agile-манифест — подробнее о нём говорим в следующем разделе.
- «Управление проектами» — систематизировать знания, получить недостающие навыки и зарабатывать больше.
Четыре ценности гибкого управления проектами:
- ЛЮДИ И ВЗАИМОДЕЙСТВИЕ важнее процессов и инструментов.
- РАБОТАЮЩИЙ ПРОДУКТ важнее исчерпывающей документации.
- СОТРУДНИЧЕСТВО С ЗАКАЗЧИКОМ важнее согласования условий контракта.
- ГОТОВНОСТЬ К ИЗМЕНЕНИЯМ важнее следования первоначальному плану.
Кроме главных ценностей, в Agile-манифесте перечислены 12 принципов Agile:
- Приоритет команды проекта — удовлетворение потребностей заказчика с помощью своевременной и регулярной поставки качественного продукта.
- Изменение требований к продукту приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют обеспечить продукт конкурентными преимуществами.
- Промежуточный рабочий продукт нужно показывать заказчику как можно чаще — с периодичностью от пары недель до пары месяцев.
- Руководители и разработчики должны ежедневно работать вместе на протяжении всего проекта.
- Над проектом должны работать мотивированные специалисты. Нужно создать для них необходимые условия и обеспечить им поддержку.
- Личное общение — самый практичный и эффективный способ обмена информацией в команде.
- Работающий продукт — основной показатель прогресса.
- Процессы в Agile должны быть настроены так, чтобы проект развивался устойчиво. Заказчики, разработчики и пользователи должны быть готовы к тому, что изменения будут вноситься равномерно.
- Постоянное внимание к техническому совершенству продукта и качеству проектирования повышает гибкость проекта.
- Не стоит переусложнять проект — лишние процессы нужно свести к минимуму.
- Лучшие продукты рождаются у команд, которые умеют организовать себя самостоятельно.
- Команда должна постоянно искать способы работать эффективнее и корректировать свой стиль работы.
Главные виды Agile-методологий: Scrum и Kanban
В семейство Agile входит несколько методологий (или фреймворков) для гибкого управления проектами. Мы расскажем о самых популярных Agile-методологиях: Scrum и Kanban.
Scrum
SCRUM (СКРАМ). Чаще всего эту методологию используют в разработке ПО. Проект разбивают на итерации (спринты) — промежутки времени, в которые команда разрабатывает продукт поэтапно.
Обычно один спринт длится 2–4 недели. В конце каждого спринта команда поставляет готовую часть продукта — его «неидеальную» версию, которой уже можно пользоваться, — или дополнительные функции к ней. При этом в начале проекта нет представления о том, как будет выглядеть продукт в самом конце: требования могут меняться в ходе разработки.
Например, к концу первого спринта разрабатывают главную страницу сайта банка. За второй спринт делают отдельную страницу для каждой банковской услуги — ипотеки, потребительских кредитов, вкладов, страхования. В конце третьего спринта на сайте появляются кредитный калькулятор и агрегатор финансовых новостей. И так далее — по мере необходимости сайт дополняют разными фичами. При этом его «сырая» версия работает уже с конца первой итерации.
Скрам — это фреймворк, в котором много специфических ролей, терминов и мероприятий. Мы расскажем о нескольких основных — это поможет лучше понять общую концепцию методологии.
Команда, или developers, — люди, которые создают продукт. Простыми словами — разработчики. Состав команды формируют отдельно для каждого проекта.
Скрам-мастер — менеджер, который направляет команду и решает проблемы, замедляющие рабочий процесс. Его задача — организовать работу так, чтобы каждый участник команды понимал потребности клиента и мог предлагать свои идеи. Также скрам-мастер организует общение клиента и команды на совместных мероприятиях.
Владелец продукта, или product owner, — человек, который отвечает за ценность продукта и за бэклог. Обычно это представитель заказчика. Он передаёт команде новые требования к продукту и следит, чтобы команда работала в нужном направлении.
Бэклог — список задач проекта, расположенных по приоритетности.
Scrum-митинг (дэйли или стендап) — ежедневный сбор команды примерно на 15 минут. За это время каждый участник команды отвечает на три вопроса:
Это далеко не вся терминология Scrum-методологии. Больше об этом фреймворке можно узнать в «Руководстве по Scrum», написанном основателями метода Джеффом Сазерлендом и Кеном Швабером.
Kanban
KANBAN («КАНБАН»). Эту методологию разработали в Японии и изначально использовали в производстве автомобилей. Слово kanban на японском означает «вывеска».
Задачи проекта расставляют в виде карточек на доске, разлинованной на колонки. Эти колонки отражают этапы выполнения проекта. Участник команды берёт задачу, перемещает карточку по доске от одной колонки к другой, и вся команда видит актуальный статус этой задачи.
Идея в том, чтобы работа над проектом шла по принципу конвейера. То есть чтобы разработчики не задумывались над планированием задач и их приоритизацией, а приходили к доске, брали задачу и шли её выполнять.
Обычно на канбан-досках минимум три колонки: «Выполнить», «В работе» и «Выполнено». Чаще всего к ним добавляют колонки для промежуточных этапов: «Бэклог», «На согласовании», «Тестирование» и так далее.
Традиционно канбан-доски представляли собой физические доски — например, магнитные или пробковые, — на которых крепили бумажные карточки. Позже появились онлайн-доски. Самые популярные из них — Trello, Jira, Asana.
В отличие от других методов проектного управления, канбан-команда работает без жёстких временных ограничений — даже несмотря на то, что на онлайн-досках задачам можно назначать срок выполнения.
Вместо этого работа над проектом организована как непрерывный поток задач. Когда участник команды заканчивает одну задачу, он идёт за другой, потом за следующей и так далее.
SCRUM (СКРАМ). Чаще всего эту методологию используют в разработке ПО. Проект разбивают на итерации (спринты) — промежутки времени, в которые команда разрабатывает продукт поэтапно.
Обычно один спринт длится 2–4 недели. В конце каждого спринта команда поставляет готовую часть продукта — его «неидеальную» версию, которой уже можно пользоваться, — или дополнительные функции к ней. При этом в начале проекта нет представления о том, как будет выглядеть продукт в самом конце: требования могут меняться в ходе разработки.
Например, к концу первого спринта разрабатывают главную страницу сайта банка. За второй спринт делают отдельную страницу для каждой банковской услуги — ипотеки, потребительских кредитов, вкладов, страхования. В конце третьего спринта на сайте появляются кредитный калькулятор и агрегатор финансовых новостей. И так далее — по мере необходимости сайт дополняют разными фичами. При этом его «сырая» версия работает уже с конца первой итерации.
Скрам — это фреймворк, в котором много специфических ролей, терминов и мероприятий. Мы расскажем о нескольких основных — это поможет лучше понять общую концепцию методологии.
Команда, или developers, — люди, которые создают продукт. Простыми словами — разработчики. Состав команды формируют отдельно для каждого проекта.
Скрам-мастер — менеджер, который направляет команду и решает проблемы, замедляющие рабочий процесс. Его задача — организовать работу так, чтобы каждый участник команды понимал потребности клиента и мог предлагать свои идеи. Также скрам-мастер организует общение клиента и команды на совместных мероприятиях.
Владелец продукта, или product owner, — человек, который отвечает за ценность продукта и за бэклог. Обычно это представитель заказчика. Он передаёт команде новые требования к продукту и следит, чтобы команда работала в нужном направлении.
Бэклог — список задач проекта, расположенных по приоритетности.
Scrum-митинг (дэйли или стендап) — ежедневный сбор команды примерно на 15 минут. За это время каждый участник команды отвечает на три вопроса:
- что он сделал с прошлой встречи;
- что планирует делать сегодня;
- что этому мешает.
Это далеко не вся терминология Scrum-методологии. Больше об этом фреймворке можно узнать в «Руководстве по Scrum», написанном основателями метода Джеффом Сазерлендом и Кеном Швабером.
Kanban
KANBAN («КАНБАН»). Эту методологию разработали в Японии и изначально использовали в производстве автомобилей. Слово kanban на японском означает «вывеска».
Задачи проекта расставляют в виде карточек на доске, разлинованной на колонки. Эти колонки отражают этапы выполнения проекта. Участник команды берёт задачу, перемещает карточку по доске от одной колонки к другой, и вся команда видит актуальный статус этой задачи.
Идея в том, чтобы работа над проектом шла по принципу конвейера. То есть чтобы разработчики не задумывались над планированием задач и их приоритизацией, а приходили к доске, брали задачу и шли её выполнять.
Обычно на канбан-досках минимум три колонки: «Выполнить», «В работе» и «Выполнено». Чаще всего к ним добавляют колонки для промежуточных этапов: «Бэклог», «На согласовании», «Тестирование» и так далее.
Традиционно канбан-доски представляли собой физические доски — например, магнитные или пробковые, — на которых крепили бумажные карточки. Позже появились онлайн-доски. Самые популярные из них — Trello, Jira, Asana.
В отличие от других методов проектного управления, канбан-команда работает без жёстких временных ограничений — даже несмотря на то, что на онлайн-досках задачам можно назначать срок выполнения.
Вместо этого работа над проектом организована как непрерывный поток задач. Когда участник команды заканчивает одну задачу, он идёт за другой, потом за следующей и так далее.
Один из вариантов Kanban-доски
В большинстве отраслей — например, в маркетинге, SMM, издательском бизнесе — когда говорят, что работают по Agile, имеют в виду Scrum или Kanban.
В сфере IT, кроме этих методологий Agile, применяют и другие. Например, XP (экстремальное программирование), Lean (бережливая разработка ПО), Dynamic systems development method (метод разработки динамических систем). В каждой методологии свои практики и инструменты — выбор зависит от потребностей проекта.
В большинстве отраслей — например, в маркетинге, SMM, издательском бизнесе — когда говорят, что работают по Agile, имеют в виду Scrum или Kanban.
В сфере IT, кроме этих методологий Agile, применяют и другие. Например, XP (экстремальное программирование), Lean (бережливая разработка ПО), Dynamic systems development method (метод разработки динамических систем). В каждой методологии свои практики и инструменты — выбор зависит от потребностей проекта.
Этапы управления проектами по Scrum
Как мы говорили выше, в Scrum работа делится на спринты. Каждый спринт — короткий период, в течение которого команда работает над несколькими задачами: анализирует их, выполняет, тестирует, обсуждает с заказчиком и при необходимости дорабатывает. Рассмотрим, как это проходит, поэтапно.
Этапы управления проектами по методологии Scrum.
Планирование. На этом этапе определяют основную идею проекта, обсуждают требования заказчика и формируют перечень задач. По-другому такой перечень называют бэклогом. Дальше задачи приоритизируют — самые важные и срочные размещают в верхней части бэклога.
Анализ. Из верхней части бэклога команда выбирает задачи для одной итерации. Затем определяет, какие ресурсы понадобятся для выполнения этих задач, и распределяет их между собой.
На этом же этапе формируют критерии успешного завершения каждой задачи: по каким параметрам будет понятно, что задача выполнена хорошо. Благодаря такому подходу у всей команды формируются одинаковые ожидания относительно результатов итерации.
Выполнение. Участники команды работают над своими задачами. Каждый день они встречаются, чтобы обсудить текущий прогресс: что они сейчас делают, какие проблемы у них возникают, что они планируют делать дальше. Это важно для того, чтобы работа над проектом была прозрачной и все участники команды владели ситуацией.
Тестирование. На этом этапе проверяют работоспособность проекта — например, запускается ли программа, выполняет ли она свои функции корректно и так далее. Этап тестирования проходит параллельно с этапом выполнения. Это нужно, чтобы быстро реагировать на обнаруженные проблемы и вносить изменения вовремя.
Релиз. В конце спринта команда показывает заказчику результаты своей работы — например, готовую программу или часть её функций. Заказчик даёт обратную связь — объясняет, что его устраивает, а что нет. Если есть замечания, команда обсуждает, как будет дорабатывать проект, и возвращается к предыдущим этапам.
Если замечаний нет, команда переходит к следующей итерации. Такой цикл повторяется до завершения всего проекта — например, до стадии, когда программу отдают заказчику полностью готовой.
Таким образом, методология Scrum позволяет команде быстро реагировать на изменения, постоянно взаимодействовать с заказчиком, учитывать новые требования и создавать актуальный продукт.
Планирование. На этом этапе определяют основную идею проекта, обсуждают требования заказчика и формируют перечень задач. По-другому такой перечень называют бэклогом. Дальше задачи приоритизируют — самые важные и срочные размещают в верхней части бэклога.
Анализ. Из верхней части бэклога команда выбирает задачи для одной итерации. Затем определяет, какие ресурсы понадобятся для выполнения этих задач, и распределяет их между собой.
На этом же этапе формируют критерии успешного завершения каждой задачи: по каким параметрам будет понятно, что задача выполнена хорошо. Благодаря такому подходу у всей команды формируются одинаковые ожидания относительно результатов итерации.
Выполнение. Участники команды работают над своими задачами. Каждый день они встречаются, чтобы обсудить текущий прогресс: что они сейчас делают, какие проблемы у них возникают, что они планируют делать дальше. Это важно для того, чтобы работа над проектом была прозрачной и все участники команды владели ситуацией.
Тестирование. На этом этапе проверяют работоспособность проекта — например, запускается ли программа, выполняет ли она свои функции корректно и так далее. Этап тестирования проходит параллельно с этапом выполнения. Это нужно, чтобы быстро реагировать на обнаруженные проблемы и вносить изменения вовремя.
Релиз. В конце спринта команда показывает заказчику результаты своей работы — например, готовую программу или часть её функций. Заказчик даёт обратную связь — объясняет, что его устраивает, а что нет. Если есть замечания, команда обсуждает, как будет дорабатывать проект, и возвращается к предыдущим этапам.
Если замечаний нет, команда переходит к следующей итерации. Такой цикл повторяется до завершения всего проекта — например, до стадии, когда программу отдают заказчику полностью готовой.
Таким образом, методология Scrum позволяет команде быстро реагировать на изменения, постоянно взаимодействовать с заказчиком, учитывать новые требования и создавать актуальный продукт.
Где используют Agile: для каких проектов подходят гибкие методологии, а для каких — нет
Методологии Agile подходят для проектов высокой степени неопределённости. При работе над таким проектом непонятно, каким в итоге получится продукт, — не видна конечная цель проекта. Или, наоборот, цель есть, но не виден путь, который нужно пройти, чтобы этой цели достичь, — неясно, как разрабатывать продукт.
Вот примеры проектов, в которых гибкие методологии работают хорошо:
Таким образом, если вы в начале проекта можете чётко описать его результат и составить план необходимых работ, методики Agile не подойдут. В этих случаях лучше использовать Waterfall.
Главное об Agile в 4 пунктах
- разработка ПО и сайтов;
- создание новых продуктов;
- маркетинговые и рекламные кампании;
- творческие проекты — например, издательский бизнес.
Таким образом, если вы в начале проекта можете чётко описать его результат и составить план необходимых работ, методики Agile не подойдут. В этих случаях лучше использовать Waterfall.
Главное об Agile в 4 пунктах
- Agile — философия гибкого управления проектами и семейство методологий на её основе.
- Методология Agile предполагает, что команда проекта быстро адаптируется к изменениям в работе и новым вводным. Например, к новым требованиям заказчика или изменениям на рынке.
- В семейство Agile входит несколько методологий гибкого управления проектами. В России чаще всего используют Kanban и Scrum.
- Гибкие методологии лучше всего подходят для проектов, при работе над которыми требуется быстро реагировать на изменения и совершенствовать продукт в ходе его создания. В случаях, когда задачи проекта важно решать последовательно и строго по первоначальному плану, Agile не подойдёт.
