LeSS (Large Scale Scrum)

Компания организует команды по техническим слоям — отдельная команда фронтенда, отдельная команда бэкенда, отдельная команда баз данных, — и любая клиентская фича, требующая изменений на всех трёх слоях, превращается в цепочку передач между тремя командами с тремя разными приоритетами и тремя разными очередями задач. Craig Larman и Bas Vodde, начавшие в 2005 году совместно работать с клиентами над масштабированием Scrum на крупные, многосайтовые и оффшорные разработки, называют организацию по компонентным слоям источником сразу пяти проблем: высоких потерь (запасы незавершённой работы, передачи, разбросанная информация), задержки возврата инвестиций, сложной координации и планирования, дополнительного управленческого оверхеда и слабой обратной связи с обучением. LeSS (Large-Scale Scrum) — не «улучшенный Scrum» и не «Scrum внизу плюс что-то другое сверху»: это попытка применить сами принципы, цель и элементы Scrum к масштабу многих команд так же просто, как это делает исходный Scrum для одной команды. В этой статье — что в точности отличает LeSS от простого «Scrum для нескольких команд», два реальных организационных варианта (обычный LeSS и LeSS Huge), эмпирическое «магическое число восемь», где метод ограничен и как использовать фрейм OrgDevTools.

Что такое LeSS и когда он нужен

LeSS нужен, когда один продукт разрабатывают несколько команд одновременно и стандартный однокомандный Scrum перестаёт масштабироваться сам по себе: команды организованы по компонентам или техническим слоям, а не по клиентской ценности, и любая сквозная фича требует координации между несколькими backlog’ами и приоритетами. Типичный случай применения по описанию самих авторов — от пяти команд на одной-двух площадках до случаев в несколько сотен человек и, в отдельных задокументированных случаях, свыше тысячи человек на множестве площадок разработки. Метод не для одной команды (там достаточно обычного Scrum) и не для организаций, не готовых реально перестроить структуру команд вокруг клиентской ценности, а не просто добавить слой координационных митингов поверх прежней компонентной структуры. Смежные методы: модель фиче-команд (Ларман, Водде), Agile/Scrum Framework, Scrum of Scrums, SAFe (Scaled Agile Framework) и Kanban Method.

Происхождение и исследовательская база

От книги 2002 года к партнёрству 2005 года

В 2002 году, когда Крэйг Ларман писал книгу «Agile & Iterative Development», многие считали, что agile-разработка применима только к небольшим группам. Ларман и Бас Водде, независимо получавшие всё больше запросов применить Scrum к крупной, многосайтовой и оффшорной разработке, начали с 2005 года совместно работать с клиентами над масштабированием Scrum. Результатом стали две книги о LeSS и сформулированные ими два организационных варианта — обычный (smaller) LeSS и LeSS Huge, — принятые, по словам авторов, в крупных группах по всему миру в самых разных отраслях.

Ключевой тезис: «LeSS — это Scrum»

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

LeSS — это Scrum. Large-Scale Scrum — не новый и улучшенный Scrum, и не Scrum внизу для каждой команды плюс что-то другое сверху (Craig Larman, Bas Vodde, less.works; перевод формулировки официального источника).

Два организационных варианта: LeSS и LeSS Huge

Обычный (smaller) LeSS: один Product Owner, от двух до восьми команд, один Scrum Master на одну-три команды — команды при этом обязательно являются фиче-командами (feature teams), то есть настоящими сквозными, межкомпонентными, полнофункциональными командами из 3-9 человек, которые работают в общей кодовой базе и делают всё — от UX до кода — чтобы довести готовые элементы продукта до состояния, готового к поставке. Когда группа превышает эмпирический порог (примерно восемь команд), она переходит на LeSS Huge: деление идёт не произвольно, а по крупным зонам клиентских потребностей — Requirement Areas, обычно от четырёх до восьми команд в каждой, с отдельным Area Product Owner, фокусирующимся на своей области backlog’а. Каждая Requirement Area работает как отдельная реализация обычного LeSS внутри одного общего Sprint для всего продукта — авторы образно называют такой Sprint в LeSS Huge «стеком LeSS».

