В одній з попередніх статей я вже писала про методологію Скрам і про те, як всього за 4 кроки зробити зі своєї звичайної команди суперкоманду. Сьогодні хочу повернутися до теми Scrum і розповісти про причини його популярності та про структуру методу. Тут немає нічого надскладного і всю методологію можна описати в одній невеликій статті.
У методології Scrum всього три ролі:
– Scrum Master
– Product Owner
– Team
Скрам Майстер (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. Він демонструє прогрес команди по ходу спринту.
У Scrum ітерація називається Sprint. Її тривалість становить 1 місяць (30 днів). Результатом Sprint є готовий продукт (build), який можна передавати (deliver) замовнику (принаймні, система повинна бути готова до показу замовнику). Короткі спринти забезпечують швидкий feedback проєктній команді від замовника. Замовник отримує можливість гнучко управляти scope системи, оцінюючи результат спринту і пропонуючи поліпшення до створеної функціональності.
Такі поліпшення потрапляють в Product Backlog, пріорітезуються нарівні з іншими вимогами й можуть бути заплановані на наступний (або на один з наступних) спринтів. Протягом спринту робляться всі роботи зі збору вимог, дизайну, кодування і тестування продукту. Scope спринту повинен бути фіксованим. Це дозволяє команді давати зобов’язання на той обсяг робіт, який повинен бути зроблений в спринті. Це означає, що Sprint Backlog не може бути змінений ніким, крім команди.
На початку кожного спринту проводиться планування спринту. У плануванні спринту беруть участь замовники, користувачі, менеджмент, Product Owner, Скрам Майстер і команда. Планування спринту складається з двох послідовних мітингів.
Планування спринту, мітинг перший. Учасники: команда, Product Onwer, Sсrum Master, користувачі, менеджмент. Мета: Визначити мету спринту (Sprint Goal) і Sprint Backlog -функціональність, яка буде розроблена протягом наступного спринту для досягнення мети спринту. Артефакт: Sprint Backlog.
Планування спринту, мітинг другий. Учасники: Скрам Майстер, команда. Мета: визначити, як саме буде розроблятися певна функціональність для того, щоб досягти мети спринту. Для кожного елемента Sprint Backlog визначається список завдань і оцінюється їх тривалість. Артефакт: в Sprint Backlog з’являються завдання. Якщо в ході спринту з’ясовується, що команда не може встигнути зробити заплановане на спринт, то Скрам Майстер, Product Owner і команда зустрічаються і з’ясовують, як можна скоротити scope робіт і при цьому досягти мети спринту.
Зупинка спринту проводиться у виняткових ситуаціях. Спринт може бути зупинений до того, як закінчаться відведені 30 днів. Спринт може зупинити команда, якщо розуміє, що не може досягти мети спринту у відведений час. Спринт може зупинити Product Owner, якщо необхідність в досягненні мети спринту зникла. Після зупинки спринту проводиться мітинг з командою, де обговорюються причини зупинки спринту. Після цього починається новий спринт: проводиться його планування і починаються роботи.
Цей мітинг проходить щоранку на початку дня. Він призначений для того, щоб всі члени команди знали, хто і чим займається в проєкті. Тривалість цього мітингу строго обмежена і не повинна перевищувати 15 хвилин. Мета мітингу – поділитися інформацією. Він не призначений для розв’язання проблем в проєкті. Всі питання, що вимагають спеціального обговорення, повинні бути винесені за межі мітингу. Скрам мітинг проводить Скрам Майстер. Він по колу ставить питання кожному члену команди:
– Що зроблено вчора?
– Що буде зроблено сьогодні?
– З якими проблемами зіткнувся?
Скрам Майстер збирає всі відкриті для обговорення питання у вигляді Action Items, наприклад у форматі що/хто/коли.
Рекомендована тривалість 4 години. Команда демонструє інкремент продукту, створений за останній спринт. Product Owner, менеджмент, замовники, користувачі своєю чергою його оцінюють. Команда розповідає про поставлені завдання, про те як вони були вирішені, які перешкоди були у них на шляху, які були прийняті рішення, які проблеми залишилися невирішеними.
На підставі рев’ю приймальна сторона може зробити висновки про те, як повинна далі розвиватися система. Учасники мітингу роблять висновки про те, як відбувався процес в команді й пропонують рішення щодо його поліпшення. Скрам Майстер відповідає за організацію та проведення цього мітингу. Команда допомагає йому скласти адженду і розпланувати, хто і в якій послідовності, що представляє. Підготовка до мітингу не повинна займати у команди багато часу (як правило – не більше 2 годин).
Методологія, як ви помітили, рясніє англійськими термінами й може здатися незрозумілою після першого прочитання. Однак Скрам стає куди більш зрозумілим після розподілу ролей і практичного застосування його інструментів. Після проведення першого Scrum Meeting і в кінці першого спринту ви з подивом виявите, що все працює “як треба”: завдання зрозумілі й чітко прописані, пріоритети виведені та дотримані, власне, як і таймінг.
