Спринт в скрамі: міфи, помилки та вигадки

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

Основне. Що таке спринт у скрамі

Як пишеться в Посібнику зі скраму, спринт — це часовий відрізок тривалістю місяць або менше, протягом якого створюється «готовий», тобто придатний до використання й релізу інкремент продукту. Для ефективної розробки спринти мають мати однакову тривалість. Новий спринт завжди починається відразу ж по завершенню попереднього.

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

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

Міф перший. Зворотний зв’язок можна часом ігнорувати

Десятиліттями успіх проєктів з розробки вимірювався за допомогою “золотого трикутника менеджера”, тобто за співвідношенням тривалості, вартості й об’єму робіт. Як результат, загинув не один проєкт і народився не один безтолковий продукт: цей трикутник стосується успіху продукту лише опосередковано.

Та як тоді зробити проєкт успішним? Перш за все, пам’ятати про те, що скрам створено для розробки креативних ПРОДУКТІВ (не проєктів).

Головна ціль у застосуванні скраму — створити продукт, що користуватиметься попитом у користувачів і даватиме достатню окупність інвестицій (ROI). Найсерйозніший ризик у розробці — випустити нікому не потрібний продукт. Скрам зменшує цей ризик за допомогою частих циклів зворотного зв’язку. Щоб розробити потрібний продукт, скрам-команда регулярно проводить демонстрації (інспектує інкремент) на оглядах спринту. На цих зустрічах ключові стейкхолдери і кінцеві користувачі працюють з інкрементом продукту. Так ми отримуємо зворотний зв’язок, а власник продукту корегує плани — адаптує беклог продукту, а часом і план релізу.

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

Міф другий. Спринт провалився, якщо в ньому не вдалося досягти цілей

Оскільки процес у скрамі емпіричний, кожен спринт — це експеримент, у якому трапляються різні випадковості. Це тягне за собою деякі ризики — якраз ці ризики мають знизитися завдяки обмеженням часу.

Кен Швабер у книзі «Софт за 30 днів» (Software in 30 days) так описує випадковості в розробці: «Від початку в нас є бачення чи можливість, якою ми маємо скористатися. Розробники створюють додаток, щоб втілити найважливіші сторони нашого бачення. Ми дивимося на інкремент і починаємо думати, як будемо його використовувати. Ми обговорюємо, що додати, щоб зробити інкремент кориснішим. У деяких дисциплінах це також називається проміжним контролем. Ми проводимо його в кожній ітерації».

Якщо спринт розглядати як експеримент, а скрам — як емпіричний процес, стає зрозуміло:

Проваленим можна назвати спринт, наприкінці якого ми нічому не навчилися. При такому сценарії ми не можемо інспектувати й адаптувати результати роботи, не можемо кастомізувати продукт і процеси.

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

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

Приклад невдалого спринту:

Команда змогла закінчити багато функцій і виконати до огляду спринту все заплановане (завдяки овертаймам і зниженню якості). Та ніхто, крім власника продукту, не прийшов на огляд спринту. Розробники досі не бачать реакції користувачів, а стейкхолдери надто зайняті, щоб ходити на огляди. Немає жодного зворотного зв’язку про інкремент. Якщо так, то можна пропустити і ретро — всі надто зайняті. А тоді — почати новий «успішний» спринт.

Миф третій. Спринт не обов’язково закінчується випуском готового інкременту

Недосвідчені фахівці вважають, що не всі спринти мають закінчуватися створенням готового інкременту. В результаті з’являються різні види «недоспринтів», яких слід уникати. Ось деякі з них.

Спринт нуль

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

Дизайн-спринт

Такий «спринт» починають, щоб створити технічну архітектуру — посібник для всього наступного релізу. Цей випадок «важчий» за попередній: окрім того, що він не відповідає визначенню спринту, він ще й заважає інспекції й адаптації в наступних спринтах. Знову ж таки, ескізи архітектури й функціоналу можуть бути корисними як частина бачення продукту: так команда уникне ризику і налагодить діалог зі стейкхолдерами. Однак не слід розробляти детальний і фіналізований дизайн процесу.

Жорсткий спринт (Hardening Sprint)

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

Висновки

• Тим, хто працює за скрамом, потрібно створювати діючі творчі продукти, а не проєкти.
• Кожен спринт — це експеримент. Його результати обов’язково підлягають інспеції й адаптації.
• Якщо результати спринту не можна інспектувати й адаптувати, спринт вважається невдалим.
• У результаті спринту має з’являтися готовий інкремент продукту, а не жорстко визначений план наступних робіт. На цьому базується емпіризм скраму.

