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

Автор: Олександра Скібіна, 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!