Часто зустрічається неправильне уявлення, що Agile (гнучка методологія) та Scrum – це одне й те саме. Насправді, скрам – це один з підходів Agile до створення продукту. Серед інших гнучких підходів: Crystal, екстремальне програмування (XP), FDD та інші. Agile – це ніби морозиво, де Scrum та інші методи виступають різними смаками та добавками.
Agile є користувацьким посібником, тоді як скрам можна вважати валізою з інструментами.
Перейти від Agile до Scrum – означає конкретизувати ваші підходи, залишаючись вірним гнучкій методології. Як це можна реалізувати, ми покажемо на прикладі нашого сервісу проектного менеджменту Worksection.
Різниця між Agile та Scrum
Якщо описати скрам двома реченнями, то це пофазовий гнучкий підхід. Він використовує ітерації, забезпечує постійну взаємодію з замовником та заохочує колективне прийняття рішень.
Методологія Agile – це 4 цінності та 12 принципів, які були виділені для успішного управління в IT-сфері. Маніфест творців підкреслює важливість працюючого продукту та готовності до змін у проекті.
Scrum був відомий майже на 10 років раніше, ніж Agile (1993 та 2001 роки відповідно), але став частиною гнучкої методології. Agile створювали представники IT-сфери, але підхід поширився і в інші галузі бізнесу. А от скрам так і залишився інструментом для управління проектами в IT-сфері.
Скрам будується на філософії Agile, але використовує також емпіричний процес та принципи філософії Lean.
Ми вже розглядали різницю між Agile та скрам у статті про скрам методологію. Там ми додавали таблицю, яка наочно демонструє спільні та різні моменти.
Scrum | Agile | |
Філософія | - | + |
Методологія | + | - |
Ритуали | + | - |
Ролі | + | - |
Артефакти* / Створювані об’єкти | + | - |
Прозорість | + | + |
Короткі ітерації | + | + |
Часті релізи | + | + |
Урахування змін | + | + |
Постійне покращення | + | + |
*Артефакти у скрамі — це об’єкти, які створюються командою під час роботи над проектом. До них відносяться беклог продукту, беклог спринта та інкремент продукту, тобто працюючий кусок функціоналу, який команда демонструє в кінці спринта.
Що таке Scrum
- У скрамі немає детального опису, як вам розвивати ваш програмний продукт.
- У Scrum немає проектного менеджера та підкоманд. Є лише одна скрам-команда, учасники якої можуть замінити інших у разі необхідності.
- Цю команду формально очолює скрам-майстер, який слідкує за правильним впровадженням scrum.
- Власник продукту складає беклог продукту з користувацькими історіями – завданнями, які потрібно реалізувати під час проекту. Product Owner повинен розуміти ринок і користувачів, щоб отриманий продукт був затребуваним.
- У скрамі важлива самоорганізація команди. У неї входять творчі та дисципліновані виконавці, кожним кроком яких не потрібно управляти особисто.
В Worksection можна ввести команду, призначити відділи та права, а далі команда буде працювати з завданнями самостійно.
- Технологія Scrum – це серія спринтів, які можуть тривати від 2 до 4 тижнів. Це цикл створення, тестування або модифікації програмного забезпечення. У нього входить 5±2 ідеї.
- В кінці спринта замовник отримує робочу версію продукту з новою або додатковою функціональністю. Замовник або користувачі тестують продукт, забезпечуючи відгуки для скрам-команди.
- Технічні спеціалісти в команді зазвичай мають високий досвід, але також розуміють бізнес-процеси.
Виклики під час переходу до Scrum
- При відсутності проектного менеджера, команда бере відповідальність за те, як працює і вирішує труднощі.
- Призвичаїтися до нового режиму роботи: планування спринта та робота в його рамках замість дій до дедлайну.
- Розбивати процес на дрібні завдання, щоб їх можна було виконати під час спринта. Якщо користувацька історія занадто велика, розробник підготує проект занадто пізно, і тестувальник не встигне зробити свою роботу до закінчення спринта. Навіть якщо дефекти будуть виявлені, часу залишиться дуже мало, щоб їх виправити.
- Використовувати покер планування, щоб оцінити складність завдання та час, який піде на її виконання. При початковому впровадженні скрама знадобиться кілька розіграшів, щоб члени команди співпали в своїх оцінках.
- Правильний вибір власника продукту. Часто ним призначається спеціаліст, який вже має свої обов’язки в компанії. Тому він розривається на два фронти. А якщо він не пройшов навчання і погано розуміє, що йому належить робити у цій ролі, то такий Product Owner лише зашкодить проекту.
- Додавати нову користувацьку історію в беклог тільки з завершенням вже існуючої. Інакше список завдань може стати непосильним під час спринта.
Наприклад, беклог контент-плану блогу в Worksection виглядає так. У спринт на місяць береться частина беклога тем і роздається авторам.
- Дотримуватися пріоритетності користувацьких історій. Не змінювати їх порядок, коли кінець спринта близький.
В Worksection кожному завданню, підзавданню та проекту можна призначити пріоритет і приймати рішення про реалізацію відповідно до нього. - Коли вирішили перейти до скраму, потрібно стежити, щоб не повернутися до практик та мислення каскадної моделі («Водопада»), де етапи реалізуються строго послідовно.
- Вибрати ті інструменти Scrum, які підходять для даного проекту.
- Не перетворювати щоденні збори на рутину або навіть джерело роздратування для команди.
Просту комунікацію можна залишити в коментарях до завдань, а на зустрічі обговорювати тільки важливі аспекти спринта.
Переваги та недоліки Scrum
Переваги
- Більше прозорості для проекту. Завдяки щоденним зборам, всі учасники команди детально знають, як виконуються процеси, і можуть одразу усунути непорозуміння або виявити загальні проблеми.
- Розвите почуття відповідальності у команди. Коли немає проектного менеджера, що роздає вказівки, виконавці самоорганізуються та приймають колективні рішення. Кожен учасник команди залишається незалежним.
- Легко впроваджувати зміни. При коротких спринтах і постійному співробітництві з замовником, модифікувати продукт стає просто.
Якщо команда відкрила нову користувацьку історію під час спринта, вона може додати її до наступного спринта, обговоривши це на зборах. - Економія коштів. Завдяки тому, що команда і замовник постійно спілкуються, а проект поділений на дрібні завдання, помилки в коді виявляються заздалегідь – поки їх виправлення не стане занадто витратним.
Недоліки
- Ризик того, що межі проекту розтягнуться. Завдання повинні бути достатньо дрібними, щоб вміститися в рамки спринта.
- Команда повинна складатися з досвідчених та зацікавлених фахівців. Невміння принципів Скраму або небажання їм слідувати негативно відобразиться на проекті.
- Непідготовлений скрам-майстер усе зіпсує. Якщо він спробує контролювати учасників команди, як це зазвичай робить проектний менеджер, то проект провалиться.
- Погано сформульовані завдання приведуть до помилок. Коли внутрішні цілі не ясні, ускладниться планування, а спринти займуть більше часу, ніж повинні були.
Правильно сформульоване завдання та його підзадачі в Worksection виглядають так:
Переваги та недоліки Agile
Переваги
- Кінцева мета проекту може залишатись невідомою. У міру просування починають вимальовуватись цілі, під які легко підстроїти команду.
- Швидкий випуск продуктів з високою якістю. Завдяки тому, що проект поділений на ітерації (як спринти в скрамі), команда може зосередитися на розробці, тестуванні та співпраці. Помилки в коді швидко виявляються та усуваються.
- Замовники почуті. Клієнти спостерігають за ходом проекту, діляться своїм баченням і можуть впливати на кінцевий продукт. Працюючи тісно з командою, вони відчувають себе повноправними власниками.
- Постійний прогрес. У процесі взаємодії команди та контактів з замовником відбувається постійна робота над помилками та покращення якості ітерацій.
Недоліки
- Планування може бути неконкретним. Проектні менеджери можуть змінювати пріоритетність завдань, через що деякі з них зриваються за термінами. Також можуть бути додані спринти під час циклу проекту.
- Недостатня увага документації. Як зазначено в маніфесті Agile методології, працюючий продукт важливіший за документацію. Однак іноді потрібен баланс між бюрократією та робочою дискусією.
- Вовлеченість команди та універсальність навичок. Як і в випадку зі скрамом, учасники проекту повинні бути взаємозамінними, розуміти та дотримуватись принципів впроваджуваної методології.
- Кінцевий продукт може дуже відрізнятися від запланованого. У процесі взаємодії з клієнтом можуть додаватися нові ітерації, які приведуть до іншого результату.
Коли використовувати Scrum
- Вимоги до проекту змінюються та доповнюються
- Потрібно постійне взаємодію з замовником та користувачами
- Не відомо, як виконати завдання великого обсягу, яке раніше не вирішувалося
- Немає фіксованої дати для випуску програмного продукту
- Команда хоче працювати більш вільно
- Потрібно на регулярній основі випускати програмні продукти
- Скрам чудово підходить для проектів, де передбачається багато невідомого або очікується чимало змін на ходу.
Коли використовувати Agile
Ви повинні зрозуміти, чи потрібно застосовувати гнучкий підхід у даному проекті. Якщо так, то можете вибрати один з компонентів Agile – в тому числі каркас Scrum.
- Концепція кінцевого продукту не визначена остаточно
- Замовники або стейкхолдери хочуть впливати на зміст проекту
- Зміни потрібно впроваджувати протягом всього циклу
- Розробники можуть адаптуватись до нових викликів і працювати незалежно
- Зміни в бізнес-середовищі відбуваються швидко
- Переконатися, що продукт вирішить критичну проблему для компанії
- Спонсорування проекту залежить від результатів на кожному етапі*
- Необхідно випустити продукт якомога швидше
*Щоб отримати подальше фінансування, можна показати результати за допомогою детального звіту в Worksection, де відображені заплановані та реально затрачені ресурси:
Гібридні підходи
Якщо скрам у чистому вигляді не підходить для проекту, але потрібен гнучкий підхід, то можна спробувати техніку Disciplined Agile Delivery (DAD). У ній поєднуються принципи Agile, Scrum, Kanban, Extreme Programming, Lean та інші. DAD передбачає часте навчання, враховує людський фактор і передбачає завершення завдань якомога раніше.
Вердикт
Як один з підходів Agile, Scrum використовує ітерації для створення програмного забезпечення. На відміну від материнської методології, скрам не передбачає наявності проектного менеджера – команда повинна бути автономною, де кожен учасник несе відповідальність.
Тому, щоб гармонійно перейти від Agile до скрам, акцент має бути зроблений на особливій ролі скрам-майстра. Це навчений спеціаліст, який вміло скористається інструментами Scrum залежно від специфіки проекту. Він також здатний донести ключові принципи до команди та не перетворить щоденні збори на нудну «обов’язкову справу».
Щоб перейти від Agile до Scrum, потрібно проводити ітерації у вигляді спринтів, які тривають кілька тижнів. Тут важливо розбити процеси на достатньо маленькі завдання, щоб завершити їх до кінця забігу.
Для переходу від Agile до Scrum потрібно
не ускладнення алгоритмів, а правильне розуміння інструментів цього гнучкого «каркаса».
Вони допоможуть забезпечити повну прозорість процесів завдяки зборам та контактам з замовником. Скрам посилює мотивацію команди, яка швидко прогресує завдяки більшій відповідальності та відсутності нагляду.
А для того, щоб реалізувати на практиці будь-яку з цих методологій, варто спробувати вести проекти в Worksection!