Ролі у SCRUM: Епізод ІІ. Повернення Scrum Master’а

Categories: DevelopmentAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

Автор: Олександра Скібіна, Project Manager, Kharkiv Agile Practice Head, Consultant, GlobalLogic Ukraine


Автор: Андрій Кульшан, Business Analyst, Product Owner, Consultant, GlobalLogic Ukraine


 

На зв'язку знову Олександра Скібіна та Андрій Кульшан і ми продовжуємо розбирати ролі, які бувають в SCRUM команді!
У цій колонці ми розберемося, хто ж такі стейкхолдери, dev команди і scrum-майстра. А для самих допитливих читачів - з'ясуємо, в чому ж ключова функція менеджера.
Поїхали!
Якщо ви пропустили перший Епізод, де ми розглядали роль Product Owner та бізнес-аналітика, то він прямо за посиланням.

Stakeholders

Термін "стейкхолдери" часто зустрічається в професійному середовищі. Можна подумати, що це одна або кілька осіб, за ким завжди фінальне слово. Часто це так, але водночас цей термін включає майже всіх учасників розробки. Серед них виділяють:

  • Клієнти. Безпосередні замовники, з якими ми співпрацюємо. Це особи, що приймають рішення, delivery і product менеджери з боку компанії-замовника. Також можуть бути люди з відділів маркетингу або продажів, які можуть допомогти нам зрозуміти, що потрібно зробити, з'ясувати очікування користувачів, надати аналітику ринку.

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

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

  • Всі інші. Наприклад, зовнішні регулятори. Якщо ви у медичній або фінансовій сфері, то ваші продукти повинні відповідати нормативам, правилам, законам, які часто контролюються спеціальними організаціями. У цю групу можна додати й внутрішніх регуляторів - наприклад, юридичний відділ. Вони не впливають безпосередньо на функціонал, але можуть накладати деякі обмеження.

Як зрозуміти, з ким як працювати?

Почати можна з матриці "Вплив / Зацікавленість". Вона допоможе визначити, куди віднести ту чи іншу групу стейкхолдерів, і як організувати процес взаємодії з ними.

  • Manage Closely - в правий верхній квадрант потрапляють стейкхолдери, які мають великий вплив і найбільше зацікавлені в продукті. З цією групою стейкхолдерів потрібно працювати в першу чергу.
  • Keep Satisfied - в лівий верхній квадрант потрапляють ті, хто не особливо зацікавлений в продукті, але мають великий вплив. Це можуть бути ті ж зовнішні регулятори, або голови юридичних відділів. Потрібно стежити, щоб вони не засмучувалися, додаючи необхідний функціонал в продукт.
  • Keep Informed - стейкхолдери, які дуже зацікавлені в продукті - у них зазвичай багато ідей, але при цьому вплив у них на проєкт невелике. Ображати їх не треба, тому ми їх інформуємо.
  • Monitor - є люди, які не зацікавлені й впливу ніякого на проєкт не мають. Проте, треба іноді на них поглядати, раптом вони перейдуть в якусь з інших груп, або висловлять ідеї, які виявляться корисними.

Тепер розгляньмо Dev команду більш детально

DEV team

 

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

Команда повинна бути крос-функціональна. Це означає, що всередині команди повинні бути всі ресурси, які необхідні для виконання потрібної роботи в спринті. Якщо потрібен сторонній фахівець, такий як UX дизайнера або DevOps, то завдання Product Owner - заздалегідь подбати про його притягнення. Потрібно все спланувати таким чином, щоб на момент старту спринту мінімізувати кількість зовнішніх залежностей.

Ще один важливий пункт - Scrum не визнає ніяких титулів всередині команди. Думка кожного члена команди важливо і кожна людина може вплинути, при оцінюванні історій. І ще! Ми не створюємо підкоманду всередині команд - вся scrum команда являє собою єдиний підрозділ.

Scrum Майстер

