Agile: что это такое и при чем тут Scrum и Kanban

Agile (гибкий подход) — это набор ценностей и принципов разработки, записанный в Манифесте гибкой разработки ПО 2001 года: работать короткими циклами, часто показывать работающий результат и менять план по обратной связи. Scrum и Kanban — не синонимы Agile, а два конкретных способа организовать работу в этом духе: Scrum задает ритм спринтов и роли, Kanban управляет потоком задач и ограничивает незавершенную работу.

Если вы пришли с задачей «в стартапе внедрили эджайл, скрам и канбан, производительность упала на 25% — на сколько процентов выросло время выполнения задачи», ответ: на 33 1/3 % (примерно 33,3%), а не на 25%. Разбор — в отдельном разделе ниже.

Мини-словарь: три уровня, которые путают

Упрощенно: Agile отвечает на вопрос «что для нас важно», Scrum и Kanban — «как именно мы работаем каждый день». Команда может быть «agile» и без Scrum, а Scrum без agile-ценностей превращается в набор обязательных созвонов.

Манифест Agile: 4 ценности

Манифест написали 17 практиков разработки в феврале 2001 года на встрече в Сноуберде (штат Юта, США). Он короткий: четыре ценности и двенадцать принципов. Ценности сформулированы как сравнение «это важнее того».

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

12 принципов, сгруппированные по смыслу

Принципы удобнее запоминать группами (пересказ, не дословный текст):

1. Ценность для заказчика. Главное — ранние и регулярные поставки полезного продукта; изменения требований приветствуются даже на поздних этапах, если дают преимущество заказчику.
2. Короткие циклы. Работающий продукт выпускается часто — с периодом от пары недель до пары месяцев, и чем короче, тем лучше; работающий продукт — основная мера прогресса.
3. Люди. Бизнес и разработчики работают вместе ежедневно; проекты строят вокруг мотивированных людей, им дают среду и доверие; самый действенный обмен информацией — живой разговор.
4. Устойчивый темп. Команда должна держать постоянный темп неограниченно долго, без авралов.
5. Качество и простота. Постоянное внимание к техническому качеству и дизайну; простота — искусство не делать лишней работы.
6. Самоорганизация и улучшение. Лучшие решения рождаются в самоорганизующихся командах; команда регулярно анализирует, как стать эффективнее, и корректирует поведение.

Если после «внедрения Agile» команда живет в режиме постоянных авралов, это нарушение принципа устойчивого темпа, а не его следствие.

Scrum: ритм спринтов и три подотчетности

Scrum описан в официальном Scrum Guide (актуальная редакция на сентябрь 2026 — ноябрь 2020 года; Scrum Guide Expansion Pack 2025 года — дополнение части соавторов, а не новая редакция руководства). Работа идет спринтами фиксированной длины — не больше месяца, чаще 1-2 недели. В каждом спринте команда берет цель, делает готовый к использованию инкремент и в конце проверяет и результат, и свой способ работы.

• Подотчетности: Product Owner (ценность продукта и порядок бэклога), Scrum Master (эффективность команды и процесса), Developers (создание инкремента). В команде обычно 10 человек или меньше.
• События: сам спринт, планирование, ежедневный Scrum (15 минут), обзор спринта, ретроспектива.
• Артефакты: Product Backlog, Sprint Backlog, Increment — у каждого свое обязательство (цель продукта, цель спринта, критерии готовности).

Scrum полезен, когда продукт развивается по целям и нужна регулярная обратная связь от пользователей. Подробный разбор ролей, таймбоксов и ошибок внедрения — в статье Scrum от А до Я; здесь нужен только контраст с Kanban.

Kanban: поток задач и лимит незавершенной работы

Слово «канбан» (по-японски примерно «карточка, вывеска») пришло из производственной системы Toyota: там карточки сигнализировали, что пора изготовить следующую партию деталей. В разработку ПО Kanban перенес Дэвид Андерсон: первые kanban-системы — в IT-подразделении Microsoft в 2004-2006 годах, описание Kanban-метода — 2007-2009, книга «Kanban» — 2010 год.

Kanban не задает ролей и итераций. Его ядро — три практики:

• Визуализация. Доска с колонками этапов («Очередь -> В работе -> Проверка -> Готово») и карточками задач.
• Лимит WIP (work in progress, незавершенная работа). Например, в «В работе» не больше 3 карточек. Пока лимит занят, новую задачу не берут — сначала доводят начатое.
• Управление потоком. Команда измеряет, сколько задача живет на доске и сколько задач завершается за период, и по этим цифрам ищет узкие места.

Доска без лимитов WIP — это еще не Kanban, а просто наглядный список задач. Именно лимит заставляет «заканчивать, а не начинать».

Чем Scrum отличается от Kanban: таблица

Это не взаимоисключающие подходы: многие Scrum-команды ведут спринт на Kanban-доске с лимитами WIP. Такой гибрид иногда называют Scrumban, но это не отдельный стандарт, а договоренность конкретной команды.

Разбор задачи: производительность упала на 25%, насколько выросло время

Производительность — это задачи в единицу времени, а время на одну задачу — обратная величина. Если производительность стала 0,75 от прежней, время на задачу стало 1 / 0,75 = 4/3 от прежнего, то есть выросло на 1/3.

p_before = 1.0                 # производительность: задач в час
p_after = p_before * (1 - 0.25)  # упала на 25%

