Как объяснить Agile за 15 минут (с картинками)

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера». Этот закон как нельзя лучше описывает проблемы традиционного планирования. Но есть способ с ним бороться, и он называется Agile.

В этой статье я простыми словами, с картинками и без заумных терминов расскажу, что такое Agile, как он работает и почему весь мир от него тащится. Хватит 10 минут.

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

Пэт, владелица продукта. Она не программист. Не знает, как устроены базы данных и API. Зато она знает, зачем мы делаем этот продукт, какие проблемы он решает и для кого. Пэт — это «голос клиента» внутри команды.

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

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

Команда разработки. Те, кто строит продукт. Программисты, тестировщики, дизайнеры. Они превращают пользовательские истории в работающий софт.

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

Как её измерить? Очень просто: посчитать, сколько историй сделано за 7 дней.

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

Важный момент. Чтобы поддерживать такой ритм (4-6 историй в неделю) и не завязнуть в ручном тестировании, команда много внимания уделяет автоматическим тестам. На каждую новую функцию пишутся автотесты, и большая часть кода ими покрыта.

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

Представь, команда соглашается сделать 10 новых историй за неделю. На входе — 10, на выходе — 4-6. Что происходит?

Команда перегружена. Она спешит, переключается между задачами, теряет фокус и мотивацию. В итоге падают и производительность, и качество. Это заведомо проигрышная стратегия.

Как же не перегружаться?

Scrum-подход (метод «вчерашней погоды»): команда смотрит, сколько историй она делала в последнее время (4-6 в неделю), и на этой основе планирует следующую неделю. Пэт (владелица продукта) из 100 просьб выбирает именно эти 4-6 самых важных.

Канбан-подход (WIP-лимиты): команда договаривается, что одновременно может работать не больше чем над N задачами (например, 5). Пока задача не дойдёт до статуса «Готово», новую не начинают.

Оба подхода создают очередь задач. В Scrum она называется Бэклог (приоритизированный список задач).

Этой очередью тоже нужно управлять. Если заинтересованные лица запрашивают 10 историй в неделю, а команда делает 4-6, то очередь будет расти. Бэклог может расписаться на полгода вперёд. Одна история будет ждать выхода 6 месяцев.

Сказать «да» легко. Сказать «нет» — сложно. Но это важнейшее слово для владельца продукта. Его нужно тренировать каждый день перед зеркалом.

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

Чтобы правильно расставлять приоритеты, нужно понимать две вещи:

• Ценность истории для бизнеса или клиента.
• Объём работ (сколько времени и усилий потребуется).

Некоторые истории критически важны. Некоторые — просто «бонусные фичи». На одни уйдёт пара часов, на другие — месяцы.

Важно: Больше — не значит лучше. Размер истории никак не связан с её ценностью.

Как владелец продукта определяет ценность и объём? Угадывает. И лучше угадывать всем вместе.

• Ценность Пэт узнаёт от заинтересованных лиц: «Насколько это важно для вас по шкале от 1 до 10?».
• Объём она узнаёт от команды разработки: «Насколько это сложно? Примерно день, неделя или месяц?».

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

Одной приоритизации недостаточно. Чтобы выпускать истории быстро и часто, их нужно разбивать на маленькие кусочки, которые можно сделать за пару дней.

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

Этот процесс называется очистка бэклога (Backlog Refinement или Grooming). Пэт проводит такую встречу раз в неделю (например, со среды с 11 до 12). Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц.

Владелец продукта постоянно балансирует между разными рисками.

Бизнес-риск: «Правильную ли вещь мы делаем?» (Нужна ли эта фича пользователям?)

Социальный риск: «Сможем ли мы сделать то, что нужно?» (Хватит ли компетенций?)

Технический риск: «Будет ли проект работать на выбранной технологии?»

Риски стоимости и сроков: «Успеем ли и хватит ли денег?»

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

Пэт постоянно балансирует между разными типами задач:

• Срочные ошибки (упал сайт, не проходит оплата).
• Сногсшибательные фичи (которые порадуют пользователей).
• Технический долг и апгрейды (переписать кривой код, обновить платформу, чтобы в будущем работать быстрее).

Нужно постоянно соблюдать баланс между реактивной работой (тушим пожары) и проактивной (инвестируем в будущее).

В идеале — всё три одновременно. В реальности — приходится выбирать.

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

Золотая середина: начинать с быстрого прототипа (чтобы проверить гипотезу), потом улучшать архитектуру (чтобы не утонуть в техническом долге), и постоянно сверяться с пользователем (чтобы делать правильные вещи).

В Scrum между ролями существует здоровое напряжение.

• Владелец продукта (Пэт) фокусируется на том, чтобы строить правильные вещи. Отвечает на вопрос «ЗАЧЕМ?».
• Команда разработки фокусируется на том, чтобы строить вещи правильно. Отвечает на вопрос «КАК?».
• Scrum-мастер (или agile-коуч) фокусируется на том, чтобы сокращать цикл обратной связи. Отвечает на вопрос «КАК БЫСТРО МЫ УЧИМСЯ?».

Короткий цикл обратной связи критически важен. Он позволяет быстро узнавать, какие вещи правильные и как их правильно построить.

Продукт никогда не бывает «завершён». Ему постоянно нужны изменения.

Когда команда начинает работать над новым продуктом, что происходит со старым? Передача продукта от одной команды к другой — дорого и рискованно. Обычно команда поддерживает старый продукт и одновременно разрабатывает новый.

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

Заинтересованные лица постоянно спрашивают: «Когда будет готова моя фича?», «Сколько фичей сделают к рождеству?».

Владелец продукта строит график на основе реальных данных команды (сколько историй делалось в прошлые недели).

• Оптимистичный тренд (верхняя граница) — если скорость будет максимальной.
• Пессимистичный тренд (нижняя граница) — если скорость упадёт.

Расстояние между трендами — это неопределённость. Со временем, когда скорость команды стабилизируется, тренды сближаются.

Три типичных вопроса:

1. «Когда фича будет готова?» (фиксированное содержание, нефиксированные сроки). Пэт смотрит на тренды и отвечает: «Примерно в апреле или мае».
2. «Сколько сделают к рождеству?» (фиксированные сроки, нефиксированное содержание). Пэт смотрит на вертикальную шкалу и называет вероятный диапазон: «К рождеству будет готово 15-20 историй».
3. «Успеем ли мы сделать вот эти 30 историй к рождеству?» (фиксированные сроки и содержание). Пэт смотрит на тренды и отвечает: «Нет. К рождеству мы сделаем примерно 20. Чтобы доделать все 30, понадобится ещё месяц».

Обычно лучше уменьшать содержание, чем увеличивать время. Можно выпустить самое важное вовремя, а остальное — позже.

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

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

У владельцев продуктов появляется дополнительная задача: общаться друг с другом. Нужно организовать работу над бэклогами так, чтобы минимизировать зависимости между командами и синхронизировать усилия. В больших проектах для этого нужен главный владелец продукта (Chief Product Owner).

Agile — это не панацея и не магия. Это просто способ работы, который признаёт, что:

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

Если ты запомнишь из всей статьи только одно, пусть будет это: Пэт (владелец продукта) говорит «нет» 90% просьб, команда работает в стабильном ритме (4-6 историй в неделю), а заинтересованные лица знают реальное положение дел и не ждут чуда. Тогда Agile работает.