Scrum, Kanban, SAFe, Lean — кто все эти люди?

Карта подходов к разработке: от Waterfall и XP до Team Topologies и работы с AI. Что они решают, где помогают и как выбрать без посвящения в тайное общество.

Представьте первый день в команде. Вам показывают доску и объясняют:

— У нас Scrum. Спринты по две недели, но срочные задачи берём каждый день. Доска канбан. Оценки в story points, для отчёта переводим в часы. А со следующего квартала масштабируем Agile.

Хочется уточнить: масштабировать будем всё сразу или сначала договоримся, что у нас уже есть?

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

Под первой статьёй этой серии читатель справедливо заметил: прежде чем обсуждать недостатки SAFe и Scrum@Scale, неплохо бы объяснить, что это вообще такое. Я пообещал отдельный ликбез. Затем напомнил об обещании в статье про метрики без story points. Пора выдавать карту.

Я прошёл путь от инженера до руководителя разработки. Мой практический опыт включает LeSS и Team Topologies: меняли устройство команд вокруг продукта, а не только календарь встреч. Ниже — более широкий обзор. Знакомство с подходом не означает, что я лично внедрял каждый из них, и универсального победителя здесь не будет.

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

Сначала рассадим всех по своим местам

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

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

Фреймворк задаёт рамку работы. Например, Scrum описывает ответственность участников, события и артефакты. При этом не рассказывает, как спроектировать базу данных или настроить сборку.

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

Практики — конкретные действия. Автоматические тесты, парное программирование, ограничение незавершённой работы. Их можно сочетать в разных рамках.

У Lean есть и принципы, и управленческая практика; Six Sigma объединяет метод улучшения и статистический инструментарий. Границы терминов здесь не бетонные. Для этой статьи достаточно помнить: подходы могут отвечать на разные вопросы и дополнять друг друга.

Схема помогает различать вопросы, а не устанавливает единственно правильную классификацию.

Несколько слов, которые понадобятся дальше. Бэклог — упорядоченный список будущей работы. Итерация — повторяющийся цикл; в Scrum он называется спринтом. Инкремент — пригодное к использованию приращение продукта. WIP, work in progress, — работа, начатая, но ещё не завершённая. Cycle time — время от согласованной точки начала задачи до её завершения. Где именно эти точки, команда должна определить явно: иначе у двух красивых графиков окажутся разные биографии.

Waterfall: сначала договоримся, потом построим

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

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

Но стабильность требований нужно проверить, а не записать в презентации. Допустим, команда полгода разрабатывает новый сервис, ни разу не показывая его пользователям. В конце можно получить идеально выполненное ТЗ и весьма неловкую демонстрацию. Риск возник задолго до тестирования: предположения о пользе продукта слишком долго оставались предположениями.

История добавляет иронии. В работе Уинстона Ройса 1970 года, с которой связывают Waterfall, простой последовательный проход назван рискованным; дальше автор обсуждает обратные связи и меры снижения риска. Поэтому пересказывать её как инструкцию «никогда не возвращайтесь назад» несправедливо.

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

Agile: четыре ценности, ни одного обязательного стендапа

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

Это существенная оговорка. «Мы Agile, поэтому не документируем» — довольно удобная философия, пока единственный человек, помнящий решение, не ушёл в отпуск.

Ценности дополняют двенадцать принципов: регулярная поставка полезного софта, обратная связь, техническое совершенство, устойчивый темп. Конкретного процесса они не задают. Спринты появляются в Scrum; инженерные практики подробно развивает XP.

Поэтому на вопрос «у вас Agile?» полезно отвечать примерами. Как быстро вы проверяете предположения? Можно ли изменить план после новых данных? Получают ли пользователи работающий результат? Название процесса само по себе ничего из этого не гарантирует.

Scrum: ритм, цель и возможность передумать

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

В Scrum Guide описаны три области ответственности:

• Product Owner отвечает за максимизацию ценности продукта и эффективное управление Product Backlog.

• Developers создают пригодный к использованию инкремент и управляют своим планом работы.

• Scrum Master помогает правильно применять Scrum и повышать эффективность команды.

Обычный размер Scrum Team — десять человек или меньше, включая Product Owner и Scrum Master. Это не значит, что одиннадцатому запрещён вход в переговорную. Это сигнал посмотреть, не стала ли координация слишком дорогой.

Спринт включает планирование, Daily Scrum, Sprint Review и ретроспективу. Daily Scrum — пятнадцать минут для Developers, чтобы проверить движение к цели спринта и скорректировать план. Стоять необязательно. Отчитываться по очереди начальнику — тоже.

