Скрам (Scrum)

Інститут управління проектами показав, що більше половини менеджерів проектів, які використовують гнучкі фреймворки (а це 75% з нас), використовують процес Scrum принаймні частину часу.

Опитування PMI показує, що в цілому 55% організацій "Завжди", "Часто", "Іноді" використовують Скрам. У статті розберемо походження гнучкої методології Scrum, ключові терміни Scrum та важливі речі, які потрібно знати, щоб застосовувати Scrum у своїх проектах.

Scrum це різновид Agile розробки програмного забезпечення

Що таке методологія Scrum?

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

Управління проектами Scrum фіксує часові та вартісні вимоги до проектів. Scrum досягає цього, використовуючи часові рамки, відставання та зустрічі. Це високоадаптивна структура, яка допомагає швидше завершувати проекти. В управлінні Scrum проекти досягають прогресу через спринти. Кожен спринт дає приріст результату.

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

Метою Scrum є покращення комунікації, командної роботи та швидкості розробки. Такі поняття, як спринт, скрам, бэклог і бэнддаун, є похідними від скраму.

Коротка історія Scrum

1986: Два японських бізнес-експерта Хіротака Такеучі та Ікудзіро Нонака опублікували в Harvard Business Review статтю "Нова гра в розробку нових продуктів". Це була перша згадка про більш швидкий і гнучкий підхід до розробки продуктів. Через дев'ять років Джефф Сазерленд розробить методологію Scrum.

1995: У 1995 році Сазерленд та його партнер по роботі Кен Швабер перетворили Scrum на формальний процес. Ідея була представлена на конференції з об'єктно-орієнтованого планування, систем, мов і додатків (OOPSLA).

2001: Сазерленд, Швабер та ще 15 розробників програмного забезпечення створили "Маніфест гнучкої розробки програмного забезпечення / Manifesto for Agile Software Development". Невдовзі після створення маніфесту вони опублікували першу книгу про Scrum та Agile-розробку.

2002: Сквабер заснував Scrum Alliance і почав пропонувати сертифікацію за окремими аспектами Скраму, включаючи сертифікацію Scrum Master. На сьогоднішній день понад 100 000 людей отримали ту чи іншу форму сертифікації Скраму.

2016: До сьогоднішнього дня Scrum продовжує розвиватися. У 2016 році був формалізований перший повністю масштабований Scrum. В наші дні Scrum розуміє необхідність розподілених команд і двох Власників продукту. Як наслідок, все більше організацій готові структурувати свою команду за методологією Scrum.

Scrum vs Agile

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

Хоча популярно розглядати Agile і Scrum як конкуруючі ідеї, це не дає читачам точного уявлення про їх взаємозв'язок. Різниця між Scrum та Agile полягає в тому, що Scrum - це план реалізації принципів Agile. Гнучка розробка програмного забезпечення за допомогою Scrum є одним з найпопулярніших підходів до розробки.

Уявіть собі Agile як будинок, а Scrum - як кімнату в будинку. Будь-яка форма розгорнутої методології Scrum також буде гнучкою. Однак, не всі гнучкі підходи слідують методології Scrum. Наприклад, іншою популярною гнучкою методологією є Kanban.

Що таке принципи скраму?

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

Люди та взаємодія вище за процесами та інструментами

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

Робоче програмне забезпечення вище за вичерпною документацією

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

Співпраця з клієнтом під час переговорів вище за укладення контракту

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

Реагування на зміни вище за то щоб слідувати плану

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

3 артефакта Скраму (Scrum Artifacts)

Артефакти Скраму передають ключову інформацію, яку команда Скраму повинна знати під час розробки продукту.

Беклог продукту (Product Backlog)

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

Позиція продуктового бэклогу (Product Backlog Item - PBI)

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

Історії користувачів структуровані таким чином: "Як [пробіл] я хочу [пробіл], щоб я міг [пробіл]".

Беклог спринта (Sprint Backlog)

Елементи беклога продукту, які були обрані для спринту. Сюди також входить план виробництва Інкременту в кінці спринту. Беклог спринту визначає роботу, яку команда розробників буде виконувати протягом наступного спринту, а також елементи, необхідні для створення інкременту, який відповідає визначенню "зроблено".

Ролі в Скрамі (Scrum Roles)

В рамках методології Scrum чітко визначені ролі.

• Скрам команда розробників (Scrum Development Team)
• Скрам-майстер (Scrum Master)
• Власник продукту (Product Owner)

