LeSS Framework

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

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

LeSS це різновид Agile розробки програмного забезпечення, за масштабом схожий на Scaled Agile Framework® (SAFe®)

Два фреймворки гнучкого масштабування

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

Глобальний та "наскрізний" фокус є, мабуть, домінуючими проблемами, які потрібно вирішити при масштабуванні. Два фреймворки, які, по суті, є масштабованим Scrum для однієї команди, є такими:

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

Що означає бути таким же, як One-Team Scrum?

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

У LeSS ви знайдете:

• єдиний Product Backlog (тому що він для продукту, а не для команди)
• єдине Визначення Готового для всіх команд,
• один потенційно можливий до відвантаження інкремент продукту в кінці кожного спринту,
• один власник продукту,
• багато повноцінних, крос-функціональних команд (без вузькоспеціалізованих команд),
• один Спринт.

У LeSS всі команди беруть участь у спільному спринті, щоб створити спільний продукт, який можна відвантажити, кожного спринту.

Що відрізняється в LeSS?

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

Введення в LeSS

Є два способи побудови [дизайну]:
Один спосіб - зробити його настільки простим, щоб не було очевидних недоліків, а інший спосіб - зробити його настільки складним, що не буде очевидних недоліків.
C.A.R. Hoare

Однокомандний Scrum (One-Team Scrum)

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

Один власник продукту відповідає за максимізацію цінності продукту, визначення пріоритетів у продуктовому беклозі та адаптивне визначення мети кожного спринту на основі постійного зворотного зв'язку та навчання. Невелика команда відповідає за досягнення мети спринту; немає обмежень на вузькоспеціалізовані ролі.

Скрам-майстер пояснює, навіщо потрібен Скрам і як отримати з нього користь, навчає Власника продукту, команду та організацію застосовувати його, а також виступає в ролі дзеркала. Тут немає менеджера проекту або керівника команди.

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

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

У Scrum Guide та Scrum Primer основна увага приділяється одній команді, а не багатьом командам, які працюють разом. І це природно призводить до роздумів про великомасштабний Scrum.

LeSS

LeSS - це Scrum, застосований до багатьох команд, що працюють разом над одним продуктом.

LeSS - це Scrum - Великий Скрам (LeSS) не є новим і вдосконаленим Скрамом. І це не Scrum в основі для кожної команди, а щось інше, що нашаровується зверху.

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

...застосовується до багатьох команд - міжфункціональні, міжкомпонентні, повностекові функціональні команди з 3-9 людей, орієнтовані на навчання, які роблять все - від UX до коду та відео - для створення готових елементів та готового до відправки продукту.

...працюють разом - Команди працюють разом, тому що у них є спільна мета - випустити один спільний продукт в кінці спільного спринту, і кожна команда зацікавлена в цьому, тому що вони є функціональною командою, відповідальною за ціле, а не за окремі частини.

...над одним продуктом - Яким продуктом? Широке комплексне наскрізне клієнтоорієнтоване рішення, яким користуються реальні клієнти. Це не компонент, платформа, шар чи бібліотека.

Передісторія (Background)

У 2002 році, коли Крейг написав книгу "Agile & Iterative Development", багато хто вважав, що гнучка розробка призначена лише для невеликих груп. Однак  Крейг і Бас зацікавилися - і отримали все більше запитів - застосуванням Скраму до великих, багатосайтових та офшорних розробок.

Тож з 2005 року вони об'єдналися, щоб працювати з клієнтами над масштабуванням Scrum. Сьогодні два фреймворки LeSS (менший LeSS та LeSS Huge) прийняті у великих групах по всьому світу в різних галузях:

• телекомунікаційне обладнання - Ericsson та Nokia Networks
• інвестиційні та роздрібні банки - UBS
• торгові системи - ION Trading
• маркетингові платформи та аналітика брендів - Vendasta
• відеоконференції - Cisco
• онлайн-ігри (беттінг) - bwin.party
• офшорний аутсорсинг - Valtech India

Якщо говорити про великі компанії, який типовий випадок впровадження LeSS? Можливо, п'ять команд на одному або двох майданчиках. Ми брали участь у проектах такого масштабу, з кількома сотнями людей, і аж до величезного кейсу LeSS, в якому брали участь понад тисячу людей, дуже багато сайтів для розробки, десятки мільйонів рядків C++, зі спеціальним апаратним забезпеченням.

Більше про навчання LeSS

Щоб допомогти людям вчитися і на основі нашого досвіду роботи з клієнтами, в 2008 і 2010 роках ми опублікували дві книги про масштабування гнучкої розробки за допомогою фреймворків LeSS:

1. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum - пояснює зміни в мисленні, лідерстві та організаційному дизайні.
2. Practices for Scaling Lean & Agile Development: Large, Multi-site & Offshore Product Development with Large-Scale Scrum - ділиться сотнями конкретних експериментів для LeSS, заснованих на нашому досвіді роботи з клієнтами; експерименти в управлінні продуктами, архітектурі, плануванні, багатосайтових, офшорних, контрактах і багато іншого.

Ця книга - Large-Scale Scrum: Більше з LeSS - це третя книга в серії LeSS, приквел і підручник. Ця книга синтезує, прояснює та висвітлює найважливіше.

Окрім цих книг, дивіться на less.works навчальні онлайн-ресурси (включаючи розділи книг, статті та відео), курси та коучинг.

Експерименти, посібники, правила, принципи

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

Практики ситуативні; безтурботне ствердження, що вони "найкращі", відриває їх від мотивації та контексту. Вони стають ритуалами. А нав'язування так званих найкращих практик вбиває культуру навчання, запитань, залучення та постійного вдосконалення. Навіщо людям кидати виклик найкращому?

Тому в попередніх книгах LeSS ми ділилися експериментами, які спробували ми та наші клієнти, і ми заохочували - і заохочуємо - такий спосіб мислення. Але з часом ми помітили дві проблеми, пов'язані з експериментальним мисленням:

• Групи-початківці приймали невмілі рішення на шкоду собі, застосовуючи LeSS не за призначенням, з очевидними проблемами; наприклад, групи створювали Зони Вимог з однією командою в кожній. Ой!
• Групи-початківці запитували: "З чого нам почати? Що найважливіше?" Зрозуміло, що вони не бачили ключових основ.

На основі цього зворотного зв'язку ми поміркували і повернулися до моделі навчання Shu-Ha-Ri: Shu - дотримуйся правил, щоб вивчити основи. Ha - порушуй правила і відкривай для себе контекст. Ri - опановуйте та знаходьте свій власний шлях.

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

Підсумовуючи та розвиваючи ці пункти, LeSS включає в себе

• Правила (Rules) - Кілька правил для початку роботи і формування фундаменту. Вони визначають ключові елементи системи LeSS, які повинні бути в наявності для підтримки емпіричного контролю процесу і фокусування на всьому продукті, наприклад, проведення загальної ретроспективи кожного спринту.
• Посібники (Guides) - помірний набір посібників для ефективного впровадження правил і для підмножини експериментів; варто спробувати, виходячи з багаторічного досвіду роботи з LeSS. Посібники містять підказки. Зазвичай корисні і є сферою для постійного вдосконалення; наприклад, Три принципи прийняття.
• Експерименти (Experiments) - багато експериментів, які є дуже ситуативними і, можливо, навіть не варті того, щоб їх пробувати, наприклад, "Спробуйте... Перекладач у команді".
• Принципи (Principles) - В основі лежить набір принципів, витягнутих з досвіду впровадження LeSS, які формують правила, настанови та експерименти; наприклад, орієнтація на весь продукт.

Хороший спосіб поглянути на LeSS - візуалізувати повну картину LeSS:

Повна картина LeSS впорядкує те, як ми впроваджуємо LeSS:

1. Принципи LeSS, далі
2. фреймворки LeSS (визначені правилами), далі в цій главі
3. посібники з LeSS, в наступних розділах цієї книги
4. Експерименти LeSS, вже доступні в перших двох книгах про LeSS

Принципи LeSS (LeSS Principles)

Правила LeSS визначають структуру LeSS. Але правила мінімалістичні і не дають відповіді на питання, як застосовувати LeSS у вашому конкретному контексті. Принципи LeSS забезпечують основу для прийняття таких рішень.

Великомасштабний Скрам є Скрам (Large-Scale Scrum is Scrum) - це не новий і вдосконалений Scrum. Скоріше, LeSS - це спроба з'ясувати, як максимально просто застосувати принципи, правила, елементи та мету Скраму в масштабному контексті.

Прозорість (Transparency) - базується на відчутних "зроблених" елементах, коротких циклах, спільній роботі, загальних визначеннях та подоланні страху на робочому місці.

Більше з меншими витратами (More with less) - Ми не хочемо більше ролей, тому що більше ролей призводить до меншої відповідальності перед командою. Ми не хочемо більше артефактів, тому що більше артефактів призводить до збільшення відстані між командами та клієнтами. Ми не хочемо більше процесів, тому що це призводить до зменшення навчання та відповідальності команд за процес. Натомість ми хочемо більш відповідальних команд з меншою кількістю ролей, ми хочемо більш клієнтоорієнтованих команд, які створюють корисні продукти з меншою кількістю артефактів, ми хочемо більшої відповідальності команд за процес і більш змістовної роботи з меншою кількістю визначених процесів. Ми хочемо більше з меншими витратами.