Стаття підготовлена за матеріалами й мотивами:

Перекладено й адаптовано командою BrainRain.

Спринт в скрамі: міфи, помилки та вигадки

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

Основне. Що таке спринт у скрамі

Як пишеться в Посібнику зі скраму, спринт — це часовий відрізок тривалістю місяць або менше, протягом якого створюється «готовий», тобто придатний до використання й релізу інкремент продукту. Для ефективної розробки спринти мають мати однакову тривалість. Новий спринт завжди починається відразу ж по завершенню попереднього.

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

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

Міф перший. Зворотний зв’язок можна часом ігнорувати

Десятиліттями успіх проєктів з розробки вимірювався за допомогою “золотого трикутника менеджера”, тобто за співвідношенням тривалості, вартості й об’єму робіт. Як результат, загинув не один проєкт і народився не один безтолковий продукт: цей трикутник стосується успіху продукту лише опосередковано.

Та як тоді зробити проєкт успішним? Перш за все, пам’ятати про те, що скрам створено для розробки креативних ПРОДУКТІВ (не проєктів).

Головна ціль у застосуванні скраму — створити продукт, що користуватиметься попитом у користувачів і даватиме достатню окупність інвестицій (ROI). Найсерйозніший ризик у розробці — випустити нікому не потрібний продукт. Скрам зменшує цей ризик за допомогою частих циклів зворотного зв’язку. Щоб розробити потрібний продукт, скрам-команда регулярно проводить демонстрації (інспектує інкремент) на оглядах спринту. На цих зустрічах ключові стейкхолдери і кінцеві користувачі працюють з інкрементом продукту. Так ми отримуємо зворотний зв’язок, а власник продукту корегує плани — адаптує беклог продукту, а часом і план релізу.

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

Міф другий. Спринт провалився, якщо в ньому не вдалося досягти цілей

Оскільки процес у скрамі емпіричний, кожен спринт — це експеримент, у якому трапляються різні випадковості. Це тягне за собою деякі ризики — якраз ці ризики мають знизитися завдяки обмеженням часу.

Кен Швабер у книзі «Софт за 30 днів» (Software in 30 days) так описує випадковості в розробці: «Від початку в нас є бачення чи можливість, якою ми маємо скористатися. Розробники створюють додаток, щоб втілити найважливіші сторони нашого бачення. Ми дивимося на інкремент і починаємо думати, як будемо його використовувати. Ми обговорюємо, що додати, щоб зробити інкремент кориснішим. У деяких дисциплінах це також називається проміжним контролем. Ми проводимо його в кожній ітерації».

Якщо спринт розглядати як експеримент, а скрам — як емпіричний процес, стає зрозуміло:

Проваленим можна назвати спринт, наприкінці якого ми нічому не навчилися. При такому сценарії ми не можемо інспектувати й адаптувати результати роботи, не можемо кастомізувати продукт і процеси.

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

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

Приклад невдалого спринту:

Команда змогла закінчити багато функцій і виконати до огляду спринту все заплановане (завдяки овертаймам і зниженню якості). Та ніхто, крім власника продукту, не прийшов на огляд спринту. Розробники досі не бачать реакції користувачів, а стейкхолдери надто зайняті, щоб ходити на огляди. Немає жодного зворотного зв’язку про інкремент. Якщо так, то можна пропустити і ретро — всі надто зайняті. А тоді — почати новий «успішний» спринт.

Миф третій. Спринт не обов’язково закінчується випуском готового інкременту

Недосвідчені фахівці вважають, що не всі спринти мають закінчуватися створенням готового інкременту. В результаті з’являються різні види «недоспринтів», яких слід уникати. Ось деякі з них.

Спринт нуль

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

Дизайн-спринт

Такий «спринт» починають, щоб створити технічну архітектуру — посібник для всього наступного релізу. Цей випадок «важчий» за попередній: окрім того, що він не відповідає визначенню спринту, він ще й заважає інспекції й адаптації в наступних спринтах. Знову ж таки, ескізи архітектури й функціоналу можуть бути корисними як частина бачення продукту: так команда уникне ризику і налагодить діалог зі стейкхолдерами. Однак не слід розробляти детальний і фіналізований дизайн процесу.