«Магическое число восемь» — эмпирическое наблюдение, а не жёсткий закон

Авторы прямо оговаривают: восемь команд — не магическое число в строгом смысле, и если группа успешно применяет обычный LeSS с большим числом команд, это тоже нормально — просто пока такие случаи не наблюдались. Это верхний предел, основанный на эмпирическом наблюдении практики, а не на теоретическом расчёте, и в отдельных случаях (например, при сложных разнородных целях с многосайтовыми неопытными командами без общего языка) порог перехода на LeSS Huge может оказаться даже ниже восьми.

Реальный масштаб LeSS Huge: документированный, но анонимизированный кейс

Официальный источник приводит конкретный, хотя анонимизированный, пример масштаба LeSS Huge: случай, в котором было задействовано свыше тысячи человек, множество площадок разработки, десятки миллионов строк кода на C++ и работа с собственным заказным аппаратным обеспечением. Оговорка: авторы не называют конкретную компанию в этом фрагменте официального источника — приводится только масштаб задачи, а не название клиента; это анонимизированный, но не выдуманный пример, задокументированный самими создателями метода как реальный случай применения LeSS Huge. Отдельная оговорка: часть иллюстраций в официальной книге и на сайте (истории про условных Пaоло, Портию и Сэма из вымышленной торговой компании) — это учебные сценарии для объяснения ролей и правил, а не описание реальной именованной компании; в этой статье они не используются как реальный кейс.

Ключевые идеи и принципы

1. LeSS — это Scrum, а не слой сверху

   Масштабирование в LeSS означает применение тех же принципов, ролей и элементов Scrum к масштабу многих команд, а не создание отдельного «фреймворка масштабирования», который просто содержит Scrum где-то на уровне команды.

2. Один продукт, один Product Owner, один Sprint

   Даже при десятках команд у продукта остаётся один Product Owner (в LeSS Huge — плюс несколько Area Product Owners) и один общий Sprint для всего продукта — это то, что реально принуждает команды координироваться вокруг единой цели, а не работать как независимые мини-проекты.

3. Фиче-команды — не оргструктурная деталь, а решение конкретной проблемы

   Переход от компонентных команд к фиче-командам — прямой ответ на документированные проблемы компонентной организации (потери, задержанный ROI, сложная координация), а не абстрактное agile-предпочтение «командам лучше быть межфункциональными».

4. «Магическое число восемь» ограничивает не масштаб продукта, а размер одного LeSS-контура

   Порог перехода на LeSS Huge — не предел того, сколько людей вообще может работать над продуктом, а предел того, сколько команд один Product Owner и общий Sprint могут скоординировать без деления на области.

Академическая теория: фиче-команды против компонентных команд

Компонентная организация: пять документированных проблем

Официальный источник прямо перечисляет, к чему приводит организация команд по архитектурным слоям (UI-слой, сервер, доступ к данным) как отдельным группам: (1) высокие потери — запасы незавершённой работы, передачи между командами, разбросанная по разным командам информация; (2) сильно задержанный возврат инвестиций — фича не приносит ценности, пока не пройдёт через все компонентные команды по очереди; (3) сложное планирование и координация — любая сквозная фича требует синхронизации нескольких backlog’ов и приоритетов; (4) дополнительный управленческий оверхед — координация сама по себе требует управленческого ресурса, которого не было бы при сквозных командах; (5) слабая обратная связь и обучение — команда, видящая только свой технический слой, не получает прямой обратной связи от клиента о том, была ли фича в целом полезна. Ключевая формулировка: такая организация выстроена вовнутрь — вокруг узких навыков, архитектуры и управления, а не вовне — вокруг клиентской ценности.

Фиче-команда: четыре обязательных признака