Фокус на цілісному продукті (Whole-product focus) - один бэклог продукту, один власник продукту, один продукт, який можна відвантажити, один спринт - незалежно від того, 3 чи 33 команди. Клієнти хочуть отримати цінну функціональність у цілісному продукті, а не технічні компоненти в окремих частинах.

Клієнтоорієнтованість (Customer-centric) - зосередьтеся на вивченні реальних проблем клієнтів та їх вирішенні. Визначте цінність і втрати в очах клієнтів, які платять. Скоротіть час очікування з їхньої точки зору. Збільшити та зміцнити зворотній зв'язок з реальними клієнтами. Кожен розуміє, як його робота сьогодні безпосередньо пов'язана з клієнтами, які платять, і приносить їм користь.

Безперервне вдосконалення до досконалості (Continuous improvement towards perfection) - ось мета досконалості: Створювати і поставляти продукт майже весь час, майже без витрат, без дефектів, який радує клієнтів, покращує навколишнє середовище і робить життя кращим. Робіть нескінченні скромні та радикальні експерименти з удосконалення для досягнення цієї мети.

Ощадливе мислення (Lean thinking) - Створіть організаційну систему, основою якої є менеджери-вчителі, які застосовують і навчають ощадливому мисленню, вміють удосконалюватися, просувають метод "зупинитися і виправити" і практикують "Go See". Додайте до цього два стовпи - повагу до людей та постійне прагнення до покращення існуючого стану речей. І все це заради мети - досконалості.

Системне мислення (Systems thinking) - бачити, розуміти і оптимізувати всю систему (а не її частини), а також використовувати системне моделювання для дослідження системної динаміки. Уникайте локальних субоптимізацій, зосереджуючись на ефективності чи продуктивності окремих осіб та окремих команд. Клієнтів цікавить загальний час і потік циклу від концепції до готівки, а не окремі етапи, і локальна оптимізація частини майже завжди призводить до субоптимізації цілого.

Емпіричне управління процесом (Empirical process control) - Постійно перевіряйте та адаптуйте продукт, процеси, поведінку, організаційну структуру та практики, щоб вони розвивалися відповідно до ситуації. Робіть це замість того, щоб слідувати встановленому набору так званих найкращих практик, які ігнорують контекст, створюють ритуальне наслідування, перешкоджають навчанню та змінам, а також пригнічують почуття залученості та причетності у людей.

Теорія черг (Queuing theory) - Зрозумійте, як системи з чергами поводяться в науково-дослідницькій сфері, і застосуйте ці знання для управління розмірами черг, лімітами незавершеного виробництва, багатозадачністю, робочими пакетами та варіативністю.

Два фреймворки: LeSS та LeSS Huge

Великомасштабний скрам має два фреймворки:

• LeSS. 2-8 команд
• LeSS Huge. 8+ команд

Слово LeSS є перевантаженим і означає як великомасштабний скрам в цілому, так і менший фреймворк LeSS.

Магічне число вісім

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

У будь-якому випадку, в якийсь момент (1) один власник продукту більше не може охопити огляд всього продукту, (2) власник продукту не може збалансувати зовнішній і внутрішній фокус, і (3) бэклог продукту настільки великий, що стає важко працювати з ним одній людині.

Коли група досягає цієї критичної точки, можливо, настав час перейти з меншого фреймворку LeSS на LeSS Huge. З іншого боку, ми пропонуємо спочатку спробувати стати кращими, меншими і простішими, перш ніж об'єднуватися.

Спільне у всіх фреймворках

Фреймворки LeSS та LeSS Huge мають спільні елементи:

• один Product Owner і один Product Backlog
• один спільний спринт для всіх команд
• один інкремент продукту, який можна відвантажити

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

LeSS Framework

Менша структура LeSS призначена для одного (і тільки одного) Власника продукту, який володіє продуктом і керує одним бэклогом продукту, над яким працюють команди в одному спільному спринті, оптимізуючи його для всього продукту. Елементи фреймворку LeSS приблизно такі ж, як і в однокомандному Scrum:

Ролі (Roles) - один власник продукту (Product Owner), від двох до восьми команд, скрам-майстер (Scrum Master) для однієї-трьох команд. Важливо, що ці Команди є функціональними командами - справжніми крос-функціональними та крос-компонентними повностековими командами, які працюють разом у спільному середовищі коду, кожна з яких робить все можливе для створення готових елементів.

Артефакти (Artifacts) - один потенційно відвантажений інкремент продукту, один Product Backlog і окремий Sprint Backlog для кожної команди.

Події (Events) - один загальний Спринт для всього продукту; він включає всі команди і закінчується одним потенційно готовим до відвантаження інкрементом продукту. Деталі пояснюються в наступних статтях та в окремих розділах.

Правила та гайди (Rules & Guides) - правила для ледь достатньої структури масштабування для емпіричного контролю процесу та фокусування на всьому продукті. У цьому можуть допомогти гайди.

Історії LeSS (LeSS Stories)

Вивчення LeSS (Learning LeSS) - Один із способів навчання - це читання глибокого викладу, і читачі, які віддають перевагу цьому способу, можуть легко перейти до вступу до LeSS Huge, а потім до наступних розділів. Інші, хто любить історії, можуть продовжувати читати.

Прості історії (Simple stories) - Ці історії не досліджують складнощі великомасштабного розвитку - від політики до визначення пріоритетів - з якими ми стикаємося під час консультування. Наступні розділи розпаковують ці коробки. Тут навмисно наведено прості та зрозумілі історії, щоб познайомити вас з основами LeSS Sprint. Якщо ви хочете захопливих діалогів і драматизму, прочитайте книгу про Lean.

Правила та інструкції (Rules & guides) - В історіях ви помітите, що на полях є посилання на відповідні правила та інструкції LeSS, щоб прояснити та встановити зв'язки.

Дві перспективи (Two perspectives) - Нижче наведені дві пов'язані історії, які фокусуються окремо на двох ключових перспективах, щоб простіше представити деякі потоки:

1. Потік команд через LeSS Sprint.
2. Потік клієнтоорієнтованих елементів (функцій).

Історії LeSS: Потік команд

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

Планування спринту один (Sprint Planning One)

Настав час для спільного Sprint Planning One. У великій кімнаті сидять 10 представників п'яти команд з цієї групи продуктів. Всі вони працюють над своїм флагманським продуктом для торгівлі облігаціями та деривативами. Сем, Scrum Master команд Trade та Margin, також присутній. Він планує спостерігати і тренувати в міру необхідності.

ПРАВИЛО: Спринт на рівні продукту один, а не окремий для кожної команди.

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

Тоді Sprint Planning One використовувався для того, щоб відповісти на багато важливих питань, які всі хотіли почути. Але останнім часом ситуація значно покращилася, і тепер група експериментує з використанням ротаційних представників, що перетворило її на просту і швидку зустріч з кількома незначними питаннями, які, як правило, з'являються.

Якщо новий підхід не спрацює добре, це питання, ймовірно, буде піднято в Загальній ретроспективі, і буде створено ще один експеримент для планування спринту.

ПРАВИЛО: Спринт-планування складається з двох частин: Планування Спринту Один є спільним для всіх команд, тоді як Планування Спринту Два зазвичай робиться окремо для кожної команди. Виконуйте Спринт-планування два для кількох команд у спільному просторі для тісно пов'язаних елементів.

Заходить Паоло і каже: "Привіт!" Він є власником продукту, а також провідним менеджером по продукту. Паоло розкладає на столі 22 картки і каже: "Ось основні теми: німецький ринок, управління замовленнями та деякі регуляторні звіти.

Я розклав їх у порядку пріоритетності. Думаю, всі присутні розуміють, чому саме ці теми є пріоритетними, оскільки ми багато обговорювали це під час вдосконалення Product Backlog. Але, будь ласка, запитайте ще раз, якщо щось незрозуміло".

ПРАВИЛО: На першому етапі планування спринту присутні власник продукту та команди або представники команд. Вони разом попередньо обирають пункти, над якими кожна команда працюватиме протягом наступного Спринту.

Міра і Марк підходять до столу (разом з іншими представниками) і беруть по дві картки з питаннями, пов'язаними з облігаціями німецького ринку. Протягом останніх двох спринтів їхня команда детально розібралася з цими питаннями під час однокомандних воркшопів з уточнення Product Backlog refinement (PBR).

І вони вибрали ще два пункти, пов'язані з управлінням замовленнями, які і Team Trade, і Team Margin розуміють досить добре. Обидві команди працювали разом над цими питаннями на багатокомандних PBR-семінарах. Чому? Команди хотіли якомога пізніше визначитися з вибором між командами, під час майбутнього спринт-планування. Це підвищує гнучкість групи - вона легко реагує на зміни, а їхні ширші знання про весь продукт сприяють самоорганізованій координації.

Хвилиною пізніше Мері з Team Margin, скануючи картки іншої команди, запитує їхніх представників: "Ви не заперечуєте, якщо ми зробимо цей звіт? Ми робили щось подібне минулого спринту, і я впевнена, що ми зможемо зробити це швидко. Чи не могли б ви обмінятися на цей продукт для німецького ринку?" Вони погоджуються.

