Scrum: що це таке, як працює і коли використовувати?

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

Scrum це одна з найпопулярніших гнучких методологій розробки програмного забезпечення з сімейства Agile (детальніше про agile розказали тут). Легка й доступна у використанні, але складна в засвоєнні, якщо вірити офіційному опису. На практиці вся складність зводиться до того, щоб навчити розробників та інших фахівців дотримуватися цієї методології в роботі. Але все по порядку.

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

По-друге, Scrum – це не якась програма та не методичка, хоча ПЗ для управління проектами на основі скрам та відповідної літератури більш ніж достатньо. Це принцип, концепція-каркас та рекомендації, як менеджеру підвищити керованість, передбачуваність та ефективність роботи.

На офіційній сторінці The Scrum Guide можна почитати докладно, хто, як і навіщо придумав Скрам, а головне, що творці вкладають у це поняття. Навіть українською (!).

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

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

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

Отже, 4 особливості Скрам як методології:

• робота над проектом розбивається на невеликі підзадачі;
• команда з 5-7 осіб виконує кожну з них у фіксований термін (1-4 тижні);
• протягом роботи над одним підзавданням проводиться 5 типів нарад;
• отриманий результат роботи над кожним підзавданням має цінність для замовника.

Тепер докладніше про кожну з особливостей та розберемо, що таке структура Scrum.

Sprint: головний інструмент Scrum

Спринт - це часовий відрізок (1-4 тижні), протягом якого команда виконує конкретний набір завдань і показує результат. Спринт – головна фішка Скрам. Саме так називається кожне невелике підзавдання, з яких складається проект. Всі спринти повинні бути однаковими за тривалістю, та ви не повірите, але найчастіше довжина одного – два тижні, рідше за місяць. А скільки саме, залежить від особливостей вашого проекту. Зазвичай, чим складніше та незвичайніше завдання, тим спринт в Scrum коротший, щоб швидше зрозуміти, скільки реально часу потрібно для досягнення більш масштабної мети, та не витрачати час розробці на те, що може не знадобитися.

Загалом спринт – це про конкретні задачі. Бракувало якоїсь функції? Додали. Щось не працювало? Полагодили. Завдяки йому зручно організовувати роботу та ще зручніше стежити за прогресом проекту загалом.

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

Артефакти Scrum: що створює команда на кожному етапі?

Красивим словом «Артефакти» в Scrum називають речі, що створюються під час розробки:

1. Беклог продукту. Product Backlog – зона відповідальності власника продукту. Це список завдань або, як його називає Вікіпедія, "журнал побажань до проекту". Беклог – це не щось, що затвердили раз і назавжди, а гнучкий перелік функцій, покращень, виправлень тощо. У ньому вказуються актуальні задачі для команди та зазначаються ті, що вже виконані. На практиці беклог зазвичай ведуть у спеціальних інструментах управління проєктами, наприклад Jira, GitHub Projects або Trello.
2. Беклог спринту. Ще один беклог, але менший і конкретніший. Це список завдань на конкретний спринт, який формується на мітингу щодо його планування. Він теж може змінюватися, якщо команда зіткнулася зі складнощами, і потрібно зробити щось ще, крім того, що запланували. Але його мета, вона мета спринту, залишається незмінною.
3. Інкременти. Це саме той, отриманий результат роботи над кожним підзавданням, що має цінність для замовника. Інкрементом він називається тому, що його вже можна так чи інакше додати до решти проекту та подивитися, як він працює. Це не обов'язково має бути ціла нова функція, цілком можливо й удосконалення тієї, що вже є, або взагалі виправлення помилки. Але обов'язково те, що команда мала зробити протягом спринту. Загалом це очікуваний (найчастіше) результат, який показують власнику продукту, щоб він бачив, як йде робота над його проектом. Якщо наприкінці спринту немає інкременту – спринт не вважається завершеним.

П'ять нарад Scrum: навіщо кожна і скільки триває?

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