Жорсткий спринт (Hardening Sprint)

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

Висновки

• Тим, хто працює за скрамом, потрібно створювати діючі творчі продукти, а не проєкти.
• Кожен спринт — це експеримент. Його результати обов’язково підлягають інспеції й адаптації.
• Якщо результати спринту не можна інспектувати й адаптувати, спринт вважається невдалим.
• У результаті спринту має з’являтися готовий інкремент продукту, а не жорстко визначений план наступних робіт. На цьому базується емпіризм скраму.

Стаття підготовлена за матеріалами й мотивами:

Перекладено й адаптовано командою BrainRain.

Scrum Master: хто такий, чим займається і як ним стати

Налагодити роботу між членами команди, а також між командою та керівництвом компанії чи замовником продукту допомагає Scrum Master. Він — своєрідний вчитель-помічник, що дбає про ефективність всіх процесів в колективі. Що таке Scrum, навіщо потрібні майстри скраму в компаніях та які їх обов’язки — розбираємось детально у статті.

Зміст

Ефективне управління проєктами за допомогою scrum: коротка теорія

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

• Всі вимоги та задачі по проєкту додаються в загальний список — беклог, який являє собою своєрідне ТЗ, що складається з окремих завдань.
• Дії учасників команди обов’язково фіксуються в одному з інструментів управління робочим процесом — Jira чи інших .
• Кожен етап роботи над продуктом поділяється на спринти — короткі відрізки часу тривалістю від тижня до місяця. Найпоширеніший період — 14 днів.
• Спринт починається з планування та закінчується оглядом і ретроспективою (обговоренням подій та процесів в команді, які спостерігались протягом всього спринту). В межах кожного спринту проводяться щоденні 10-15-хвилинні зустрічі — Daily Scrum.
• В кінці спринту команда має презентувати вимірний результат, який буде частиною готового продукту.

Джерело зображення: https://commons.wikimedia.org/

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

Якщо розбирати сам термін « scrum » , то насправді він спортивний ( scrum — в перекладі з англійської — « бій навколо м’яча » , елемент гри в регбі ). Його значення переноситься і на роботу компанії. Учасники звичайно не « б’ються » , але, як і спортивна команда, — є єдиним цілим. Зазвичай, це близько 10 осіб, залучених до однієї справи. Вони налаштовані на загальний результат і прагнуть однієї цілі. Співробітники, працюючи над проєктом за допомогою цього методу, вчаться підтримувати один одного, аналізувати отриманий досвід, самоорганізовуватись, не боятись нововведень, бачити свої сильні та слабкі сторони.

Основні принципи роботи scrum-команди:

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

Scrum найчастіше використовують в IT-компаніях (відповідно, в цій галузі скрам-майстри і є найбільш затребуваними). Але методику можна застосувати для роботи команд в будь-якій іншій ніші (фінанси, промисловість, торгівля, маркетинг тощо), не лише інформаційних технологіях. Наприклад, за скрамом працюють у таких всесвітньо відомих компаніях, як Netflix, Adobe, Vodafone, Intel .

Scrum Master: хто це такий та яка його роль в компанії?

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

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

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

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

Обов’язки scrum-майстра

Методологія Scrum передбачає три головних ролі:

• Product owner або «власник продукту» — розпоряджається продуктом від імені компанії. Здійснює контроль над розвитком продуту, відповідає за максимізацію його цінності в результаті роботи скрам-команди. Він висуває вимоги до майбутнього продукту, визначає бачення, керує беклогом, контролює процес розробки.
• Scrum team — команда, що працює над проєктом.
• Scrum master — оптимізує роботу, допомагає власнику продукту і скрам-команді виконувати задачі без перешкод та відволікаючих факторів.

Також має сформовані етапи, за дотриманням яких слідкує безпосередньо спеціаліст зі скраму. Згідно з підходом, робота складається із наступних кроків:

1. Product owner ставить перед командою одне велике завдання.
2. Команда розділяє його на етапи — спринти.
3. Scrum team сумісно з власником продукту та скрам-мастером перевіряє працездатність результату. За потреби коригує план наступного спринту.
4. Дії повторюються.

На різних етапах scrum-мастер виконує наступні обов’язки:

