Огляд методології Scrum

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

Ролі
У методології Scrum лише три ролі:

Скрам Майстер (Scrum Master) – найважливіша роль методології. Скрам Майстер відповідає за успіх Scrum у проекті. По суті, Скрам Майстер є інтерфейсом між менеджментом та командою. Як правило, цю роль у проекті грає менеджер проекту або тимлід. Важливо наголосити, що Скрам Майстер не роздає завдання членам команди. В Agile команда є самоорганізованою та самоврядною. Основні обов'язки Скрам Майстра:

• Створює атмосферу довіри
• Бере участь у мітингах як фасилітатор
• Усуває перешкоди
• Робить проблеми та відкриті питання видимими
• Відповідає за дотримання практик та процесу у команді

Скрам Майстер веде Daily Scrum Meeting та відстежує прогрес команди за допомогою Sprint Backlog, відзначаючи статус усіх завдань у спринті. ScrumMaster також може допомогти Product Owner створювати Backlog для команди.

Product Owner - Це людина, яка відповідає за розробку продукту. Як правило, це product manager для продуктової розробки, менеджер проекту для внутрішньої розробки та представник замовника для замовлення розробки. Product Owner – це єдина точка ухвалення остаточних рішень для команди у проекті, саме тому це завжди одна людина, а не група чи комітет. Обов'язки Product Owner такі:

• Відповідає формування product vision
• Керує ROI
• Керує очікуваннями замовників та всіх зацікавлених осіб
• Координує та пріоритизує Product backlog
• Надає зрозумілі та тестовані вимоги команді
• Взаємодіє з командою та замовником
• Відповідає за приймання коду наприкінці кожної ітерації

Product Owner ставить завдання команді, але немає права ставити завдання конкретному члену проектної команди протягом спринту.

Команда (Team).У методології Scrum команда є самоорганізується і самоврядною. Команда бере на себе зобов'язання щодо виконання обсягу робіт на спринт перед Product Owner. Робота команди оцінюється як робота єдиної групи. У Scrum внесок окремих членів проектної команди не оцінюється, оскільки це розвалює самоорганізацію команди. Обов'язки команди такі:

• Відповідає за оцінку елементів баклогу
• Приймає рішення щодо дизайну та імплементації
• Розробляє софт та надає його замовнику
• Відстежує свій прогрес (разом зі Скрам Майстром)
• Відповідає за результат перед Product Owner

Розмір команди обмежується розміром групи людей, здатних ефективно взаємодіяти віч-на-віч. Типові розміри команди – 7 плюс мінус 2.

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

Команда самоорганізується до виконання конкретних завдань у проекті, що дозволяє їй гнучко реагувати будь-які можливі завдання. Для полегшення комунікацій команда має бути в одному місці (colocated).Переважно розміщувати команду не в кубиках, а в одній спільній кімнаті для того, щоб зменшити перешкоди для вільного спілкування. Команді необхідно надати все необхідне для комфортної роботи, забезпечити дошками та фліпчартами, надати всі необхідні інструменти та середовище для роботи.

Product Backlog – це пріоритезований список наявних на даний момент бізнес вимог та технічних вимог до системи. Product Backlog включає use cases, defects, enhancements, technologies, stories, features, issues, і т.д.. Product backlog також включає завдання, важливі для команди, наприклад «провести тренінг», «добити всім пам'яті»

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

Sprint Backlog містить функціональність, вибрану Product Owner із Product Backlog. Усі функції розбиті по завданням, кожна з яких оцінюється командою. Кожен день команда оцінює обсяг роботи, який потрібно зробити для завершення завдань.

Сума оцінок роботи може бути побудована як графік залежності від часу. Такий графік називається Sprint Burndown chart. Він демонструє прогрес команди в ході спринту.

Спринт (Sprint)
У Scrum ітерація називається Sprint. Її тривалість становить 1 місяць (30 днів).Результатом Sprint є готовий продукт (build), який можна передавати (deliver) замовнику (принаймні система має бути готова до показу замовнику). Короткі спринти забезпечують швидкий feedback проектної команди від замовника. Замовник отримує можливість гнучко керувати scope системи, оцінюючи результат спринту та пропонуючи покращення до створеної функціональності.