Через кілька хвилин команди закінчують вибір і міняються місцями, виходячи зі своїх інтересів, сильних сторін і бажання згрупувати пов'язані пункти для фокусування.

Сем (Scrum Master) каже: "Я помітив, що команда "Маржа" має чотири найпріоритетніші пункти. Чи може це стати проблемою?" Починається швидке обговорення, в ході якого група розуміє, що є шанс, що один з найбільш пріоритетних пунктів продукту може бути відкинутий, якщо справи у Team Margin підуть не так гладко. Вони вирішили розподілити кілька найбільш пріоритетних завдань між кількома командами (обмежуючись тим, які команди знають, які саме завдання), щоб підвищити ймовірність того, що першочергові завдання будуть виконані.

Представники вибрали загалом 18 карток, залишивши на столі чотири найменш пріоритетні завдання. Паоло переглядає невибрані картки з завданнями, бере дві з них і каже: "Ці два завдання дуже важливі для мене в цьому спринті. Можливо, мені слід було спочатку дати їм вищий пріоритет, але я цього не зробив, а тепер хочу передумати. Давайте знайдемо спосіб поміняти їх місцями з деякими пунктами, які ви вже вибрали. І, звичайно, якщо команді пощастить і вона закінчить раніше, будь ласка, заберіть невибрані речі".

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

ПРАВИЛО: Під час планування спринту команди визначають можливості для спільної роботи і з'ясовують остаточні питання.

Паралельно Міра, Марк та інші учасники ретельно обмірковують остаточні дрібні моменти, які потрібно з'ясувати для своїх предметів, і записують деякі питання на аркушах для фліпчарту, прикріплених на стінах по всій кімнаті. Паоло ходить по кімнаті, обговорюючи питання. Всі змішуються і роблять свій внесок. Приблизно через 30 хвилин на всі незначні питання, на які можна було б відповісти, вже є відповіді.

Група утворює коло, щоб завершити обговорення. Ніхто не піднімає жодних тем про координацію, тож зрештою Сем каже: "Я помітив, що команди "Торгівля і маржа" та "Похідні фінансові інструменти" обговорили тісно пов'язані між собою питання управління замовленнями". Міра каже: "Гей, давай об'єднаємо Trade, Margin і NotDerivative разом для багатокомандного Sprint Planning Two. У нас є можливості працювати разом". Домовленість досягнута. Зустріч закінчується.

Планування командного та мультикомандного спринту 2 (Team and Multi-Team Sprint Planning Two)

Після перерви дві з п'яти команд проводять власні однокомандні зустрічі "Планування Спринту", на яких створюють власні бэклоги Спринту, розробляють і планують свою роботу на Спринт.

ПРАВИЛО: кожна команда має свій власний бэклог спринту.

На противагу цьому, команди Trade, Margin і NotDerivative проводять багатокомандне Sprint Planning Two разом у великій кімнаті, оскільки вони впроваджують тісно пов'язані елементи (які також були попередньо з'ясовані разом під час багатокомандного PBR), і вони передбачають користь від тісної співпраці.

ПРАВИЛО: Проводьте SP2 для кількох команд у спільному приміщенні для тісно пов'язаних між собою питань.

Вони обговорюють разом протягом 10-хвилинної сесії, щоб створити основу, визначаючи спільну роботу (спільні завдання) і питання дизайну. Потім вони починають відлік 30-хвилинної сесії дизайну в таймбоксі, домовляючись про візуалізацію: більше ескізів на дошці, менше розмов без малювання. За цей час також знаходять і записують на дошці більше спільної роботи.

Дзень! Через 30 хвилин залишається ще багато недосліджених деталей, але команди все одно рухаються далі. Кожна команда прямує в інший кут великої кімнати, де кожна починає свій власний етап планування спринту №2, обговорюючи більш детально питання дизайну та створюючи свій власний список відставання за допомогою карток.

Подальша координація відбувається за допомогою вдосконаленої варіації техніки "просто поговорити" в LeSS: "просто крикнути".

Під час розмови команди усвідомлюють необхідність проведення поглибленого багатокомандного дизайн-воркшопу. Вони погоджуються провести його пізніше того ж дня.

Мульти-командний дизайн-майстер-клас (Multi-Team Design Workshop)

Після планування спринту та чергової перерви Міра та Марк з Team Trade, а також кілька людей з Team Margin та Team NotDerivative проводять годинний командний дизайн-воркшоп, щоб глибше зануритися у спільний та послідовний дизайн для своєї роботи. Біля великої дошки вони малюють ескізи та обговорюють їх, щоб досягти певної ясності та згоди щодо підходу до дизайну та спільних технічних завдань.

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

Діяльність з розвитку, що підтримує координацію та безперервне надання послуг (Development Activities Supporting Coordination and Continuous Delivery)

Після планування спринту команди занурюються в розробку елементів, приділяючи особливу увагу спілкуванню в коді. Всі команди безперервно інтегруються.

Безперервна інтеграція всього коду в усіх командах створює можливість співпрацювати, перевіряючи, хто ще вносив зміни в компонент, над яким працюють. Це корисно, тому що група використовує інтеграцію як спосіб інформування та підтримки своєї координації.

Наприклад, на початку другого дня спринту Марк, розробник з Team Trade, витягує останню версію локально і швидко перевіряє останні зміни, пов'язані з компонентом, над яким вони зараз працюють. Він виявляє зміни, пов'язані з кодом, доданим Максиміліаном з Team Margin.

Він знає, що ця команда працює над тісно пов'язаним елементом, тому він не особливо здивований. Оскільки код повідомив, що тепер потрібно координувати дії і з ким йому потрібно поговорити, він негайно йде до Team Margin, що знаходиться далі по коридору. Вони просто говорять про те, як працювати разом, щоб отримати вигоду від роботи один одного.

ПРАВИЛО: Надавайте перевагу децентралізованій та неформальній координації перед централізованою.

Для продукту, який розробляє Team Trade, і фактично для кожного продукту в кожній команді, вони написали автоматизовані приймально-здавальні тести перед тим, як почати розробляти код рішення. Таким чином, на додаток до безперервної інтеграції коду, вони також інтегрують автоматизовані тести.

Ці приймально-здавальні тести часто виконуються членами команди, і коли будь-який з них не спрацьовує, команди негайно отримують сигнал для координації. Код говорить їм: "Гей! Є проблема! Вам потрібно поговорити і вирішити її".

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

ПРАВИЛО: Мета досконалості полягає в тому, щоб покращити визначення "Готового" так, щоб це призводило до створення продукту, придатного до відвантаження, кожного спринту, або навіть частіше.

Загальна ретроспектива (Overall Retrospective)

На другий день Спринту Сем та інші Скрам-майстри, власник продукту Паоло, менеджер сайту та представники більшості команд збираються разом для проведення 90-хвилинної загальної ретроспективи, пов'язаної з останнім Спринтом.

ПРАВИЛО: Загальна ретроспектива проводиться після командних ретроспектив для обговорення міжкомандних та загальносистемних питань, а також для створення експериментів з покращення.

Чому вони не провели цю загальну ретроспективу перед початком нового спринту? Вони могли б, але зазвичай вони закінчують спринт у п'ятницю і починають новий у понеділок (на відміну від пропозиції Сема, який запропонував спробувати провести його в середу-четвер).

І в останню п'ятницю вони проводили як огляд спринту, так і ретроспективу на рівні команди. Після цього у них не вистачило енергії на проведення загальної ретроспективи наприкінці дня. Тому вони вирішили провести наступний Спринт раніше. Сем приватно вважає, що така затримка - не найкраща ідея - він би волів, щоб вони розпочали планування Спринту трохи пізніше після цієї зустрічі, але він хоче, щоб група зрозуміла це для себе.

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

Діяльність з координації (Activities for Coordination)

ПРАВИЛО: міжкомандна координація визначається командами.

Четвертий день демонструє різноманітні ідеї координації в LeSS:

У LeSS кожна команда проводить щоденний скрам, як зазвичай. Щоб підтримати координацію між командами Trade і Margin, Міра йде як розвідник, щоб спостерігати за щоденним скрамом команди Margin, а потім повертається і інформує свою команду про те, що вона дізналася. А хтось із Team Margin робить навпаки.

Як було узгоджено в загальній ретроспективі, група проводить 45-хвилинну зустріч у відкритому просторі для координації та навчання, якій передують напої та закуски. Сем виступає в ролі фасилітатора, який навчає групу, як проводити зустрічі у відкритому просторі. Запрошуються всі бажаючі, але більшість команд вирішують відправити лише кількох представників. До них приєднуються Міра і Марк з Team Trade. Група планує спробувати проводити Відкритий Простір раз на тиждень.

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

Міра є членом спільноти дизайнерів/архітекторів. У цьому спринті немає воркшопу з дизайну, пов'язаного з загальною архітектурою, але вона хоче провести південний воркшоп у наступному спринті для нової технології. Вона публікує свою ідею на інструменті для співпраці спільноти і пропонує спільноті провести цей спринту разом з моб-програмуванням, щоб підвищити рівень спільного навчання.

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

