Scrum від А до Я: повний гід з методології гнучкої розробки

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

Scrum пропонує ролі, принципи та цінності, за якими працюватиме команда.

Термін Scrum вперше з’явився у 1986 році в статті Harvard Business Review. Пізніше, у 1990-х, методологію почали використовувати в розробці, а у 2001 опублікували Маніфест гнучкої розробки програмного забезпечення, який з того часу майже не змінився.

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

У команді Scrum всього три ролі — розробники, власник продукту та скрам мастер:

• Development Team (команда розробки) створює продукт. Команда самоорганізована, часто кросфункціональна — дизайнер, програміст та тестувальники працюють над своїми задачами, щоб виконати спільні цілі. Зазвичай у команді 3-9 людей, іноді більше.
• Scrum Master (скрам майстер) стежить за тим, аби команда дотримувалася принципів Scrum, проводить Scrum-події, підвищує ефективність командної роботи, усуває перешкоди.
• Product Owner (власник продукту) представляє інтереси замовника та користувачів. Чітко знає, яким має бути продукт. Визначає цілі та пріоритети кожного етапу розробки.

В основі Scrum три принципи — прозорість, інспекція та адаптація.

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

Добре, з ролями розібралися, принципи дізналися, тож що далі? Як всі ці люди взаємодіють між собою? Повернімося до основ — базових подій, описаних у Scrum Guide.

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

• Sprints (спринти) — фіксовані періоди, протягом яких команда працює над одним етапом проєкту. Зазвичай спринт триває 1-4 тижні, тривалість змінювати не рекомендується. Кожен спринт має мету.
• Sprint Planning (планування спринту) — зустріч на початку спринту, на якій планується робота команди. В результаті має бути створено беклог — список завдань на спринт.
• Daily Scrum (щоденний стендап) — ранкова 15-хвилинна зустріч команди, на якій вона оцінює свій прогрес та за потреби адаптує план дій. Стендап синхронізує роботу команди та допомагає уникнути блокерів.
• Sprint Review (огляд спринту) — зустріч у кінці спринту, на якій команда демонструє результати роботи всім зацікавленим сторонам та отримує зворотний зв’язок щодо зробленого.
• Sprint Retrospective (ретроспектива спринту) — зустріч, якою завершується спринт. Команда аналізує, як пройшов спринт, що було добре, а що варто покращити у власних процесах, аби надалі працювати ефективніше.

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

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

• Product Backlog (беклог продукту) — загальний список вимог. Він формується перед початком розробки продукту, постійно доповнюється та оновлюється власником продукту.
• Sprint Backlog (беклог спринту) — частина загального списку, яку команда планує виконати протягом поточного спринту. 
• Increment (інкремент) — готова частина роботи, створена протягом одного спринту.

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

Чим точнішим буде беклог, тим легше команді буде розуміти вимоги, планувати спринт та змінювати продукт на краще.

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

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

Можливість вносити зміни на кожному етапі мінімізує можливі помилки, знижує ризики та витрати.

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

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

Читайте також: 

• Що таке Microsoft Azure: найважливіше про глобальну хмарну платформу
• 5 сценаріїв використання хмарних рішень: який вибрати для свого бізнесу
• Аналітика та візуалізація даних хмарними сервісами Azure
• Azure DevOps: розробка програмного забезпечення на новому рівні