Такі покращення потрапляють у Product Backlog, пріоритезуються нарівні з іншими вимогами і можуть бути заплановані на наступний (або на один із наступних) спринтів. Кожен спринт є маленьким «водоспадом». Протягом спринту робляться всі роботи зі збирання вимог, дизайну, кодування та тестування продукту. Scope спринту має бути фіксованим. Це дозволяє команді давати зобов'язання на той обсяг робіт, який має бути зроблено у спринті. Це означає, що Sprint Backlog не може бути змінений ніким, окрім команди.

На початку кожного спринту проводиться планування спринту. У плануванні спринту беруть участь замовники, користувачі, менеджмент, Product Owner, Скрам Майстер та команда. Планування спринту і двох послідовних мітингів.

Планування спринту, мітинг перший. Учасники: команда, Product Onwer, Sxrum Master, користувачі, менеджмент Мета: Визначити мету спринту (Sprint Goal) та Sprint Backlog –функціональність, яка буде розроблена протягом наступного спринту для досягнення мети спринту. Артефакт: Sprint Backlog.

Планування спринту, мітинг другий. Учасники: Скрам Майстер, команда Ціль: визначити, як саме розроблятиметься певна функціональність для того, щоб досягти мети спринту.Для кожного елемента Sprint Backlog визначається список завдань та оцінюється їхня тривалість. Артефакт: у Sprint Backlog з'являються завдання Якщо в ході спринту з'ясовується, що команда не може встигнути зробити заплановане на спринт, Скрам Майстер, Product Owner і команда зустрічаються і з'ясовують, як можна скоротити scope робіт і при цьому досягти мети спринту.

Зупинка спринту (Sprint Abnormal Termination)

Зупинка спринту провадиться у виняткових ситуаціях. Спринт може бути зупинений до закінчення відведених 30 днів. Спринт може зупинити команду, якщо розуміє, що не може досягти мети спринту у відведений час. Спринт може зупинити Product Owner, якщо потреба у досягненні мети спринту зникла. Після зупинки спринту проводиться мітинг із командою, де обговорюються причини зупинки спринту. Після цього починається новий спринт: проводиться його планування та стартують роботи.

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

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

Скрам Майстер збирає всі відкриті для обговорення питання у вигляді Action Items, наприклад у форматі що/хто/коли:

• Обговорити проблему з відображенням контролю
• Петя та Вася
• Відразу після скраму

Демо та ревью спринту
Рекомендована тривалість: 4:00 Команда демонструє інкремент продукту, створений за останній спринт. Product Owner, менеджмент, замовники, користувачі своєю чергою його оцінюють. Команда розповідає про поставлені завдання, про те, як вони були вирішені, які перешкоди були у них на шляху, які були прийняті рішення, які проблеми залишилися невирішеними.

На підставі рев'ю сторона, що приймає, може зробити висновки про те, як повинна далі розвиватися система. Учасники міітингу роблять висновки про те, як йшов процес у команді та пропонує рішення щодо його покращення. Скрам Майстер відповідає за організацію та проведення цього мітингу. Команда допомагає йому скласти адженду і розпланувати, хто і в якій послідовності, що представляє. Підготовка до мітингу не повинна займати у команди багато часу (правило не більше двох годин).

Зокрема саме тому забороняється використовувати презентації в Power Point. Підготовка до мітингу не повинна займати у команди більше двох годин.

Міні-довідник та посібник з Scrum

Ця стаття – це міні-довідник і посібник з методу Scrum, створені в результаті прочитання книги Сазерленда, статей з інтернету та застосування на практиці.

Треба розрізняти Agile та Scrum. Agile – це методологія (наука), а Scrum – це спосіб досягнення мети.

Застосовуючи Scrum важливо мати справжню команду професіоналів, дотримуватись умов прозорості, відкритості та довіри.

Члени команди мають бути задоволені своєю діяльністю, бути щасливими у своїй роботі. Стан щастя призводить людей до чудових результатів.

Щасливі люди успішніші на 50%. А значить вони на 50% продуктивніші, якщо щасливі і знаходять сенс у своїй роботі.При цьому вони на 88% лояльніші, бо розуміють, що працюють не дарма, присвячуючи половину свого часу розвитку цього бізнесу.

- Доктор Коррі Блок, експерт зі стратегії бізнесу в галузі оцінки щастя.

Міні-довідник Scrum

Scrum (Скрам) - сутичка, гнучкий метод управління проектами. Термін прийшов із гри регбі.

Product Owner (Продакт оунер) – власник продукту, що сполучна ланка між замовником та командою розробки. Найголовніша відповідальність Product Owner – це створення та контроль Product Backlog.