Пізніше Міра та ще кілька членів команди відвідують групу підтримки та навчання клієнтів, яка тісно співпрацює з практичними користувачами. Її команда закінчила свій перший продукт і хоче отримати якнайшвидший зворотній зв'язок від людей, які стоять ближче до клієнтів. Один з тренерів вільний, і він грається з новою функцією. Команда Trade йде з кількома ідеями, як зробити її кращою.

Пізніше в той же день Марк і решта Team Trade виконують завдання для другої частини тренінгу. Марк щойно завершив 10-хвилинний цикл TDD і має чистий стабільний код після мікро-зміни. Знову - приблизно кожні 10 хвилин - він переміщує крихітну зміну до центрального спільного сховища (до "head of trunk"), щоб постійно інтегрувати її зі своєю командою та всіма іншими. Він дивиться на великий видимий червоно-зелений екран на стіні і бачить, що система збірки проходить всі тести для всієї групи.

Доопрацювання загального продуктового бэклогу (Overall Product Backlog Refinement)

ПРАВИЛО: Проводьте багатокомандний та/або загальний PBR, щоб покращити спільне розуміння та використати можливості координації, коли є тісно пов'язані елементи або є потреба у ширшому вкладі/навчанні.

На п'ятий день Марк і Міра приєднуються до загального воркшопу з PBR, в якому беруть участь представники кожної команди та Паоло, власник продукту. Паоло починає з того, що ділиться своїм поточним баченням напрямку розвитку продукту і того, куди рухатися далі в короткостроковій перспективі і, що найважливіше, чому.

Щоб допомогти учасникам зрозуміти його міркування, він розглядає з групою свою модель визначення пріоритетів, яка враховує вплив на прибуток, вплив на клієнтів, бізнес-ризики, технічні ризики, вартість затримки і багато іншого.

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

Потім група розділяє кілька великих нових пунктів, робить легкі роз'яснення (більше буде пізніше) і планує покерну оцінку як спосіб дізнатися більше про пункти - замість того, щоб створювати оцінки.

Представники трьох команд (у тому числі Trade і Margin) вирішують пізніше провести багатокомандний PBR для деяких позицій, щоб покращити їхнє спільне розуміння і тому, що вони тісно пов'язані між собою. А представники двох інших команд обирають питання, на яких зосереджуватимуться окремо під час командних сесій PBR.

Мульти-командний PBR та командний PBR (Multi-Team PBR and Team PBR)

ПРАВИЛО: всі пріоритети визначаються через Власника Продукту, але роз'яснення, наскільки це можливо, проводяться безпосередньо між командами та клієнтами/користувачами та іншими зацікавленими сторонами.

На шостий день всі учасники трьох команд збираються разом на багатокомандний PBR-семінар у великій кімнаті.

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

Таня і Тед - трейдери, які розповіли Паоло про тенденцію, що призвела до доопрацювання позицій на багатокомандній PBR-сесії. Тож вони обидва приєдналися в якості експертів, щоб допомогти командам вивчити та пояснити нові елементи.

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

На останньому етапі зустрічі учасники БОР фотографують все, що є на стінах і дошках. Вони додають їх на вікі-сторінки, які використовуються для запису всього, що стосується кожного пункту. Крім того, вони оновлюють і очищають текст і таблиці на вікі-сторінках, які були швидко додані під час обговорень.

Чат про відставання на рівні команди та власників продуктів (A Chat About Team-Level Backlogs and Product Owners)

Після багатокомандного семінару з PBR Майк (який щойно приєднався до компанії) бачить Сема біля кавомашини і підходить до нього, щоб поговорити. Майк каже: "Привіт, Сем. Мені цікава твоя думка про дещо. На семінарі з уточнення, який ми щойно закінчили, я, звичайно, помітив, що ми працювали безпосередньо з деякими трейдерами, щоб разом прояснити ситуацію. Але чи не є це неефективним? У моїй попередній компанії кожна команда мала власного Product Owner, який писав історію, фреймворки та специфікації, а потім передавав їх нам для реалізації. Тоді ми могли просто зосередитися на програмуванні. І кожна команда мала свій власний Product Backlog, який Product Owner визначав пріоритети. Але я не бачу цього тут. Чому все інакше?"

Сем каже: "Цікаві запитання. Ви не заперечуєте, якщо я поставлю вам кілька запитань, щоб розібратися в цьому?"

"Звичайно, давай".

"Давайте спочатку розглянемо один продуктовий бэклог у порівнянні з багатьма бэклогами на рівні команд. Уявімо, що кожна команда має власний беклог. Наскільки легко та ефективно один дійсно загальний Власник Продукту може мати загальний огляд? І наскільки команда буде обізнана з вимогами та дизайном елементів у бэклозі іншої команди?"

Майк відповідає: "Я можу відповісти на це досить чітко на прикладі моєї останньої компанії. Небагато".

Сем продовжує. "Тепер уявімо, що є вісім команд і вісім командних бэклогів. Що, якщо з точки зору компанії або продукту, з якихось причин, два з восьми командних бэклогів насправді є найбільш важливими або найбільш пріоритетними. Можливо, на ринку відбулися якісь зміни, що призвели до такої ситуації. Тому кілька запитань до вас: Чи можуть шість команд, які працюють над менш пріоритетними бэклогами, легко переключитися на роботу над високопріоритетними проектами в інших двох бэклогах? І чи ймовірно, що група взагалі побачить цю проблему, враховуючи, що кожна команда має свій власний бэклог і локальні пріоритети?"

Майк відповідає: "Наші команди на моєму попередньому місці роботи працювали лише над власними командними завданнями. Вони не могли переключитися на інші. Та й навіщо їм це? Хіба це не неефективно?"

Сем відповідає: "Ну, з точки зору компанії, команди працюють "ефективно" лише над низькопріоритетними завданнями через їхні вузькі знання, створені тим, що кожна з них зосереджується на своєму власному бэклозі, і тому що загальний пріоритет і огляд не видно. Дозвольте поставити вам кілька запитань: Чи здається це негнучким або гнучким? І чи оптимізує це людей, які працюють над найбільш важливими з точки зору компанії завданнями?"

Майк робить паузу: "О! Здається, я зрозумів. Насправді це не є гнучкістю, хоча наша група стверджувала, що працює за гнучким підходом. Ми не реагували на найбільш важливі зміни в цілому. І моя колишня продакт-власниця в моїй старій команді сказала, що вона визначала пріоритети для найвищої цінності в нашому командному беклозі. Але тепер я бачу, що моя команда була просто зайнята ефективною роботою над тим, що могло бути малоцінним, якщо дивитися на це з вищого рівня". (ПРАВИЛО: Є один власник продукту і один бэклог для повного готового до відвантаження продукту).

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

"Крім того, - коментує Майк, - я помітив, що в моїй попередній компанії всім командам було набагато складніше працювати разом одночасно, оскільки ми працювали над дуже різними цілями в асинхронних спринтах. Тут же відчувається, що всі команди мають більше спільного фокусу та напрямку в одному спринті разом".

"Точно!" відповідає Сем, а потім продовжує.

"Ось ще одне питання: Якщо є лише один Product Backlog і один справжній Product Owner, який визначає його пріоритети, але в кожній команді все ще є свій так званий Product Owner, який за визначенням не визначає пріоритети для командного бэклогу - оскільки його немає - тоді що вони роблять цілими днями? "

Майк відповідає: "Ну, в моїй попередній компанії робота власника продукту на рівні команди полягала в тому, щоб спілкуватися з користувачами і писати історії для команди, щоб вони могли зосередитися на ефективному програмуванні, в той час як власник продукту на рівні команди працював над збором і написанням вимог".

Сем запитує: "Майку, до того, як ти дізнався про такі терміни Scrum, як "Product Owner", як би ти назвав посередників між розробниками та реальними клієнтами - тих, хто збирає вимоги, а потім передає їх розробникам?"

"Я приєднався до своєї останньої компанії ще до того, як ми впровадили там Скрам". Майк відповідає: "І в той час там була група бізнес-аналітиків, які цим займалися. Після того, як ми перейшли на Скрам, нас попросили називати їх Власниками Продукту".

"Сьогодні на вашому семінарі PBR, - запитує Сем, - ви розмовляли з трейдерами, які там були?"

"Дай пригадати". Майк відповідає: "Так, я говорив з Танею про її ідею аналізувати торгівлю російськими корпоративними облігаціями. Це здалося мені трохи незрозумілим, тому я запитав її, чому? Вона пояснила, що це через занепокоєння щодо відмивання грошей на офшорних рахунках. Вона не знала, що ми нещодавно працювали над деякими іншими функціями, які інтегруються з новими регуляторними базами даних ЄС і США, щоб оцінити це. Тому я запропонував їй інший підхід, який, на мою думку - і вона погодилася - краще вирішить проблему.

"Тепер, коли я думаю про це, - розмірковує він, - цього, мабуть, не сталося б у моїй попередній компанії, оскільки ми рідко спілкувалися безпосередньо з користувачами".

ПРАВИЛО: Власник продукту не повинен працювати над удосконаленням Product Backlog наодинці; його підтримують численні команди, які працюють безпосередньо з клієнтами/користувачами та іншими зацікавленими сторонами.