LeSS формулирует признаки команды не как пожелание, а как правило: каждая команда должна быть (1) самоуправляемой, (2) межфункциональной, (3) находящейся в одном месте (co-located) и (4) долгоживущей. Дисперсные, разбросанные по разным местам команды по определению самого метода обычно являются следствием плохих организационных решений и незнания реальной цены отсутствия совместного расположения команды, а не неизбежностью крупного масштаба: авторы прямо отмечают, что группа в 50 или даже 500 человек не требует разбросанных команд — команда из примерно семи человек легко может сидеть в одном месте, даже если сама продуктовая группа многосайтовая.

Lean-мышление как фундамент организационной системы

LeSS явно опирается на lean-мышление: организационная система, где менеджеры выступают учителями, применяющими и обучающими lean-мышлению, управляющими для улучшения, поощряющими принцип «остановись и исправь» и практикующими «пойди и посмотри» (Go See) лично на месте работы, а не по отчётам. К этому добавляются две опоры — уважение к людям и постоянный вызов статус-кво с установкой на непрерывное улучшение, всё это в направлении к идеалу совершенства процесса.

Учебный расчёт: комбинаторный рост зависимостей между компонентными командами

Число потенциальных связей координации между n компонентными командами равно n×(n-1)/2 — та же формула, что использует фрейм LeSS в OrgDevTools. При 3 компонентных командах (фронтенд, бэкенд, данные) это всего 3 потенциальные связи. При росте до 6 компонентных команд (например, добавились команды мобильных клиентов, аналитики и интеграций) число потенциальных связей вырастает до 15 — рост в 5 раз при росте числа команд лишь в 2 раза, потому что зависимости растут квадратично, а не линейно. Именно эта комбинаторная логика, а не абстрактное «координация — это плохо», объясняет, почему компонентная организация масштабируется тем хуже, чем больше команд в неё добавляется, и почему LeSS настаивает на фиче-командах вместо роста числа компонентных команд.

Ограничения метода

Типовые ошибки

1. Ошибка 1: LeSS внедряют как слой митингов над прежней компонентной структурой.

   Организация вводит Scrum of Scrums, общие ретроспективы и общий Product Backlog, но команды остаются организованы по техническим слоям (фронтенд/бэкенд/данные) — координационная нагрузка растёт, а фундаментальная проблема (n×(n-1)/2 потенциальных связей между компонентными командами) не устраняется.

   Как избежать

   начинать с реальной перестройки команд в фиче-команды, а не с добавления координационных ритуалов поверх старой структуры.

2. Ошибка 2: деление на LeSS Huge происходит механически по числу команд, без учёта клиентских областей.

   Requirement Areas формируются произвольно (например, поровну по числу людей), а не по реальным зонам клиентских потребностей — команды внутри одной области работают с несвязанными частями продукта, и обещанное упрощение координации не происходит.

   Как избежать

   формировать Requirement Areas вокруг реальных, устойчивых во времени зон клиентских потребностей, а не по формальному признаку равного размера.

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

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

   Как избежать

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

4. Ошибка 4: дисперсные (не co-located) команды считаются приемлемой нормой при масштабировании.

   Группа в несколько сотен человек рассеивает участников одной команды по разным городам «потому что это большой масштаб», хотя по правилу LeSS команда должна быть co-located независимо от того, сколько всего команд и площадок в продуктовой группе.

   Как избежать

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

5. Ошибка 5: восемь команд воспринимается как жёсткий лимит, требующий немедленного перехода на LeSS Huge.

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

   Как избежать

   сначала пробовать становиться лучше, компактнее и проще в рамках обычного LeSS и переходить на LeSS Huge только когда группа реально упирается в порог координации, а не по формальному счёту команд.

Как измерить эффект

• Доля фиче-команд от общего числа команд: растущая доля — прямой индикатор движения от компонентной к клиентоориентированной структуре (эта же метрика — основа вердикта фрейма OrgDevTools).

