Хто такі “девелопери” у Scrum?

Хто такі “девелопери” у парадигмі Scrum? Чому всіх учасників скрам-команди називають “девелоперами”? У чому різниця між девелоперами скрам-фреймворку та іншими?

Слава Москаленко, перший тренер від scrum.org в Україні, співзасновник Agile.Live, практик із світовим досвідом запровадження Scrum (Сінгапур, США, Велика Британія, Австралія та ін.) пояснює різницю.

Один термін, різні значення

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

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

Визначення понять

Взагалі девелоперами називають багато кого — будівельників, фахівців із розвитку бізнесу чи організацій тощо. У нашому контексті йдеться про галузь інформаційні технології та галузі, що їх інтегрують у свої бізнес-процеси.
Сам термін “девелопер” набув популярності в Україні доволі давно. Ще в мої студентські часи побутував термін Software Developer (розробник програмного забезпечення), що міг стосуватися різних мов програмування, у той час як Software Engineer передбачав вужчу спеціалізацію, так само як:

• Net-Developer;
• Java-Developer;
• Full Stack-Developer та ін.

У широкому чи вузькому значенні — йдеться про “розробників”.

Специфіка Scrum

У Scrum “девелоперами” вважають усіх причетних до розробки продукту й підвищення його цінності для кінцевих споживачів та стейкхолдерів.

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

Складнощі

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

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

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

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

Проблеми

Невідомо чому, але існує певна сакралізація “вузької спеціалізації”. Певна річ, найкращим можна бути в чомусь одному. Та хіба це означає зупинку професійного розвитку? Адже “інтеграція” апріорі передбачає взаємодії різних систем.

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

Рішення

Продукт не обов’язково є новою технологію. Водночас нова технологія не буде цінною, якщо не буде вдало інтегрована в існуючий продукт. Іншими словами, технологія — не панацея.

Я наголошую на тому, що:

• Скрам потрібно створювати навколо бізнес-процесу, а не технології (яка може застаріти!);
• Варто просуватися у бік продукту та підвищення його цінності (а не “технології”).

Компонентні і кроскомпонентні команди

Щоб найкраще зрозуміти поняття “розробники” в Scrum, поміркуймо про компонентні та кроскомпонентні команди.

Наприклад, у розробці беруть участь інженери програмного забезпечення. Їх небагато, вони весь час зайняті й перевантажені, а тому створюють bottle-neck — “закупорюють”, заповільнюють процес на вході чи виході. Розгляньмо два приклади.

Кейс 1 — Рішення на користь кроскомпонентності

Компанія поставила завдання розробити дві нові технології та модифікувати шість уже існуючих. Проект був надзвичайно складний.

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

Звісно, що наша команда працювала повільніше, ніж зазвичай, але то було значно краще, аніж якби ми спокусилися на “недоскрам”.

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

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

На противагу, кроскомпонентна команда відповідає за реалізацію не однієї вузькоспрямованої системи, а всього бізнес-процесу.

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

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

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

Кейс 2 — Інвестиційний банк

Розповім іще один кейс із мого професійного досвіду. На замовлення одного зі світових інвестиційних банків наша команда мала створити нову технологію на базі вже існуючої.

Наш досвід і кваліфікація покривали 80% вимог. Одна з головних проблем полягала у застарілих технологіях (Сobol, Microsoft.Net тощо), та більша проблема полягала у тому, що ми не мали досвіду роботи зі старими технологіями.

Так ми втрапили у залежність від рідкісних експертів, графік яких був перевантажений і розписаний на кілька місяців уперед! Однак ми не могли сидіти, склавши ручки.

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

Із неабияким завзяттям ми реалізували весь бізнес-процес, незалежно від графіка роботи рідкісних спеціалістів.
У нас було 4 розробники, один тестувальник (який за кілька місяців навчився добре програмувати), ми утворили dream-team! “Дайте нам будь-яке завдання, ми вирішимо його — самостійно!” — ось було наше гасло. То був справжній ІТ-спецназ, елітний дивізіон.

Результат був феноменальним. За короткий час (півтора місяці) ми вивчили все, що нам було потрібно і реалізували проект раніше від попередніх прогнозів керівництва. (Зазвичай на такі завдання йшло 4-5 місяців). Топ-менеджери були в захваті. Щойно ми завершили цей проект, нас запросили в інших — на таких умовах, відмовитися від яких було неможливо.

Висновки

Що означає мати команду “девелоперів” у Scrum? Поділюся своїми міркуваннями:

• Краще мати п’ятьох справжніх девелоперів (без звуження у бік “тільки” — тільки JavaScript, тільки FrontEnd, тільки BackEnd тощо), які утворюють цілісну кросфункціональну та автономну команду.
• Варто прибрати титули (“старших”, “вищих”, геніальних тощо) з команди розробників.
• Класний девелопер першим пріоритетом ставить завдання бізнесу (а не амбіції кодувати улюбленою мовою програмування — і тільки нею).
• Крутий девелопер цікавиться розвитком ІТ-сфери — вивчає нові підходи, нові технології, розширює власну компетентність.
• Вмілий девелопер заглиблюється у завдання бізнесу, ставить запитання та комунікує (навіть якщо він інтроверт!) з представником бізнесу або фахівцем.
• Справжній девелопер здатний попросити про допомогу, коли її потребує. Це не ущемлює велич його персони.
• Особи, які не хочуть розширювати свій професійний горизонт (наприклад, вивчати інші мови програмування), навряд підійдуть для скрам-команди.
• Варто пам’ятати про іншу пастку — “нагрівати океан” (Boil the Ocean) — не потонути в океані знань, а навпаки — взяти тільки ту частинку, яка справді потрібна для вирішення завдання.
• Справжній девелопер у парадигмі Scrum володіє такими рисами, як лідерство та ініціативність. Адже саме такі люди здатні змінити всю організацію! Зауважте: я говорю не про “менеджмент”, а риси характеру, особистості. Менеджмент (керівники) мислить категоріями ресурсів, витрат, доходів тощо. Справжні девелопери (лідери, ініціатори) створюють набагато сприятливіші умови для менеджменту (розподілу ресурсів, зрозуміліші процеси тощо). Наприклад: “Дайте мені ще одного проактивного фахівця, і ми разом зробимо більше, аніж залучати багатьох різних пасивних фахівців…” — це тема для окремої розмови.
• Agile — риса справжніх девелоперів у Scrum.

ДОЛУЧИТИСЯ ДО AGILE.LIVE

• Найближчі сертифікаційні тренінги Agile.Live: Advanced Scrum Master with PSM II Certification, Professional Scrum Product Owner (PSPO), Professional Agile Leadership Essentials (PAL-E)
• Підписатися на сторінку у LinkedIn
• Підписатися на Telegram-канал Agile.Live
• Підписатися на You-канал Agile.Live