ПРАВИЛО: Всі пріоритети проходять через Власника Продукту, але роз'яснення, наскільки це можливо, проводяться безпосередньо між командами і клієнтами/користувачами та іншими зацікавленими сторонами.

Більше розвитку (More Development)

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

Тому, коли спринт майже закінчився і команди готуються приєднатися до Sprint Review, немає ніякого божевільного пориву інтегрувати і протестувати велику партію коду - він був інтегрований і протестований весь цей час.

Огляд спринту (Sprint Review)

ПРАВИЛО: існує один продукт Sprint Review; він є спільним для всіх команд.

Нарешті настав останній день і час для спільного Sprint Review. Хто тут? Паоло (власник продукту, провідний менеджер продукту), всі внутрішні трейдери облігацій, кілька тренерів і представників служби підтримки, кілька людей з відділу продажів і чотири користувачі з числа зовнішніх клієнтів, які платять нижчі річні тарифи в обмін на регулярну участь в цих оглядах. Крім того, це всі члени команди.

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

Через годину група збирається разом, щоб обговорити питання та відгуки на сесії, яку веде Паоло. Після цього вони обговорюють майбутній напрямок. Паоло ділиться тим, що відбувається на ринку і з конкурентами, а також своїми думками про те, куди рухатися далі, і просить поради.

Ретроспективи команди (Team Retrospectives)

ПРАВИЛО: кожна команда має власну ретроспективу спринту.

Після перерви команда Trade (і всі інші команди) проводять окремі ретроспективи спринту на рівні команд. Вони вирішують, що проведення багатокомандного дизайн-семінару з командним запасом після планування спринту (а не раніше) було далеко не ідеальним у цьому випадку, тому що основні питання залишилися невивченими до останньої хвилини - питання, які могли б серйозно заблокувати або ускладнити розробку.

Тож для наступного спринту вони вирішили, що під час сесій PBR вони намагатимуться визначити елементи, які мають серйозні проблеми з дизайном, які варто обговорити з іншими командами. І якщо це так, провести багатокомандний дизайн-воркшоп якомога швидше.

Кінець (The End)

Спринт завершено! Сем запрошує команду Trade приєднатися до нього і Міри в бельгійському пивному пабі вниз по вулиці - улюбленому пабі Міри - щоб відсвяткувати її день народження.

ПРАВИЛО: пиво - бельгійське Трипель Кармелієт )).

Підсумок (Summary)

Кілька ключових моментів з історії:

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

Історія LeSS: Потік історій (LeSS Story: Flow of Items)

Ця історія більше фокусується на потоці елементів (функцій) через частину спринту, насамперед під час доопрацювання та розробки.

Порша завершує зустріч з державним регулятором і прямує до аеропорту та додому. Вона ще один продакт-менеджер; вона допомагає Паоло і спеціалізується на регуляторних та аудиторських тенденціях.

Пізніше Порша зустрічається з Паоло. Пишучи на картках, вона підсумовує нові правила, які вплинуть на їхній продукт, і те, які клієнти, на її думку, захочуть отримати певні функції в першу чергу. Паоло показує на п'ять карток і запитує: "Отже, це охоплює всю роботу, наскільки ти знаєш?" Порша посміхається і каже: "Це регуляторна робота. Він ніколи не буває закінченим чи чітким".

Паоло запитує: "Можеш покласти їх у список нерозподілених завдань, поки що без порядку внизу?"

"Звісно".

Тиждень потому Паоло каже Порції: "Незабаром я хочу почати виконувати деякі частини великої регуляторної вимоги щодо деривативів на облігації. На наступних семінарах Sprint, присвячених доопрацюванню продуктового беклогу, я попрошу деякі команди зосередитися на цьому. Ви знаєте про це найбільше, тому, будь ласка, приходьте на загальний PBR і на всі семінари з доопрацювання для команд, де вас запросять. Крім того, чи можете ви створити вікі-сторінку з посиланнями на нові нормативні документи, щоб поділитися ними з командами?"

"Вже зроблено", - відповідає Порша.

Загальний PBR (Overall PBR)

Паоло розпочинає короткий загальний семінар з PBR: "У нас багато роботи з новими правилами. Незабаром нам потрібно буде здати відповідні документи, оскільки законодавчо встановлений крайній термін - кінець фінансового року.

Ми знатимемо більше після певного розподілу та оцінки, але я не здивуюся, якщо для впровадження знадобиться три або більше команд, а також багато часу".

Група ділить новий гігантський об'єкт лише на кілька великих частин, щоб вивчити основні елементи. Більше розділень відбудеться пізніше під час сесії ПБР для однієї або кількох команд. Порша підходить до дошки; на лівій стороні вона пише "правила для деривативів облігацій".

Потім у розмові з групою вони накреслюють деревоподібну діаграму з чотирма гілками, що представляють поділ на чотири основні підпункти. Але вони не заглиблюються - уникають надмірного аналізу.

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

Далі Паоло запитує: "Отже, Порша, з цих чотирьох великих проектів, який з них перший?"

Вона вказує на другу картку. "Позабіржові екзотичні похідні облігації".

Паоло каже: "Нам потрібно почати продавати деякі з них якомога швидше. Це просувається вгору по списку нерозглянутих продуктів. Тож я хотів би, щоб одна команда взялася за це на наступному спринті. Хто зацікавлений?"

Волонтери з команди Trade.

Зрештою, члени трьох інших команд вирішують провести багатокомандний PBR-семінар для суміжних продуктів.

Команда PBR: вступаємо в гру (Team PBR: Biting In)

Наступного дня Team Trade проводить командний воркшоп з PBR з Поршею. Їм потрібно зосередитися лише на одному з чотирьох гігантських пунктів: Нові правила для позабіржових (OTC) екзотичних деривативів на облігації. Сем (їхній Scrum Master) також присутній. Порша каже: "Це гігантський складний пункт, у сфері, в якій, відверто кажучи, ніхто нічого не розуміє. Нам знадобиться багато часу, щоб розділити його на частини, по-справжньому зрозуміти і добре прописати".

Сем запитує: "Чи справді нам потрібно все це розуміти? І чи навчить нас увесь цей аналіз більше, чи навпаки затримає наше навчання?".

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

З Порцією команда відколупує один крихітний шматочок тонкого наскрізного продукту, орієнтованого на клієнта.

Відтепер вони зосереджуватимуться на цьому маленькому шматочку, уточнюючи та впроваджуючи його. Лише після впровадження та зворотного зв'язку вони повернуться набагато пізніше до більшого дроблення та доопрацювання. Використовуючи специфікацію на прикладі, Порша і Team Trade провели решту дня, пережовуючи свій шматочок.

