2. Адаптивна модель життєвого циклу Scrum

Scrum - це один з основних підходів до гнучкої розробки програмного забезпечення. Був розроблений в 1994 році Джефом Сазерлендом та Кеном Швабером та представлений на конференції OOPSLA'96.

Основною передумовою виникнення методології Scrum була неможливість використання існуючих на той момент моделей (каскадна модель, RUP) для динамічного адаптування програмного продукту до нових вимог. Модель Scrum включає три стадії:

• Підготовка (pregame phase)

• Розробка запланованих функціональних можливостей (development phase)

• Завершення (postgame phase)

Структура моделі Scrum зображена на рис. 2.1 Розглянемо детально стадії моделі Scrum

Стадія підготовки ітерації включає в себе дві під стадії:

1) планування

• Розробка повного Product Log;

• визначення дати кінцевого релізу та функціоналу для однієї або декількох ітерації;

• вибір початкової ітерації;

• визначення команди розробників для ітерації;

• визначення можливих ризиків та засобів їх контролю;

• перегляд та можливе коректування Product Log;

• вибір та валідація інструментів та технології для розробки;

• визначення бюджету релізу, включаючи розробки, маркетинг, тренінги та інше;

• узгодження з керівництвом бюджету та функціонального вмісту релізу.

Рис. 2.1 – Адаптивна модель життєвого циклу Scrum

2) високорівневий дизайн

• Перегляд зазначених в Product Log специфікації;

• визначення необхідних змін в специфікаціях для імплементації нових функціональних можливостей програмного продукту;

• проведення аналізу систему для виділення необхідних дій для створення, розширення чи обновлення існуючого програмного забезпечення, так щоб воно задовольняло поставленим умовам;

• уточнення архітектури системи для підтримання запланованих в Product Log специфікації;

• виявлення проблем та питань, що можуть виникнути в процесі розробки;

• створення плану імплементації для кожної специфікації Product Log, обговорення та затвердження цих планів командою розробників.

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

• Періодичне обговорення отриманих результатів та планів наступного релізу;

• перегляд та корегування стандартів, яким буде відповідати розроблений продукт;

• ітеративні спринти, поки програмних продукт не буде готовий до випуску.

Спринт (sprint) - це сукупність усіх завдань, що будуть виконувати розробники протягом визначеного періоду, за звичай від одного до чотирьох тижнів. Довжина спринту залежить від складності продукту, оцінених ризиків. Кожен спринт включає всі традиційні фази розробки програмного забезпечення: специфікації, аналіз, дизайн, розробка, тестування та демонстрація розроблених функціональних можливостей. Довжина спрінту має бути фіксованою, встановлюється за вибором команди розробників. В теорії Scrum довжина спринту - 30 днів.

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

Розглянемо організаційні аспекти для ефективного впровадження та використання моделі Scrum:

1. Команда розробників має бути невеликою та крос-функціональною (дозволяє уникнути ризиків пов'язаних з незамінністю членів команди);

2. команда має бути самоорганізованою та має вирішувати проблеми на кожному спринті самотужки;

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

4. робота організовується через Product log та Sprint BackLog. Product log - список основних вимог до програмного продукту, які мають бути реалізовані на протязі проекту. Sprint Backlog - це список функціональних можливостей, що будуть реалізовані протягом поточного спринту. Наповнення Sprint Backlog відбувається на стадії планування ітерації- спринту

5. інтереси замовника в команді представляє Product Owner. Його функції полягають в наповненні, управлінні та контролю Product Log , оцінці часу для реалізації історій з Product Log, прийняття остаточне рішення щодо реалізації історій з Product Log, написанням специфікації для затверджених до імплементації нових функціональних можливостей.

Використання спеціальних засобів для покращення комунікації, контролю над станом проекті, плануванні та огляді ітерацій. Це такі засоби, як daily scrum meetings (щоденні зустрічі команди розробників для контролю перебігу проекту), sprint planning meetings (планування ітерацій scrum командою), sprint retrospective meeting (аналіз результатів спринтів та проекту в цілому).