Agile: что это, где применяется и как освоить

Главное заблуждение: гибкий подход не сводится к доске с колонками и ежедневному созвону. Их заводят за вечер, а работа остаётся прежней: всё «почти готово», заказчик видит результат через два месяца. Манифест Agile 2001 года написали разработчики, и его седьмой принцип называет главной мерой прогресса работающий программный продукт. В маркетинге или HR мерой становится опубликованная статья, запущенная рассылка, закрытая вакансия, а не процент готовности в отчёте. Поэтому начинать стоит с вопроса «что мы покажем заказчику через две недели», а не с выбора трекера.

Что меняется в работе команды

Два самых распространённых подхода — Scrum и Kanban — решают одну задачу разными средствами. Scrum задаёт ритм: работа идёт спринтами постоянной длины, по Руководству по Scrum не дольше месяца. В начале спринта команда планирует, что успеет, каждый день 15 минут сверяет, как движется работа к цели, в конце показывает результат на обзоре, а на ретроспективе ищет, как работать лучше. Для месячного спринта ретроспектива ограничена тремя часами, для более коротких спринтов она обычно короче.

Kanban ритма не задаёт. Задачи идут непрерывным потоком, а команда следит, чтобы одновременно их не застревало слишком много. Это удобно там, где заявки приходят каждый день и ждать планирования нельзя: внутренние запросы на дизайн, поддержка, подбор персонала.

Команды вне ИТ чаще всего берут поток и доску из Kanban, а из Scrum — регулярный обзор и ретроспективу. Это нормально, если помнить назначение каждого элемента: обзор нужен, чтобы заказчик увидел готовое и поправил направление, ретроспектива — чтобы команда меняла способ работы, а не только список дел.

Где agile не нужен

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

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

Учебный пример: отдел маркетинга и бесконечные заявки

Ситуация учебная. В отделе маркетинга четыре человека: руководитель, два автора и дизайнер. Заявки приходят от продаж, HR и руководства: презентация для клиента, пост о вакансии, рассылка к акции. На доске в колонке «В работе» 23 задачи, почти каждая ждёт чьего-то ответа, а продажи не понимают, когда получат материалы.

Руководитель открывает Руководство по Kanban (версия от мая 2025 года) и обнаруживает, что доска с колонками по этому документу ещё не Kanban. Руководство требует «определение рабочего процесса» из шести обязательных элементов: что считается единицей работы, когда она начата и завершена, через какие состояния проходит, как ограничено число незавершённых задач, по каким явным правилам задача переходит дальше, и ожидание по сроку обслуживания. Ограничение незавершённой работы — не рекомендация: участники должны явно контролировать число начатых задач и брать новую, только когда есть ясный сигнал, что на неё хватит сил.

Команда договаривается так. Единица работы — заявка с одним итоговым материалом; большую кампанию делят на несколько заявок. Начатой задача считается, когда исполнитель забрал её из очереди, завершённой — когда материал опубликован или передан заказчику, а не отправлен на согласование. Состояния: «Текст», «Дизайн», «Согласование», «Готово». Начатых задач на команду не больше шести. Если материал лежит у заказчика больше двух рабочих дней, руководитель звонит ему сам.

Шестой элемент — ожидание по сроку обслуживания, SLE (service level expectation): прогноз из срока и вероятности, например «85 % задач завершаются за восемь дней или быстрее». Считают его по истории, а не придумывают. Месяц команда записывает даты начала и завершения заявок и получает своё число — допустим, 85 % укладываются в семь рабочих дней. Теперь на вопрос «когда будет?» есть ответ по данным, а каждое утро команда смотрит на задачи, чей возраст приближается к семи дням: руководство прямо требует следить, чтобы задачи не старели без необходимости.

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

С чего начать и в каком порядке осваивать

Порядок освоения идёт от того, что видно, к тому, что требует договорённостей. Сначала нужно увидеть собственный поток работы, иначе правила будут придуманы наугад. Затем появляется ограничение, потом ритм встреч и лишь в конце — роли и формальные методики. Если начать с ролей и ритуалов Scrum, легко получить созвоны без изменений в работе.