Багатокомандний PBR: вдосконалення ротації (Multi-Team PBR: Rotation Refinement

Одним із результатів загального PBR стало рішення про співпрацю з Team Trade. Іншим було рішення трьох команд провести багатокомандний семінар з PBR для суміжних товарів, щоб покращити навчання та спритність кількох команд, які знають і думають про одні й ті ж товари.

На додаток до всіх трьох команд, внутрішні трейдери Таня, Тед і Тревіс приєдналися, щоб допомогти командам почати роз'яснювати близько десятка нових товарів.

ПРАВИЛО: Усі пріоритети визначаються через Власника продукту, але уточнення відбувається, наскільки це можливо, безпосередньо між командами та клієнтами/користувачами та іншими зацікавленими сторонами.

Для початку вони формують три тимчасові змішані групи, до яких входять люди з кожної команди. Змішані групи починають з'ясовувати різні питання в окремих зонах кімнати, кожна з яких має дошку, велику стіну, ноутбук і проектор. Таня з однією групою, Тед з іншою, а Тревіс з третьою.

Потім вони вдосконалюють ротацію: Через 30 хвилин дзвенить таймер! Одна група переходить до іншої, і навпаки, але Таня, Тед і Тревіс не рухаються. Таймер перезапускається, учасники пояснюють поточні результати новим групам, а ті продовжують уточнювати.

Протягом дня, коли різні елементи стають відносно зрозумілими - або залишаються невирішеними питаннями, які потрібно буде дослідити пізніше, - на робочій зоні з'являються нові елементи. Деякі з великих питань розбиваються на два-три нових менших.

Кілька разів протягом дня групи припиняють пояснення і роблять деякі оцінки, в основному для того, щоб дізнатися і підштовхнути до розмови. Вони використовують відносні (сюжетні) точки; щоб залишатися синхронізованими щодо загальної базової лінії, вони калібрують за деякими вже завершеними і добре відомими пунктами в Product Backlog.

Оновлення беклогу продуктів та власника продукту (Updating the Product Backlog and Product Owner)

Наступного дня після воркшопів PBR Порша та кілька членів команди

• оновили Product Backlog новими розділеними позиціями, отриманими з оригінальних, і видалили оригінали
• додають посилання на нові вікі-сторінки з деталями проєктів, створені під час семінарів РОР
• записати нові кошториси та пункти, готові до реалізації.

Пізніше Порша та інші члени команди зустрічаються з Паоло, щоб переглянути зміни у Product Backlog та відповісти на його запитання.

Кінець (The End)

Кілька ключових моментів з історії:

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

Наступний розділ присвячений фреймворку LeSS Huge, який використовується для великих груп з багатьох команд.

LeSS Величезний фреймворк (LeSS Huge Framework)

Області вимог (Requirement Areas)

Коли над одним продуктом працює 1000 або навіть лише 100 людей, принцип "розділяй і володарюй" здається неминучим через складність такої кількості вимог і людей. Традиційна великомасштабна розробка ділиться таким чином

• однофункціональні групи (група аналізу, група тестування, ...)
• архітектурно-компонентні групи (група інтерфейсу користувача, група серверної частини, група компонентів доступу до даних, ...)

Така організаційна структура призводить до повільного негнучкого розвитку з (1) високим рівнем відходів (інвентаризація, незавершене виробництво, передача, розпорошення інформації, ...), (2) тривалим терміном окупності інвестицій, (3) складним плануванням і координацією, (4) більшими накладними витратами і (5) слабким зворотним зв'язком і навчанням. І вона організована всередині навколо окремих навичок, архітектури та управління, а не ззовні навколо цінності для клієнта.

Але у фреймворку LeSS Huge, де понад вісім команд, поділ відбувається навколо основних сфер занепокоєння клієнтів, які називаються Областями Вимог (Requirement Areas). Це відображає клієнтоорієнтований принцип LeSS.

Розмір (Size) - Область Вимог є великою, зазвичай вона має від чотирьох до восьми команд, а не одну чи дві. У наступному розділі "Команди для зони" пояснюється, чому.

Динамічність (Dynamic) - Зони вимог є динамічними. З часом важливість області змінюється, а потім вона зростає або зменшується, оскільки команди приєднуються або покидають її - найімовірніше, в іншу існуючу область або з неї.

Приклад (Example) - наприклад, у продукті з цінних паперів (для торгівлі акціями), це можуть бути деякі основні сфери інтересів клієнтів - Сфери вимог:

• торговельна обробка (від ціноутворення до фіксації та розрахунків)
• обслуговування активів (наприклад, обробка дроблення акцій, дивідендів)
• вихід на нові ринки (наприклад, Нігерія)

Концептуально в одному продуктовому беклозі додається атрибут "Сфера вимог", і кожна позиція класифікується в одну і тільки одну сферу:

Тоді люди можуть зосередитися на одній області (концептуально, на погляді на один продуктовий бэклог), наприклад, на області виведення на ринок:

Спільний спринт (Common Sprint) - Чи працює кожна область вимог окремо у своєму власному спринті, з відкладеною інтеграцією до далекого майбутнього? Ні.

У LeSS Huge безперервна інтеграція в одному загальному спринті

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

Власники окремих продуктів (Area Product Owners)

У LeSS Huge з'явилася одна нова роль. Кожна Область Вимог має Власника Продукту, який спеціалізується на цій області і зосереджується на її бэклоге продуктів.

Великі групи продуктів зазвичай мають кілька допоміжних менеджерів продуктів, що спеціалізуються на різних сферах клієнтів, і деякі з них, ймовірно, будуть виконувати обов'язки власників продуктів. Іноді власник продукту також виконує подвійні обов'язки власника продукту для однієї області; це більш ймовірно в невеликих менш величезних групах LeSS Huge!

Команди по роботі з окремими напрямками (Area Feature Teams)

Зональні функціональні команди працюють в межах однієї області (наприклад, обслуговування активів), з одним Зональним Власником Продукту, який зосереджується на елементах в одному Зональному Беклоге Продукту. З точки зору команди, робота в цій області схожа на роботу в меншому фреймворку LeSS - вони взаємодіють зі своїм Area Product Owner так, ніби він є власником продукту, і так далі.

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

Ключовий момент про розмір: Багато функціональних команд працюють в області вимог.

Зазвичай в області вимог працює від чотирьох до восьми команд.
Це означає, що область вимог є великою.

Магічне число чотири (The Magic Number Four)

По-перше, чому для Зони Вимог пропонується верхня межа у вісім команд? Див. статтю "Магічне число вісім".

А як щодо нижньої межі в чотири команди? Чому не одна або дві команди? Звичайно, чотири - не магічне число, але воно забезпечує баланс, щоб група продуктів не складалася з багатьох крихітних областей вимог.

У чому проблема з великою кількістю крихітних областей? Вони зменшують видимість загальних пріоритетів на рівні продукту, збільшують локальні оптимізації, підвищують складність координації, вимагають більше посад і створюють команди, які занадто вузько спеціалізуються і яким не вистачає гнучкості (маневреності), щоб братися за нові, найбільш цінні з точки зору компанії елементи. Крім того, в крихітній області власник продукту все частіше виступає в ролі бізнес-аналітика між користувачами та однією або двома командами.

Чи є якісь розумні винятки з нижньої межі в чотири особи? Так:

• Рання перехідна ситуація, коли група поступово розвиває новий напрямок, який, як очікується, в кінцевому підсумку матиме чотири або більше команд. Тоді почніть з малого і простого - з однієї команди.
• При перерозподілі команд із зони зі зменшуваним попитом на зону зі зростаючим попитом, ця зона може скоротитися з чотирьох до трьох команд. Зрештою, об'єднайте дві зменшені маленькі області в нову більшу область.

Приклади областей вимог та команд (Example Requirement Areas and Teams)

Таким чином, продукт з цінних паперів може мати

• одного Власника продукту та трьох Власників продукту в регіоні, які разом утворюють Команду Власника продукту
• шість функціональних команд в області обробки торгівлі
• чотири функціональні групи у сфері виходу на ринок
• чотири функціональні групи у сфері обслуговування активів

Короткий огляд фреймворку LeSS Huge (LeSS Huge Framework Summary)

Кожна Область Вимог працює як (менша за розміром) реалізація LeSS, кожна з яких працює паралельно в одному загальному спринті. Іноді ми підсумовуємо спринт в LeSS Huge як стек LeSS.

З точки зору команди в одній області,
LeSS Huge виглядає як (менший) LeSS щодо подій.

Як і у випадку з LeSS, для LeSS Huge існують правила та необов'язкові керівництва; вони представлені в наступних історіях і детально розглянуті в наступних розділах.

Ролі (Roles) - те ж саме, що і в LeSS, плюс два або більше Власників Продукту, і від чотирьох до восьми команд в кожній Області Вимог. Один Власник Продукту (який зосереджується на загальній оптимізації продукту) і кілька Власників Продукту в областях утворюють Команду Власника Продукту.

Артефакти (Artifacts) - те ж саме, що і LeSS, плюс атрибут Area Requirement в одному Product Backlog і, таким чином, подання Area Product Backlog для кожної області.

Події (Events) - Існує лише один загальний спринт для продукту; він включає всі команди і закінчується загальним потенційно відвантаженим приростом продукту.

LeSS Величезні історії (LeSS Huge Stories)

Вивчаємо LeSS Huge (Вивчаємо LeSS Huge) - Читачі, які віддають перевагу викладу, можуть легко перейти до наступних розділів, оминаючи ці історії.

Прості історії (Simple stories) - Це навмисно прості історії, щоб познайомити вас з основами LeSS Huge.

Дві теми (Дві теми) - Нижче наведено дві історії з різними темами:

1. Створення і розвиток нової області вимог для роботи з новими гігантськими вимогами.
2. Робота з мультисайтовими командами. (Це трапляється і в менших фреймворках LeSS, але особливо часто в LeSS Huge).

LeSS Величезні історії LeSS: Нова область вимог (LeSS Huge Story: A New Requirement Area)

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

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

"Порша, після останнього краху регулятори стали більш жорсткими і вимагають від нас дотримання вимог закону Додда-Франка. Наразі ми не знаємо, що саме це означає і як це вплине на нашу систему. Ви володієте неймовірними знаннями в цій сфері і маєте чудові професійні зв'язки з регуляторами. Я був би радий, якби ви приєдналися до нашої групи і допомогли нам з'ясувати, як з цим боротися".

Великий сюрприз (A Big Surprise)

Кілька днів по тому... Пріті вітає Поршу, Пітера та Сьюзен у своєму офісі. Пітер є власником продукту в області ринкового онбордінгу, а Сьюзан - Scrum-майстром у сфері обробки торгових операцій.

Пріті каже: "Як ви знаєте, наближається закон Додда-Франка, і це дуже важливо. Але ви не знаєте, що сьогодні вранці до нас зателефонували регулятори і вимагають, щоб ми негайно вжили заходів. Я працював з припущенням, що ми можемо почати наступного року. Тож нам доведеться адаптуватися, дуже швидко.

"Я не думаю, що хтось чітко розуміє, що це означає в деталях - навіть регулятори. І ми не знаємо, як це вплине на нашу систему і скільки роботи це займе, окрім того, що дуже багато! Але тепер до нас приєдналася Порша, і вона розуміє це краще за всіх, хоча вона зовсім новачок у нашій системі. Тож, як ми можемо допомогти їй почати долати цю гору роботи?"

Сьюзан запитує: "Ви ж розумієте, що таке дислексичні зомбі, так?"

Пітер і Пріті кивають. Про них знають усі - і справа не лише в їхній назві. Дислексичні зомбі мають, мабуть, найбагатший досвід серед усіх команд. Вони існують вже багато років і були справжньою скалкою в дупі, коли прийняли LeSS.

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

На їхнє здивування, сталося навпаки! Завдяки своїм глибоким знанням вони постійно отримують складні завдання для розробки. І вони регулярно беруть участь в якості експертів-викладачів у навчальних семінарах з сучасної архітектури для новачків, а Маріо - один з колишніх архітекторів PowerPoint - зараз є координатором архітектурної спільноти. Коли він вип'є достатньо пива, він зізнається, що тісніша робота з кодом і тестами покращила його реальне розуміння системи.

Сьюзан продовжує: "Якщо якась команда може швидко допомогти Порше краще зрозуміти розмір і вплив закону Додда-Франка, то це будуть "Зомбі". Вони очолювали роботу над Сарбейнса-Окслі кілька років тому. Завтра у них сесія PBR. Вони майже завершили роботу над новим сюжетом. Чому б нам не перенаправити зустріч так, щоб включити їх в обговорення Додда-Франка, а незабаром після цього попросити їх зосередитися на цьому питанні на повний робочий день?"

Переробка з зомбі (Refining with Zombies)

Наступного дня на уточнювальній нараді з "Зомбі" Порша пояснює ситуацію: "Ви, напевно, всі чули про закон Додда-Франка. Але ось сюрприз: Регулюючі органи щойно повідомили нам, що вони хочуть, щоб ми вжили заходів "зараз" і продемонстрували значну відповідність до кінця року. Інакше вони можуть обмежити нашу торгівлю".

Зомбі помітно здивовані. До них доходили чутки, але вони не очікували такого поспіху!

Маріо каже: "Гаразд, Порша, розкажи нам коротко, що це означає. І чим він відрізняється від Сарбейнса-Окслі?"

Порша бере ручку і починає малювати на дошці. Приблизно через 45 хвилин вона закінчує огляд, і Зомбі виглядають трохи приголомшеними.

"Кажуть, кінець року?" - запитує Маріо. "Якби вся група почала сьогодні, вона б не закінчила. Це величезна робота!"

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

Він каже: "Порша, давай використаємо це як шанс допомогти тобі краще зрозуміти систему. Запитуй".

Порша каже: "Можеш зачекати секунду? Дозвольте мені почати відеозапис, щоб допомогти мені запам'ятати це".

Мішель, ветеран команди, каже: "Нам краще розпочати реальну розробку найближчим часом і дізнаватися більше по ходу справи, бо інакше ми будемо аналізувати вічно. Я вже бачила цю історію раніше".

Сьюзан, їхній Scrum-майстер, каже: "Це нагадує мені... Том ДеМарко якось сказав, що причиною кожного невдалого проекту є те, що він розпочався занадто пізно". Всі сміються. Вона продовжує: "Тож ось вам пропозиція: відкусіть шматочок".

Створення нової області вимог (Creating a New Requirement Area)

Наступного дня Порша, Пріті та решта команди розробників зустрічаються. Порша ділиться коротким описом обсягу робіт, як вона його розуміє зараз.

Пріті каже: "Це навіть більше, ніж я очікувала, і ми повинні продемонструвати відчутний прогрес регуляторам протягом декількох місяців, а найбільший прогрес - до кінця фінансового року - через сім місяців. Очевидно, що тепер вони мають право вимагати від нас більшого і можуть нас закрити. Як ви знаєте, лише минулого місяця генеральний директор чітко дав зрозуміти, що нові регуляторні запити мають пріоритет над будь-якими іншими проблемами. З мого досвіду, наша добра воля та гнучкість у відносинах з регуляторами зростає, якщо ми можемо надати їм щось на ранній стадії, бути прозорими та чуйними. Саме так ми і будемо діяти".

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

Після короткої дискусії стає зрозуміло, що всі визнають важливість створення нового напрямку.

Пріті каже: "Порто, я знаю, що ти в нас новачок, але як ти думаєш, чи зможеш ти впоратися з обов'язками власника продукту цього напряму?"

Порша киває.

Пріті продовжує: "Пітере, як ти думаєш, "Зомбі" можуть почати роботу над цим? Нам потрібно, щоб вони вивчили закон Додда-Франка і з'ясували його вплив на нашу систему, перш ніж ми зможемо долучити до нього більше команд".

Пітер каже: "Не думаю, що у нас є вибір".

Пріті каже: "Гаразд, Порша, наразі у нас є кілька завдань у зоні відставання Пітера, одне величезне завдання, яке ти, здається, назвала "залишок Додда-Франка", і крихітне завдання, яке ви з Зомбі відкололи від нього. Будь ласка, попросіть Пітера показати вам, як створити нову зону в Product Backlog і перенести туди ці елементи".

Пріті продовжує звертатися до групи: "Наступний спринт починається через три дні. Давайте перемістимо зомбі у вашу область і почнемо працювати над цим монстром. Можливо, через кілька спринтів ми будемо готові - і нам потрібно буде - розширити вашу територію, перемістивши туди ще одну команду. Друзі, будь ласка, подумайте про дві основні проблеми:

• По-перше, про підготовку до серйозної зустрічі з визначення пріоритетів, яка відбудеться через кілька днів. І,
• по-друге, які інші команди будуть хорошими кандидатами на нову територію".

Планування спринту в новій області вимог (Sprint Planning in the New Requirement Area)

Кожна Зона Вимог проводить свої власні зустрічі з планування спринту, які проходять більш-менш паралельно. У новій області Порша розпочинає спринт-планування з представлення зомбі двох незнайомих осіб.

Вона каже: "Джилліан і Зак регулярно контактують з регуляторними органами і допоможуть нам наповнити цю ідею конкретним змістом. Вони погодилися допомагати нам зараз у плануванні, під час наших сесій PBR, і стільки, скільки зможуть щодня під час майбутніх спринтів".

Вона продовжує: "Ось мій попередній план дій на наступні два спринти. По-перше, ми разом повинні дізнатися більше про закон Додда-Франка, а також розбити його на кілька великих і керованих частин, щоб ми могли почати розсіювати туман і краще зрозуміти пріоритети.

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

"По-третє, ми готуємося до того, що до нас приєднається більше команд. Що ви думаєте про такий підхід? Інші пропозиції?"

Під час короткої дискусії Маріо каже своїй команді: "Дозвольте мені дати трохи більше контексту, тому що я представляв нашу команду на нещодавній зустрічі Product Owner Team з усіма Власниками продуктів регіону та Пріті. Почнемо з того, що почнемо тільки ми. Ми візьмемо на себе ініціативу щодо раннього впровадження, отримання загальної картини цього елемента та розуміння загального впливу на нашу архітектуру".

Мішель перебиває: "Як команда тигрів, що працює над новим продуктом?"

"Так, саме так, - каже Маріо. "Уявіть собі підтримку Додда-Франка як новий продукт, який потрібно постійно інтегрувати з рештою продукту. Але ми поспішаємо, і це дуже багато роботи, тому через кілька спринтів до нас приєднається ще одна команда, а незабаром, можливо, ще дві. Ми теж продовжуємо розвиватися, але ми будемо провідною командою, а це означає, що нам потрібно буде підтягувати інші команди і не забувати про загальний продукт".

Мішель каже: "Мені починає здаватися, що ми станемо командою з архітектури та управління проектами!"

Маріо сміється: "Ні. Я з цим покінчив. Ми все ще звичайна функціональна команда, але окрім розробки ми зосередимося на наставництві та якнайшвидшому введенні нових команд в курс справи. Але давайте прояснимо: координація та управління командою, як і раніше, залишається відповідальністю кожної команди".

Перший спринт у новій області вимог (The First Sprint in the New Requirement Area)

Їхній перший спринт - це незвичний баланс між проясненням і розвитком, але, тим не менш, досить корисний у цій екстремальній ситуації. Майже половину спринту вони проводять у з'ясуванні з Поршею, Джилліан і Заком.

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

Вони очікують, що в майбутніх спринтах кількість часу, необхідного для роз'яснення, скоро скоротиться до звичайних 10% або 15% від їхнього спринту.

І тому вони також витрачають лише близько половини спринту на розробку одного невеликого елементу. Але обговорення і навчання під час кодування окупаються. Повільно, але впевнено вони починають розбирати Додда-Франка на частини - принаймні на ті, які кожен з них може зрозуміти.

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

Спринт-огляд в області нових вимог (Sprint Review in the New Requirement Area)

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

У зоні Порші під час огляду вона, Джилліан і Зак досліджують один "готовий" елемент, який зомбі вдалося завершити і інтегрувати в загальний продукт. Спочатку вони прогнозували два пункти, але Порша вражена тим, що їм вдалося виконати навіть один, враховуючи, як швидко на них навалилася нова робота.

Другий спринт (The Second Sprint)

У другому спринті їм вдається дещо краще впоратися з завданнями, хоча вони знову витрачають багато часу на роз'яснення разом з Поршею, Джилліан і Заком.

В середині спринту вони проводять багатокомандну сесію PBR з другою командою, яка планує незабаром приєднатися до зони, навчаючи їх методу Додда-Франка. Вони проводять навчальний семінар з поточної архітектури, щоб познайомити команду з основними елементами дизайну, які вже є на місці.

Зомбі знають, наскільки великою є робота, і з нетерпінням чекають на подальшу допомогу.

Зустріч команди власників продукту (Product Owner Team Meeting)

Минуло кілька спринтів... І знову настав час для зустрічі команди власників продуктів для кожного спринту. Вони використовують її для узгодження та координації дій між різними власниками продуктів, а також для того, щоб Пріті давала вказівки.

По черзі кожен з них ділиться своєю ситуацією та майбутніми цілями. Коли настає її черга, Порша каже: "Не дивно, що прогрес невеликий, а несподіванки великі. Але туман розсіюється, і ми з командою починаємо розбиратися в роботі. Джилліан і Зак нам дуже допомагають".

Пабло, керівник відділу обслуговування активів, коментує тісний взаємозв'язок, який він тепер бачить між їхніми підрозділами. Порша погоджується зустрітися з Пабло та деякими представниками команди пізніше.

Пріті запитує: "Порто, розкажи про наш майбутній спринт. Які твої цілі?"

Додавання третьої команди (Adding a Third Team)

Два спринти пізніше... На координаційній нараді команди власників продукту Пріті каже: "Як ви знаєте, у зоні Порції досі працює лише дві команди. Я знаю, що Пабло хотів би залишити шість команд для обслуговування активів, але Додд-Франк занадто важливий для мене в цьому році.

Тому ми переведемо одну команду із зони Пабло до зони Порши. Пабло, будь ласка, попроси команду волонтерів з твоєї групи і дай мені і Порші знати".

Кінець (The End)

Кілька ключових моментів з історії в LeSS Huge:

• Product Owner відповідає за пошук Area Product Owners і розвиток їхніх талантів.
• Власник продукту відповідає за прийняття рішення про запуск, розвиток або закриття Зони Вимог.
• Зони вимог є великими і зазвичай потребують від чотирьох до восьми команд, але під час початкового запуску вони можуть бути меншими, особливо якщо їх ініціює одна команда, використовуючи підхід Take a Bite (відкусити шматочок).
• Провідна команда працює самостійно над гігантським об'єктом, поки не розбереться в предметній області та розробці, а потім тренує нові команди, щоб допомогти їм впоратися з величезним обсягом роботи.

Багатопрофільні команди: Умови та поради (Multi-Site Teams: Terms & Tips)

Далі ми розповімо про величезну історію LeSS, пов'язану з розподіленими командами. Але спочатку кілька уточнюючих визначень, тому що загальний термін "розподілені команди" плутають між собою кілька речей. Уточнюючі терміни є наступними:

• розпорошена команда (dispersed team) - одна команда з (наприклад, семи) людей, розкиданих у різних місцях; або в різних кімнатах, будівлях, або в різних містах
• спільна команда (co-located team) - одна команда, що працює буквально за одним столом
• команди, що працюють на різних майданчиках (multi-site teams) - одна команда працює на одному майданчику, а інша команда - на іншому майданчику.

По-друге, спостереження та керівництво:

• Розпорошена команда рідко є справжньою командою; це, швидше за все, слабко пов'язані між собою групи людей. Тертя в комунікації та координації вищі, і вони рідко стають єдиною командою.
• Коли ваша продуктова група налічує 50 або 500 осіб, розпорошені команди не потрібні. Кожну команду з семи осіб можна легко розмістити в одному приміщенні. Однак деякі команди можуть працювати на різних майданчиках, тож продуктова група може мати команди, що працюють на кількох майданчиках. Розпорошені команди зазвичай є результатом поганих організаційних рішень і незнання того, скільки коштує відсутність спільного розташування команд. (Правило: Кожна команда є (1) самокерованою, (2) крос-функціональною, (3) спільною та (4) довготривалою).

Величезна історія LeSS: Багатопрофільні команди (LeSS Huge Story: Multi-Site Teams)

Порша є власником продукту для нової області вимог у системі торгівлі цінними паперами. Новий напрямок починався лише з однієї команди для фокусування та простоти. Через кілька спринтів до команди Порши додалася третя команда. Перші дві команди базуються в Лондоні разом з нею. Але її третя нова команда, HouseDraculesti, базується в Клужі, Румунія, на головному місці розробки компанії.

Чому б не додати третю команду з лондонського офісу? Це дозволило б уникнути багатьох ускладнень і втрат ефективності, які можуть виникнути через розробку на декількох майданчиках в межах однієї території - витрати потенційно настільки високі, що додавання команди може фактично призвести до видалення команди.

Але позитивним моментом у цьому випадку є те, що Клуж знаходиться лише у двох часових поясах від Лондона, і всі там добре розмовляють англійською. І всі вони - сильні розробники з дипломами з комп'ютерних наук, які живуть у місті, де цінують довгострокову і практичну інженерну майстерність. Крім того, це спеціальний внутрішній сайт компанії для розробки, тому це досвідчені внутрішні команди, які мають глибокі знання про продукт і домен.

І насамкінець, Пріті (Product Owner) не хотіла, щоб жодна з інших лондонських команд переходила зі своїх поточних напрямків.

Пріті знала, що для Порши команди, які працюють на декількох майданчиках, є новою ситуацією, тому на наступній зустрічі вона сказала: "Будь ласка, попросіть вашого скрам-майстра поговорити з Сітою, а також попросіть Сіту провести коучинг на деяких ваших заходах. Вона скрам-майстер з обслуговування активів, і вона спостерігала за їхньою ситуацією з декількома майданчиками протягом декількох років. Вона знає, наскільки важливо, щоб Scrum-майстри працювали разом зі своїми командами, і вона допомогла провести багато зустрічей на різних майданчиках".

Пріті продовжила: "Крім того, у нас був надзвичайно прибутковий рік, тому я надаю фінансування для вас і команди Zombies - принаймні для тих, хто може подорожувати, - щоб провести спринт у Клужі якомога швидше. Працюйте з ними в тісній співпраці, всі в одній кімнаті. Команда Клужа могла б приїхати сюди, до Лондона, але ви хочете послати сильний сигнал, що вони важливі, на їхньому місці. Намагайтеся не дати їм відчути, що Лондон важливіший за Клуж. І ви захочете регулярно приїжджати сюди кожні кілька місяців".

Планування багатопрофільного спринту, частина перша (Multi-Site Sprint Planning Part One)

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

Усі представники команди мають із собою планшети або ноутбуки.

Порша починає. "Ласкаво просимо і давайте почнемо. Мої пропозиції для цього спринту висвітлені у спільній таблиці. Ви всі її бачите? Думаю, ви всі розумієте, чому саме ці теми і пріоритети, оскільки ми обговорювали це в РОР, і це відображає ваш і мій внесок. Але, будь ласка, запитуйте знову, якщо вам потрібні роз'яснення. Крім того, вам пропонується вписати імена ваших команд поруч з потрібними пунктами".

Після цього група вступає у фазу запитань і відповідей, щоб завершити роботу над питаннями, які залишилися. Представники Лондона прикріплюють кілька аркушів для фліпчарту і починають писати запитання. Члени команди з Клужу записують свої запитання на окремих аркушах спільної таблиці. Порша проводить деякий час біля різних паперових фліпчартів, обговорюючи відповіді та роблячи замальовки на папері. А вона проводить деякий час за електронною таблицею, вводячи відповіді для команди Клужу, одночасно розмовляючи з ними віч-на-віч під час відеосесії.

Приблизно через 30 хвилин окремі питання були вирішені, і Порша просить усіх зібратися разом. Вона каже: "Чи є якісь проблеми або питання, які ви хотіли б обговорити разом, перш ніж ми завершимо?"

Загальний PBR для кількох об'єктів (Multi-Site Overall PBR)

Люди заходять до майстерні в Лондоні для проведення багатосайтового PBR. Встановлено два проектори. Один показує відео сесії воркшопу в Клужі. На іншому - браузер на комп'ютері Порції.

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

Використовуючи інтелект-карту, графічний інструмент на основі браузера, Зак починає створювати кілька гілок, обговорюючи їх з групою.

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

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

Кінець (The End)

Кілька ключових моментів з історії про мультисайтів в LeSS Huge:

• Багатосайтові команди часто створюють як очевидні, так і приховані тертя та витрати, які є напрочуд великими за своїм негативним впливом.
• Якості, які зменшують тертя з іншим сайтом, включають схожий часовий пояс, внутрішній виділений сайт (не аутсорсинговий), розробників, які вільно розмовляють однією мовою, місце розташування і культуру, яка високо цінує довгострокову практичну досконалість розробників.
• Скрам-майстер повинен жити разом зі своїми командами.
• На кожному майданчику скрам-майстер повинен відчувати себе рівним, а не громадянином другого сорту.
• Команди повинні регулярно відвідуватися і взаємозапилюватися.
• На зустрічах прагніть працювати віч-на-віч з відеоінструментами.
• Використання інструментів спільного доступу до документів полегшує спільну і одночасну модифікацію артефактів.

Вперед (Onwards)

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

Далі йдуть основні розділи про більш клієнтоорієнтований продукт та спринт у простішій LeSS-організації.