Sprint Review нужен для обсуждения результата и дальнейшего направления вместе с заинтересованными сторонами. Ретроспектива — для улучшения того, как команда работает. Это разные разговоры: пользователю важно, решена ли его задача; команде ещё нужно понять, почему релиз снова потребовал вечернего подвига.

И три поправки, которые экономят немало споров. Scrum не требует story points. Готовый инкремент можно выпустить до конца спринта — Sprint Review не является обязательным разрешением на релиз. И спринт не является запечатанной коробкой с неизменяемым списком задач: объём можно уточнять с Product Owner по мере получения знаний, сохраняя цель спринта.

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

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

Kanban: закончить начатое — тоже стратегия

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

Доска полезна, но сама по себе ничего не ограничивает. Можно нарисовать прекрасную колонку «В работе» и сложить туда весь бэклог. Получится очень наглядная перегрузка.

Контроль WIP означает, что новую работу начинают с учётом доступной мощности. Если проверка переполнена, полезнее помочь закончить существующие задачи, чем бодро начать следующие. Работа вытягивается, когда для неё освобождается место.

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

В Kanban Guide выделены четыре базовые метрики потока: WIP, throughput — сколько задач завершается за период, work item age — возраст незавершённой задачи, и cycle time. Из истории можно строить вероятностные ожидания: например, какая доля похожих задач укладывается в определённый срок. Это прогноз при известных условиях, а не гарантия на все случаи жизни.

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

Scrum и Kanban совместимы. Цель и ритм спринта можно дополнить контролем WIP и метриками потока. Термин Scrumban часто используют для разных сочетаний этих идей; единственного обязательного рецепта за ним нет. Полезно уточнить конкретные правила, а не остановиться на удачном названии.

XP: кто-то всё-таки должен поговорить про код

Extreme Programming, или XP, уделяет большое внимание инженерной дисциплине: разработке через тестирование, парной работе, частой интеграции, рефакторингу, простому дизайну и коллективной ответственности за код.

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

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

XP полезен в условиях меняющихся требований: способность безопасно переделывать код становится частью скорости. Однако отдельные практики требуют обучения и адаптации. Парное программирование не означает «двое весь день смотрят на один экран, потому что так положено»; TDD не избавляет от проектирования, интеграционных проверок и понимания задачи.

Scrum оставляет инженерные способы работы открытыми, поэтому XP хорошо его дополняет. Мартин Фаулер описывал проблему Scrum без достаточной технической дисциплины в заметке Flaccid Scrum. Регулярные встречи помогают увидеть трудности, но сборку всё равно придётся чинить руками.

Несколько команд: теперь проблема между ними

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

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

SAFe: координация с подробной картой ролей

Scaled Agile Framework соединяет командную работу с координацией крупных решений и портфеля. Одно из центральных понятий — Agile Release Train, устойчивое объединение команд и специалистов, которые вместе поставляют ценность. Совместное PI Planning помогает согласовать цели, зависимости и риски на очередной Planning Interval.

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

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

LeSS: один продукт, меньше организационных перегородок

Large-Scale Scrum распространяет Scrum на несколько команд, работающих над одним продуктом. В базовом LeSS — общий Product Backlog, один Product Owner, общий спринт и интегрированный результат. Для большего масштаба существует LeSS Huge с дополнительным устройством областей требований.

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

Здесь мой непосредственный опыт: при внедрении LeSS мы параллельно меняли структуру команд. Разворот и стабилизация заняли несколько месяцев. Подробности — в первой статье серии. Перестройка ответственности оказалась существенной частью работы; один общий календарь спринтов её не заменяет.

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

Scrum@Scale: соединить командные циклы

Scrum@Scale предлагает координировать множество Scrum-команд через два взаимосвязанных цикла: продуктовые приоритеты и поставку результата с устранением препятствий. Scrum of Scrums помогает обсуждать межкомандную работу; одних встреч представителей, однако, для всей модели недостаточно.

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

Nexus: общий результат нуждается в интеграции

Nexus рассчитан примерно на три–девять Scrum-команд, создающих один продукт. У них общий Product Backlog и Product Owner; дополнительное внимание уделяется зависимостям и созданию единого интегрированного инкремента.

Nexus Integration Team отвечает за обеспечение интеграции. Это не повод вынести туда всю сложную работу и сдавать по пятницам пакеты несовместимого кода. Команды по-прежнему должны уметь совместно создавать работающий продукт.

Spotify: полезный рассказ, опасный шаблон

Squads, tribes, chapters, guilds — названия из описаний организации Spotify. Их легко полюбить: «племя» звучит интереснее «подразделения номер три».

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

