Scrum

Що насправді дає Scrum

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

Scrum — це фреймворк, тобто невеликий набір правил про те, як команда себе організовує, і не більше. Він визначає рівно три речі: три зони відповідальності, три артефакти й п’ять подій. Це вся офіційна специфікація, і вона вміщається в документ приблизно на тринадцять сторінок.

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

Спринт: серцебиття команди

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

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

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

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

Кожна церемонія по черзі

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

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

Kick-off — один раз, на самому початку

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

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

Kick-off зазвичай триває від двох годин до цілого дня — залежно від того, скільки всього нового. Присутні всі: уся команда, Product Owner, Scrum Master і ключові стейкхолдери. Це та єдина зустріч, де забагато людей у кімнаті краще, ніж замало.

Планування спринту — відкриває кожен спринт

Планування — це зустріч, де команда вирішує, що робитиме в наступному спринті. Це одна з п’яти офіційних подій, і вона по черзі відповідає на три питання.

• Навіщо цей спринт? Команда узгоджує Sprint Goal — одне речення про те, що зміниться наприкінці.
• Що ми можемо зробити? Команда обирає з беклогу задачі, які служать цій цілі, і рівно стільки, скільки реально встигне.
• Як ми це зробимо? Розробники розкладають обрані задачі на конкретні кроки — ця частина належить команді, а не Product Owner.

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

Daily Scrum — п’ятнадцять хвилин щодня

Daily Scrum — коротка зустріч у той самий час і в тому самому місці кожного робочого дня. П’ятнадцять хвилин, у багатьох командах стоячи, і обов’язкова присутність лише розробників.

Її призначення часто розуміють неправильно, тож будьмо точними. Daily Scrum — це не звіт про статус для керівника. Це команда, яка сама між собою переплановує наступні двадцять чотири години на основі того, що дізналася вчора. Питання, на яке вона відповідає: враховуючи те, де ми зараз, який найшвидший шлях до Sprint Goal сьогодні?

Брейншторм — коли команда впирається в невідоме

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

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

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

Презентація — знайомство команди з новою роботою

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

Спочатку ця зустріч односпрямована: Product Owner пояснює бізнес-потребу, хто її попросив, яку проблему вона розв’язує і як виглядатиме успіх. Далі вона перетворюється на розмову. Розробники ставлять питання, що виявляють приховану складність — «а на наявних користувачів це теж поширюється?», «що станеться, якщо оплата зірветься посередині?» — і ці питання часто змінюють вимогу ще до першого рядка коду.

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

Backlog Refinement (грумінг) — тут відбувається оцінювання

Refinement — багато команд досі кажуть «грумінг», це стара назва — це робоча сесія, де беклог доводять до готовності. Product Owner, Scrum Master і розробники сідають разом, беруть задачі, які раніше презентували й декомпозували, і роблять із ними три речі.

• Уточнюють — усе досі неоднозначне фіксують, і пишуть критерії приймання: конкретні перевірки, за якими вирішується, чи задача готова.
• Ділять — усе, що завелике, щоб завершити за один спринт, розбивають далі.
• Оцінюють — команда призначає кожній задачі розмір, щоб Product Owner міг упорядкувати беклог, знаючи ціну кожного варіанта.

Саме на оцінюванні зазвичай з’являється покерне планування. Кожен приватно обирає число з обмеженого набору — найчастіше 1, 2, 3, 5, 8, 13 за послідовністю Фібоначчі — і всі відкривають одночасно. Числа означають відносний розмір, а не години: 8 — це приблизно вдвічі більше роботи, ніж 5, а не вісім годин друкування.

Цінність одночасного відкриття не в числі. Вона в розбіжності. Коли одна людина каже 2, а інша 13, вони сперечаються не про арифметику — вони по-різному розуміють задачу, і саме подальша розмова є сенсом усієї вправи. Число, на якому зійдеться команда, важить значно менше, ніж непорозуміння, яке воно виявило.