1. Project/Product backlog. Власник продукту приходить на першу таку нараду з найголовнішим артефактом проекту – підготовленим списком завдань, які потрібно вирішити для запуску. Беклог – це гнучкий список робочих задач (Story, Bug, Task та інше), які відсортовані за пріоритетом і можуть змінюватися. На цьому мітингу команда знайомиться з тим, над чим працюватиме.
2. Sprint Planning.Планування спринту – обговорення найпріоритетніших завдань командою та скрам-майстром. На цьому етапі обираються історії з беклогу, які потрібно виконати для досягнення мети спринту.
3. Daily Standup Meeting. Щодня 15 хвилин: кожен каже що зробив, що планує і чи є блокери. Детальні обговорення – окремий дзвінок.
4. Sprint Review. Наприкінці спринту інкремент показують власнику продукту та іншим зацікавленим учасникам. Якщо все працює добре, результат можна випускати на прод, а в беклог вносяться зміни.
5. Sprint Retrospective. Зустріч команди для обговорення підсумків спринту. Скрам-майстер аналізує процес, команда ділиться думками і вирішує, як працювати ефективніше.

Ролі в Scrum-команді: хто за що відповідає?

Які основні ролі присутні в методології Scrum? У класичному Scrum існує 3 базові ролі:

1. Product owner (PO). Це ви як власник продукту, а найчастіше хтось із ваших співробітників, кого ви зробите відповідальним за спілкування з командою розробки. Та людина, яка створюватиме беклог проекту та доповнюватиме його, слухатиме наприкінці спринту, що ж там ця команда розробки зробила, а що ні, і що робитиме далі. PO не обов'язково повинен розумітися на технологіях розробки, але мусить бути спеціалістом у своїй галузі. Його робота – точно знати, що має робити готовий проект і кожна його частина, а також вникати в те, як розробляється.
2. Scrum master (SM). Скрам-майстер – проджект-менеджер на максималках. Його робота, з одного боку, допомагатиме продукт оунеру розібратися в нюансах роботи зі Скрам, а з іншого – організовувати роботу команди. Він відповідає і за пошук кадрів для команди, і за те, щоб у них були матеріально-технічні ресурси, і загалом за те, щоб усі товаришували та ефективно працювали. Планування та проведення всіх мітингів у спринті – теж робота SM.
3. Development team (DT). Команда розробників, які займатимуться роботою над проектом. The Scrum Guide вимагає від них не тільки навичок для виконання завдань, але ще й бути спроможними самостійно організовувати робочі процеси, а також відповідати за досягнення мети спринту. Команд цих може бути будь-яка потрібна кількість, але вони повинні складатися з фахівців у певних технологіях і бути невеликими, щоб уникнути проблем із комунікацією.

Scrum методологія підходить для команд оптимальний розмір яких – 5-9 спеціалістів. Більше - комунікація ускладнюється і продуктивність падає до 45%.

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

1. Гнучкість. Scrum – просто ідеальна система управління проектами, які ростуть і масштабуються, а це буквально будь-яка мобільна або веб-додаток, і навіть сайти. Сьогодні ви додали нову функцію, подивилися, як вона працює, і вже у наступному спринті можете почати її вдосконалювати, міняти чи прибрати! І це актуально не тільки для MVP, для яких кожна функція нова, але й для проектів, яким вже кілька років, і вони постійно тестують гіпотези, щоб стати кращими.
2. Видимі результати. Підсумок кожного спринту – щось реальне. Нова функція або виправлення помилки не так важливо, як можливість бачити, що робота йде, і йде успішно. Саме за це, окрім можливості міняти беклог, коли їм хочеться, і люблять Scrum власники продуктів. Учасникам команди це теж дуже важливо, оскільки умовно «закриває гештальт», дає змогу відчути задоволення від виконаної роботи.
3. Мотивація. Хотіти дотримуватися принципів Agile і робити це насправді – дві великі різниці. Самоорганізація команди – складна задача: далеко не всі люди готові брати на себе колективну відповідальність і працювати в такому форматі. Саме тому багато залежить від скрам-майстра, який допомагає команді організувати ефективну спільну роботу.

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

Коли Scrum не підходить

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

Scrum також може бути надлишковим у простих проєктах. Наприклад, для лендингу або сайту-візитки на 5 сторінок веб-агентствам зазвичай достатньо прямого плану робіт. Методологія Скрам показує найбільшу користь у середніх і великих проектах – наприклад, інтернет-магазинах із власною логікою або SaaS-продуктах.

Інші випадки, коли краще розглянути альтернативи:

• фіксоване ТЗ без права на зміни → підходить класична модель Waterfall;
• підтримка вже готового продукту → частіше використовують Kanban;
• дуже маленька команда (1-2 людини) → повний Scrum-процес зазвичай зайвий.

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

Головні принципи Scrum – ясність комунікації, прозорість і прагнення постійного вдосконалення. Плануєте впровадити Scrum у своєму проєкті? Зв'яжіться з нами - розповімо, як організувати роботу команди.