Основні обов'язки та відповідальність Product Owner при керуванні Product Backlog:

• визначення елементів беклогу продукту;
• правильне розташування елементів для оптимізації досягнення мети;
• забезпечення зрозумілості та прозорості Product Backlog;
• забезпечення прозорості та зрозумілості вимог, над якими має працювати всієї Scrum Team;
• загальна оптимізація задля досягнення найбільшої цінності роботи Development Team;
• відповідальність за розуміння беклогу командою розробки.

Scrum Master (Скрам майстер) – арбітр, який організовує та проводить наради, стежить за дотриманням усіх принципів скраму, дозволяє протиріччя та захищає команду від відволікаючих факторів, проводить фасилітацію мітингів, відповідає за облік, зберігання та видачу SCRUM-інвентарю. Ця роль передбачає нічого іншого, крім коректного ведення скрам-процесу.

Scrum Master не дає завдань, а усуває проблеми, що виникають усередині команди.
Крос-функціональна команда розробників проекту, що складається із фахівців різних профілів: програмістів, тестувальників, аналітиків, архітекторів тощо.

Development Team (Девелопмент тим) - команда розробки, крос-функціональна команда розробників проекту, що складається зі спеціалістів різних профілів: програмістів, тестувальників, аналітиків, архітекторів і т.д. Розмір команди складає від 5 до 9 осіб (5 оптимально). Команда є єдиним повністю залученим учасником розробки та відповідає за результат як єдине ціле. Дана робоча одиниця є самодостатньою, самоврядною та самоорганізованою. Це як єдиний організм, що складається з окремих елементів.

Stakeholders (стекхолдерс) – дослівно акціонери, особи, які ініціюють проект (бізнес-замовники), яким скрам-проект приноситиме вигоду. Вони залучені в скрам лише під час оглядової наради зі спринту (Sprint Review).

User - Користувач продукту.

Product Backlog (продакт беклог) – або Backlog вимоги до продукту, побажання замовника щодо функціоналу та дизайну, всі «хотілки»; вони розставляються за рівнем важливості та цінності для замовника.

Epic (Епік) – одна з кількох глобальних функцій продукту. В епіку можуть бути User Story, наприклад, пакет побажань одного користувача або список завдань (Task) для реалізації Епіка.

User Story (юзер сторі) – або Story, cюжет, у яких містяться побажання користувача.

Task (Таск) – завдання, фрагмент, який необхідно виконати для реалізації мети проекту.

Sprint (Спринт) – часовий проміжок від 1 до 4 тижнів, за який команда створює частину продукту, готову до демонстрації та цінну для замовника. Оптимальна тривалість спринту – 1-2 тижні.Це робиться для того, щоб інформація, отримана на початку першого тижня, не забулася до кінця другого тижня і не потрібен час відновлення зв'язків.

Sprint Goal (Спринт гоол) – мета спринту.

Sprint Planning Meeting (Спринт пленін мітін) - планування Sprint, скрам-збори, де бере участь Scrum Team. Вибираються завдання з Беклогу, які можна виконати за спринт.

Scrum Poker (Скрам поке) - швидкий і точний спосіб збору оцінок за допомогою колоди карт з числами Фібоначчі (1,2,3,5,8,13). Можна використовувати мобільні програми для Scrum Poker. Завдання з оцінкою 13 необхідно дробити більш дрібні.

Story Points (сторі поінтc) – одиниця оцінки складності виконання завдання. Story Points має сенс застосовувати, якщо проект складається з трьох і більше спринтів, оскільки у команди накопичується статистика та досвід оцінювання завдань. На проекті з одного-двох спринтів використовувати Story Points немає сенсу, якщо не для отримання практики.

Daily Scrum Meeting (Дейлі скрам мітін) - щоденні збори не більше 15 хвилин, що проводиться в один і той же час. Бере участь скраму, спостерігати можуть усі. Проводить скрам-майстер. Мета мітингу – оперативний обмін інформацією, все в курсі того, що відбувається, немає комунікаційних розривів. Постають три запитання: що зробив учора? що робитимеш сьогодні? які перешкоди постають шляху до мети?

Sprint Review (Спринт ревью) – огляд спринту, беруть участь усі, зустріч відкрита. Команда розповідає, що було зроблено і демонструє ті частини проекту, які остаточно готові.

