Чому Посібник зі Скраму так рідко оновлюють

Щастя-здоров’я. Мене звати Богдан. Працюю в ІТ останні 10 років, 9 з яких зі Скрамом. Починав як розробник, далі — скрам-майстер, продакт-овнер/менеджер та аджайл-коуч. Сьогодні — Professional Scrum Trainer у компанії Scrum.org та Senior Agile Coach у компанії EPAM. Відданий та палкий фанат Брюховицьких чебуреків.

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

Запитання без відповіді

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

Серед багатьох запитань до учасників дискусії було одне, що не на жарт мене зацікавило: «Які аргументи Ви можете навести проти використання Скраму?». Проте цей епізод я так добре запам’ятав не через запитання, а через відповідь на нього: «Немає сенсу використовувати те, що з одного боку „продають“ як гнучкий підхід, а з іншого — оновлюють лише раз на три роки».

Чесно кажучи, на той час така відповідь мене дещо збентежила, оскільки я ніколи раніше не замислювався про Скрам з цієї точки зору. А й справді, чому зміни до Посібника зі Скраму вносять настільки рідко? Єдине, з чим я міг їх порівняти — це оновлення SAFe-у. Останній, до слова, оновлювався частіше, ніж Тейлор Свіфт чи Ед Ширан випускали новий альбом. Тож на той час у мене цілком логічно склалося враження, що теоретична частина в основі Скраму недостатньо часто вдосконалюється та переосмислюється. Оскільки питання було цікавим, проте нетерміновим, то я залишив його десь у потилиці чекати більш сприятливих обставин.

Відтоді минуло трохи часу і я мав нагоду суттєво краще довідатися про Скрам: дедалі більше використовував його, обіймаючи різні посади; читав актуальні галузеві книги та статті, розширюючи горизонти; відвідував тренінги та конференції вже як доповідач; навіть подкаст започаткував (у лютому плануються 2 нових епізоди). Все це дозволило заповнити чимало прогалин, змінити ставлення до певних аспектів використання фреймворку та намацати речі, про існування яких я раніше навіть не здогадувався. Відповідь на запитання з попереднього абзацу теж почала вимальовуватися, радше її обриси. Впевненості у правильності ходу думок на 100% ще не було. Проте щонайменше дві речі стали очевидними на цьому етапі.

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

До чого тут Starcraft

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

Дещо згодом (від 30 хвилин до 6 годин потому) я натрапив на відео, яке описувало одну з найбільш знакових подій в історії Starcraft Brood War. Відео розповідало про матч 2007 року між двома професійними гравцями з Південної Кореї: Bisu і Savior. І перш ніж продовжити історію, мені потрібно додати кілька важливих і не дуже деталей, аби все це хоч якось трималось купи в очах читачів, що не є поціновувачами відеоігор.

Зображення взяте у TL.net

Першою і, певно, найменш важливою деталлю, є величезна значимість відеоігор у Південній Кореї. Для них це не віртуальний чи дитячий спорт, а майже релігія. Фінал чемпіонату з популярного кіберспорту — це не менша подія для пересічного південнокорейця, ніж фінал Ліги чемпіонів УЄФА для пересічного європейця. Як доказ наведу лише один приклад: якось під час чемпіонату світу з футболу до роздягальні південнокорейської чоловічої збірної завітали найкращі професійні гравці у Starcraft, аби підняти моральний дух команди та налаштувати на перемогу. Футболісти шанували їх як своїх національних героїв.

По-друге, щодо власне гри, то в ній доступні усього три можливі раси, з-поміж яких гравець може обирати: Террани, Зерги та Протосси. Кожна з них має унікальний набір інструментів, тактик, стратегій та сильних/слабких сторін. З моменту виходу в 1998 аж до 2007 року у грі налічувалось лише три великих оновлення, що мали вагомий вплив на ігровий баланс. Три основні суб’єкти та лише 3 оновлення протягом майже десятиліття — нічого вам не нагадує?

Зображення взяте у Blizzard Entertainment

Звідки беруться геймченджери

У 2007 році поєдинок Протоссів проти Зергів, відомий ще як PvZ, вважався заздалегідь програшним для перших. Статистичні дані свідчили, що гравці за Зергів вигравали близько 53% усіх ігор, з іще вищими показниками на професійному рівні, де помилки та відхилення від оптимальних стратегій були рідкістю. Природно, Bisu, котрий грав за Протоссів, перед матчем вважали аутсайдером. Однак він використав несподівану та інноваційну стратегію, над якою працював довгий час, і виграв матч з рахунком 3:0. Цей поєдинок став настільки знаковим, що за одну ніч змінив хід PvZ протистояння назавжди, зробивши Протоссів фаворитами. Тож як Bisu зміг цього досягти? Майстерність і, головне, час!

