Scrum

Scrum на одному екрані

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

Таймбокси — це максимуми з Guide для місячного спринту. Цифри для двох тижнів після скісної риски — звичайна пропорційна практика, а не правило: Guide каже лише, що для коротших спринтів події зазвичай коротші.

І решта фреймворку: три зони відповідальності й три артефакти — кожен зі зобовʼязанням, яке перетворює список на щось вимірюване.

На чому він тримається: емпіризм

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

Guide називає для цього три опори, і вони залежать одна від одної по черзі. Прозорість робить можливою перевірку; перевірка робить можливою адаптацію. Словами самого Guide, перевірка без прозорості вводить в оману й марнує час, а перевірка без адаптації безглузда.

Кожна подія — це формальна нагода перевірити одне й адаптувати інше. Схема показує артефакти як конвеєр — Product Backlog, Sprint Backlog, інкремент — з подіями на ньому як точками перевірки та зобовʼязанням під кожним артефактом.

Пʼять цінностей

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

Кожна подія по черзі — і чотири, які додають команди

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

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

Спринт — контейнер для решти чотирьох

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можливо, ви знаєте три питання — що я зробив учора, що робитиму сьогодні, чи щось мені заважає. Вони завжди були лише прикладом. Guide 2017 року зробив їх необовʼязковими, а Guide 2020 року прибрав зовсім, бо, зачитувані по черзі кожним, вони перетворювали подію саме на той звіт про статус, який вона мала замінити.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Три зони відповідальності — і чому межа десятеро

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

• Product Owner — що

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

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

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

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

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

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

Тепер розмір. Guide каже, що Scrum-команда — це зазвичай десятеро або менше людей, і в ці десять входять Product Owner і Scrum Master. Причина тут в арифметиці, а не в смаку.

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

Коли команда переростає цю межу, відповідь Guide — не одна більша команда. Це кілька згуртованих Scrum-команд зі спільними Product Goal, Product Backlog і Product Owner — саме це по-своєму формалізують Nexus, LeSS і Scrum@Scale.

Definition of Done — і де вона зупиняється

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

Guide тут суворий. Щойно задача відповідає Definition of Done, народжується інкремент. Задачу, яка їй не відповідає, не можна релізити й не варто навіть показувати на огляді; вона повертається в Product Backlog. Якщо в організації є своя Definition of Done, кожна команда застосовує її як мінімум; якщо немає — команда мусить написати власну.

Найважливіше — де вона зупиняється. Схема показує ті самі шість спринтів за двох визначень: одне закінчується на «змерджено», інше — на «можна релізити».

Scrum чи Kanban?

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

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

Пʼять задокументованих епізодів — і правило, яке кожен перевірив

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

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

Чесна межа: Scrum робить проблеми видимими за спринт — і не розвʼязує жодної з них. Команда без інженерної практики, Product Owner без повноважень чи організація, яка не вміє релізити, бачитимуть ці проблеми кожні два тижні, чітко, стільки, скільки працюватимуть за Scrum, — і ніщо у фреймворку їх не виправить. Так задумано, і саме тому «Scrum у нас не спрацював» так часто означає «Scrum показав нам щось, із чим ми нічого не зробили».

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

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

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

• МенеджментAgileAgile — це чотири цінності й дванадцять принципів розробки софту, записані 2001 року, які ставлять навчання на робочому продукті вище за дотримання плану. Це не методологія: Scrum, Kanban і Extreme Programming — методології, збудовані поверх нього, — і власних зустрічей, ролей чи артефактів у нього немає. Сторінка починається з Маніфесту повністю, пронумерованого, щоб на рядок можна було послатися; далі — шар, який він займає, на що міняє кожна цінність, ставка на вартість змін, петлі зворотного звʼязку як справжній механізм, кожен принцип як перевірка, яку можна провести у своїй команді, шість програм, долю яких він вирішив, і де все це вироджується в театр.
• МенеджментKanbanKanban — це спосіб керувати роботою, який починається з наявного процесу й покращує його, обмежуючи незавершену роботу й вимірюючи, як вона тече. Він не додає ні ролей, ні спринтів. Сторінка починається з усіх елементів Kanban-системи на одному екрані — що команда записує і як виглядає відсутність кожного; далі — чому дошка сама по собі ще не Kanban і хто визначає метод, шість принципів і шість практик, чотири метрики потоку й арифметика під ними, прогноз з історії замість оцінок, сім ритмів, пʼять задокументованих випадків і де все це вироджується.
• МенеджментScrumbanScrumban — це спосіб організувати роботу команди, який зберігає зустрічі Scrum, а зобовʼязання спринту замінює лімітами WIP із Kanban і плануванням на вимогу. Назву 2008 року придумав Корі Ладас для шляху від Scrum до безперервної поставки; сьогодні більшість команд називає так сталий гібрид. Сторінка починається з кожного елемента Scrum і того, що з ним стає; далі — навіщо гібрид існує, два значення слова, три числа, які його визначають, як запланована робота й переривання ділять одну дошку, планування далі ніж на два тижні, порівняння з обома батьками й один виміряний перехід, і де все це вироджується.