Что такое Agile простыми словами: принципы, Scrum, Kanban и где это работает

Что такое Agile простыми словами

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

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

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

Важно. Частая путаница: Agile — не методология. Методология описывает, что делать по шагам. Agile описывает, чему следовать при принятии решений. Конкретные шаги дают уже фреймворки — Scrum, Kanban и другие.

Откуда взялся Agile

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

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

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

12 принципов манифеста

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

Ценность важнее объёма работ

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

Передумать разрешено

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

Люди решают больше, чем регламент

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

Заказчик внутри работы, а не снаружи

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

Ровный темп вместо рывков

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

Простота и аккуратность

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

Чинить не только продукт, но и сам процесс

Команда регулярно останавливается и разбирает, что мешало работать, после чего меняет способ работы. Без этого шага всё остальное превращается в ритуал.

Как Agile выглядит в работе

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

Итерация, или спринт

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

Бэклог

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

Инкремент

То, что появилось за цикл и уже работает. Ключевое слово — «работает»: макет, черновик и «осталось чуть-чуть» инкрементом не считаются, даже если труда в них вложено много.

Как выглядит бэклог

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

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

Обратите внимание на числа в таблице: 3, 5, 8, 13. Это не случайный набор, каждое следующее равно сумме двух предыдущих. Такой шкалой пользуются нарочно: чем крупнее задача, тем крупнее шаг между вариантами. Спорить, семь тут или восемь, просто не получится — таких значений в шкале нет.

Из чего состоит спринт

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

Планирование

Команда смотрит на верх бэклога и сама решает, сколько возьмёт. Именно сама — если объём назначают сверху, оценка превращается в формальность, а сроки всё равно поедут.

Ежедневная синхронизация

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

Обзор результата

Показывают не слайды и не проценты готовности, а то, что работает. Здесь и всплывает «мы имели в виду немного другое» — ради этого встреча и придумана. Услышать такое через две недели дёшево, через полгода дорого.

Ретроспектива

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

Scrum и Kanban: чем отличаются

Это два самых распространённых способа воплотить принципы Agile. Их часто произносят через запятую, хотя устроены они по-разному.

Scrum строит работу вокруг спринтов. Команда берёт объём задач на цикл, внутри цикла состав задач не меняется, а в конце проходят две встречи — показ результата и разбор процесса. Ролей в Scrum три. Владелец продукта отвечает за то, что делать. Скрам-мастер следит, чтобы процесс работал. Команда решает, как сделать.

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

Канбан-доска — самый узнаваемый инструмент подхода, и её часто заводят в отрыве от всего остального. Доска сама по себе Kanban не делает: без ограничения на число задач в работе она превращается в обычный список дел, где всё одновременно «в процессе».

Какие ещё есть фреймворки, кроме Scrum и Kanban

Scrum и Kanban — самые известные, но не единственные. Ещё несколько названий встречаются в вакансиях и на собеседованиях достаточно часто, чтобы понимать, о чём речь.

XP, экстремальное программирование

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

Lean, бережливая разработка

Идея пришла с заводов Toyota: всё, что не приносит пользы клиенту, — потери. Готовая функция, которая три месяца лежит невыпущенной, с этой точки зрения такая же потеря, как склад непроданных деталей.

SAFe и LeSS

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

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

Agile и водопад: в чём разница

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

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

Плюсы и минусы Agile

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

Где Agile работает, а где мешает

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

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

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

В каких отраслях применяют Agile

Разберём подробнее, где именно гибкий подход прижился за пределами разработки и почему в каждой из этих отраслей он оказался к месту.

Разработка программ

Родная территория: приложения, сайты, сервисы. Здесь гибкий подход давно стал нормой.

Банки и финтех

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

Интернет-торговля

Карточку товара, корзину и доставку меняют по тому, как ведут себя покупатели. Годовой план тут бесполезен: данные приходят каждую неделю.

Маркетинг

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

Медиа и редакции

План выпусков собирают на короткий срок и перестраивают под то, что читают.

HR и обучение

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

Как отличить настоящий Agile от имитации

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