Задоволення приходить від уміння, а точніше — від результативного навчання. Ми найчастіше тішимось тоді, коли навчились робити те, чого раніше не вміли, нерідко вкладаючи у це чималі зусилля. Незалежно від того, чи запитаєте Ви Дена Пінка, шахіста, що є міжнародним гросмейстером, чи підлітка, котрий грає у Mortal Kombat, оволодіння своїм «ремеслом» — це найкращий спосіб втілити в життя такі «ого-го» моменти (як це зробив Bisu, змінивши гру назавжди), про які ви ще довго будете згадувати і розповідати. Хоча цей момент і триває недовго, але час, вкладений в нього, зазвичай вимірюється місяцями або роками. Сотні і тисячі годин наполегливої, невтомної роботи, невдач і повторних спроб залишаються за лаштунками. Тож тепер для мене стало очевидно, що навіть у середовищі, здавалося б, зрозумілому та статичному (як то комп’ютерна гра категорії AAA із трьома великими оновленнями протягом 10 років), дивовижні та інноваційні речі не лише можуть відбуватися, а й відбуваються.

Чому ж Скрам змінюється так повільно

Тут вже настав час повернутися до розмови про Скрам. Якщо абстрагуватися від розробки ПЗ, спринтів, артефактів та решти, то можна перестати думати про Скрам як про фреймворк і почати сприймати його як продукт, яким доволі успішно користуються понад 10 мільйонів людей. Це — чимала аудиторія, яку не хочеться розчаровувати. Безумовно, не варто поспішати вносити у такий продукт зміни без достатньо зваженого попереднього аналізу. Бо тим самим ви ризикуєте не бути в стані передбачити, який вплив ці зміни матимуть, і врешті-решт ще й розчарувати мільйони людей, які використовують ваш продукт (грають у вашу гру). Тож співавторам Посібника зі Скраму доводиться ухвалювати зважені та обґрунтовані рішення щодо деталей кожного нового оновлення. Але скільки часу знадобиться, щоб упоратися із цією непростою задачею? Можемо спробувати оцінити.

Розглянемо як приклад останнє оновлення Посібника зі Скраму від 2020 року. Командам, що вже використовують Скрам, знадобиться чимало спринтів, аби опанувати нові речі, як-от ціль продукту, Зобов’язання (Commitments) щодо Артефактів, перенесення відповідальності за Визначення Готового (Definition of Done) та створення придатного до використання Інкременту на плечі усієї Скрам-команди. Від себе можу додати, що минуло вже більше року, а нашій команді вдалося реалізувати ці речі лише на базовому рівні. Ми й далі активно оптимізуємо процес розробки, аби досягти кращих результатів. Тож в середньому знадобиться від декількох місяців до року, щоб Скрам-команда набила достатньо гуль і була в змозі оцінити вплив останніх змін, мати можливість поділитися набутим досвідом з іншими, надати зворотній зв’язок співавторам Скраму.

То були команди, що вже досить довго варяться у Скрамі та їхнє сприйняття змін. Свіжа точка зору від людей ззовні може мати не меншу цінність. Проте скільки часу знадобилося б команді, що лише почала використовувати Скрам, аби досягти принаймні базового (механічного) рівня процесу? А скільки часу мине, перш ніж все працюватиме настільки злагоджено, що команда матиме шанс дістатися до «ого-го» моменту, яким варто буде поділитися зі спільнотою? Ймовірно, роки. Не забуваймо, що після всього вищесказаного відгуки від таких команд мають бути зведені докупи, перетравлені та проаналізовані, аби дозволити співавторам отримати якісно кращу, нову версію. Таку, що з більшою ймовірністю матиме позитивний вплив на Скрам-спільноту. Наостанок зауважу, що версія Посібника зі Скраму від 2020 року була переглянута не менше 15 разів, перш ніж побачила світ. Майже всі хороші речі потребують часу.

Замість висновку

Отже, маємо те, що маємо. Якщо тепер хтось запитає мене, чому Посібник зі Скраму оновлюють так рідко, то я відповім, що це через те, що у 2007 році Протосси почали перемагати Зергів у Starcraft. Чесно кажучи, мене ця відповідь влаштовує. А вас? Буду радий побачити ваші думки та відгуки у коментарях.