SCRUM. Термінологія

Для того, щоб бути на одній хвилі зі своїми колегами, новачкам-тестувальникам, які тільки починають працювати у сфері ІТ здаються складними терміни, які з’являються у розмовах команди. І якщо із звичайними «дейліками» все більш менш зрозуміло, то сторі пойнт та інкремент продукту можуть і налякати або як мінімум насторожити. Для того,щоб пояснити загальну термінологію методики Scrum, ми підготували наш топ-20 найпоширеніших термінів.

Важливо розуміти та відрізняти поняття Scrum та Agilе і це насправді легше, аніж визначити, що з’явилось раніше – яйце чи курка?

Agile (англ. agile – гнучкий) – це сімейство гнучких підходів до розробки програмного забезпечення. Ці підходи базуються на маніфесті розробки ПЗ, основні пункти якого звучать наступним чином: «Люди та комунікації набагато важливіші за процес та інструменти», «Функціонуючий продукт є набагато важливішим, ніж ідеально вичерпна документація.» «Готовність до покращення продукту важливіша, аніж дотримання до початкового плану.»

Популярними представниками цього підходу є такі методології як Scrum та Kanban. 

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

Отже, підсумовуючи ми можемо сказати, що Scrum та Kanban виникли на основі Agile. І Agile є їхнім маніфестом та філософією.

Почнемо наш топ термінів Scrum методології із ролей у команді.

Скрам команда (Development team) – це команда розробників, які працюють над створенням функціоналу. Команда є самоорганізованою та крос-функціональною одиницею у методології, що означає, що команда сама звітує про хід роботи на проєкті та обирає порядок виконання завдань із беклогу продукту. Важливо розуміти що таке трактування даного терміну передбачає роботу спеціалістів, котрі знайомі із особливостями проєкту і будуть працювати над створенням продукту від початку до кінця. 

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

Власник продукту (Product Owner) – член команди, який відповідає за максимізацію цінності продукту, розробленого скрам командою. Ця людина несе відповідальність за ефективне керування беклогом та відображає  потреби замовників.

До завдань власника продукту входять:

• розробка та обговорення мети продукту (product goal);
• створення та пояснення позицій беклогу;
• упорядкування елементів беклогу;
• забезпечення прозорості, доступності та розуміння беклогу.

Скрам-майстер (Scrum master) – є фасилітаторами і тренерами для решти команди. Вони допомагають командам виконувати свою роботу, усуваючи будь-які перешкоди чи бар’єри, які перешкоджають виконанню проєктної діяльності.

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

Види подій у Скрам методології

Ітерація або спринт (Iteration or sprint) – це цикл виконання завдань або часові відрізки, які можуть складатися від одного тижня до місяця. За цей період, команда має розробити готовий до тестування продукт. Спринт складається із декількох статусів, а саме:

• планування (Sprint planning);
• інспекція роботи над проєктом (Daily Scrum);
• презентація результату (Sprint Review);
• аналіз (Sprint Retrospective).

Спеціалісти команди самі вирішують кількість завдань скільки вони можуть виконати протягом одного спринта.

І звісно, є певні правила та особливості спринтів, як наприклад:

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

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

Етап планування (Sprint Planning) – це етап спринту який ініціює спринт, під час якого планується робота, яку необхідно виконати. Призначення та формування мети спринту також відбувається на цьому етапі. В результаті з’являється план створений усією командою.В ході планування розглядаються наступні питання:

• Яка цінність цього спринту?
• Що буде готово у цьому спринті?
• Як буде виконуватись ця робота?

Інспекція роботи (Daily Scrum) – це щоденні зустрічі скрам команди для спрощення процесу роботи над проєктом.

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

Перегляд спринту (Sprint Review) – це перегляд результату досягнутого за спринт.

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