1. Две недели записывайте свои задачи: откуда пришла, когда начали, когда закончили, сколько ждали чужого ответа.
2. Нарисуйте доску с реальными состояниями и договоритесь, что значит «начато» и «готово».
3. Введите лимит начатых задач и заметьте, где они теперь скапливаются.
4. Проведите обзор с заказчиком и ретроспективу; выносите из неё одно-два изменения, не больше.
5. После месяца учёта посчитайте свой срок обслуживания.
6. Только после этого прочитайте Руководство по Scrum и решите, нужны ли команде спринты и роли.

Пройти эту последовательность с разбором ролей, событий и метрик можно в коротком формате. На онлайн-курсе «Agile: Scrum и Kanban в работе над продуктом» Skillbox месяц обучения и 42 видеоматериала: бэклог, роли и события Scrum, критерии готовности, ретроспективы и фасилитация, метрики потока в Kanban, удалённая работа в Jira и Trello. Итоговая работа — план внедрения Scrum или Kanban. Примеры взяты из продуктовых команд, их придётся переносить на свою работу.

Упражнения и типичные ошибки

Полезное упражнение — разобрать одну застрявшую задачу: сколько дней её делали и сколько она ждала. Обычно ожидание занимает больше половины срока, и становится ясно, что ускорять нужно согласования, а не авторов. Второе — провести ретроспективу по одному вопросу: «что в прошлом цикле отняло больше всего времени зря». Через цикл проверьте, выполнено ли решение и изменилась ли проблема.

Новички ошибаются в четырёх местах. Нарушают лимит «для срочного», и он перестаёт что-либо значить. Считают задачу готовой, когда она ушла на согласование. Превращают ежедневную встречу в отчёт руководителю. Проводят ретроспективы, после которых ничего не меняется. Отдельная ошибка руководителя — ввести agile приказом и продолжать решать всё самому: короткие циклы работают, когда команда решает, как выполнить задачу, а руководитель отвечает за приоритеты и снимает препятствия.

Потренировать такие ситуации безопаснее на учебной команде. На онлайн-курсе «Agile-менеджмент: управление продуктами и проектами» Нетологии шесть месяцев и 173 часа, из них 66 — практика: пользовательские истории, декомпозиция бэклога, доска Kanban с лимитами, бизнес-симуляция с командой и ретроспективой, подготовка к экзамену Professional Scrum Master I. Программа рассчитана на тех, кто уже работает с командой, и требует 8–10 часов в неделю.

Как навык влияет на доход

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

Роли, где гибкие методы и есть основная работа, — скрам-мастер и agile-коуч — встречаются в основном в ИТ и крупных компаниях. Открытых данных о зарплатах по ним мало: на странице Хабр Карьеры о скрам-мастерах расчёт опирается всего на 20 анкет. Надёжнее самим открыть вакансии своей должности, отфильтровать по региону и опыту и сравнить предложения с требованием опыта по Scrum или Kanban и без него. Смотрите на медиану и помните, что в объявлениях обычно указана сумма до вычета налога.

Как выбрать обучение

Сначала решите, что вам нужно: наладить работу своей команды или сменить профессию. Для первого хватит короткой программы и собственной доски. При выборе проверьте, будет ли практика на вашем материале или на учебной команде, разбирают ли Kanban как метод с лимитами и метриками, а не только как доску, и есть ли примеры вне разработки. Руководителю, который переводит отдел на гибкий подход, может подойти программа «Эджайл (Agile)» Московской бизнес академии: месяц дистанционного обучения, 29 видеоматериалов об Agile, Scrum и Kanban и удостоверение о повышении квалификации. Названия модулей на странице не приведены, а проверяемое задание одно, поэтому состав программы стоит уточнить у школы.

Если же навык тянет к смене роли, присмотритесь к связанным профессиям: менеджер проектов, продакт-менеджер, тимлид, руководитель проектного офиса. О них на сайте есть отдельные статьи, и там нужны месяцы практики, а иногда и международный сертификат.

Отдельного рейтинга по agile на сайте нет. Ближе всего к теме рейтинг онлайн-школ по управлению проектами — он шире: гибкие методы составляют лишь часть его программ. Прежде чем платить, попробуйте первые три шага из плана выше: за месяц станет понятно, какой части навыка вам не хватает.