Sprint Retrospective Meeting (Спринт ретроспектив мітін) - ретроспектива, бере участь скрам тим. Збори за "круглим" столом.Обговорюються питання: що пройшло добре, а що погано? що можна було зробити краще? Головне, нікого не викривати! Розглядається робочий процес. Мета - вдосконалення робочого процесу, стати "супер" командою.

Definition of Done (DoD) (Дефенишин оф дан) - критерій, що визначає ступінь готовності завдання. Застосовується у випадках коли остаточно неможливо перевірити готовність завдання, наприклад, якщо елемент функціоналу перебуває у інший скрам команді чи компанії. Опис DoD починається зі рядка «done = », наприклад, done = функціонал реалізований в тестовому середовищі, потрібно вивантаження та перевірка в основному середовищі.

Velocity (велосіті) - швидкість команди; для аналітики будується графік Velocity, де по осі Х у спринтів, а по осі Y Story Points. На основі цих показників вибудовуються середні Velocity і Story Points.

Burndown Chart (Бердаун Чарт) - діаграма згоряння завдань. Напрямок графіка зверху вниз. Призначений для відстеження обсягу робіт, що залишився, де по осі Х у дні спринту, а по осі Y у Story Points. Першому дню спринту відповідає максимальна кількість Story Points.

Burnup Chart (Бернап Чарт) - діаграма згоряння завдань. Напрямок графіка знизу вгору. Призначений для відстеження обсягу робіт, де по осі Х у дні спринту, а по осі Y у Story Points. Останньому дню спринту відповідає максимальна кількість Story Points.

Abnormal Termination (Абнормол термінейшн) – зупинка спринту, аномальна дія. Зупинку ініціює Product Owner. Відбувається мітинг, де обговорюються причини виникнення Abnormal Termination. Потім спринт запускається знову.

Керівництво Scrum

Product Backlog
Формується при спільній зустрічі або індивідуальних інтерв'ю з усіма зацікавленими особами (стекхолдерами, користувачами). Записуються User Story, вимоги та побажання.

1. Основні поля у картці: id, назва, важливість, оцінка, реліз, опис, автор, виконавець;
2. Додаткові поля картки. Наприклад, поле «Тематика» – рейтинг товару в інтернет-магазині зараз не потрібен, а до рейтингу входять кілька завдань. Тоді можна змінити «важливість» всіх завдань із цією тематикою;
3. Завдання краще розбивати за однаковими типами.

Завдання з компонентами типу: 3IIIC, 5VE складніші і потребують більше часу.

123, ABC - швидше, тому що мозку не треба перемикатися між різними типами завдань.

User Story

1. Отримання від замовника Бізнес-мети. Складаємо Impact Map для кожної бізнес-мети: Why?->Who?->How?->What? (Навіщо? -> Хто? -> Як? -> Що треба зробити?);
2. Формулювання User Story:
   Будучи користувачем я хочу зробити, щоб отримати.
   Як менеджер складу я отримую звіт про товарні залишки, щоб ШВИДШЕ ухвалити рішення;
   Формулювання без ЩОБ (так краще).
   Як, я,.
   Як менеджер складу я отримую звіт про товарні залишки ШВИДШЕ.
3. Поділ «акторів» на групи: цільова, важлива, менш важлива тощо. Присвоєння унікальних назв акторам у цих групах, навіть якщо є однакові ролі «Користувачі системи»;
4. Написання історії з погляду цих акторів із зазначенням унікальних назв;
5. У результаті можна побачити, які історії необхідні акторам цільової групи, важливої ​​групи ітд. Отже можна побудувати пріоритет;
6. Дія. Важливо описувати історію лише на рівні «Що?» робить, а чи не «Як?», описати проблему, а чи не її вирішення. "Як?" знаходиться разом із командою;
7. Цінність. Відмова від формулювання "Щоб".Для історій можна вказати цінність історії у форматі «Щоб», але не для більшості;
8. Перехід із поняття «цінність» (value) на поняття «вплив» (impact). Історія не обов'язково повинна мати цінність, але обов'язково має впливати на того актора, який вказаний в історії. Цей вплив зрештою веде до мети;
9. User Story розбиваються за важливістю та функціональністю і далі розбиваються на завдання у белогу.

Відбувається разом із Development team. Команда має оцінити кожне завдання: чи здійсненна вона в принципі? чи достатньо інформації для виконання?

Формується Sprint. Sprint Planning Meeting. Scrum Poker

