Знайомство зі Scrum

1. Історія появи Scrum

З моменту публікації в 1970 році звіту Вінстона Ройса "Управління розробкою великих програмних систем" багато хто намагався знайти методику, яка могла б усунути мінуси моделі розробки Waterfall. Альтернативою "водоспаду" став метод Scrum, про який зараз йтиметься.

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

У 1995 році з'явилося ще одне керівництво "Розробка програмного забезпечення Scrum" авторства Сазерленда і Швейбера. Згодом ця публікація багаторазово оновлювалася. Зараз вона вважається основним посібником для розробки за цим методом. В даний час актуальна версія Scrum Guide містить відомості, оновлені у 2020 році.

Основні положення Scrum Guide припускають, що шаблон управління проэктами має базуватися на тому, що розробники постачають готовий продукт у зазначені терміни – спринти. Для успішного застосування Scrum рекомендується використовувати структуру, що складається з кількох елементів: ролей, подій, правил та артефактів.

2. Ролі у Scrum

У Scrum є три ролі, всі вони формують скрам-команду:

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

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

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

3. Події у Scrum

Є 5 різновидів scrum-подій:

Sprint – найбільш значна частина Scrum. До неї входить планування спринту, щоденні стендапи (daily scrum), огляд та ретроспектива спринту.

Sprint Planning. У складанні плану майбутнього спринту беруть участь усі учасники скрам-команди. Саме тут презентують ідею продукту, і кожен учасник команди може висловити свою думку з цього приводу. Потім на зустрічі визначаються пріоритети та оголошуються дедлайни.

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

Sprint Review (Demo) – показ результатів, створених під час спринту. Зазвичай ця подія відбувається на завершальному етапі. У ній беруть участь усі зацікавлені особи.

Sprint Retrospective – обговорення результатів спринту. Учасники команди діляться думкою щодо того, як вони впоралися з поставленими перед ними завданнями та як покращити результати роботи надалі.

Крім цього, іноді проводиться уточнення беклогу – Backlog Refinement. На ньому обговорюються елементи беклогу, підготовка до майбутнього спринту та пріоритети поточних завдань.

4. Артефакти

Aртефакти Scrum – це робота, виконання якої відбувається при завершенні проєкту чи спринту. Є три артефакти – беклог продукту, беклог спринту та інкремент. Кожен із них потрібен для своєчасного постачання ПЗ користувачам. Є також допоміжні артефакти (берн-даун чарти та інше).

Компоненти, що входять до артефактів спринту:

Беклог продукту - функції інтерфейсу та бекенда.

Беклог спринту – список завдань, які потрібно зробити під час ітерації. Їх узгоджують перед початком спринту.

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

Елемент беклог продукту - його необхідно виконати за час ітерації спринту. Як правило, елемент розбивають на кілька дрібних завдань.

Мета спринту — завдання, які потрібно виконати (створення елемента бэклога чи інше завдання).

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

Реліз продукту/берн-даун чарт продукту – графік, який перед завершенням чергового спринту малює скрам-майстер. Горизонтальна вісь — це спринти, вертикальна — кількість роботи, що залишилася.

5. Правила скрам-фреймворку

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

• До scrum-команди входять замовник ПЗ, scrum-майстер та розробники.
• Усі спринти мають бути однаковими за тривалістю.
• Після завершення одного спринту одразу починається робота над новим.
• Спринт завжди починається із узгодження плану.
• Учасники команди на початку робочого дня проводять ранковий скрам.
• Під час кожного спринту виконується огляд. Це покращує взаємодію між командою та зацікавленими особами.
• Не рекомендується змінювати беклог спринту під час спринту.

6. Обмеження у Scrum

Поряд із очевидними плюсами, у Scrum є й недоліки:

• Scrum часто призводить до зменшення обсягу виконаної роботи через відсутність загального дедлайну.
• За низької залученості чи неготовності до співпраці серед учасників проєкту є чималі шанси провалити результат.
• Структуру Scrum складно використовувати у великих командах, але все ж таки це реально. Для цього є фреймворки масштабування: LeSS, SAFe, Nexus та інші.
• Відхід одного або кількох учасників із команди в середині проєкту не дуже добре впливає на проєкт.