Створення стартап-вебдодатків за допомогою Scrum: покрокове керівництво, натхненне проєктом Ratifire

«Scrum?! Scrum?! Що це за дивне слово взагалі?» було в моїй голові, як тільки я почала себе знайомити з цим поняттям. Розуміння управління проєктом було, але саме те, що ти використовуєш конкретні елементи та принципи Scrum — ні, тому ми вирішили це виправити й написати статтю, яка допоможе новачку зануритись у цей світ та не загубитись на проєкті, особливо на першій IT-роботі. То ж почнімо.

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

Scrum — це доволі популярний фреймворк/схема (Плануй, Роби, Перевіряй і Дій) для управління проєктами, яка підвищує ефективності команди. Широко застосовується у сфері розробки програмного забезпечення. Він пропонує інтерактивний, ітеративний підхід до створення продуктів, що дозволяє командам бути більш гнучкими й адаптуватися до змінних вимог.

Про складові компоненти Scrum поговоримо у другому розділі, а зараз сконцентруймося на питанні «Які переваги Scrum у startup проєктах і не тільки?»:

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

Але Scrum — це не єдине, що варто розуміти. Поруч зі Scrum стоять такі поняття як Agile, Kanban, etc. То ж тримайте короткий опис цих термінологій, які будете постійно чути при розробці програмного забезпечення.