Тривалість мітингу трохи більше 8 годин. Для 2-х тижневого спринту мітинг триває дві години. Для візуалізації виконання завдань у спринті зручно використовувати Kanban-дошку.

1. Перша частина мітингу можуть брати участь усі.
   Право голосу у Product Owner та Developer Team. Вибір User Story та Завдання з Product Backlog у Sprint Backlog;
   Формулювання мети спринту - Sprint Goal. Визначення цінності бізнесу. Короткий опис бізнес-мети, заради якої виконується цей спринт. Допомагає команді приймати бізнес-обґрунтовані рішення або альтернативні рішення.
2. Друга частина мітингу беруть участь лише у Scrum Team. Наповнення Sprint Backlog.
   Визначення, як буде реалізовано обсяг робіт. Обговорення технічних деталей;

Розставлення Story Points (за основу взято низку Фібоначчі - 1,2,3,5,8,13). Завдання 13 і більше поінтів необхідно дробити більш дрібні. Термін виконання завдання одним розробником не більше одного дня або 8 годин. Якщо в проекті всього один спринт, то немає сенсу розставляти Story Points, тому що не буде статистики і не буде точності визначення оцінок.
Для коректного присвоєння Story Points можна статистику, як, наприклад, у такій таблиці:

1. Scrum Master веде збори;
2. Product Owner представляє короткі огляди кожного завдання;
3. Відбувається обговорення, запитують;
4. Учасники Developer Team обирають по одній карті, потім перевертають;
5. Якщо в результаті голосування є великий розкид в окулярах, то вислуховують двох, які перевернули карти з мінімальним та максимальним значенням;
6. Потім голосують знову і надають задачі Story Points.

Проводиться щодня. Усі можуть спостерігати.

1. Проводиться в один і той же час;
2. Триває строго трохи більше 15 хвилин.
3. Всі відповідають лише на три питання, відповідають один одному, не Scrum Master-у: Що я зробив сьогодні?Які проблеми є у мене та команди на шляху до мети?

Беруть участь усі. Знамениться значним приростом функціоналу продукту.

Тривалість мітингу: по одній годині на тиждень спринту (2 години Sprint Review = 2-тижневому спринту). Підготовка до цієї зустрічі не повинна перевищувати 2-х годин.

Sprint Retrospective Meeting.

Проводиться останній день спринту.

Покликана оцінити результат команди: що можна поліпшити?
Час на ретроспективу для 2-х тижневого спринту трохи більше 2-х годин.
Поняття Кайдзен та щастя. Кайдзен – безперервне вдосконалення.

Можна запитати: Що може зробити вас щасливішим у наступному спринті? Що зробить вас щасливішим взагалі?

Хто є хто: ролі та обов'язки у Scrum

Як працює scrum-команда та як її учасники пов'язані один з одним.

Дар'я Лебедєва

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

Що таке Scrum команда

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

1. Крос-функціональність - учасники команди мають всі необхідні компетенції для створення продукту. Це не означає, що всі повинні вміти всі, але за потреби вузькому фахівцю хтось повинен прийти на допомогу або замінити його у разі відсутності. Це забезпечує незалежність команди від зовнішніх факторів.
2. Самоорганізованість - члени команди самостійно розподіляють роботу між собою, визначають цінність завдання та призначають дедлайн.
3. Співприсутність - скрам команді необхідно перебувати в одному просторі один з одним для оперативної комунікації.Раніше обов'язково було перебувати як мінімум в одному офісі, але з переходом на видалення обов'язковою умовою став швидкий зв'язок та відповіді на запитання.
4. Зосередженість — учасники команди займаються лише одним проектом, не розпорошуючись на інші. Це дозволяє максимально концентруватися на поставлених завданнях та досягати високих результатів.
5. Довгостроковість — оскільки на формування нової скрам команди витрачається час, учасників зазвичай збирають разом на тривалий термін, оскільки тільки так можна досягти максимального розуміння між членами команди.

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

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

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

Ролі та обов'язки в Agile команді

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

Product owner

Назва ролі звучить так, ніби обраний учасник команди буде менеджером проекту чи тим лідом, але це не зовсім так. Власник продукту поєднує кілька функцій, які зазвичай виконують різні співробітники:

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

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

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

Крім професійних якостей, роль власника продукту в скрамі вимагає від учасника команди мати деякі особисті якості, такі як:

