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 у команді. Раніше було чітко вказано, що для оптимальної співпраці команда розробки має складатися із 3-9 людей. Зараз же зазначено лише те, що Scrum Team зазвичай складається з 10 чи менше осіб. Але це як рекомендація.

У новій версії автори ставили собі за мету елімінувати концепцію, що сформувалася у багатьох 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. Чи схвалюєте ви вищезгадані зміни? І чому? Заздалегідь дякую за відгуки.

Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.

👍НравитсяПонравилось0
В избранноеВ избранном4
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


26 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Скрам нужен не только разработчикам. Нас вот коллектив оракловцев на проекте, тоже по скраму работаем.

Сначала сам смотрел на это как на тех, кто стучится в двери и предлагает поговорить о боге. Но потом начал понимать, что смешно это пока ты в одно рыло пялишься в монитор. А когда смотришь на проект сверху, то уже не до смеха.

И как только взял на себя роль скрам-мастера, то видишь как и зачем соединять усилия. Иначе все будут постоянно идти вперёд, без конечной цели, просто потому что движение вперёд оплачено по часам.

Как по мне, перебор это только ежедневные дейли.

Но справедливости ради — в разгар пандемийских сокращений, первыми под нож пошли всякие коучи )

я вот ваще хз чем все эти люди занимаются с этими скрам фреймворками :) работа о работе

Благодарю за статью и краткое, четкое изложение основных изменений:)

Имхо лучший фреймворк — пиши код б***ь. Остальное — цирк чтоб дать погонщикам видимость контроля.
macode.ru

Детский сад
Ограниченный инфантильный взгляд на деливери софта состоящей только из 1 активити — написание кода — наиболее точно показывает зачем придумывают эти самые 101 методологии для команды (ключевое слово тут)

Не все работают в аутсорсе, где нужно каждые 2 недели отчитаться что заделиверили за оплаченные человеко-часы.

Везде где есть команды — нужна интер и интра- синхранизация и управление этими командами
Про то, какие девелоперы все самоорганизованные и умеющие в коллективное деливери — мы уже тут много раз слышали, на словах то конечно))
Хз, при чем тут аутсорс

Я не говорю, что управлять командами вообще не надо. Я к тому, что фарс в виде дейли стендапов, кучи бесполезных митингов, на которых qa и дизайнеры выслушивают про проблемы бекенда и двигания тасков по доске вовсе не обязателен. Как и скрам мастера и им подобные должности. Про группировку кусков работы в спринты — моё ИМХО, что это надо исключительно чтобы обезопасить себя перед заказчиком, тем что взять минимальный объём работы на это время и снизить риски, что «заделиверить» не успеют. Заказчик ведь расстроиться.

Тоесть, тебе не нравится скрам, но ты согласен что какая-то методология управления командой и разрабрткой нужна, ничего не имею против
Это совсем не похоже на дайтекодитьманифест

это надо исключительно чтобы обезопасить себя перед заказчиком, тем что взять минимальный объём работы на это время и снизить риски, что «заделиверить» не успеют. Заказчик ведь расстроиться.

Так «заказчик» есть на абсолютно любом проекте и в любом типе компании, а не только в аутсорсе. В продукте заказчиком будет тот же самый Product Owner/Manager, что был в аутсорсе, только теперь он сидит с тобой в одном офисе и выдвигает тебе требования и сроки напрямую, а не через галерного ПМа/БА. Понятно, что конечный заказчик не сам PO, а его начальник, который распоряжается бюджетом — как правило какой-нибудь VP.
В стартапах заказчики — это ключевые шейрхолдеры и ранние клиенты/пользователи.
Даже в опен сорсе есть заказчики — другие программисты, которые ждут от тебя багфиксы или новые фичи регулярно и вовремя. И в случае невыполненных ожиданий просто уходят в чей-то форк.

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

В аутсорсе ПО какого дал заказчик, и он может быть без руля и без крыши, а удовлетворить — надо. Поэтому нужна бюрократия.

В общем, скрам.ком двигается по направлению к SAFe скраму, там многое из этого уже давно ввели

Треба бути в тренді пмських штучок :)

Дякую за статтю. Цікаво, чому вибрали саме такий порядок

Why → What → How.

, а не «Why — How — What» (згідно книги «Start with Why»). Є якісь інсайти з цього приводу?

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

Тут мужчина з досвідом детальніше пояснює:
www.youtube.com/watch?v=oeqPrUmVz-o

Богдан, большое спасибо за статью. Ознакомилась со всеми изменениями и поняла, что нужно уже сейчас сдавать сертификат:)

Сколько вам заплатили за написание этой статьи? Только не говорите, что бесплатно эту чушь пропагандируете.

привет) а по какой методике вы работаете на проектах в EPAM?)

В ЕПАМ працюють по різним методикам від класичних Agile практик (Scrum, Kanban) до просунутих таки як SAFe, LeSS, NeXus. Також є проекти з класичними підходами та проекти де ЕПАМ комітається заделіверити проект до певного терміну т.зв. Fixed Price. Завдяки великому портфоліо проектів з якими працюємо виробилися свої традиції і кращі практики як реалізовувати проекти відповідного до вимог замовника.
Останнім часом саме ЕПАМ рекомендує замовникам використовувати ту чи іншу методологію розробки для досягнення результату.

Я думаю вопрос был лично ко мне. Ежу понятно, что у нас при желании можно найти проект на любой методологии

так гражданін скруммастер со стажем. ему нада продаваться. для продаваться нада рекламироваться. вот и пишет.

Де ви побачили пропаганду? Patch notes, виходить, — теж пропаганда?
Стверджувати, що один фреймворк гірший за інший, — то як говорити, що викрутка гірша, ніж молоток. Це різні інструменти, що краще чи гірше служать для вирішення конкретних задач.

Богдан, вот вы и узнали мнение из комментария Егора))).
Если серьезно — спасибо за статью, без воды по делу об изменениях

Подписаться на комментарии