Scrum Guide помер. Нехай живе Scrum Guide
Вітаю. Мене звати Богдан. Працюю в ІТ останні 9 років, 8 з яких зі Scrum. Спочатку був розробником, потім перейшов на позицію Scrum Master. Протягом останніх п’яти років працював як Product Owner/Product Manager у продуктових компаніях в Україні, Польщі, Німеччині. Сертифікований Scrum Master (PSM III) та Product Owner (PSPO III), нещодавно склав іспит для отримання ліцензії Professional Scrum Trainer від Scrum.org.
Стаття присвячена основним змінам у новій редакції Scrum Guide. Передусім матеріал буде цікавий людям, що працюють у Scrum-командах чи співпрацюють із ними.
Цього року Scrum виповнюється 25 років. Саме стільки часу минуло, відколи Кен Швабер і Джефф Сазерленд уперше формально презентували його на конференції OOPSLA 1995 року.
Ілюстрація Аліни Самолюк
Зміни у Scrum: чому це важливо
Наприкінці цього літа Кен Швабер анонсував у своєму блозі масштабну для Scrum-світу подію: вихід оновленої версії Scrum Guide. Новий документ обіцяли зробити lean and focused і зменшити до 13 сторінок (попередня англомовна версія містила 19). Подія, безперечно, важлива одразу з двох причин.
Перша: зміни у Scrum Guide — рідкісна річ. Востаннє документ змінювали восени 2017 року. Зазвичай нова версія з’являється не частіше ніж раз на два-три роки. Друга: останні зміни зачепили практично всі секції документа, водночас значною мірою це були спрощення та узагальнення, а не уточнення, як зазвичай. Особливо тішить, що світ побачила не початкова версія документа, а виправлена, в котрій були враховані відгуки Scrum-спільноти.
18 листопада відбулась офіційна презентація оновленої версії документа. Звісно, не така масштабна, як презентація нового iPhone, зокрема через те, що Zoom вміщував максимально 1000 користувачів в одній нараді. Окрім привітання та загального тлумачення змін від співавторів (тішить, що дідусі ще живі-здорові), можна було взяти участь у воркшопах та Q&A-сесіях, де пояснювали нові зміни та їхнє прикладне значення. Повний запис трансляції доступний за посиланням.
Зліва — Кен Швабер; справа — Джефф Сазерленд
Що змінилося
Нижче пропоную ознайомитись з основними змінами в документі.
Введення нового поняття Commitment, кристалізація в ньому Sprint Goal та Definition of Done
Попередня версія документа була наскрізь пронизана згадками про Definition of Done та Sprint Goal. Про останню йшлося аж 27 разів. І не дивно, бо це суттєво впливає на всі Events та Artifacts. Проте жодне з понять не було формально визначеним, воно нікуди не належало. У Scrum-спільноті неодноразово лунали пропозиції формалізувати їх, як приклад — долучити до списку Artifacts.
У цьогорічній версії автори вводять нове поняття Commitment (зобов’язання). Тепер кожен зі Scrum Artifacts матиме відповідний Commitment. Тобто кожен артефакт (радше люди, що його творять) охоплюватиме зобов’язання надати інформацію, що підвищує прозорість та фокус, на основі яких можна виміряти прогрес до конкретної цілі.
Commitment для Product Backlog — Product Goal.
Commitment для Sprint Backlog — Sprint Goal.
Якщо коротко, то в обох випадках створення артефакту має бути продиктоване прагненням досягти конкретних цілей, зробити це треба максимально гнучко та ефективно.
Commitment для Increment — Definition of Done.
Кожен інкремент зобов’язаний відповідати всім стандартам якості для продукту. Якщо увесь інкремент чи навіть одиничний елемент Product Backlog не є done, то його не можна ані релізити, ані презентувати на Sprint Review.
Введення нового поняття Product Goal
Нове поняття Product Goal є, на мою думку, найбільш цікавою зміною з усіх. Цитуючи Scrum Guide: «Ціль продукту описує майбутній стан продукту, який може слугувати скрам-команді метою для планування. Ціль продукту висловлена у беклозі продукту. Решта беклогу продукту з’являється, щоб визначити, „що саме“ буде виконувати ціль продукту».
Якщо простіше, то у попередній версії згадувалося, що кожен Increment — це крок у напрямку до певного кінцевого бачення чи цілі. Кен і Джефф вважають, що саме поняття бачення є занадто розмитим, а Scrum передусім є інструментом досягнення конкретних цілей. Звідси й формалізація поняття Product Goal. Згідно із задумом авторів, Product Backlog тепер має будуватися не на абстрактному баченні майбутнього продукту, а на конкретних осяжних цілях.
Scrum Guide умисно не тлумачить жодних додаткових питань довкола цього нововведення, а питань виникає чимало:
- Як саме краще формалізувати Product Goal та моніторити прогрес до неї?
- Наскільки амбітною має бути ціль, щоб шанси її досягти були максимальними?
- Як саме треба оновлювати ціль і Product Backlog, якщо наявна ціль була досягнута (відкинута)?
- За допомогою яких технік досягти прозорості Product Goal?
Автори переконані, що Scrum будується на основі колективного інтелекту людей, які його використовують. Тож відповіді на ці та інші запитання доведеться шукати нам з вами.
Зміни в Scrum Team та акцент на її єдності
Зникло базове поняття «ролі» у скрам-команді, замість неї маємо «сферу відповідальності». Поняття Development Team теж замінили на більш просте — Developers. Прибрали й вимоги стосовно кількості Developers у команді. Раніше було чітко вказано, що для оптимальної співпраці команда розробки має складатися із
У новій версії автори ставили собі за мету елімінувати концепцію, що сформувалася у багатьох Scrum-командах, а саме: «команда в команді» (Development Team y Scrum Team). Нерідко це спричиняло розділення Scrum-команди на «ми» і «вони» між Development Team та Product Owner. Це супроводжувалося взаємними звинуваченнями, було небажаним і контрпродуктивним.
Саме тому формулювання та опис сфер відповідальності у Scrum Team змінили, аби підкреслити, що є лише єдина команда, яка працює над спільними цілями й має три складники: Product Owner, Scrum Master та Developers. Певно, ключовою зміною в цьому контексті є те, що раніше за створення Increment’y відповідала тільки Development Team, а тепер це відповідальність всієї Scrum Team, а не лише розробників.
Крім того, попередня версія Scrum Guide наголошувала на самоврядувальній та кросфункційній Development Team, котра сама обирає, хто і як виконує поставлені цілі. У новій же версії акцент роблять на Scrum Team як на самоврядувальній та кросфункційній одиниці, де люди самі вирішують, хто, як і над чим працюватиме.
Зміни у проведенні Sprint Planning
На додаток до двох наявних логічних частин Sprint Planning What і How вводять нову частину Why, що фокусуватиметься на Sprint Goal. Порядок буде такий: Why → What → How.
Ідея полягає в тому, що під час частини Why Product Owner має запропонувати, як саме продукт може збільшити цінність, яку приносить, упродовж поточного спринту. Далі вся Scrum Team має визначити Sprint Goal, що чітко пояснює стейкхолдерам, чому саме цей спринт є для них цінний.
Звучить дещо формально, проте є додатковою нагодою переконатися, що поточний Sprint Goal спрямований на збільшення цінності. А ще — що Sprint Goal справді крок на шляху до Product Goal.
Менш розпорядчий та більш доступний
Як зауважили автори, упродовж останніх років Scrum Guide містив усе більше вказівок. Версія 2020 має на меті повернути Scrum до першоджерела, коли він був minimally sufficient framework.
Наприклад, було вилучено або спрощено такі частини документа:
- повністю прибрали і без того необов’язкові три питання для Daily Scrum;
- зменшився перелік необхідних атрибутів для елементів Product Backlog;
- вимога додавати найбільш критичні речі зі Sprint Retrospective до наступного Sprint Backlog стала рекомендацією;
- розділ, що стосується скасування спринту, скоротили з 4 абзаців до 1 речення тощо.
З документа вилучили надлишкові та занадто складні мовні конструкції. Крім того, прибрали останні згадки про ІТ (testing, system, design, requirement тощо), оскільки за ці 25 років Scrum вийшов далеко за межі ІТ і успішно застосовується у багатьох інших сферах життя. Як і обіцяли, новий Scrum Guide помістився усього на 13 сторінках.
Оновлена версія Scrum Guide вже доступна як англійською, так і українською мовами.
Замість висновків
Радикальних змін у практичному застосуванні Scrum’у не передбачають. Найбільших труднощів, певно, додасть введення поняття Product Goal та пошук оптимальних технік для її опанування вже в контексті конкретного продукту/команди. Доведеться більше часу та уваги приділити плануванню спринту.
З того, що було анонсовано на одній із сесій, — до кінця року Scrum-сертифікації (як і підготовчі матеріали до них) мали б базуватися на старій версії Scrum Guide. Якщо ви давно хотіли скласти якийсь іспит, то простіше буде зробити це зараз. Інакше доведеться вчити частину матеріалу з нуля (і забути частину того, що вже знаєте!) та бути у першій хвилі, що випробовуватиме на міцність нові набори екзаменаційних питань.
Як і раніше, перші місяці після виходу нової версії Scrum Guide будуть схожими на перші місяці після випуску відеогри: люди ділитимуться досвідом та допомагатимуть одне одному подолати перепони; знайдуться баги та експлойти, котрі ляжуть в основу нової версії. Може, навіть буде як з Diablo II: знайдеться спідранер, котрий покаже, що всю гру можна пройти менше ніж за годину.
І хоча частину про те, що Scrum є «Simple to understand. Difficult to master» прибрали з нової версії документа, проте таким Scrum і залишається. І навіть суттєві зміни та спрощення цього не змінять.
Наостанок цікаво було б почути думки колег з українського ІТ, що теж не перший рік працюють зі Scrum. Чи схвалюєте ви вищезгадані зміни? І чому? Заздалегідь дякую за відгуки.
Щоби не пропустити нові статті Богдана Онищенка — підписуйтеся на нього у телеграм-боті Стрічки DOU.