• комунікабельність – для встановлення близького контакту з усіма учасниками команди;
• лідерство - для спрямування роботи команди та прийняття рішення;
• наполегливість – для вміння переконувати;
• стресостійкість - для збереження спокою у непростих ситуаціях.

Scrum-майстер

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

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

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

Development team

Можна скористатися декількома перекладами - "команда розробників", "команда розробки продукту", "команда створення продукту". Учасників команди розробки продукту називають "developers". Через те, що слово «розробник» найчастіше асоціюється зі сферою IT, може здатися, що йдеться про програмістів, але це не так.У посібнику Scrum зазначено, що під «developers» можуть бути вказані представники різних професій: маркетологи, дизайнери, розробники ігор, програмісти та багато інших.

Ці учасники scrum команди займаються безпосередньо роботою із завданнями, усуненням помилок, і багів. Розмір команди розробників від 3 до 9 осіб. другом.

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

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

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

Обов'язки development team:

• робота над завданнями в рамках беклог продукту;
• передача точних результатів роботи один одному та заінтересованим особам.

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

Професійний інструмент для роботи Agile-команд. Спробуйте модуль Scrum на своєму проекті

Як працює команда scrum?

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

У скрам команда працює за чітко визначеними часовими інтервалами — спринтами. Вони тривають від одного до чотирьох тижнів. Структура спринту виглядає так:

1. Планування спринту. Власник продукту і скрам-майстер вибирають завдання з беклогу продукту, формують завдання з історій користувача і з запитів зацікавлених осіб, ставляться цілі. Після цього власник продукту збирає всіх членів команди, пояснює цілі спринту, відповідає питанням учасників. Потім команда розподіляє між собою завдання на канбан дошці та починають працювати з ними.
2. Щоденні мітинги. Це щоденні зустрічі команди перед початком робочого дня та після нього. На першій зустрічі учасники команди кажуть, чим займатимуться, на другій – що зробили. Також під час мітингів члени команди можуть розповісти про проблеми під час роботи. Деякі команди проводять обидва мітинги на день, інші проводять лише один. Мітинги важливі для scrum-команди, оскільки дозволяють контролювати прогрес у роботі та оперативно виявляти проблеми.Важливо пам'ятати, що на мітингу не обговорюється вирішення проблем, оскільки на нього виділено лише 15 хвилин. Під час мітингу скрам-майстер може помітити труднощі в учасників команди та після нього запропонувати допомогу.
3. Огляд спринту. Скрам команда у повному складі або тільки власник продукту звітують перед зацікавленими особами про результати спринту, отримують фідбек, обговорюють беклог продукту та беклог майбутнього спринту. Проміжні результати роботи також передаються заінтересованим особам після закінчення спринту.
4. Ретроспектива спринту. Скрам команда збирається разом та обговорює результати, що пройшло добре, які були проблеми, що нового дізналися учасники під час роботи. Також той, хто стежить за метриками якості в scrum команді показує, де саме команда зробила помилки, де прискорилася, а де не впоралася.

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

Як вибрати роль у scrum-команді?

Команда зібрана, визначено, який продукт створюватиметься, але ким стати? Усі учасники мають уявлення про scrum, працювали з фреймворком та мають достатні компетенції для роботи над продуктом. Якщо ви стикаєтеся з питанням, ким вам бути, подумайте, що вам ближче:

• якщо вам цікаво працювати з користувачами, ви володієте підсумковим баченням проекту, не боїтеся бути лідером, знаєтеся на нюансах бізнесу і користуєтесь довірою зацікавлених осіб, яким ви займаєтеся, вам можна рекомендувати роль product owner;
• якщо ви добре знаєтеся на принципах і цінностях scrum, вмієте працювати з людьми і домагатися їх довіри, надихаєте, вмієте стежити за показниками і знаєтеся на менеджменті, подумайте про роль scrum-master;
• Якщо ви володієте набором необхідних для створення продукту навичок і вам подобається їх застосовувати, вам підійде роль developer.

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

Підсумуємо

Що таке scrum команда Це група професіоналів, об'єднана однією метою — створенням продукту.

Власник продукту відповідає за зв'язок з клієнтами та працює з проектом з погляду бізнесу, scrum-майстер стежить за дотриманням цінностей скрам, спостерігає за метриками ефективності та допомагає команді ставати більш ефективною, а команда розробників займається безпосередньо створенням продукту.

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

Успішні компанії вже використовують Kaiten.