• приймає участь у щоденних скрам-зустрічах для відслідковування процесу роботи, виявлення та усунення труднощів;
• долучається до планування задач на початку спринта — оцінює навантаженість кожного учасника;
• по завершенню кожного спринта збирає зворотний зв’язок від команди;
• управляє беклогом в планері: змінює статуси наявних задач, додає нові за узгодженим при плануванні списком, з’ясовує причини відтермінованих відкритих завдань;
• відслідковує та аналізує роботу над проєктом, веде звітність;
• організовує бесіди « віч-на-віч » із залученими до процесу;
• надає учасникам необхідні інструкції, слідкує за дотриманням scrum-цінностей;
• проводить внутрішні консультації з приводу організації роботи scrum-команди;
• сприяє подоланню різноманітних проблем, що впливають на продуктивність — навіть якщо це « повільний » комп’ютер чи некомфортне робоче місце, спеціаліст шукає способи вирішити питання.

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

Чого не робить scrum-майстер?

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

Scrum Master — не адміністратор Jira, не офіс-менеджер та не секретар. Так, він може принести каву комусь із скрам-команди, якщо це підбадьорить колегу та підвищить його продуктивність, однак зробить це виключно з власної ініціативи та бажання, без прив’язки до своїх функціональних обов’язків. У скрам-команді всі ролі учасників є рівнозначними. Відповідно, майстер не керує нею, а підтримує колектив та спрямовує його у правильне русло.

Чим скрам-майстер відрізняється від менеджера проєкту?

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

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

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

Що потрібно знати та вміти для роботи Scrum Master?

Щоб стати Scrum Master, не обов’язково мати освіту чи значний досвід в IT-сфері. Вони, безумовно, стануть перевагою. Але в першу чергу вирішальним для роботодавців буде перелік необхідних « м’яких » та професійних навичок у претендента. Отже, скрам-мастер повинен знати:

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

Список потрібних soft skills для успішного закриття робочих завдань на посаді Scrum Master — ширший. І за важливістю вони майже рівнозначні із hard skills. Фахівець зі скраму має бути:

• комунікабельним та емпатичним. Робота scrum-майстра потребує щоденної взаємодії з людьми. І зазвичай він виступає ініціатором в перемовинах з учасниками проєкту. Причому це можуть бути як формальні робочі мітинги, так і, інколи, бесіди « по душам » ;
• терплячим. Скрам-мастер пояснює, переконує, повторює. Інколи по 10 разів. Дуже бажано це роботи спокійно та доброзичливо;
• адаптивним. Підхід Scrum відрізняється гнучкістю та допускає експерименти. Вносити корективи у беклог не просто можна, а необхідно, якщо це буде на користь продукту. Експерту зі скраму слід не просто швидко адаптуватися під зміни, а й допомогти в цьому учасникам проєкту у разі виникнення такої потреби;
• лідером за характером. Хоч в спеціаліста відсутні управлінські обов’язки, він повинен захоплювати команду ідеями Scrum. А це неможливо, якщо складно здобути довіру колег;
• з організаторськими здібностями. Вони необхідні для проведення зустрічей згідно із затвердженим регламентом, навчання учасників команди правилам та цінностям підходу;
• кмітливим та винахідливим. Щоб швидко генерувати варіанти рішення проблем для орієнтування в складних проєктах.

Як стати Scrum Master?

Здебільшого в скрам-майстра перекваліфіковуються ІТ-фахівці суміжних напрямів. Наприклад, бізнес-аналітики, проджект-менеджери, бізнес-консультанти. Але претендувати на посаду можна і без досвіду в галузі інформаційних технологій. Головне — бажання та час на навчання. Отримати необхідну базу hard skills можна на курсі проджект менеджера від Wizeclub , який підійде як бажаючим опанувати професію Project Manager, так і майбутнім Scrum-майстрам. Адже навчальна програма складається з модулів, присвячених взаємодії з командою, методологіям Agile і фреймворку Scrum, особливостям роботи з програмним продуктом (від технічної термінології до знайомства з Jira). Онлайн-курси дозволять здобути відповідні знання, важливі для входу в професію Scrum Master.

Для підвищення конкурентоспроможності на ринку та перспектив на посаді обов’язкове проходження офіційної сертифікації. Таку можливість надають міжнародні організації, наприклад Scrum Alliance , Scrum.org , PMI . Проходження курсу із сертифікацією Scrum Master відбувається на англійській мові, включає в себе фінальний екзамен. Вартість залежить від обраної організації, однак орієнтуватись слід на витрати близько 1000 USD.

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