LeSS

Масштабування через віднімання

Почнімо з того, що зазвичай стається, коли продукт переростає одну команду. З’являється друга команда, потім третя. Хтось помічає, що троє Product Owner тепер пріоритизують один проти одного, тож над ними наймають координатора. Інтеграція постійно зривається — створюють команду інтеграції. Через півроку є програмний менеджер, реліз-менеджер, керівний комітет і купа передач роботи між ними, а поставка йде повільніше, ніж із однією командою.

LeSS вважає весь цей ланцюжок хворобою, а не ліками. Його відповідь — масштабувати Scrum, додаючи якомога менше: один Product Owner на весь продукт, один Product Backlog, один спринт, спільний для всіх команд, і один інтегрований інкремент наприкінці. Над командою немає жодної нової ролі. Між командами й замовником немає програмного прошарку.

Власне слово фреймворку для цього — розмасштабування. Замість додавати механізми управління координацією, він прибирає організаційні межі, які цю потребу в координації й породили. Найяскравіший приклад — сама команда: компонентні команди, кожна з яких володіє одним технічним шаром, розпускають на фіче-команди, здатні провести видимий користувачеві шматок від ідеї до продакшену, нікому його не передаючи.

Десять принципів

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

Правила, гайди та експерименти

LeSS розділяє свій зміст на три шари з дуже різною силою, і розуміння того, до якого шару належить твердження, відрізняє впровадження фреймворку від карго-культу.

• Правила — обов’язкові

  Мінімальне визначення LeSS: один Product Owner, один Product Backlog, спільний спринт, один Definition of Done, фіче-команди. Порушили правило — ви більше не робите LeSS. Це припустимий вибір, але назвіть його чесно.

• Гайди — перевірені поради

  Практики, що спрацювали в багатьох впровадженнях: як провести Sprint Planning Two, як формувати фіче-команди, як Product Owner працює з багатьма командами. Наполегливо рекомендовані, але не обов’язкові.

• Експерименти — спробуй і подивись

  Те, що десь спрацювало, а десь провалилося, опубліковане з обома результатами. LeSS свідомо перелічує «експерименти, яких варто уникати», поряд із перспективними.

Саме через це розшарування документація LeSS тонка там, де в SAFe вона товста. LeSS стверджує: поза невеликим набором структурних правил правильна практика залежить від організації, тож публікувати детальний припис було б нечесно. Компроміс реальний: LeSS дає менше того, що можна скопіювати, і тому вимагає більше суджень від того, хто веде впровадження.

Що LeSS зберігає, а що прибирає

Ролі в LeSS — це ролі Scrum і більше нічого. Один Product Owner володіє впорядкуванням усього Product Backlog і спілкується з командами напряму, а не через бізнес-аналітиків. Команди — це фіче-команди по три-дев’ять осіб, крос-функціональні й довгоживучі. Scrum Master обслуговує одну-три команди на повну ставку — «на повну» тут правило, бо частково зайнятий Scrum Master стабільно скочується до ролі координатора.

Складніша половина — прибирання. Немає проєктного менеджера, немає програмного менеджера, немає тімліда, що роздає роботу, немає окремої архітектурної групи, яка вирішує за команди, немає відділу аналізу чи тестування, немає PMO між Product Owner і замовником. Наявні менеджери не зникають — але їхня робота змінюється з керування роботою на покращення системи, крізь яку ця робота проходить.

Події LeSS по черзі

Усі команди працюють одним спільним спринтом однакової довжини, що починається й закінчується в один день. Події — це події Scrum із визначеною відповіддю на питання «що робити, коли це потрібно вісьмом командам одночасно».

Між подіями координація навмисно лишається неформальною — LeSS називає це «просто поговоріть». Опубліковані гайди тут про людей, а не про зустрічі: мандрівники, що переходять в іншу команду на спринт, розвідники, які спостерігають Daily Scrum іншої команди, спільноти практики навколо спільної навички, сесії open space і найсильніший варіант — комунікація через код на спільній кодовій базі з безперервною інтеграцією.

Basic і Huge

• LeSS Basic — 2–8 команд

  Один Product Owner здатен утримати весь беклог у голові. Усі команди мають спільний Sprint Review і спільну загальну ретроспективу. Нічого понад Scrum не додається — це фреймворк у задуманому вигляді.