• Число потенциальных межкомандных связей (n×(n-1)/2) среди оставшихся компонентных команд: снижение этого числа при сокращении компонентных команд напрямую снижает нагрузку на координацию.

• Время от появления фичи в Product Backlog до её поставки конечному клиенту: должно снижаться при переходе от компонентной к фиче-организации.

• Число областей (Requirement Areas), которым реально нужна координация друг с другом на каждый Sprint: для LeSS Huge — индикатор того, насколько удачно проведено деление на области.

• Доля команд, физически находящихся в одном месте (co-located): соответствие правилу LeSS, а не оправдание дисперсности масштабом.

План внедрения

• 1. Составить ростер всех текущих команд с типом (фиче-команда или компонентная) и посчитать текущую долю фиче-команд.

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

• 3. Спроектировать переход хотя бы одной компонентной пары команд в единую сквозную фиче-команду, начиная с наименее рискованной области продукта.

• 4. Если число команд превышает эмпирический порог около восьми, спроектировать Requirement Areas вокруг реальных зон клиентских потребностей, а не по формальному признаку размера.

• 5. Проверить, что каждая команда физически co-located, самоуправляема, межфункциональна и долгоживущая — по всем четырём правилам одновременно.

• 6. Регулярно (каждый Sprint) пересчитывать долю фиче-команд и число потенциальных связей между оставшимися компонентными командами, отслеживая прогресс перехода.

Как работать с фреймом «LeSS» в OrgDevTools

Фрейм «LeSS» в OrgDevTools — собственный (не унифицированный) компонент с тремя вкладками: «Ростер» (список команд с ручной классификацией каждой как фиче-команда или компонентная), «Визуализация» (доля фиче- и компонентных команд на шкале, число потенциальных межкомандных связей) и «Итоги» (вердикт). Вердикт использует ровно ту же комбинаторную формулу, что разобрана выше: при доле фиче-команд от 80% и выше фрейм показывает минимальный риск межкомандных зависимостей; от 40% до 80% — умеренный риск координации с явным указанием числа потенциальных связей между оставшимися компонентными командами; ниже 40% — высокий риск межкомандных задержек с тем же расчётом n×(n-1)/2, показанным явно, а не абстрактно.

Чего фрейм не делает. Фрейм не проверяет, действительно ли команда, отмеченная как «фиче-команда», реально межфункциональна и не специализирована скрыто внутри себя (типовая ошибка 3 выше) — классификация вносится вручную и доверяется пользователю. Он не различает обычный LeSS и LeSS Huge и не подсказывает, когда пора формировать Requirement Areas — расчёт n×(n-1)/2 верен для любого масштаба, но организационное решение о переходе на LeSS Huge остаётся за пользователем. Он не проверяет совместное расположение (co-located) команд — это ещё одно обязательное правило LeSS, не отражённое в структуре данных фрейма.

Инструмент: ❌ нет. Отдельного платного инструмента для управления многокомандным LeSS-масштабированием (с реальными несколькими backlog’ами команд, Requirement Areas, ролями Area Product Owner) на платформе не предусмотрено — фрейм в OrgDevTools — учебный тренажёр для оценки риска компонентной организации через ростер команд. Реальное ведение нескольких команд с общим и раздельными backlog’ами выполняется в инструменте «Проекты и Задачи» вручную (отдельные проекты/доски на команду), без встроенной поддержки специфичных для LeSS ролей и правил.

Книги и источники

• Craig Larman, Bas Vodde. Large-Scale Scrum: More with LESS (Addison-Wesley, 2016) — основная современная книга метода.

• Craig Larman. Agile and Iterative Development: A Manager's Guide (2004) — более ранняя книга, отражающая контекст 2002 года, из которого выросло партнёрство над LeSS.

• less.works — официальный сайт метода (Craig Larman, Bas Vodde): точные формулировки принципов, правил, двух организационных вариантов и «магического числа восемь». Прочитан целиком через extract-source.mjs.