Процеси у Scrum

1. Планування спринту

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

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

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

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

Питання, які необхідно вирішити під час планування спринту:

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

На планування не можна відводити понад дві години на тиждень. Скрам-майстер має пояснити всім, що є часові обмеження. Якщо всі робочі питання вирішені швидко, збори можна закінчити раніше звичайного. Мінімальної тривалості для такої наради не передбачено.

2. Оцінка завдань

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

Для оцінки складності можна використовувати звичні для всіх розміри одягу (L, XL, XXL). Звісно, це не дає гарантії точності, але все ж.

Щоб оцінка складності була точнішою, потрібне порозуміння. Учасники команди повинні відкрито ділитися своєю думкою та не боятися ставити запитання власнику продукту.

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

Оцінка складності в очках, балах та годинах

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

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

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

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

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

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

3. Daily Scrum Meeting

Робочі наради мають важливе значення: на них учасники команди діляться своєю думкою, спілкуються та узгоджують подальші дії. Щоденні scrum-наради також потрібні для підняття командного духу та оголошення поточних новин.

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

• Що ми зробили вчора?
• Над чим ми сьогодні працюватимемо?
• Що заважає нам досягти результату?

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

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

А тепер обговоримо, що потрібно для ідеального стендапу і познайомимося з прикладами ефективних стендапів.

Для початку потрібно обрати час, який підходить усім. Зазвичай стендапи для команд з одного офісу проводяться на початку робочого дня між 9 і 10 годинами ранку. Це дозволяє краще спланувати розклад на день. Якщо ж учасники команди працюють у різних регіонах, то обирається час, який влаштує всіх. Наприклад, якщо деякі члени команди живуть у Каліфорнії та Сіднеї, тоді стендап починається о 15:30 за каліфорнійським часом. Зрозуміло, стендап після обіду не кожному зручний, але це дає можливість підтримувати зв'язок з колегами по інший бік океану.

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

Використовуйте м'яч. Його можна кидати один одному по черзі. Так кожен буде залучений до обговорення. Ця гра добре допомагає підтримувати увагу групи. Застосовуйте командну ретроспективу. Стендапи використовуються в багатьох Agile-методиках, це не заважає обговорювати ефективність стендапів на ретроспективах. Хтось збирається щодня, інші команди – кілька разів на тиждень. Якщо команді важко отримати користь зі стендапу, знайдіть причини цього і щось змініть.

4. Sprint review

Sprint review проводиться на завершальному етапі спринту. Він необхідний для перевірки інкременту продукту та адаптації беклогу. У рев'ю підсумків спринту бере участь вся scrum-команда та всі зацікавлені особи. Збори проводяться у невимушеному форматі для покращення взаємодії учасників проєкту.

В огляд результатів спринту входять такі елементи:

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

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

5. Sprint Retrospective

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

В основні цілі Sprint Retrospective входить:

• Аналіз спринту (робота учасників, результати та проблеми).
• Обговорення можливих рішень для покращення робочого процесу у наступних спринтах.
• Створення плану щодо впровадження учасниками команди покращень у процесі реалізації проекту.

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

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

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