Спринт есть, а результата нет

В конце цикла нечего показать, потому что задачи «почти готовы». Спринт без работающего инкремента — просто отрезок календаря.

Ежедневная встреча превратилась в планёрку

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

Бэклог никто не пересматривает

Список задач составлен полгода назад и с тех пор не менялся по приоритетам. Это уже не бэклог, а техническое задание с другим названием.

Ретроспективы нет или она ничего не меняет

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

План остался жёстким

Сроки и объём согласованы на квартал вперёд и не пересматриваются. Тогда спринты — просто способ нарезать водопад на части.

С чего начать переход на Agile

Переход обычно начинают не с обучения всей компании, а с одной команды и одного процесса. Порядок примерно такой.

Взять одну команду

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

Собрать все задачи в один список

И расставить приоритеты. Это и есть бэклог. Пока задачи живут в головах и переписке, планировать нечего.

Договориться о длине цикла

Две недели — самый частый вариант. Короче — слишком много времени уходит на встречи, длиннее — теряется смысл быстрой обратной связи.

Завести доску

Столбцы по этапам: нужно сделать, в работе, на проверке, готово. И сразу ограничить, сколько задач может одновременно висеть в столбце «в работе».

Провести показ результата и ретроспективу

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

Через два-три цикла решить, что менять

Первые спринты почти всегда идут плохо: команда не угадывает объём. Это нормально, оценка выравнивается примерно к четвёртому циклу.

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

В чём вести доску и задачи

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

Долгое время стандартом была Jira, а для простых досок — Trello. Оба сервиса принадлежат Atlassian, которая в 2022 году свернула работу с российскими пользователями, поэтому команды перешли на другие сервисы.

Кому нужно разбираться в Agile

Знание подхода перестало быть узкой темой для руководителей проектов — его спрашивают на собеседованиях в нескольких профессиях сразу.

Project-менеджер

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

Product-менеджер

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

Бизнес- и системный аналитик

Работает с требованиями, которые в гибком подходе меняются по ходу, а не фиксируются один раз.

Разработчик и тестировщик

Живёт внутри процесса: оценивает задачи, участвует в планировании и ретроспективах, отвечает за готовность инкремента.

Маркетолог

Гипотезы, короткие циклы проверки и отказ от кампаний, которые не сработали, — та же логика, что в разработке.

Двум профессиям из этого списка у нас посвящены отдельные разборы: как стать тестировщиком с нуля и кто такой бизнес-аналитик.

Что спрашивают про Agile на собеседовании

Вопросы почти всегда проверяют не знание терминов, а понимание смысла. Заучивать двенадцать принципов наизусть бесполезно — спросят иначе.

• «Чем Agile отличается от Scrum»: Проверяют, различаете ли вы подход и фреймворк. Ответ: Agile задаёт принципы, Scrum — один из способов их применить.
• «Что делать, если заказчик меняет требования в середине спринта»: Проверяют, понимаете ли вы смысл фиксированного цикла. Правильный ход — не менять текущий спринт, а положить задачу в бэклог и пересмотреть приоритеты на следующем планировании.
• «Зачем нужна ретроспектива, если и так всё обсуждаем»: Проверяют, отличаете ли вы разговор о продукте от разговора о процессе. Ретроспектива — единственная встреча про то, как команда работает.
• «Как оценивать задачи»: Ждут, что вы знаете про относительную оценку — стори-поинты вместо часов — и понимаете, почему команда оценивает вместе, а не поодиночке.
• «Что такое Definition of Done»: Договорённость команды о том, при каких условиях задача считается готовой. Без неё «почти сделано» тянется из спринта в спринт.

Частые вопросы

Agile и Scrum — это одно и то же?

Нет. Agile — набор принципов, Scrum — один из способов их применить. Можно работать по Scrum и нарушать принципы Agile, а можно следовать принципам без Scrum вовсе.

Нужен ли сертификат по Agile?

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

Можно ли работать по Agile в одиночку?

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

Сколько длится спринт?

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

Agile подходит только для IT?

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