Примітка: Сайт перекладено автоматично. Переключіться на англійську для кращого читання.

зображення (1)

Чи може розробник бути Скрам-майстром? 3 переваги та недоліки

Команди Agile є основою сучасної розробки проектів. Але питання залишається відкритим: Чи може розробник бути ефективним скрам-майстром? Або навпаки: чи може скрам-майстер також бути розробником? Деякі тімліди переймаються цими міркуваннями. У цій статті ми спробуємо відповісти на це питання і виділити три переваги та недоліки цієї подвійної ролі.

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

Давайте почнемо з короткого визначення ролей, про які ми говоримо.

Чи може розробник бути Scrum Master | Scrum Developer

Скрам-розробник проти Скрам-майстра

Тому що в Scrum дуже важливі ролі. У зв'язку з цим важливим є розмежування "Скрам-розробник vs. Скрам-майстер": Скрам-майстер зосереджується на оптимізації процесу та усуває перешкоди для команди розробників. Скрам-розробник, навпаки, зосереджується на технічній реалізації вимог замовника.

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

Чи може розробник бути Scrum Master | Scrum Developer

Перевага: Agile Використовуйте синергію

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

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

Чи може Скрам-майстер бути розробником, або розробник бути Скрам-майстром? Якщо коротко, то це працюватиме, але може призвести до дезорганізації.

Чи може розробник бути Scrum Master | Scrum Developer

Недолік: брак об'єктивності

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

Другий вже згаданий недолік, який може мати ще більший вплив: об'єктивно кажучи, у більшості гнучких програмних проектів не вистачає часу, щоб ефективно виконувати обидві ролі - скрам-майстра та розробника програмного забезпечення - паралельно. Деякі обов'язки постраждають у будь-якому випадку. А недоліків ще більше.

Чи може розробник бути Scrum Master | Scrum Developer

Недолік: залишення власної бульбашки

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

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

Отже, чи може Скрам-майстер бути частиною команди розробників чи ні? Підсумовуючи, так, це можливо, але не рекомендується.

"Багато членів команди не наважуються висловитися!"

"Ми виявляємо занадто багато несподіваних проблем і помилок на пізньому етапі!"

"Чому іноді на підготовку простої ретроспективи я витрачаю години?"

Woman_pm
Ви очолюєте гнучку команду і...
📊... хочете вразити чіткими KPI щодо рівня гнучкості вашої команди?
⏱️... не маєте часу на підготовку чудового гнучкого ретро?
Спробуйте Echometer безкоштовно.

Чи може розробник бути Scrum Master | Scrum Developer

Одне з рішень: цифрова підтримка коучингу

Якщо у вас дійсно немає іншого варіанту, окрім як заповнити роль Scrum-майстра "неповним" розробником програмного забезпечення, тоді вам дуже допоможе наш інструмент Echometer. – був розроблений, зокрема, і для цього виклику: "неповний робочий день" Scrum-майстра стає професійним тренером команди в ефективний спосіб за допомогою нашого простого інструменту.

Echometer - це цифровий інструмент, який допомагає гнучким лідерам команд з гнучкими ретроспективами та командами Health Check. Дистанційно, гібридно чи на місці: він робить командний коучинг вимірюваним і професіоналізує вашу роботу, заощаджуючи при цьому багато часу. Просто завітайте на наш сайт, щоб дізнатися більше: www.echometerapp.com.

"Якщо у вас дійсно немає іншого виходу, окрім як перетворити розробника програмного забезпечення на Scrum-майстра з неповною зайнятістю, принаймні спробуйте Echometer, щоб максимізувати ймовірність успіху".

Чи може розробник програмного забезпечення бути Scrum Master | Scrum Developer

Висновок - Розробники як Scrum-майстри

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

Наостанок, ось ще одна підказка: якщо ви хочете спробувати, як це - розвивати свою команду за допомогою нашого інструменту: Ви можете розпочати ретроспективу гнучкого розвитку без входу в систему, в даному випадку воркшоп "Keep, Stop, Start". 

Або ж просто перешліть наш сайт відповідальним колегам: www.echometerapp.com.

Відкриті питання зворотного зв'язку

Продовження: Що ми повинні зберегти?

Зупинка: На чому ми повинні зупинитися?

Початок: Що ми повинні почати робити?

Поділіться цією статтею зі своїми знайомими

Потрібен командний поштовх? Ось що вам потрібно зробити: Ретроспектива Spotify Health Check!

Перше питання про здоров'я: "😍 Ми із задоволенням ходимо на роботу і отримуємо задоволення від спільної праці".

Хочете ще? Спробуйте наш Retro Tool зараз.

Більше статей

Інформаційний бюлетень Echometer

Не пропускайте оновлення на Echometer та отримуйте натхнення для гнучкої роботи