АНАЛІЗ ЕФЕКТИВНОСТІ МЕТОДОЛОГІЇ SCRUM ЯК МЕТОДУ УПРАВЛІННЯ ПРОЕКТАМИ ІНФОРМАТИЗАЦІЇ

Анотація

На сьогодні ринок товарів і послуг дуже швидко розширюється. Scrum призначений для швидкої розробки та постачання складних, принципово нових продуктів, яких ще немає на ринку. Коли є тільки ідея, проте готовий продукт ще не готовий, ніхто не може дати чіткий план, куди має піти траєкторія розробок. Scrum допомагає визначити напрям руху, рухаючись невеликими ітераціями та постійно перевіряючи головні запитання: чи робимо ми те, що потрібно клієнтам? чи приносить це користь? Проте методологія Scrum є досить новою на українському ринку і потрібно переконатись в її ефективності. Тому завдання даного дослідження є: 1) розглянути основні принципи, поняття, організаційну структуру розробки інформаційних систем в Scrum; 2) проаналізувати доцільність даної методології, порівнявши її з традиційним методом управління проектами - Waterfall. Scrum – легкий фреймворк, який допомагає людям, командам та організаціям створювати цінність за допомогою адаптивних рішень комплексних проблем. Тобто Scrum – це спосіб організації робочого процесу, гнучка методологія, яка дозволяє вносити в проект необхідні коригування і зміни по ходу його здійснення. Scrum розроблено для того, щоб змінити спосіб за яким розробляються складні інформаційні проекти, в результаті чого рамки Scrum є гнучкими і його принципи можуть бути застосованими не тільки для інформаційних проектів, але й у більш широкій сфері для проектів в інших галузях промисловості. Scrum ґрунтується на філософії емпіризму і теорії управління емпіричними процесами. В основі управління емпіричними процесами лежать три основні принципи: прозорість, перевірка та адаптація. Модель емпіричних процесів методології Scrum показано на рисунку 1 [1, с. 8-10]. Можна виділити три головні особливості процесу розробки, заснованого на Scrum.
1. Робота ведеться ітераціями, котрі називають спринтами.
2. Результатами роботи вважається тільки те, що готове до використання: тобто це не може бути якийсь проміжний результат; по закінчення спринту елемент вважається виконаним, якщо його повністю готовий до використання, тобто відповідає критеріям готовності.
3. Продукт розробляє самоврядна команда: у Scrum-команду, крім розробників продукту, входять також власник продукту як відповідальний за успіх продукту представник замовника / клієнта, і Scrum-майстер як відповідальний за ефективність команди в цілому. Але ніхто з них не диктує розробникам, як працювати: розробники в Scrum утворюють самоврядну команду [2].
Рисунок 1 - Модель процесів SCRUM Джерело: [1]
Центральним ядром Scrum є команда і розподіл ролей у ній. Є роль Власника продукту (Product Owner) - це представник бізнесу, через якого в системі з'являються вимоги; є роль Scrum Masterа - це людина, яка створює для команди проекту умови продуктивної роботи, виступає в ролі організатора, помічника і підтримки для команди; і нарешті сама команда, кросфункціональна, мотивована на результат, з розподіленим лідерством. Команди є невеликими – до 9 чоловік. Scrum не визнає розподіл ролей і всі розробники мають працювати спільно, допомагати один одному закінчити кожен взятий в спринт елемент беклога.
Основна структура процесів Scrum обертається навколо 5 основних зустрічей, в яких бере участь вся команда: упорядкування беклога, планування спринту, щоденних зустрічей, підбивання підсумків спринту і ретроспективи спринту [3].
Починається все з формування вимог замовника, якого представляє Product Owner. На першій зустрічі ці вимоги оформляються за пріоритетом в список, званий «беклог». Крім цього відбувається розбиття бажань замовника на технологічні процеси і планування спринту (ітерації) – це нарада команди з власником продукту, на якому визначається той набір вимог, який команда готова реалізувати за відведений інтервал часу. Далі береться весь список вимог до продукту і розбивається на більш-менш однакові елементи, весь передбачуваний час проекту розбивається на однакові інтервали, наприклад по 2 тижні.
Починається робота і кожен день проводиться нарада під назвою Daily Meeting, на якій кожен учасник команди відповідає за своїми завданнями на 3 ключових питання: «що зробив вчора», «що зробиш сьогодні», «які проблеми». Проводиться, як правило, в одному і тому ж місці, стоячи, щоб не затягувати, і вже за 15 хвилин максимум.
Після того як час ітерації (спринту) завершилося, команда збирається на демонстрацію, куди запрошує зацікавлених осіб, замовників і показує те, що вдалося виконати до поточного моменту.
Завершує ітерацію нарада під назвою «Ретроспектива», в рамках якого команда обговорює, що саме за час спринту було реалізовано добре, що не вдалося і які зміни будуть реалізовані на наступному етапі. Після прийняття рішень, команди виходить на наступну ітерацію.
Якщо порівнювати класичний метод – Waterfall, який характерний поступовим переходом від одного завдання до іншого, зі Scrum, то можна виділити наступні відмінності:
 Головна перевага гнучких методів управління перед класичним – це швидка адаптація до змін. Для прогресу в традиційному методі управління вам необхідно переходити від одного етапу до іншого. Використовуючи Scrum, ви можете набагато швидше виконати певні задачі, на які акцентовано увагу.
 За вартістю набагато дорожчим є Scrum-метод, який вимагає повну реорганізацію організаційної структури, введення додаткової мотивації співробітників, наймання команди-професіоналів і так далі.
 За складністю збору команди управління проектом найскладніший і найдовший процес збору команди для управління проектом відповідно до методології Scrum, бо при відборі працівників потрібно враховувати не тільки професійні навички, а ще й психологічні, тому що команда Scrum – це не просто набір професіоналів, а ще і єдиний організм.
 Класичний підхід дозволяє найбільш повно здійснювати контроль над реалізацією проекту.
 Якщо порівнювати можливість внесення змін, то Scrum є більш гнучким і дозволяє вносити зміни впродовж всього проекту. За класичним методом кінцева ціль і методи розглядаються тільки на початку, проте під час проекту це робити вже не можна.
Отже, ознайомившись із методологією Scrum та порівнявши її з класичною, можна зробити висновок, що і Scrum, і традиційний метод управління проектами є ефективними, проте вони зорієнтовані на різні цілі. Застосування класичної методології має сенс в проектах, результатом виконання яких є матеріальний продукт, і для якісної реалізації яких необхідна чітка послідовність дій. Scrum розроблено для того, щоб змінити спосіб, за яким розробляються складні інформаційні проекти, в результаті чого рамки Scrum є гнучкими і його принципи можуть бути застосованими не тільки для інформаційних проектів, але і у більш широкій сфері для проектів в інших галузях промисловості. Якщо метод Waterfall є універсальним методом управління для будь-яких сфер діяльності, то Scrum – не для всіх. Для досягнення ефективності цим методом має бути поле для експериментів та досліджень, замовник має бути готовим залучатися в процес і давати зворотний зв’язок та ціна помилки не повинна бути занадто великою.