Як працює Scrum?

Автор(и): Джей Джей Сазерленд (J.J. Sutherland), фрагмент книги «The Scrum Fieldbook»

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

Власник продукту (PO, Product Owner) відповідає на запитання «Що ми будемо робити?» Під продуктом мається на увазі те, що команда збирається створити та яку послугу або процес представити. Власник продукту отримує дані від користувачів, стейкхолдерів, самої команди та всіх, хто має цінність із діяльності команди. Це можуть бути фермери з Уганди, які постраждали від захворювання сільськогосподарських культур; або інженери, які будують безпілотний автомобіль; або відвідувачі кінотеатру, які йдуть подивитися новий фільм. Власник продукту має зібрати всі вхідні дані, частина яких може бути суперечливою, і створити візію того, що команда робитиме. Потім (це зазвичай найскладніше), після збирання всіх ідей, власник продукту повинен розставити їх у порядку зменшення цінності. У Scrum може бути лише одне пріоритетне завдання на відрізок часу. Це складно забезпечити, але саме так працює методика.

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

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

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

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

Тепер у справу вступає scrum-майстер. Дивна назва посади, чи не правда? Я переконував мого батька, одного із творців Scrum, вибрати інше, щось на зразок коуча. Він сказав мені, що я запізнився і назва вже встоялася у культурі. Надто пізно. Ну що ж. Нині роль scrum-майстра — новинка для більшості компаній. Його завдання — допомогти команді рухатися швидше. Швидкість — ікона, на яку вони моляться.

Навіщо комусь платити за це? Якщо ці люди можуть змусити команду створювати цінність удвічі швидше, вони більш ніж окупаються. Зробити так, щоб поточна команда працювала швидше, завжди краще ніж наймати нових людей. Scrum-майстер допомагає їй нарощувати швидкість (Velocity), і власник продукту відповідає за те, щоб вона перетворювалася на цінність. Немає нічого більш сумного, ніж чудова група людей, яка швидко робить нікому непотрібні речі. Пам’ятаєте Nokia Mobile? Там були чудові scrum-команди, що неймовірно швидко створювали телефони, які не були потрібні шанувальникам iPhone. Усього за кілька років із лідера ринку вони перетворилися на компанію з нульовою ринковою цінністю.

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

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

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

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

Наприкінці спринту команда та власник продукту проводять огляд спринту. Під час цього заходу вони показують стейкхолдерам та споживачам, що вони зробили, що готове. І тут я маю на увазі дійсно готове, а не «майже готове», «начебто готове» або «щось, над чим хтось дуже багато працював, але не закінчив, проте зусилля треба визнати». Готове. Команда та власник продукту отримають зворотний зв’язок від усіх, хто в кімнаті: «Нам подобається це. А те не подобається. Як на рахунок цього? Тепер, коли ми маємо це, ми хочемо отримати…» Власник продукту використовує цей зворотний зв’язок, щоб скоригувати пріоритизацію в белог продукту, оскільки тепер у нього є конкретні дані від справжніх споживачів, знання про те, чого вони хочуть насправді.

У сфері програмного забезпечення є одне старе правило, яке називається законом Хемфрі: насправді люди не знають, чого хочуть, доки не побачать те, чого не хочуть. Ви можете змусити їх описувати свої бажання в тисячосторінкових документах, але поки вони не побачать те, що працює, вони не знають чого хочуть. А після огляду спринту ви можете з’ясувати, що у вас є готовий елемент. Він може бути надто маленьким для введення в експлуатацію або не мати цінності сам по собі, але він цілком готовий. Їм не доведеться займатись знову.

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

Дивно бачити, як маленькі події, які здавались непослідовними свого часу, стали важелями, які змінили майбутнє. Щось на кшталт «не було цвяха — ворог вступає до міста»^*. І перший огляд спринту став однією з таких подій.

Перша scrum-команда працювала над технічно складним проєктом, тому не могла попросити рядових споживачів прийти та подивитися на проміжний результат. Мій батько найняв кількох експертів із Массачусетського технологічного інституту, щоб вони подивилися на попередній результат. Вони були жорстокі. Вони поставили під питання навички команди, вказали на значні недоліки, невірні припущення тощо. Команда втратила ґрунт під ногами. Мені сказали, що це був непростий день і до кінця зустрічі члени команди хотіли вмити руки. Вони подивилися на Джефа і сказали йому, що не хочуть повторення. Ще один такий день зламав би їх.

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

Що було далі — вам відомо.

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