Team Topologies: а команды вообще удачно устроены?

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

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

Платформа, например, должна снижать нагрузку на продуктовую команду. Если ради стандартного развёртывания надо создать заявку, сходить на согласование и дождаться свободного специалиста, название «платформа» ещё не делает это удобным сервисом.

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

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

Lean: куда уходит время между началом и пользой

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

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

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

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

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

Six Sigma: когда нужны данные о повторяемом процессе

Six Sigma занимается качеством и вариативностью процесса. Рабочий цикл DMAIC расшифровывается как Define, Measure, Analyze, Improve, Control: определить проблему, измерить, проанализировать причины, улучшить и удержать результат.

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

У меня есть Lean Six Sigma White Belt. Это вводный уровень, а не заявление о многолетней практике статистических преобразований. Из подхода для управленческого разговора полезна сама дисциплина: сначала описать и измерить проблему, потом спорить о решении.

Lean Six Sigma соединяет внимание к потоку и потерям с работой над качеством и вариативностью. В программных системах повторяемые операции — например, обработка транзакций или стандартных обращений — могут быть подходящей областью применения.

С исследовательской разработкой осторожнее. Две разные функции не обязаны занимать одинаковое время; попытка устранить эту «вариативность» может означать, что мы боремся с природой работы. Статистическому анализу нужны сопоставимые наблюдения и осмысленная модель, а не просто много строк в таблице. Подробнее об инструментах — у ASQ.

Соседние области: пригодятся, но отвечают на другие вопросы

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

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

Shape Up предлагает заранее прорабатывать задачу, выбирать, сколько времени готовы в неё вложить, и передавать команде пространство для решения. В книге Basecamp описаны шестинедельные циклы и паузы между ними. Appetite, «аппетит», — бюджет времени на идею. Это отличается от оценки «сколько займёт весь придуманный объём»: объём приходится подгонять под осознанное ограничение.

Discovery, dual-track, product operating model — про поиск полезного решения и устройство продуктовой работы. Discovery проверяет предположения о проблеме и решении; delivery доводит решение до пользователя. В dual-track эти виды деятельности идут согласованно, а не превращаются в два отдела, перекидывающих друг другу готовые ТЗ. Более широкая продуктовая модель затрагивает полномочия команд, стратегию и ответственность за результат. Scrum может дать ритм этой работе, но не проведёт исследование пользователей вместо команды.

Spec-driven development строит работу вокруг явной спецификации и её связи с реализацией. Например, GitHub Spec Kit предлагает процесс с участием AI-инструментов. Письменно сформулировать цель, ограничения и критерии проверки полезно. Но аккуратная спецификация остаётся гипотезой о нужном поведении: её тоже придётся сверять с реальностью.

AI и удалёнка: условия меняются, вопросы остаются

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

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

В отчёте DORA 2025 AI описывается как усилитель существующей системы. Из этого не следует, что любая команда обязательно ускорится. Полезнее проверять эффект на своём потоке, чем измерять успех количеством сгенерированных строк.

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

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

Как выбрать: пять вопросов до закупки сертификатов

1. Что мы пока не знаем? Когда неизвестны потребности пользователя или способ решения, нужен дешёвый эксперимент и быстрая обратная связь. Чем раньше узнаем, что ошиблись, тем меньше придётся защищать уже потраченные месяцы.

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

3. Где задача ждёт? Не где люди наиболее заняты, а где результат простаивает: ревью, согласование, интеграция, ожидание другой команды. Новое название процесса не устраняет очередь автоматически.

4. Сколько команд действительно должны работать вместе? Проверьте границы продукта, зависимости и полномочия. Возможно, нужен механизм координации. Возможно, полезнее убрать саму необходимость координировать каждую мелочь.

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

Эта таблица предлагает место для начала разговора. Одна продуктовая команда вполне может применять Kanban; наличие регулятора не обязывает покупать SAFe; Scrum сам по себе не противопоказан стартапу.

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

А лозунг «со следующего квартала у нас новый фреймворк» пока можно оставить в черновиках. Там ему ничто не угрожает.

Для первого знакомства достаточно прочитать Agile Manifesto, Scrum Guide и Kanban Guide — ссылки уже есть выше. После этого определения станут яснее, а выбирать конкретные практики будет проще.

Это третья статья серии «Предсказуемая доставка как система». В первой разбирал несколько команд вокруг одного продукта, во второй — прозрачность и метрики без story points. Здесь собрали карту подходов, чтобы выбирать инструменты с пониманием их назначения.

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