Покерне планування не є обов’язковим. Деякі команди використовують розміри футболок (S, M, L), деякі взагалі не оцінюють розмір, а спираються на виміряну пропускну здатність. Усе це працює. Не працює лише пропуск самої розмови.

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

Review спринту (огляд) — показуємо результат

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

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

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

Ретроспектива — завершення спринту

Ретроспектива — остання подія спринту, і вона про команду, а не про продукт. Огляд питав «чи те ми побудували?»; ретроспектива питає «чи так ми працюємо?».

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

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

Усі церемонії одним поглядом

Ось увесь набір в одному місці. Права колонка позначає, які з них є частиною офіційного Scrum Guide, а які реальні команди додають, — цю різницю варто знати перед співбесідою чи аудитом.

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

Три ролі

Scrum визначає три зони відповідальності. Офіційна назва — «accountabilities», а не ролі, і різниця мала, але справжня: це те, за що людина відповідає, а не посада в контракті.

• Product Owner — що

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

• Scrum Master — наскільки добре

  Допомагає команді працювати ефективно. Усуває перешкоди, захищає спринт від переривань, коучить. Не роздає задачі й не звітує статус нагору.

• Розробники — як

  Усі, хто створює інкремент, незалежно від спеціальності — бекенд, QA, дизайн. Вони обирають технічний підхід і спільно відповідають за результат.

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

Три артефакти

Артефакт у Scrum — це просто те, що команда веде й на що дивиться. Їх три, і кожен несе зобов’язання — супровідне твердження, яке перетворює список на щось вимірюване.

Definition of Done вартий окремої уваги, бо саме його команди найчастіше лишають розмитим. Це записаний чекліст, що застосовується до кожної задачі: код відрев’ювано, тести написані й проходять, розгорнуто на staging, документацію оновлено — усе, чого справді потребує ваша команда. Якщо це не записано, «готово» означає для кожного трохи різне, і ця різниця спливає в найгірший момент.

Scrum чи Kanban?

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

А якщо вам хочеться обох — ритму Scrum із гнучкістю Kanban — у цього поєднання є назва й окрема сторінка: Scrumban.

Як це виявляється в реальній поставці

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

Де він вироджується

• Definition of Done, що не доходить до готовності до деплою, — «завершена» робота потім усе одно потребує стабілізаційного спринту.
• Немає refinement — і кожне планування перетворюється на чотиригодинну спробу зрозуміти роботу.
• Product Owner без реальних повноважень — порядок беклогу задає той, хто гучніше ескалював.
• Спринти лише як ритм звітності, тоді як релізи лишаються квартальними, — словник без циклу.
• Velocity як показник продуктивності — це надійно роздуває оцінки, а не результат.

Коли це застосовувати

Пов’язані сторінки

• МенеджментAgileAgile — це спосіб створювати софт, який припускає, що ви в чомусь помиляєтесь, і планує дізнатися про це рано. Agile не є процесом, який «встановлюють», і не є набором зустрічей — це невелика група переконань, записаних 2001 року, на яких побудовано з десяток різних методологій. На цій сторінці ми розберемо ці переконання, усі дванадцять принципів за ними і те, що насправді змінюється в команді, яка сприймає їх серйозно.
• МенеджментKanbanKanban — це спосіб керувати роботою, який починається з наявного процесу й покращує його під вимірюванням. Kanban не додає ні ролей, ні спринтів. Він додає одне правило — обмеження кількості задач, над якими можна працювати одночасно, — і саме це обмеження змушує працювати все інше в методі. На цій сторінці ми розберемо дошку, метрики, сім регулярних зустрічей, які метод визначає, і те, як на практиці встановити це обмеження.
• МенеджментScrumbanScrumban — це ритм Scrum із механікою витягування Kanban. Ви зберігаєте ритм планування й ретроспективу, прибираєте зобов’язання спринту й поповнюєте дошку, коли вона порожніє, а не за календарем. Більшість команд, які кажуть «у нас Scrum, але гнучкий», описують саме це — і правильна назва перетворює тиху ерозію Scrum на свідому конструкцію.