Специфіка роботи Agile-команди в SAFe відносно Scrum на практиці

Після публікації серед друзів першої статті про Burn Down Chart, у коментарях перше питання, яке було задане: "Було б цікаво дізнатися докладніше про ваш досвід із SAFe". Тому в цій статті я постараюся розкрити специфіку роботи в SAFe відносно Scrum на нашій практиці. Я точно не претендую на істину в першій інстанції і буду радий будь-яким виправленням і уточненням з боку колег.

Спочатку перелічу тезово найголовніше, що відрізняє роботу в SAFe від SCRUM, на мій погляд.

• Increment у Scrum і Program Increment у SAFe
• ART - Agile Release Train
• Кількість взаємодіючих команд
• PIPE
• SOS
• PO - не власник бізнесу
• RTE
• П'ятий спринт для навчання
• System Demo

Increment у Scrum і Program Increment у SAFe. Насправді різні терміни, але в них легко заплутатися, оскільки ніхто не використовує в нас термін Program Increment, усі кажуть просто Increment - а це вже інший термін, який використовується в SCRUM. Але загалом вони досить схожі з точки зору сенсу, на мій погляд. Increment у SCRUM - це по суті поточний продукт + заплановані історії на спринт у виконаному стані (що пройшли DOD команди). Program Increment - це часовий інтервал, протягом якого поїзд (Agile Release Train) доставляє інкрементальну цінність у продакшн. За тривалістю в нас це 4 спринти по 2 тижні на розробку і один спринт на навчання.

Agile Release Train - це команда команд, що працюють над одним потоком створення цінності. Ми це називаємо просто поїздом, але за фреймворком правильно це називати "Solution". У нашому випадку це правило не повністю дотримується і команди часто працюють над різними продуктами з технічної точки зору, оскільки більшість бізнес-фіч реалізується комплексно і зачіпає кілька продуктів. Це з технічного боку. Але, впевнений, що хтось вважає всі it-системи одним продуктом компанії і, можливо, так навіть правильніше.

Кількість взаємодіючих команд у нас у SAFe суттєво більша, в сумі рекомендується до 125 осіб в одному поїзді. У нас 3 поїзди і не в кожному це правило дотримується, є поїзди з кількістю понад 125 осіб. SCRUM не описує як взаємодіяти з іншими командами, наскільки мені відомо, на відміну від SAFe, де є дуже чіткі рекомендації щодо цього. Найяскравіший, на мій погляд, артефакт для цього - це Program Board.

На ньому відображаються взаємозв'язки між командами поїзда і, обговорюючи його, проходять щотижневі заходи Scrum Of Scrums (SOS) у нас.

Приблизно кожні 2,5 місяця (кожні 5 спринтів) відбувається подія PIPE - Programm Increment Planning Event. Це коли всі розподілені команди збираються в одній залі на 2 дні і планують свої роботи на наступні 2,5 місяця. У процесі цього заходу з'являються такі артефакти, як Program board, наприклад, на якому відображаються всі залежності команд між собою для кожного з поїздів, вище я вже показав як він виглядає. Завданням Скрам Майстра кожної команди на цьому заході є фасилітація виявлень максимальної кількості залежностей, потім за можливості, їх видалення (шляхом передачі компетенцій усно, наприклад, від команди команді або шляхом забирання залежності від однієї команди в іншу, щоб команда могла автономно реалізувати свою фічу ні від кого не залежачи). На практиці це в нас так і відбувається. Спочатку декомпозуються фічі на User Story, User Story розкидаються по 4 спринтах. Фічі розміщуються на Program Board і виставляються залежності від інших команд які є. Протягом заходу це обговорюється, коригується.

SOS - Scrum Of Scrum. Цей захід проходить раз на тиждень для кожного поїзда окремо. Скрам Майстра всіх команд поїзда збираються онлайн, транслюється Program Board поїзда і обговорюються статуси всіх залежностей і фіч команд конкретного поїзда. По суті цей захід необхідний для централізованої синхронізації команд усередині поїзда. Щось на кшталт стендапу, але раз на тиждень і не для команди, а для Скрам Майстрів.

PO (Власник продукту) - не власник бізнесу. Є Product Manager - він працює з Bussiness Owner'ами відповідних напрямів бізнесу і по суті роздає фічі Власникам продукту. Власник продукту працює вже безпосередньо в команді - б'є фічі на User Stories (у нашому випадку спільно з командою) і не завжди б'є, але ми постійно прогресуємо в цьому напрямку.

RTE (Release Train Engineer - машиніст потяга. Скрам Майстер Скрам Майстрів. Проводить заходи SOS свого потяга. Взаємодіє з Product Manager'ом на рівні фіч. Фасилітує PIPE.

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

System Demo. В результаті PIPE у кожної команди є список цілей на інкремент і кожна з цих цілей оцінена Buisseness Owner'ом потяга за 10-бальною шкалою. Це називається Business Value. Цілі ці діляться на основні та розширені. Основні цілі - це цілі, в яких команда не бачить жодних ризиків у досягненні. Розширені - це цілі з ризиками досягнення. Всі цілі обов'язкові і обсяг робіт планується під всі цілі. На System Demo Business Owner приймає результати роботи за інкремент. Припустимо, у команди було 3 основні цілі з оцінками 10, 6, 8 і 2 розширені з оцінками 10, 3. Уявімо, що Business Owner поставив відповідно оцінки такі: 8, 6, 4, 2, 0. Тепер можна порахувати відсоток досягнення цілей: за 100% береться початкова сума балів за основні цілі, в нашому випадку це 10+6+8=24. Досягнуті бали рахуються з урахуванням розширених цілей(тобто 20 з 24 команда досягла), тобто в результаті відсоток досягнення цілей у команди буде (20*100)/24 = 83,3%. Нормальним результатом вважається досягнення від 80% до 100%.

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

Коментарі колег з facebook

«Женю, привіт! Круто, що пишеш, молодець! Трохи поправлю про потяги - збираються вони не навколо продукту, а навколо потоку створення цінності. А в роздрібі у нас з точки зору SAFe не потяг, а Solution. Просто для зручності комунікації та спрощення розуміння ми продовжуємо називати це потягом)»

– Костянтин Воронін (представник проектного офісу Інгосстраху)

«Ну і може хтось помітить, що з точки зору SAFe оцінка цілей проходить на I&A; (куди SD входить як частина, але напряму з оцінкою не пов'язаний) а самі SD мають проходити кожен спринт (після демо команд). Але ми поки від цього далекі, тому усвідомлено називаємо все як написано у тебе в статті)»

– Костянтин Воронін (представник проектного офісу Інгосстраху)

«Женю, продовжуй, будь ласка, дуже корисно!»

– Олексій Іонов (Сертифікований тренер з SAFe)