Найскладніші терміни Scrum та їх пояснення

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

Чому важливо розуміти тонкощі термінології методики (окрім того, що «Scrum-майстер» буде звучати для вас наче людина з іншої планети)? Детальне і точне знання термінів забезпечить розуміння процесів, які відбуваються. А для найдопитливіших – дадуть відповідь на питання «А чому так?».

1. Agile це не суто Scrum, проте Scrum це точно Agile

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

Тож для того, щоб пояснити різницю між ними, найлегше звернути увагу на офіційну документацію:

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

2. Agile-фреймворк чи все-таки методологія?

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

Саме тому, Scrum буде фреймворком, адже він надає дещо спрощену структуру без покрокових інструкцій, де команда сама може впроваджувати свої технічні процеси та ролі розробки. Наприклад, такий Agile підхід, як Extreme Programming (XP), вже буде методологією, адже він має у собі точні технічні техніки. 

3. Самокеровані та самоорганізовані команди це одне й те саме?

Команда є чи не найголовнішою одиницею у розробці програмного забезпечення, тому розуміти принципи її роботи дуже важливо. Обидва терміни - «самокерована (self-managed)» та «самоорганізована (self-organized)» команда іноді є каменем спотикання. Саме тому, варто запам’ятати, що самоорганізована команда буде самостійно обирати шлях та спосіб виконання певного переліку завдань, у той час, як самокерована команда сама призначає завдання певному члену команди та обирає дедлайн для виконання цього завдання.

Проте, ані самокерована, ані самоорганізована команди не можуть робити що завгодно. Обидві команди повинні дотримуватись ієрархії та субординації.

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

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

4. Беклог продукту та Беклог спринту

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

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

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

5. Відносна оцінка та Оцінка на основі часу

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

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

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

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

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

6. Інкремент продукту чи Реліз?
Інкремент продукту вміщує всі завдання за один спринт. Коли відправляється або запускається інкремент зовнішнім зацікавленим сторонам і користувачам – це є релізом.

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

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

7. Визначення «Готово» (Done) та критерії прийнятності

Визначення «Done» визначає критерії якості для всіх ваших функцій і завдань. Воно працює на макрорівні.

Критерії прийнятності застосовуються на мікрорівні – вони визначають, як перевірити виконання конкретного завдання.

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

Ось приклад кожного:

• Визначення «Done»: тест пройдено, перевірка якості завершена, критерії прийняття для кожного елемента виконано;
• Критерії прийняття: коли користувач натискає посилання «змінити пароль», додаток відображає повідомлення про помилку, якщо користувач не зареєструвався за допомогою електронної адреси.

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

8. Рев’ю спринту та Демо спринту

Рев’ю спринту (Sprint Review) завершує спринт перевіркою виконаної роботи та обговоренням між командою Scrum та зацікавленими сторонами.

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

У багатьох організаціях рев’ю спринту визначається так само, як і демонстрація. Керівництво Scrum категорично не радить цього:

«Рев’ю спринту – це робоча сесія, і Scrum-команді не слід обмежуватися лише презентацією».

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

9. Безперервна інтеграція (Continuous integration) та безперервна доставка (continuous delivery)

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

Постійна інтеграція чи безперервна доставка?

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

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

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