Я продовжую роботу над дисертацією з проектного менеджменту. Сьогодні ми коротко розглянемо Scrum, розглянемо типові помилки, що призводять до проблем. Цей пост не претендує на повноту, він є оглядовим і адресується тим, хто ще не знайомий зі Scrum, або знайомий лише частково (наприклад, працює в модифікованому Scrum).
Зараз Scrum є однією з найбільш популярних «методологій» розробки ПЗ. Згідно з визначенням, Scrum - це каркас розробки, з використанням якого люди можуть вирішувати проблеми, при цьому продуктивно і виробляючи продукти найвищої значущості (з точки зору клієнта - прим. автора) [1].
Це говорить про те, що в Scrum неможливо знайти відповіді на всі питання і вказівки до дії у всіх ситуаціях (наприклад, в офіційному описі Scrum лише вказана необхідність оцінки часу, необхідної на виконання роботи, але не уточнюється вид оцінки. Тобто. це може бути і planning poker і інший спосіб оцінки). Таким чином, саме найменування топіка не вірне:)
Коли говорять про методологію Scrum, найчастіше мають на увазі гнучку методологію розробки ПЗ, побудовану на основі правил і практик Scrum, так що цілком може виявитися що ваш Scrum крутіший за мій Scrum, а також бути від нього так само далеким, як ВАЗ 7-ка від BMW 7-ї серії:)
Авторами Scrum заявлені такі особливості:
-Легка (англ. Lightweight)
-Понятний, доступний
-Складний в освоєнні
(практично взаємовиключні параграфи)
Ролі в Scrum
У класичному Scrum існує 3 базових ролі:
-Product owner
-Scrum master
- Команда розробки (Development team)
Product owner (PO) є сполучною ланкою між командою розробки і замовником. Завдання PO - максимальне збільшення цінності розроблюваного продукту і роботи команди.
Одним з основних інструментів PO є Product Backlog. Product Backlog містить необхідні для виконання робочі завдання (такі як Story, Bug, Task та ін.), відсортовані в порядку пріоритету (терміновості).
Scrum master (SM) є «службовцем лідером» (англ. servant-leader). Завдання Scrum Master - допомогти команді максимізувати її ефективність за допомогою усунення перешкод, допомоги, навчання та мотивації команді, допомоги PO
Команда розробки (Development team, DT) складається з фахівців, що виробляють безпосередню роботу над виробленим продуктом. Згідно з The Scrum Guide (документом, що є офіційним описом Scrum від його авторів), DT повинні володіти наступними якостями і характеристиками:
- Быть самоорганизуемой. Ніхто (включаючи SM і PO) не може вказувати команді, як їм перетворити Product Backlog на працюючий продукт
- Бути багатофункціональною, володіти всіма необхідними навичками для випуску працюючого продукту
- За роботу відповідає вся команда, а не індивідуальні члени команди
Рекомендований розмір команди - 7 (плюс-мінус 2) людини. Згідно з ідеологами Scrum, команди більшого розміру вимагають занадто великих ресурсів на комунікації, в той час як команди меншого розміру підвищують ризики (за рахунок можливої відсутності необхідних навичок) і зменшують розмір роботи, який команда може виконати в одиницю часу. [1]
Процес Scrum
Основою Scrum є Sprint, протягом якого виконується робота над продуктом. По закінченню Sprint повинна бути отримана нова робоча версія продукту. Sprint завжди обмежений за часом (1-4 тижні) і має однакову тривалість протягом усього життя продукту.
Перед початком кожного Sprint проводиться Sprint Planning, на якому проводиться оцінка вмісту Product Backlog і формування Sprint Backlog, який містить завдання (Story, Bugs, Tasks), які повинні бути виконані в поточному спринті. Кожен спринт повинен мати мету, яка є мотивуючим фактором і досягається за допомогою виконання завдань з Sprint Backlog.
Кожен день виробляється Daily Scrum, на якому кожен член команди відповідає на питання «що я зробив вчора?», «що я планую зробити сьогодні?», «які перешкоди на своїй роботі я зустрів?». Завдання Daily Scrum - визначення статусу і прогресу роботи над Sprint, раннє виявлення виниклих перешкод, вироблення рішень щодо зміни стратегії, необхідних для досягнення цілей Sprint'a.
По закінченню Sprint'a виробляються Sprint Review і Sprint Retrospective, завдання яких оцінити ефективність (продуктивність) команди в минулому Sprint'e, спрогнозувати очікувану ефективність (продуктивність) в наступному спринті, виявленні наявних проблем, оцінки ймовірності завершення всіх необхідних робіт по продукту та інше.
Схематичне зображення процесу наведено на наступному малюнку:
Важливі особливості, які часто забувають
Часто можна почути, що Scrum не працює, або працює гірше, ніж очікувалося. Необхідно зауважити, що найчастіше так відбувається з однієї з таких причин:
1. Scrum використовується неправильно або неповно.
Згідно з авторами Scrum, емпіричний досвід є головним джерелом достовірної інформації. Необхідність повного і точного виконання Scrum вказана в The Scrum Guide і обумовлена нетиповою організацією процесу, відсутністю формального лідера і керівника.
2. Недооцінена важливість роботи із забезпечення мотивації команди.
Одним з основних принципів Scrum є самоорганізовані, багатофункціональні команди. Згідно з дослідженнями соціологів, чисельність самомотивованих співробітників, здатних на самоорганізацію не перевищує 15% від працездатного населення [2].
Таким чином, лише невелика частина співробітників здатна ефективно працювати в Scrum без істотних змін в ролях Scrum master і Product Owner, що суперечить ідеології Scrum, і потенційно призводить до невірного або неповного використання Scrum.
3. Scrum застосовується для продукту, вимоги до якого суперечать ідеології Scrum.
Scrum належить до сімейству Agile, так Scrum вітає зміни у вимогах в будь-який момент (Product backlog може бути змінений в будь-який момент). Це ускладнює використання Scrum у fixed-cost/fixed-time проектах. Ідеологія Scrum стверджує, що заздалегідь неможливо передбачити всі зміни, таким чином немає сенсу заздалегідь планувати весь проект, обмежившись тільки just-in-time плануванням, тобто Планувати тільки ту роботу, яка повинна бути виконана в поточному Sprint. [3] Існують й інші обмеження.
Гідності та недоліки
Scrum володіє досить привабливими достоїнствами. Scrum орієнтований на клієнта, адаптивний. Scrum дає клієнту можливість робити зміни у вимогах у будь-який момент часу (але не гарантує того, що ці зміни будуть виконані). Можливість зміни вимог приваблива для багатьох замовників ПЗ.
Scrum досить простий у вивченні, дозволяє економити час, за рахунок виключення не критичних активностей. Scrum дозволяє отримати потенційно робочий продукт в кінці кожного Sprint'a.
Scrum робить упор на самоорганізовану, багатофункціональну команду, здатну вирішити необхідні завдання з мінімальною координацією. Це особливо привабливо для малих компаній і стартапів, оскільки позбавляє від необхідності від найму або навчання спеціалізованого персоналу керівників.
Звичайно, у Scrum є і важливі недоліки. Зважаючи на простоту і мінімалістичність, Scrum задає невелику кількість досить жорстких правил. Однак це вступає в конфлікт з ідеєю клієнтоорієнтованості в принципі, т. к. клієнту не важливі внутрішні правила команди розробки, особливе якщо вони обмежують клієнта. Наприклад, у разі необхідності, за рішенням клієнта Sprint backlog може бути змінений, не дивлячись на явне протиріччя з правилами Scrum.
Проблема є більшою, ніж здається. Оскільки Scrum відноситься до сімейству Agile, в Scrum не прийнято, наприклад, створення плану комунікацій і реагування на ризики. [3] Таким чином, роблячи складним або неможливим формальну (юридичну або адміністративну) протидію порушенням правил Scrum.
Іншою слабкою особливістю Scrum є акцент на самоорганізованій, багатофункціональній команді. При здається зниженні витрат на координацію команди, це призводить до підвищення витрат на відбір персоналу, його мотивацію, навчання. За певних умов ринку праці, формування повноцінної, ефективної Scrum команди може бути неможливим.
Крім Scrum, я рекомендую звернути увагу на Канбан. У цьому відео я зробив невеликий огляд методу Канбан:
Список використаних джерел
[1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
[2] Психологія управління, навчальний посібник. (А. А. Трусь)
[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)
Заздалегідь дякую за зазначені помилки і неточності!