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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вирішіть цю проблему

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

Вирішіть цю проблему

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

Вирішіть цю проблему

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

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

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

Крістіан Хайдемайєр, психолог та скрам-майстер

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

Тому, ще раз нагадую: якщо ви хочете спробувати, як це – розвивати свою команду за допомогою нашого інструменту: ви можете запустити гнучку ретроспективу без входу в систему, в даному випадку майстерню «Keep, Stop, Start». 

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

Як це зробити

Keep Stop Start Retro: Як проходить ретроспектива

1. Випадковий Icebreaker (2-5 хвилин)

   Echometer надає вам генератор випадкових питань для реєстрації.

2. Огляд відкритих заходів (2-5 хвилин)

   Перш ніж почати з новими темами, слід поговорити про контроль ефективності того, що сталося з заходами з минулих ретроспектив. Echometer автоматично перераховує всі відкриті пункти дій з минулих ретроспектив.

3. Обговорення ретро-тем

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

   • Продовження: Що ми повинні зберегти?
   • Зупинка: На чому ми повинні зупинитися?
   • Початок: Що ми повинні почати робити?

4. Універсальне питання (рекомендовано)

   Щоб інші теми також мали місце:

   • Про що ще ви хочете поговорити на ретроспективі?

5. Пріоритезація / Голосування (5 хвилин)

   На ретро-дошці в Echometer ви можете легко розставити пріоритети для відгуків за допомогою голосування. Голосування, звичайно, є анонімним.

6. Визначення заходів (10-20 хвилин)

   За допомогою символу "плюс" на відгуку можна створити пов'язаний захід. Ще не впевнені, який захід буде правильним? Тоді відкрийте дошку для обговорення з цієї теми за допомогою символу "плюс", щоб провести мозковий штурм щодо основних причин і можливих заходів.

7. Виїзд / Закриття (5 хвилин)

   Echometer дозволяє збирати анонімні відгуки від команди про те, наскільки корисною була ретроспектива. Це створює оцінку ROTI ("Retrun On Time Invested"), яку ви можете відстежувати з часом.

Keep Stop Start Retro

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

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

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

Відкрийте це ретро зараз Пристосуватися...