Ретроспектива спринту (Sprint Retrospective) – це загальні збори для визначення результатів спринту. Основна мета ретроспективи спринту це запланувати покращення якості та ефективності наступного спринту. Збори ініціює скрам майстер, тож він так само як і команда аналізує не тільки особливості проєкту які з’явились під час останнього спринту, але також і комунікативну складову роботи команди. 

Ретроспектива завершує спринт і може тривати всього три години для спринту, що триває місяць.

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

Трьома важливими артефактами є:

• беклог продукту (Product backlog);
• беклог спринту (Sprint backlog);
• інкремент продукту (Product Increment).

Ми розглянемо пояснення до кожного з артефактів, і почнемо з беклогу продукту.

Беклог продукту (Product backlog) – це організований список того, що необхідно для покращення продукту. Це єдине джерело роботи, яку виконує скрам команда. Цей список постійно оновлюється.

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

Беклог спринту (Sprint backlog) – це план обсягу роботи, створений розробниками для самих себе. Це водночас доступна та наочна картина роботи, яка має бути виконана протягом спринту для того, щоб досягти мети спринту (Sprint Goal). Мета спринту (Sprint goal) – це єдина, сукупна ціль на увесь спринт.

Інкремент продукту (Product increment) – це доповнення до усього переліченого вище. Інкремент – це усі пункти беклогу зі статусом «виконано» (Done), які може переглянути і сам замовник під час перегляду спринту. Звісно, інкремент може бути надісланий клієнту ще до кінця спринту.

Статус «Виконано» гарантує, що немає непорозумінь щодо того, коли спринт або завдання можна назвати «виконаними». Члени Scrum-команди повинні чітко сформулювати вимоги до того, що потрібно зробити, щоб і замовник, і команда розуміли та погоджувалися.

Таймбокс (Timebox) – це певний проміжок часу, який був узгоджений заздалегідь. Цей час не можна продовжувати ні за яких обставин.

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

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

Шкала прогресу команди (Burn-up Chart) – це шкала, яка показує кумулятивну кількість виконаної роботи, нанесену на діаграму робочих днів. Щоразу, коли новий елемент вважається Готовим (Status Done), смуга на діаграмі підвищується.

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

Ідеальні години або дні (Ideal hours/days) – це поняття, яке використовується для визначення працездатності Scrum-команди.

Наприклад, 8 годин на день вважається звичайним робочим часом. Однак деякі з цих годин використовуються для планування, зустрічей, не запланованої роботи або соціальних взаємодій і не можуть вважатися «годинами розробки продуктів/послуг». Більш розумно очікувати, що члени команди приступлять до роботи 6 з 8 годин доступних на продукт або послугу.

Планування релізу (Release planning) – це підхід до організації роботи, який бере до уваги гнучку природу процесу розробки системного забезпечення. Його основна мета – це контроль також регулярних проміжкових релізів, на відміну від традиційного підходу, де все фокусується переважно на великих основних релізах. Планування релізу відбувається після окреслення основної мети продукту, його вигляду та процесу розробки.

Сторі пойнт (Story point) – це інструмент оцінювання складності та потрібного часу для роботи команди для  виконання певного завдання.

Призначення завдань на основі відносної складності дозволяє точніше відобразити зусилля, очікувані для виконання завдання, оскільки, на відміну від оцінок часу, сторі пойнти стосуються лише поточного завдання, а не несподіваних електронних листів, зустрічей або затримок, які можуть вплинути на час виконання завдання. Зазвичай для сторі пойнтс використовуються числа Фібоначчі. Сторі пойнтс застосовуються під час Скрам покеру (Scrum Poker) і більше про нього можна прочитати в іншій статті нашого блогу.

Історія користувача (User Story) – це коротке формулювання намірів користувача продукту та того, що цей продукт має зробити для користувача. Іншими словами, це інструмент який допомагає зафіксувати опис дій продукту з точки зору користувача.

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

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

У цій статті ми зібрали для вас найважливіші терміни методології Sсrum та сподіваємось, що вона стала у нагоді.