Робота зі Scrum

1. User Story

Користувацьці історії (User Story) — ефективний спосіб викласти вимоги до програмного забезпечення, що знаходиться в розробці. Такі історії містять короткі поради від імені користувача ПЗ.

Оскільки у методиці Scrum постановка завдань — це зазвичай прерогатива замовника чи власника ПЗ, вони вважаються головним способом впливу на процес розробки. Кожна User Story має обмеження за обсягом тексту та складністю викладу. Історію найчастіше пишуть на невеликому аркуші, що саме по собі обмежує обсяг.

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

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

Структура історії має приблизно такий вигляд: “Якщо користувач є <тип користувача>, я хочу виконати <дія> для отримання <результат>” (As a product owner I want …). Подібна структура не лише проста, а й зрозуміла кожному.

Переваги застосування User Stories:

• Історії невеликі за обсягом та їх легко створювати.
• Допомагають усім зацікавленим особам обговорювати роботу над проєктом та його підтримку.
• Не потребують постійного обслуговування.
• Актуальні лише при використанні.
• Поліпшують взаємодію з клієнтом.
• Завдяки їм можна поділити проєкт на дрібні етапи.
• Полегшують роботу над проєктами із погано зрозумілими вимогами.
• Спрощують оцінку завдань.

Недоліки User Stories:

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

2. Backlog

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

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

Дві важливі умови беклогу

Основа беклогу продукту складається з дорожньої карти, пропозицій та умов виконання. У епіках містяться умови та User Story. Давай розглянемо приклад типової дорожньої карти.

Створення сайту "Команди в космосі" – перша пропозиція з дорожньої карти. Її потрібно розділити на епіки (на малюнку вони показані зеленим, синім та бірюзовим кольорами) та User Story для кожного епіка.

Замовник ПЗ формує з кількох User Story один список. У разі необхідності він може змінити порядок виконання історій, щоб розробники спочатку зайнялися одним із найважливіших епіків (ліворуч) або перевірили, як працює пільгове бронювання квитків. Щоб це виконати, потрібно реалізувати історії з епіків (праворуч). Обидва варіанти можна побачити нижче.

На основі яких факторів замовник має розставляти пріоритети?

• Актуальність користувачів.
• Наявність зворотного зв'язку.
• Складність розробки.
• Взаємозв'язок між завданнями (щоб виконати “Б”, спочатку потрібно зробити “А”).

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

Як вести беклог

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

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

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

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

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

3. Sprint

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

“Застосовуючи Scrum, можна розробити продукт за кілька ітерацій із чіткою тривалістю – спринтами. Це допомагає розбивати великі проєти на дрібні завдання”, – стверджує Меган Кук, керівник напряму Jira у компанії Atlassian.

Як відбувається планування та виконання спринтів у Scrum?

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

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

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

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

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

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

На що потрібно звернути увагу, а що робити не варто

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

Що потрібно робити:

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

Чого варто уникати:

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

4. Scrum board

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

Scrum-дошка складається не менше ніж з трьох стовпців: "зробити", "в роботі" та "готово". Ось приклад дошки:

На Scrum-дошці розміщена вся інформація з беклогу, який раніше затвердили на плануванні. Зазвичай картки бізнес-завдань закріплено на дошці за пріоритетом зверху донизу. Можна поділити їх на конкретні типи робіт (робота над кодом, дизайн та інші).

Після того, як частину роботи завершено, картку пересувають до сусідньої колонки. Показати видимість прогресу роботи команди допомагає “робота, яка залишилася” за днями на Burndown Chart.

Можна також використовувати дошку із фліпчартами. На ній назви робіт пишуть на паперових наклейках та прикріплюють їх на дошку. Щойно робота закінчена, стікери пересувають до іншої колонки.

5. Burndown chart

Діаграма згоряння завдань (Burndown chart) показує кількість роботи, яку виконано, і роботи, що залишилася. Вона оновлюється щодня та доступна всім зацікавленим особам. Графік необхідний відображення прогресу у роботі над спринтом.

Є два види діаграм:

• Burndown chart із відображенням прогресу роботи у спринті.
• Burndown chart із відображенням прогресу роботи до випуску продукту (дані сумуються з кількох спринтів).

Приклад діаграми:

У цьому прикладі використовується психологія: діаграма показує не кількість зроблених завдань, а кількість не зроблених (залишок).

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

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