Scrum: Правила Гри

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

Кажучи це, мають на увазі, що Scrum — це деяка езотерична методика, яка застосовується в реальному житті з тієї чи іншої причини. Наприклад тому що «для скрам потрібно дуже багато бабла, а ми повинні жити по коштах» або «в Scrum розробники повинні бути супер універсальними, а у нас таких немає». А раз так — робиться висновок, що «треба думати головою», і все потрібно робити по-своєму. В результаті такого підходу в робочому процесі з'являються деякі поліпшення, але в цілому нічого не змінюється, що ще більше переконує в тому що Scrum — це фантазії не мають відношення до реального світу. Це не так.



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

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

Scrum як Гра
Найбільш точний опис Scrum винесено на титульний лист Scrum Guide.

Scrum — це правила гри.

Scrum — це не тільки опис процесу (planning, daily, review, retro), але й визначення ролей учасників гри, їх відносин один з одним і цінностей, які вони поділяють.

Наприклад, шахи. Два гравці переміщують фігури на полі. Один — тільки білі. Інший — тільки чорні. Є черговість ходів і правила, за якими ходить кінь і пішак. У серйозні шахи грають на час.

Що буде якщо гравці заявляють, що грають в «шахи», а насправді продовжать грати в шашки шаховими фігурами? Що буде, якщо, граючи в «шахи», один гравець буде слідувати правилам справжніх шахів, а другий буде грати в «Чапаєва»?

Scrum Guide — продуманий, розумний, глибокий, збалансований, складний для розуміння документ. До поточної редакції 2016 року йому більше 20 років (Scrum був публічно анонсований в 1995), при цьому його обсяг лише 17 сторінок. Достатньо одного, щоб організувати роботу компанії? Немає, як і шахових правил недостатньо, щоб навчитися грати добре.

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

Хенніг Бранд, ґрунтуючись на принципах алхімії, намагався отримати золото, випарівая воду з сечі. Основна ідея була в тому, що і те, і інше золотистого кольору. Не можна сказати, що задум повністю провалилася. У результаті він у 1669 році отримав фосфор, який, як і золото, має певну комерційну цінність. Але це все ж була чиста удача. Побудований на цих принципах «стартап», хоча і приніс власнику спочатку деякий дохід, в цілому швидко провалився і був проданий за порівняно невелику суму.

З іншого боку, Гемфрі Деві, ґрунтуючись на принципах електролізу, в 1807 році відкрив калій, натрій, барій і кальцій (І це далеко не повний список хімічних елементів їм відкритих). Важко назвати його інакше як результат закономірним. Що, втім, не применшує його особистого таланту, наполегливості і безстрашності.

Scrum і теорія обмежень Голдратта
Еліяху М. Голдратт, визнаний гуру теорії бізнес менеджменту, автор Теорії Обмежень, в книзі «The Goal» пояснює техніки пошуку і усунення вузьких місць у виробничому процесі. «isn't it Obvious?» він розповідає про те, як збільшити продажі, скоротивши кількість відсутніх позицій найбільш популярних товарів за рахунок реорганізації роботи системи магазину-складу.

Його теорії об'єднує ідея, що для досягнення реальних результатів для компанії, всі ці процеси повинні бути реорганізовувати одночасно, в комплексі і з урахуванням інтересів всіх сторін. Цю думку він висловлює у книзі, підвідної підсумок попереднім, «Beyond the Goal». Парадокс полягає в тому, що оптимізація тільки частини процесів компанії, наприклад, тільки розробки, не тільки не призведе до зростання бізнесу в цілому, але і може негативно позначитися на співробітників підрозділу, який домігся істотних поліпшень в продуктивності своєї роботи.

Це повною мірою відноситься до Scrum. Впроваджувати його тільки в розробці, не досягнувши порозуміння та злагоди роботи по Scrum у всій компанії — свідомо погана ідея. Так, техніки Scrum дозволяють істотно розширити можливості розробки. Це дозволить швидко і якісно випустити безліч нових функцій додатки… які в результаті будуть абсолютно не потрібні користувачам. «Ваш продукт занадто складний, ми не змогли розібратися, сумний смайлик». Результат — незадоволення з боку бізнесу і розчарування на стороні розробки.

Гра для всіх
Перш ніж міняти що-небудь в процесі розробки, необхідно домогтися повного визнання Scrum усіма в компанії. Зокрема це вимагає спільного прийняття цінностей Scrum (Scrum Guide, Scrum Values: commitment, courage, focus, openness and respect.): старанність, сміливість, сфокусованість, відкритість і повага.

Нехтуючи цінностями Scrum, легко знищити всі вигоди, які він може дати.

Якщо власник бізнесу не поважає право Product Owner'а приймати рішення з розвитку продукту і нав'язує йому конкретний план дій, вся Scrum-команда позбавляється можливості швидко адаптуватися, оскільки не зможе прийняти ніякі рішення самостійно.

Якщо Product Owner не буде виконувати зобов'язання щодо збільшення цінності продукту, що є єдиною його відповідальністю, як він зможе зберегти довіру з боку власників бізнесу?

Якщо Product Owner не буде мати сміливості міняти продукт і пробувати щось нове, як він зможе домогтися збільшення цінності продукту? Адже будь-яке поліпшення — це в кінцевому підсумку зміна.

Якщо Product Owner не буде поважати право Development Team на самоорганізацію, та на щоденній основі буде втручатися в роботу команди, постійно змінюючи плани і контролюючи всі етапи роботи, Development Team не зможе поліпшити свою продуктивність. Результат її роботи буде стабільно мізерним і посереднім.

Якщо Development Team не буде виконувати обіцянки щодо досягнення цілей взятих на спринт, як вона зможе зберегти самостійність і довіру з боку Product Owner?

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

Якщо всі сторони не будуть відкриті один одному в тих проблемах, з якими вони стикаються і будуть приховувати труднощі комерційного або технічного плану, це все одно з часом стане відомо. Але довіра і повага буде втрачено.

Недостатньо просто сказати «так, мовляв, ми всі розуміємо, що таке Scrum і будемо діяти за його принципам». Перш за все всім потрібно прочитати Scrum Guide. Серйозно, потрібно прочитати. Виниклі питання і непорозуміння потрібно обговорити і узгодити. Коли всі конфлікти можна, кожна із сторін повинна прямо і недвозначно заявити, як вона збирається працювати по Scrum, або взаємодіяти з Scrum командами. І тільки тоді можна буде починати діяти, і діяти потрібно рішуче і негайно.

Для досягнення спільного розуміння процесу всі повинні дотримуватися єдиної термінології. Хоча це здається дрібницею і формалізмом, це дійсно важливо. Якщо власник бізнесу називає Product Owner'а «Продукт-менеджером», розробники «начальством», а сам Product Owner величає себе, наприклад, "Імператором", можна говорити про те, що досягнуто взаєморозуміння?

Досягнення загальної стратегії компанії по Scrum — важливе і складне завдання. Без її вирішення рухатися далі безглуздо. Тим не менш вона здійсненна. Але це лише перший крок, і труднощі тільки починаються.

В наступному пості я постараюся детальніше розкрити типові помилки при реалізації Scrum в розробці, причини, за якими вони зводять користь від Scrum до нуля і способи їх виправлення.

Дмитро Мамонов

Департамент розробки,
Підрозділ мержа у майстер,
Відділ роботи з гіт,
Молодший оператор баш консолі

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

0 коментарів

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