Термін

Визначення

Scrum

Термін взятий з регбі, який означає сутичку навколо м’яча.

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

Product Owner

Власник продукту. Людина, яка безпосередньо зацікавлена у якісному кінцевому продукті і розуміє, як продукт повинен виглядати / працювати. Ця людина не працює в команді, працює на стороні замовника / клієнта (це може бути як інша компанія, так і інший відділ), але ця людина працює з командою. І це та людина, яка розставляє пріоритети для завдань в спринті.

Scrum Master

Людина, яку можна назвати керівником проекту, хоча це не зовсім так. Головне, що це людина, “заражена Scrum-бацилою” на стільки, що несе її як своїй команді, так і замовнику, й відповідно стежить за тим, щоб усі принципи Scrum дотримувалися.

Scrum Team

Команда, яка приймає всі принципи Scrum і готова з ними працювати.

Sprint Backlog

Cписок робіт, який визначила команда і погодила з Product Owner (власником продукту) на найближчий звітний період (Sprint). Завдання в Sprint Backlog беруться з Product Backlog.

Sprint Planning

Буквально — планування спринта. Meeting (нарада), на якому присутні всі (Scrum Team, Scrum-Master, Product Owner). Протягом цієї наради Product Owner (власник продукту) визначає пріоритети завдань, які він хотів би побачити виконаними після закінчення Спринта. Команда оцінює за часом, скільки з бажаного вони можуть виконати. У підсумку виходить список завдань, який не може змінюватися протягом Спринта і до кінця Спринта повинен бути повністю виконаний.

Bug

Помилка

Task

Завдання

Daily Scrum Meeting

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

Sprint Retrospective

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

Sprint Review

Демонстрація робочої версії продукту Product Owner -у для обговорення, отримання вражень і побажань.

Scrum Model image

Малюнок 6. Схема роботи в Scrum

Процес Scrum:

Основою Scrum є Sprint, протягом якого виконується робота над продуктом. По закінченню Спринта має бути отримана нова робоча версія продукту. Sprint завжди обмежений у часі (1-4 тижні) і має однакову тривалість протягом усього життя продукту.

Перед початком кожного Спринта проводиться Sprint Planning, на якому проводиться оцінка вмісту Product Backlog і формування Sprint Backlog, який містить завдання (User Story, Bugs, Tasks), які повинні бути виконані в поточному Спринті. Кожен Спринт повинен мати мету, яка є мотивуючим фактором і досягається за допомогою виконання завдань з Sprint Backlog.

Кожен день проводиться Daily Scrum, на якому кожен член команди відповідає на питання “Що я зробив вчора?”, “Що я планую зробити сьогодні?” “Які перешкоди у своїй роботі я зустрів?”. Завдання Daily Scrum — визначення статусу і прогресу роботи над Sprint, раннє виявлення перешкод, які виникли, вироблення рішень по зміні стратегії, необхідних для досягнення цілей поточного Спринта.

По закінченню Спринта проводять Sprint Review і Sprint Retrospective, завдання яких оцінити ефективність (продуктивність) команди в минулому Спринті, спрогнозувати очікувану ефективність (продуктивність) в наступному Спринті, виявити наявні проблеми, оцінити ймовірності завершення всіх необхідних робіт по продукту та інше.

Важливі особливості, котрі буває забуваються!!!

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

  1. SCRUM застосовується невірно або неповністю. Згідно авторів Scrum, емпіричний досвід є головним джерелом достовірної інформації. Необхідність повного і точного виконання Scrum вказана в The Scrum Guide і обумовлена нетиповою організацією процесу, відсутністю формального лідера і керівника.
  2. Недооцінена важливість роботи щодо забезпечення мотивації команди. Одним з основних принципів Scrum є самоорганізована, багатофункціональна команда. Згідно з дослідженнями соціологів, чисельність ініціативних співробітників, здатних на самоорганізацію не перевищує 15% від працездатного населення. Таким чином, лише невелика частина співробітників здатна ефективно працювати в Scrum без істотних зміни у ролях Scrum Master і Product Owner, що суперечить ідеології Scrum, і потенційно призводить до невірного або неповного використання підходу.
  3. Підхід застосовується для продукту, вимоги до якого суперечать ідеології Scrum. Scrum відноситься до сімейства Agile, тому Scrum вітає зміни у вимогах в будь-який момент (Product Backlog може бути змінений в будь-який момент). Це ускладнює використання Scrum у fixed cost (фіксована вартість)/fixed-time(фіксований час) проектах. Ідеологія Scrum стверджує, що заздалегідь неможливо передбачити всі зміни, таким чином немає сенсу заздалегідь планувати весь проект, обмежившись тільки just-in-timе (тільки в цей час) плануванням, тобто планувати тільки ту роботу, яка повинна бути виконана в поточному Sprint.

Існують і інші обмеження.

Переваги та недоліки Scrum

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

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

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

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

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