Придивімося до ролі scrum майстра.  Можна виділити 5 основних його завданнь.


  1. Основна задача - це служити команді. Якщо на шляху команди виникає будь-яка перешкода - завдання Scrum майстра його усунути.
  2. Фасилітація. Він фасилітує більшість мітингів: планування спринту, стендап, ретроспективи, демо мітинги.
  3. Scrum майстер повинен займатися навчанням своєї команди. Тобто навчати учасників команди взаємодії один з одним і з представниками бізнесу, оптимізувати процеси, підвищувати їх ефективність, а також пояснювати які цілі стоять перед командою в поточному спринті, і які очікування є з боку клієнтів.
  4. Scrum майстер повинен взаємодіяти не тільки зі своєю командою, а й повинен працювати зі стейкхолдерами. В його обов'язки входить навчати стейкхолдерів як їм краще взаємодіяти з командою. Які процеси прийняті на проєкт і яким чином потрібно співпрацювати з командою.
  5. Scrum майстер постійно вдосконалює свої знання в області Agile та фасилітації. Він використовує всі можливості для поліпшення поточного процесу.

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

Scrum майстер, як частина Dev команди

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

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

Scrum майстер, як виділений фахівець

Плюси Scrum майстри як виділеного фахівця: йому не доведеться вибирати між двома ролями (розробника і власне майстра) і він зможе більше часу витрачати на навчання команди.

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

Роль менеджера

А хіба у Scrum передбачено роль менеджера? Нумо з'ясуймо.

У SCRUM проєктах ми рухаємося від традиційного погляду на менеджера як керівника проєкту в напрямку servant-leader позиції. Таким чином завдання менеджера - забезпечити всі необхідні умови для створення високоякісних продуктів і сформувати культуру проєкту. Він повинен допомагати команді й Scrum майстру усунути перешкоди та поліпшити процеси.

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

Менеджер повинен розуміти, що відбувається в командах, проводити регулярні мітинги зі Scrum майстрами й Product Owner, розбиратися в питаннях розробки. Досить часто менеджер грає одну з Scrum ролей.

Менеджер може грати роль Product Owner на проєкті, але на наш погляд, краще менеджеру бути Scrum майстром. Зараз ми аргументуємо чому.

Менеджер як PO. Є велика спокуса, що в якийсь момент він почне тиснути на команду, аби збільшити продуктивність. Додавати завдання, збільшувати їх обсяг, тощо. Менеджера почнуть сприймати виключно як людину, яка є джерелом завдань у трекері. У підсумку, такому менеджеру команда може не довіряти, люди перестануть ділитися своїми проблемами.

На наш погляд, краще обрати роль Scrum майстра. Що це дасть:

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

Але є нюанс - такий менеджер буде більше сконцентрований на розробці, а не на людях. Але з іншого боку, хіба ми тут не для цього?

Підбиймо підсумки. У цій колонці ми розглянули:

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

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

Хай буде з вами SCRUM!

Top Insights

Python: чому вивчати та з чого почати?

Python: чому вивчати та з чого почати?

InsightsSoftwareAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
Тонкощі CV або Як скласти та куди надіслати, щоб отримати пропозицію мрії про співпрацю

Тонкощі CV або Як скласти та куди надіслати,...

HRAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
CI/CD для JS розробників. Частина перша – теорія

CI/CD для JS розробників. Частина перша – теорія

DevelopmentSoftwareAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology
Soft and Hard Skills: Що важливіше? Розповідь одного рекрутера

Soft and Hard Skills: Що важливіше? Розповідь одного...

HRAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

ТОП автори

Oleh Moroz

Oleh Moroz

Test Engineer, Quality Assurance, GlobalLogic

Volodymyr Nos

Volodymyr Nos

Lead Software Engineer, Engineering, GlobalLogic

Mariia Krapyvka

Mariia Krapyvka

Specialist, GlobalLogic

Maryna Sergiyenko

Maryna Sergiyenko

Associate Manager, Engineering, GlobalLogic

Yaroslav Pushko

Yaroslav Pushko

Lead Software Engineer, Engineering, GlobalLogic

Категорії блогів

  • URL copied!