t_before = 1 / p_before        # время на одну задачу
t_after = 1 / p_after

growth = (t_after / t_before - 1) * 100
print(f"Время на задачу выросло на {growth:.1f}%")

Результат прогона на Python 3.14:

Время на задачу выросло на 33.3%

Типичная ошибка — ответить «на 25%»: проценты считаются от разных баз (снижение — от старой производительности, рост — от старого времени). Условие задачи неявно предполагает, что задачи одинаковые по объему и время обратно пропорционально производительности.

Как Kanban-команда видит такое замедление: метрики потока

В реальной команде «время выполнения задачи» не вычисляют из производительности, а измеряют по доске или баг-трекеру. Три базовые метрики:

• Cycle time — сколько дней задача была в работе, от старта до готовности.
• Throughput — сколько задач завершено за период.
• WIP — сколько задач в работе одновременно.

Их связывает закон Литтла: средний WIP = throughput x средний cycle time. Закон точен для средних значений при условии, что система стабильна (задачи не копятся бесконечно) и мы учитываем все задачи периода. Пример на шести багах, которые начаты и завершены за две недели:

from datetime import date, timedelta

# Карточки с Kanban-доски: (задача, взята в работу, готова)
done = [
    ("BUG-101", date(2026, 9, 1), date(2026, 9, 3)),
    ("BUG-102", date(2026, 9, 1), date(2026, 9, 8)),
    ("BUG-103", date(2026, 9, 2), date(2026, 9, 4)),
    ("BUG-104", date(2026, 9, 3), date(2026, 9, 9)),
    ("BUG-105", date(2026, 9, 7), date(2026, 9, 10)),
    ("BUG-106", date(2026, 9, 8), date(2026, 9, 11)),
]
start, end = date(2026, 9, 1), date(2026, 9, 14)
days = (end - start).days + 1  # 14 дней, обе границы включительно

# Cycle time: дни в работе, день старта и день готовности включительно
cycle = [(fin - beg).days + 1 for _, beg, fin in done]
avg_cycle = sum(cycle) / len(cycle)
throughput = len(done) / days

# Фактический WIP: сколько карточек было в работе в каждый день
wip = []
for i in range(days):
    d = start + timedelta(days=i)
    wip.append(sum(beg <= d <= fin for _, beg, fin in done))

print("Cycle time, дней:", cycle)
print(f"Средний cycle time: {avg_cycle:.2f} дн.")
print(f"Throughput: {throughput:.2f} задач/день")
print("WIP по дням:", wip)
print(f"Средний WIP факт: {sum(wip) / days:.2f}")
print(f"Литтл, throughput x cycle time: {throughput * avg_cycle:.2f}")

Вывод (Python 3.14):

Cycle time, дней: [3, 8, 3, 7, 4, 4]
Средний cycle time: 4.83 дн.
Throughput: 0.43 задач/день
WIP по дням: [2, 3, 4, 3, 2, 2, 3, 4, 3, 2, 1, 0, 0, 0]
Средний WIP факт: 2.07
Литтл, throughput x cycle time: 2.07

Две последние строки совпали, потому что все задачи начались и закончились внутри окна. Если часть задач переходит через границы периода, совпадение будет приблизительным. Практический вывод из закона: при том же throughput рост WIP означает рост cycle time. Поэтому Kanban-команда борется с замедлением не «ускорением людей», а снижением лимита WIP.

Частые путаницы

• SAFe — это не Scrum. Scaled Agile Framework — отдельный фреймворк для масштабирования Agile на много команд, его автор — Дин Леффингуэлл. Scrum-команды могут работать внутри SAFe, но это разные вещи.
• Agile не отменяет планирование. План есть, просто он короче и пересматривается по обратной связи.
• Kanban не «только для менеджеров». Метрики и лимиты WIP — инструмент самой команды, а не отчет для начальника.
• Внедрение не гарантирует ускорения. Если «внедрили Scrum» означает только новые созвоны без изменения того, как команда берет и завершает задачи, производительность действительно может упасть — как в школьной задаче.

Как выбрать подход

Выводы

• Agile — это 4 ценности и 12 принципов манифеста 2001 года, а не конкретный процесс.
• Scrum — фреймворк: спринты до месяца, три подотчетности, пять событий, три артефакта.
• Kanban — метод управления потоком: визуализация, лимит WIP и метрики cycle time и throughput.
• Если производительность упала на 25%, время на задачу выросло на 33 1/3 %: величины обратно пропорциональны.
• Закон Литтла связывает средние WIP, throughput и cycle time: при том же throughput меньший WIP означает меньшее среднее время задачи, поэтому лимит WIP — главный рычаг Kanban против замедления.

Где применяется / связь с практикой

FAQ

Agile подходит только для IT?
Нет. Манифест писали разработчики ПО, но короткие циклы и работа по обратной связи применяются в маркетинге, дизайне и операционных командах. Эффект слабее там, где результат нельзя показать частями.

Можно ли менять задачи внутри спринта Scrum?
Можно уточнять Sprint Backlog, если это не ставит под угрозу цель спринта. Если цель потеряла смысл, Product Owner может отменить спринт.

Какой лимит WIP поставить на старте?
Универсального числа нет. Часто начинают с количества людей в колонке и снижают лимит, пока задачи не перестают простаивать.