Ці ролі допомагають відрізнити модель Scrum від схожих Agile-методів, таких як Kanban.

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

Команда Scrum-розробників (Scrum Development Team)

Команда розробників Scrum - це група професіоналів, відповідальних за досягнення результату "Готово" в кінці кожного спринту.

Команди розробників є унікальними в наступних аспектах:

• Команди розробників самоорганізуються. Ніхто в Scrum команді (навіть Scrum майстер) не має права вказувати їм, як перетворити Product Backlog в Increments.
• Вони крос-функціональні. Всі члени команди повинні мати навички, необхідні для створення Інкременту.
• Вони несуть відповідальність за успіхи і невдачі як команда. Не має значення, якщо один член команди допустив помилку, яка призвела до того, що команда не отримала Інкремент в кінці спринту, команда розробників приймає відповідальність як єдине ціле.

Скрам-майстер (Scrum Master)

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

Скрам-майстер веде скрам-команду через щоденний скрам (daily Scrum). Вони часто задають три питання:

• Що ви робили вчора?
• Що ви будете робити завтра?
• Які перешкоди стоять на вашому шляху?

Однак Скрам-майстер не є остаточним лідером Скрам-команди. Він не несе безпосередньої відповідальності за результати. Вся команда в цілому повинна взяти на себе відповідальність за кінцевий продукт.

Скрам-майстер також буде працювати з власником продукту, щоб переконатися, що проект йде за планом. Вони будуть виконувати такі завдання, як:

• Гарантія того, що цілі Scrum зрозумілі всім.
• Оптимізація управління відставанням продукту.
• Організація Scrum заходів
• Допомагати команді Scrum зрозуміти необхідність стислого викладу елементів бэклога продукту.

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

Власник продукту (Product Owner)

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

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

Скрам-зустрічі (так звані Скрам-церемонії)

Існує 4 основних види скрам-зустрічей або скрам-церемоній:

• Щоденний скрам (Daily Scrum)
• Зустріч з планування спринту (Sprint Planning Meeting)
• Зустріч з огляду спринту (Sprint Review Meeting)
• Ретроспективна зустріч спринту (Sprint Retrospective Meeting)

Певні типи зустрічей Scrum відбуватимуться в певний час в процесі розробки. Вони також відомі як церемонії Scrum. Для отримання додаткової інформації, ви можете прочитати наш посібник по скрам-церемоніям.

Щоденний Scrum (Daily Scrum)

Щодня відбуватиметься щоденна Scrum-зустріч, на якій члени команди обговорюватимуть досягнутий прогрес та проблеми, з якими вони зіткнулися.

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

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

Хочете переконатися, що ви проводите найкращий щоденний Scrum? Прочитайте наш посібник про те, як проводити більш ефективний щоденний скрам.

Нарада з планування спринту (Sprint Planning Meeting)

Під час наради з планування спринту команда узгоджує низку продуктів, які вона має завершити протягом наступного спринту.

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

Найважливішою частиною зустрічі з планування спринту є підготовка, яка повинна бути проведена до початку зустрічі.

Те, які і скільки елементів з бэклога продукту будуть завершені, залежить від прихильності команди і швидкості (швидкості, з якою команда розробників може створювати Інкременти). Якщо ви плануєте спринт з новою командою, краще не розраховувати на основі очікуваної швидкості, поки ви не зробите кілька спринтів з командою (тут можно подивитися на Модель Брюса Такмана чому команді потрібен час на виход в продуктивність).

Нарада за результатами спринту (Sprint Review Meeting)

Підсумкова нарада відбувається в кінці спринту з чітко визначеною метою - проаналізувати досягнутий прогрес. Під час огляду спринту Scrum Master і Product Owner перевіряють, чи відповідають результати очікуванням, встановленим на нараді з планування спринту. Тут власник продукту перевіряє, чи відповідає приріст роботи визначенню "виконано".

Ретроспективна нарада Спрінта (Sprint Retrospective Meeting)

Ретроспективна зустріч дозволяє вашій команді озирнутися на минулі події та ситуації. Відповідно до Scrum Guide, ретроспектива спринту - це "можливість для Скрам-команди проінспектувати себе і створити план поліпшень, які будуть введені в дію під час наступного спринту". Має сенс, особливо з огляду на те, що в центрі уваги гнучкої розробки - безперервне вдосконалення. Для того, щоб стати краще, треба знати, що покращувати в оперційній роботі.

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

