LeSS Framework

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

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

Два фреймворки для масштабування Agile

LeSS пропонує два окремі фреймворки для масштабування Scrum. Більшість елементів LeSS, пов’язаних із масштабуванням, фокусують увагу всіх команд на продукті в цілому, замість «лише моєї частини». Глобальний та “end-to-end” фокуси, можливо, є найважливішими проблемами для вирішення при масштабуванні. Ось два фреймворки, які, по суті, є масштабованим однокомандним Scrum:

• LeSS: До восьми команд (кожна по вісім людей).
• LeSS Huge: До кількох тисяч людей на одному продукті.

Що це означає – бути таким самим, як однокомандний Scrum?

LeSS – це масштабована версія однокомандного Scrum, яка підтримує багато практик та ідей однокомандного Scrum. У LeSS ви знайдете:

• єдиний Product Backlog (Беклог Продукту), тому що він – для продукту, а не для команди;
• єдиний Definition of Done для всіх команд;
• єдиний Потенційно Придатний для Доставки Product Increment (Інкремент Продукту) в кінці кожного Sprint (Спринт);
• єдиний Product Owner (Власник Продукту);
• багато професійних, кросфункціональних команд (та жодних спеціалізованих команд);
• єдиний Sprint.

У LeSS всі Команди працюють у загальному Sprint для створення спільного, придатного для доставки продукту. І так кожен Sprint.

Чим відрізняється LeSS?

• Sprint Planning Part 1 (Перша частина Планування Спринту): Крім єдиного Product Owner у цьому івенті беруть участь люди з усіх команд. Дайте командам самостійно вирішувати, як вони розподілятимуть елементи Product Backlog між собою. Члени Команд також обговорюють можливості спільної роботи та кооперації, особливо щодо повʼязаних між собою елементів.
• Sprint Planning Part 2 (Друга частина Планування Спринту): Триває незалежно для кожної команди, найчастіше одночасно. Задля підвищення зручності та координації дві чи більше Команд можуть працювати в одній кімнаті (в різних її частинах).
• Daily Scrum (Щоденний Scrum): Також триває окремо для кожної Команди, однак задля збільшення обміну інформацією, хтось із Команди А може спостерігати за Daily Scrum Команди Б.
• Coordination (Координація): Використовуйте практики «Просто розмовляй», «Спілкування в коді», «Мандрівники», «Відкритий Простір» та «Спільноти».
• Overall PBR (Загальне Уточнення Беклогу Продукту): Можливе проведення короткої необовʼязкової зустрічі overall Product Backlog Refinement (PBR), де беруть участь єдиний Product Owner та люди з усіх команд. Основна мета – вирішити, якими командами, і які елементи Product Backlog, найімовірніше, будуть взяті для реалізації, щоб потім глибше розглянути їх на однокомандному PBR кожної групи. Це також шанс покращити взаємодію Product Owner з усіма командами.
• Product Backlog Refinement (Уточнення Беклогу Продукту): LeSS вимагає лише однокомандного PBR, так само як і в однокомандному Scrum. Але поширеним і корисним варіантом є багатокомандний PBR, коли дві або більше команд знаходяться в одній кімнаті, щоб покращити навчання та координацію.
• Sprint Review (Огляд Спринту): Крім єдиного Product Owner, в івенті також беруть участь всі члени команд, клієнти/користувачі та інші зацікавлені сторони. На етапі інспекції Product Increment і нових елементів Product Backlog, розгляньте стиль «Базар» або «Науковий ярмарок»: велика кімната з кількома ділянками, де окремі команди показують та обговорюють елементи Product Backlog, розроблені під час Sprint.
• Overall Retrospective (Загальна Ретроспектива): Це новий івент, якого немає в однокомандному Scrum. Його мета полягає у покращенні системи загалом (замість зосередження на одній Команді). Максимальна тривалість – 45 хвилин за кожен тиждень тривалості Sprint. У ньому беруть участь Product Owner, Scrum Master та змінні представники від кожної Команди.

Переклад українською здійснив Кирило Сітніков