• LeSS Huge — 8+ команд

  Беклог ділиться на Requirement Area, кожна з Area Product Owner і чотирма-вісьмома командами. Єдиний Product Owner лишається й тепер упорядковує роботу між областями, а не між окремими задачами.

Requirement Area — це велика область потреб замовника, і правило, яке вирішує долю LeSS Huge, — як ви їх нарізаєте. Області виділяють за видимою користувачеві потребою, ніколи за технічним компонентом. Область «оформлення замовлення» — правильно. Область «шар бази даних» відтворює саме ту межу передачі роботи, заради усунення якої LeSS існує, і за два спринти дасть компонентні команди з новою вивіскою.

Кожна область потребує щонайменше чотирьох команд. Ця нижня межа не випадкова: область з однієї-двох команд — це відділ, що вдягнув слово «область», і вона почне поводитися як окремий продукт із власними пріоритетами. Області також мають змінюватися з часом разом із продуктом — це поточний погляд на попит, а не оргструктура, яку треба захищати.

LeSS проти SAFe

Це найчіткіша розвилка в масштабуванні. LeSS вимагає, щоб змінилася організація й фреймворк до неї підійшов; SAFe сам підлаштовується під організацію. LeSS дає кращий результат там, де керівництво справді йде на реорганізацію, і провалюється повністю там, де ні: напів-LeSS, який усе одно працює, не існує, бо відкинуті правила якраз і тримають решту.

Як це виявляється в реальній поставці

Впровадження LeSS — це зміна організаційного дизайну під назвою процесу. На практиці воно означає розпуск компонентних команд, прибирання прошарку середнього менеджменту й передачу одній людині повноважень, раніше розподілених по керівному комітету. LeSS незвично прямий у цьому: його власні поради з впровадження радять починати глибоко й вузько — з однієї продуктової групи, спиратися на добровільність, а не на призначення, і бути готовими, що посади менеджерів зміняться.

Найчастіше недооцінюють технічну передумову. Один інтегрований інкремент за спринт від восьми команд неможливий без безперервної інтеграції у спільний транк, єдиного Definition of Done, який виконує кожна команда, і автотестів, що проходять за хвилини, а не за ніч. Організації, які беруть структуру LeSS без цієї інженерної бази, отримують кілька Scrum-команд зі спільним беклогом і авральну інтеграцію наприкінці кожного спринту.

Де він вироджується

• Кілька Product Owner, що з’являються «з практичних міркувань», відновлюють прошарок, який LeSS прибрав.
• Requirement Area, нарізані за технічними компонентами, а не за потребами користувача.
• Команди інтегруються лише наприкінці спринту, тож «один інкремент» стає авральним складанням.
• Збереження компонентних команд із перейменуванням їх у фіче-команди.
• Scrum Master на частину ставки на п’ять команд, який стає координатором зустрічей замість того, щоб змінювати систему.
• Пропуск загальної ретроспективи, де мали порушувати міжкомандні та організаційні перешкоди.

Коли це застосовувати

Пов’язані сторінки

• МенеджментSAFeSAFe (Scaled Agile Framework) координує десятки команд, ставлячи їх на спільний ритм планування. Це найбільш приписовий із фреймворків масштабування і найпоширеніший у великих компаніях — саме тому, що дає наявній управлінській структурі визначене місце. На цій сторінці ми розберемо всі чотири конфігурації, ролі над рівнем команди, десять принципів під ним і чесні аргументи проти.
• МенеджментNexusNexus — це фреймворк масштабування від Scrum.org для трьох-дев’яти команд на одному продукті. Nexus додає до Scrum рівно одну зону відповідальності — команду інтеграції, відповідальну за єдиний інтегрований інкремент, — виходячи з того, що на цьому масштабі ламається саме інтеграція, а не планування. На цій сторінці — хто входить до цієї команди, три артефакти й усі п’ять подій.
• МенеджментScrumScrum — це найпоширеніший спосіб організувати роботу команди розробки. Scrum ділить роботу на короткі фіксовані цикли — спринти, дає трьом ролям чіткі зони відповідальності й обкладає роботу невеликим набором регулярних зустрічей, щоб проблеми спливали за дні, а не за місяці. На цій сторінці ми пройдемо кожну з цих зустрічей — включно з кількома, які реальні команди проводять, хоча в офіційному посібнику їх немає.