Терміни скраму (Scrum Terms)

Є деякі терміни, про які ви, швидше за все, ніколи раніше не чули. Ось список термінів Scrum, до яких ви можете звернутися в будь-який момент:

• Agile: рамки, в яких була розроблена методологія Scrum. Сприяє адаптації та гнучкості замість жорсткої структури.
• Burn-down Chart: Діаграма, що показує кількість роботи, яка залишається в беклозі продукту.
• Burn-Up Chart: Діаграма, що показує обсяг робіт, які були виконані з продуктового беклогу.
• Узгодженість (Coherent): Якість взаємозв'язку між елементами відставання продукту. Якщо достатня кількість елементів взаємопов'язані між собою, їх варто розглядати як єдине ціле, і про це слід згадати при обговоренні наступної Цілі Спринту.
• Daily Scrum: Зустріч, що проводиться щодня, де п'ятнадцять хвилин відводиться на структурування майбутнього робочого дня.
• Визначення поняття "Готово" (Definition of Done): Очікування, яким повинен відповідати Інкремент, щоб вважатися готовим до випуску.
• Команда розробників (Development Team): Команда в рамках Scrum-команди, яка керує, організовує та виконує роботу з розробки, необхідну для створення Інкременту.
• Емпіризм (Empiricism): Управління процесом, яке стверджує, що тільки минуле є достовірним. Дозволяє забезпечити максимальну гнучкість в рамках гнучкого фреймворку.
• Інженерні стандарти (Engineering Standards): Набір стандартів, які поділяються між командами для забезпечення приросту.
• Прогноз функціональності (Forecast of Functionality): Набір кроків, взятих з відставання продукту, який команда розробників розглядає як можливий для завершення в спринті.
• Інкремент (Increment): Частина програмного забезпечення, яка може бути додана до інших інкрементів. Зібрані разом, достатня кількість інкрементів створює продукт.
• Беклог продукту (Product Backlog): Список (зазвичай впорядкований) робіт, які необхідно виконати для створення продукту.
• Власник продукту (Product Owner): член команди в Scrum, якому доручено максимізувати цінність продукту.
• Скрам доска (Scrum Board): Простий спосіб візуалізації інформації, якою обмінюється команда Scrum.
• Посібник зі Скраму (Scrum Guide): Оригінальне визначення Скраму. Посібник детально описує ролі, події, артефакти та правила Скраму.
• Scrum Master (Скрам-майстер): Відповідає за керівництво Скрам командою. Переконується, що кожен має тверде розуміння принципів Скраму. Пропонує керівництво та навчання, коли це необхідно.
• Цінності Скраму (Scrum Values): Основні цінності, які керують структурою Скраму. Це: відданість, цілеспрямованість, відкритість, повага та сміливість.
• Самоорганізація (Self-organization): Основний принцип Scrum, який стверджує, що команди повинні внутрішньо організовувати свою роботу без втручання з боку зовнішніх команд.
• Спринт (Sprint): Часовий проміжок в один місяць або менше, протягом якого проводяться події Scrum. Спринти проводяться один за одним. Перерви між ними не передбачені.
• Мета спринту (Sprint Goal): Мета поточного спринту.
• Ретроспектива спринту (Sprint retrospective): Зустріч, тривалістю не більше трьох годин, на якій команда спринту збирається разом і обговорює будь-які поліпшення, які повинні бути реалізовані для наступного спринту.
• Огляд спринту (Sprint Review): Зустріч, тривалістю не більше чотирьох годин, яка є завершенням спринту. Робота переглядається, і зацікавлені сторони перевіряють Інкремент, щоб переконатися, що він відповідає визначенню "виконано".
• Зацікавлена сторона (Stakeholder): Особа, що не входить до складу Скрам Команди. Забезпечує зовнішню перспективу і бере активну участь в оглядах спринту.

Істочники:
- https://thedigitalprojectmanager.com/projects/pm-methodology/scrum-methodology-complete-guide/
- https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Ukrainian.pdf (переклад орігінальної методології авторів на українську)

Що допрацювати в статті:
- Міжфункціональної команди - після публікації додати посилання
- Історії користувачів
- як проводити більш ефективний щоденний скрам (є посилання із орігінальної статті) і також як запланувати спринт
- посібник про те, як провести чудову ретроспективу спринту