• Agile — це парасольковий термін (an umbrella term — англ., охоплює суміжні наукові напрями, що мають спільний об'єкт дослідження), що об’єднує методики, які наголошують на гнучкості та співпраці. Головна відмінність між Scrum & Agile полягає в тому, що Agile — це загальна концепція, а Scrum — це конкретний фреймворк з чітко визначеними правилами. Якщо пояснити це дуже просто, то Agile — це рецепт приготування їжі, а Scrum – це рецепт конкретного торта.
• Kanban — це концепція управління проєктом з сімейства Agile. Він фокусується на постійному потоці роботи, візуалізації завдань та їхньому безперервному вдосконаленні. Це більш гнучкий принцип, який дозволяє легко адаптуватися до змін. Іншими словами: Kanban — це про постійний потік і гнучкість, а Scrum — про ітерації та структуру.

ПОКРОКОВЕ КЕРІВНИЦТВО ЗІ СТВОРЕННЯ ВЕБДОДАТКУ RATIFIRE ЗА ДОПОМОГОЮ SCRUM

Щоб глибше розкрити тему Scrum, розглянемо практичний приклад. Я працюю як Front-End Developer на проєкті Skillzzy — платформою, яка допомагає розробникам готуватися до технічних співбесід за допомогою підтримки досвідчених фахівців і спільноти.

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

Команди та ролі в команді, їхні відповідальності та взаємодія

Skillzzy має добре структуровану команду, розподілену за технологічними стеками: front-end, back-end, QA, design і DevOps. Кожна з цих команд має своїх Team & Tech Leads і Product Owner, що забезпечує чіткий розподіл відповідальності й ефективне управління.

Основні ролі в Scrum

Product Owner:

• Визначає цінність і бачення продукту.
• Формує і керує Product Backlog (беклогом продукту) — списком всіх функціональностей, які необхідно реалізувати в продукті.
• Ухвалює рішення про пріоритетність реалізації функціоналу і встановлює терміни їх виконання.

Team & Tech Leads:

• Елімінують перешкоди, що заважають команді працювати ефективно.
• Фасилітують всі Scrum-церемонії (планування спринту, щоденні мітинги, ретроспективи).
• Допомагають команді розвиватись і вдосконалюватися.

Development Team:

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

Кожна команда складається з 6 (max 9) team members. І даний аспект дуже важливий для Scrum, бо це оптимальне число для ефективно роботи й комунікації. В іншому разі збільшення команд від +9 призводить до зниження продуктивності до 45%.

Артефакти в Scrum: фундамент успішного проєкту

У Scrum артефакти — це не просто модні терміни. Це конкретні інструменти, які допомагають команді тримати курс, розуміти, де ми є, що робимо й навіщо.

Ось три ключові артефакти, з якими ми щодня працюємо в Skillzzy:

1. Product Backlog — серце продукту:

• Це список усього, що продукт може і повинен робити. Мрії та плани, які ще не стали кодом.
• Борда, яка допомагає візуалізувати задачі. В нас використовується GitHub Boards. Також можна зустріти Jira, Trello, Asana, JetBrains, etc. Вибирати є з чого, все залежить від того, який бюджет команди та яка функціональність борди потрібна — суть не в інструменті, а в принципі: всі завдання бачать усі.
• Завдання сортуються за пріоритетами та статусами:

Backlog → Bugs → ToDo → In Progress → Blocked → On Review → Ready for Testing → Done

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

2. Sprint Backlog — наша «порція піци»

• Це певний відсоток Product Backlog. Скажімо Product Backlog — це піца, а Sprint Backlog — це її один шматочок.
• Простими словами — це пул задач, які команда визначила на конкретний спринт і старається закрити. Саме так, це певного роду agreement команди й менеджера, не нав'язана думка згори, а decision команди.

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

Звичайно при умові, що кожний член команди занурений у процес. Якщо ми, як розробники не можемо закрити конкретну задачу за спринт, то дивимося на причини «Чому так трапилось?». Можливо задача велика для спринту загалом і варто її розбити на підзадачі або ж є якісь блокери, які варто вирішити.

3. Increment (Інкремент)

• Це працююча версія продукту, яка створюється в кінці кожного спринту.
• Інкремент демонструє прогрес команди і є результатом виконання завдань зі Sprint Backlog.
• Проєкт має бути готовим до демонстрації: стабільним, протестованим, реальним.
• Якщо інкременту немає — спринт не можна вважати завершеним. Просто «писати код» — це не Scrum.

СПРИНТИ: ПЛАНУВАННЯ, ЩОДЕННІ ЗУСТРІЧІ, ДЕМОНСТРАЦІЯ РЕЗУЛЬТАТІВ

Спринт — це доволі короткий ітеративний проміжок часу (зазвичай від 1 до 4 тижнів), якщо порівняти з загальним часом реалізації продукту/програмного забезпечення, за який команда працює над реалізацією певного набору функціональних можливостей продукту.

На проєкті Skillzzy він особливо важливий, бо:

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

Ключові етапи спринту:

Планування спринтів у нас — це завжди захопливий процес, який вимагає від усієї команди занурення в деталі. Один з ключових моментів — оцінка складності завдань. Для цього ми використовуємо Scrum Poker, хоч і в онлайн-форматі.

Як це працює?

1. Вибір завдань: на початку спринту ми вибираємо завдання з беклогу, які плануємо виконати.
2. Оцінка за шкалою Фібоначчі: кожен член команди оцінює складність завдання за допомогою чисел Фібоначчі (1, 2, 3, 5, 8, 13). Це допомагає нам швидко зорієнтуватися і зрозуміти, наскільки завдання складне.
3. Обговорення розбіжностей: якщо оцінки сильно розходяться, ми детально обговорюємо завдання. Кожен пояснює свою точку зору, враховуючи технічні аспекти, залежності від інших завдань, а також зовнішні фактори (наприклад, зміни в дизайні).
4. Повторна оцінка: після обговорення ми повторно оцінюємо завдання. Як правило, після обміну думками оцінки зближуються.
5. Прийняття рішення: завдання включається до спринту з узгодженою оцінкою.

Чому ми не використовуємо людино-години?

Використання абстрактних одиниць (сторіпоінтів, розмірів футболок) дозволяє нам:

• Зберегти фокус на складності: ми оцінюємо не час, а обсяг роботи та її складність.
• Уникнути тиску: відмова від годин дозволяє розробникам зосередитися на творчому вирішенні задач, а не на годиннику.
• Стимулювати командну роботу: обговорення оцінок сприяє кращому розумінню завдань і зміцнює команду.

ПРИКЛАД ІЗ ЖИТТЯ

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

1. Розробка. Отримавши своє завдання, кожен член команди занурюється в роботу. Адже ми розуміємо, що успіх проєкту залежить від кожного. Якщо виникають сумніви щодо правильного рішення, завжди можна провести додаткове дослідження або звернутися за допомогою до досвідчених колег. Відкрита комунікація — наш ключ до успіху. Тому будь-які проблеми чи затримки обговорюються одразу ж, під час щоденних мітингів або в загальному чаті.
2. Щоденні мітинги: Це наші короткі, але ефективні зустрічі, де ми обмінюємось інформацією про прогрес роботи. Кожен учасник стисло розповідає, що вдалося зробити, над чим працює зараз і чи є якісь перешкоди. Такий формат дозволяє нам швидко реагувати на зміни й підтримувати загальний темп роботи. Загалом має тривати 15 хв. Якщо є конкретні топіки для обговорення, то виноситься як окремий call.
3. Демонстрація: У Skillzzy ми проводимо щотижневі демонстрації, відходячи від класичного Scrum. Це дозволяє нам отримувати швидкий зворотний зв’язок й оперативно адаптувати розробку під мінливі потреби стартапу.
4. Ретроспектива: Після завершення кожного спринту ми проводимо ретроспективу, щоб глибоко зануритися в результати нашої роботи. Разом з Tech & Team Lead-ами ми аналізуємо, що допомогло нам досягти успіху, а над чим ще потрібно працювати. Це не просто підбиття підсумків, а скоріше спільна рефлексія, яка допомагає нам розвиватися як команді фронтів.

ТИПОВІ ПРОБЛЕМИ ПРИ ЗАСТОСУВАННІ SCRUM

Як команда Front-end розробників у Skillzzy, ми зіштовхнулися з кількома типовими проблемами при впровадженні Scrum:

• Недотримання принципів Scrum. Особливо це стосувалося молодих спеціалістів, які раніше не працювали за цією методологією. Творчий характер розробників також впливав на дотримання жорстких правил, таких як щоденні мітинги.
• Проблеми з комунікацією. Складнощі виникали при взаємодії з іншими командами, наприклад, дизайнерами. Кожна команда прагнула відстоювати свою точку зору, що ускладнювало процес ухвалення рішень.
• Зміна вимог. Як і в багатьох інших проєктах, ми стикалися з ситуацією, коли product owner міг запропонувати інше рішення вже під час спринту.

Як ми розв'язали ці проблеми:

• Накопичення досвіду: з часом команда набула досвіду роботи з Scrum, що дозволяє краще зрозуміти його принципи й переваги.
• Менторство: досвідчений Tech&Team Lead допоміг команді освоїти Scrum і дотримуватися встановлених правил.
• Посилення комунікації: ми чітко визначили відповідальних за ухвалення технічних рішень і налагодили ефективну комунікацію між командами.
• Адаптація до змін: ми навчилися швидко адаптуватися до змін вимог, включаючи їх у наступний спринт.

РЕЗУЛЬТАТИ, ЯКИХ БУЛО ДОСЯГНУТО НА ПРОЄКТІ SKILLZZY

1. Зростання продуктивності. Проєкт стартував в січні 2024 року. До червня 2024 року були часткові застосування Scrum, я б сказала невдалі й на момент цього часу було розроблено не цілі дві сторінки з багатьма багами. Від липня 2024 року з застосуванням Scrum продуктивність front команди виросла й increment на даних період становить 5 сторінок https://skillzzy.com, рефакторинг модалок + чат на WebSocket + повноцінний landing https://ratifire.org/. Порівнюючи з чого ми стартували, то за моїми скупими оцінками продуктивність зросла до 500%
2. Презентація Skillzzy платформи на Web Summit 2024 в Лісабоні. Продукт було презентовано великій IT-community. В результаті якого ми отримали багато позитивних відгуків і головне — feedback для поліпшення платформи та впровадження інноваційних рішень.
3. Майбутня колаборація з сучасними й передовими українськими IT School такими як Hillel. Наразі проходять перемовини щодо умов співпраці.
4. Подання заявки на Премія DOU 2024. Шукаємо проєкти, ініціативи, людей, які впливають на українську IT-спільноту.

Scrum став нашим компасом у світі розробки. Це не просто інструмент, це філософія. Вона навчила нас, що успіх — це не кінцева точка, а постійний процес удосконалення. Кожен спринт — це новий крок до покращення та чогось нового. Ми з нетерпінням чекаємо, чого ще можемо досягти. Певною мірою Scrum допомагає зловити щастя у щоденній метушні задач, озирнутись і відповісти на запитання «Що зробив? Куди я рухаюся та що буду робити? Чи є якісь блокери?». Спробуй і ти!