Гнучка методологія розробки "Scrum"

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

В даний час, Scrum є однією з найбільш популярних методологій розробки ПЗ. Згідно з визначенням, Scrum — це каркас розробки, з використанням якого люди можуть вирішувати з'являються проблеми, при цьому продуктивно і виробляючи продукти найвищої значущості (з точки зору клієнта — прим. Автора) [1].

Це говорить про те, що в Scrum неможливо знайти відповіді на всі запитання та вказівки до дії у всіх ситуаціях (наприклад, в офіційному описі Scrum лише зазначена необхідність оцінки часу, необхідного на виконання роботи, але не уточнюється вид оцінки. Тобто це може бути і planning poker й інший спосіб оцінки). Таким чином, саме найменування топіка не вірно :)

Коли говорять про методології Scrum, найчастіше мають на увазі гнучку методологію розробки ПО, побудовану на основі правил і практик Scrum, так що цілком може виявитися, що ваш Scrum крутіше мого Scrum, а також бути від нього так само далеким, як ВАЗ 7-ка від BMW 7-ї серії :)

Авторами Scrum заявлені наступні особливості:
-Легкий (англ. Lightweight)
-Зрозумілий, доступний
-Складний в освоєнні
(практично взаємовиключні параграфи)

image

Ролі в 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, Завдання), які повинні бути виконані в поточному спринті. Кожен спринт повинен мати мету, яка є мотивуючим фактором і досягається за допомогою виконання завдань з Sprint Backlog.

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

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

Схематичне зображення процесу наведено на наступному малюнку:
image

Важливі, часто забуваються особливості

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

1. Методологія застосовується невірно або неповністю.
Згідно авторам Scrum, емпіричний досвід є головним джерелом достовірної інформації. Необхідність повного і точного виконання Scrum вказана в The Scrum Guide і обумовлена нетиповою організацією процесу, відсутністю формального лідера і керівника.

2. Недооцінена важливість роботи щодо забезпечення мотивації команди.
Одним з основних принципів Scrum є самоорганізуються, багатофункціональні команди. Згідно з дослідженнями соціологів, чисельність ініціативою співробітників, здатних на самоорганізацію не перевищує 15% від працездатного населення [2].
Таким чином, лише невелика частина співробітників здатне ефективно працювати в Scrum без істотних зміни у ролях Scrum master і Product Owner, що суперечить ідеології Scrum, і потенційно призводить до невірного або неповного використання методології.

3. Методологія застосовується для продукту, вимоги до якого суперечать ідеології Scrum.
Scrum відноситься до сімейства Agile, так Scrum вітає зміни у вимогах в будь-який момент (Product backlog може бути змінений в будь-який момент). Це ускладнює використання Scrum fixed cost/fixed-time проектах. Ідеологія Scrum стверджує, що заздалегідь неможливо передбачити всі зміни, таким чином немає сенсу заздалегідь планувати весь проект, обмежившись тільки just-in-timе плануванням, тобто Планувати тільки ту роботу, яка повинна бути виконана в поточному Sprint. [3] Існують і інші обмеження.

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

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

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

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

Проблема є більшою, ніж здається. Т. к. Scrum відноситься до сімейства Agile, в Scrum не прийнято, наприклад, створення плану комунікацій та реагування на ризики. [3] Таким чином, роблячи складним або неможливим формальна (юридична або адміністративне) протидія порушенням правил 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)

Заздалегідь дякую за вказані помилки та неточності!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.