Зміст
Якщо ви хоч раз сиділи на плануванні розробки, напевно чули: «ця задача на п’ять сторипойнтів», «додамо в беклог», «не встигнемо в поточний спринт», «velocity просіла», «потрібен planning poker». Для новачка це звучить як окремий діалект. Насправді за термінами стоять прості ідеї: короткі цикли роботи, прозорий список задач, відносні оцінки складності та регулярний зворотний зв’язок від замовника.
Ключові висновки
Agile — це цінності, Scrum — конкретний спосіб їх застосувати. Маніфест Agile (2001) описує навіщо змінювати підхід до розробки; Scrum додає ролі, події та артефакти — як організувати роботу команди.
Story Points — не години. Це відносна оцінка обсягу, складності, невизначеності та ризику. Дві задачі на вісім годин можуть отримати різні оцінки, якщо одна зрозуміла, а друга — ні.
Velocity — метрика команди, не людей. Вона показує, скільки story points команда зазвичай закриває за спринт. Порівнювати velocity різних команд безглуздо: шкала оцінок у кожної своя.
Backlog — єдине джерело правди про роботу. Product Backlog — усе, що може бути зроблено; Sprint Backlog — те, на що команда взяла зобов’язання в поточному циклі.
Процес існує заради продукту. Daily, review, retrospective — не бюрократія, а інструменти, щоб швидше постачати цінність і покращувати спосіб роботи.
Звідки взявся Agile
Проблеми каскадної моделі
До широкого поширення Agile більшість проєктів ішли за каскадною моделлю (Waterfall): збір вимог → проєктування → розробка → тестування → впровадження. Кожен етап «закривали» документами, а повернення назад було дорогим.
Реальність software-проєктів інша: вимоги змінюються, ринок реагує на конкурентів, користувачі розуміють продукт лише після перших релізів. Через рік розробки замовник міг отримати саме те, що просив у ТЗ, — і зрозуміти, що це вже не те, що потрібно зараз.
Маніфест Agile
У 2001 році сімнадцять практиків сформулювали Agile Manifesto. Чотири цінності (скорочено):
- Люди та взаємодія важливіші за процеси та інструменти.
- Працюючий продукт важливіший за вичерпну документацію.
- Співпраця з замовником важливіша за узгодження контрактів.
- Готовність до змін важливіша за дотримання первинного плану.
За маніфестом — дванадцять принципів: короткі ітерації, часті поставки, самоорганізовані команди, регулярна рефлексія. Agile не скасовує планування — він робить його безперервним і адаптивним.
Що таке Scrum
Scrum — найпоширеніша фреймворк-реалізація Agile для продуктових команд. Він не описує, як писати код, але задає мінімальний каркас: три ролі, п’ять подій, три артефакти.
Ролі
Product Owner (PO) відповідає за цінність продукту. Формує та пріоритизує Product Backlog, перекладає бізнес-цілі в зрозумілі елементи backlog, приймає результат спринту. PO — не «начальник розробників», а представник інтересів користувача та бізнесу.
Scrum Master стежить за процесом: допомагає прибрати перешкоди, фасилітує події, навчає команду практикам Scrum. Це не project manager у класичному сенсі і не техлід — скоріше «сервісна роль» для команди.
Development Team (команда розробки) — кросс-функціональна група, яка створює інкремент продукту. У Scrum немає підролей «лише кодер» і «лише тестувальник» на рівні процесу: команда разом відповідає за результат спринту.
Sprint — серце Scrum
Що таке спринт
Sprint — фіксований інтервал (timebox), протягом якого команда створює готовий «Done»-інкремент. Типова тривалість: одна, дві, три або чотири тижні; найчастіше — два тижні.
Усередині спринту scope не змінюють довільно: якщо прилетіла термінова задача, PO і команда усвідомлено вирішують, що викинути або перенести — а не «додати зверху без наслідків».
Навіщо потрібні спринти
Короткі цикли дають передбачуваний ритм: планування → робота → демо → покращення процесу. Помилки у вимогах спливають через тижні, а не через квартали. Stakeholders бачать прогрес регулярно, а не лише на «великому релізі».
Типовий цикл спринту
- Sprint Planning — що робимо і як.
- Daily Scrum — коротка синхронізація (зазвичай 15 хвилин).
- Робота над задачами.
- Sprint Review — демонстрація результату.
- Sprint Retrospective — що покращити в процесі.
- Новий спринт.
Backlog і User Story
Product Backlog і Sprint Backlog
Backlog — упорядкований список усього, що потрібно або може знадобитися продукту.
Product Backlog — головний список проєкту: нові функції, баги, технічний борг, spikes (дослідження). PO постійно його уточнює та пересортовує.
Sprint Backlog — підмножина Product Backlog плюс план команди на поточний спринт. Лише те, на що команда взяла зобов’язання в цьому циклі.
Приклад елементів Product Backlog:
- Авторизація через Google.
- Експорт звіту в Excel.
- Прискорення сторінки каталогу на 30 %.
- Виправлення помилки розрахунку ПДВ.
User Story
User Story описує потребу користувача, а не технічну реалізацію. Класичний шаблон:
Як [роль]
я хочу [дія]
щоб [результат / цінність]
Погано: «Зробити кнопку експорту».
Добре: «Як бухгалтер, я хочу експортувати звіт у Excel, щоб надіслати його податковому консультанту».
До story додають критерії приймання (acceptance criteria) — перевірювані умови «готово з точки зору користувача». Це міст між PO і командою під час тестування.
Story Points і Planning Poker
Що таке Story Point
Story Point (SP, сторипойнт) — відносна оцінка складності задачі. Це не:
- години чи дні;
- гроші;
- «продуктивність програміста».
При оцінці враховують:
- обсяг роботи — скільки кроків і зачеплених частин системи;
- технічну складність — нестандартні інтеграції, legacy-код;
- невизначеність — неясні вимоги, слабка документація API;
- ризики — зовнішні залежності, міграції даних.
Приклад. «Змінити текст на кнопці» — 15 хвилин, мінімальна складність → 1 SP. «Інтеграція нового платіжного шлюзу» — може зайняти 8 годин, але з невідомою документацією та ризиками → 13 SP.
Чому SP не дорівнюють часу
Дві задачі за часом однакові, а складність — ні. Задача А: зрозумілий CRUD, знайомий стек, без ризиків. Задача Б: той самий обсяг коду, але невідома поведінка стороннього API і ймовірність зміни вимог. Задача Б отримає більше SP, хоча «години в календарі» можуть збігтися.
Послідовність Фібоначчі
Часто використовують шкалу 1, 2, 3, 5, 8, 13, 21, 34. Чим більша задача, тим вища невизначеність — різниця між 1 і 2 мала, між 21 і 34 уже «інший порядок величини». Великі оцінки сигнал: задачу варто декомпозувати.
Planning Poker
Planning Poker — техніка командної оцінки:
- Команда читає user story.
- Кожен таємно обирає карту зі значенням SP.
- Усі одночасно показують оцінки.
- Обговорюють розбіжності (особливо min і max).
- Повторюють голосування до консенсусу або вузького діапазону.
Метод знижує ефект «авторитетної думки» і витягує приховані ризики: junior бачить підводний камінь, який senior не помітив.
Velocity та ієрархія задач
Velocity
Velocity — скільки story points команда завершила (за Definition of Done) за спринт. Приклад: спринти на 30, 35 і 40 SP → середня velocity ≈ 35 SP/спринт.
Velocity допомагає прогнозувати: «за поточного backlog і velocity реліз X займе N спринтів». Це не KPI для «покарання» команди і не спосіб порівняти дві команди — шкали SP у них різні.
Epic, Feature, Story, Task
На великих продуктах роботу групують:
| Рівень | Сенс | Приклад |
|---|---|---|
| Epic | Велика бізнес-ціль | «Система онлайн-платежів» |
| Feature | Крупна функція | «Оплата банківською карткою» |
| User Story | Потреба користувача | «Як клієнт, хочу оплатити замовлення карткою…» |
| Task | Технічний крок | «Створити таблицю payments», «API checkout» |
Epic декомпозують на stories; stories — на tasks у Sprint Backlog. Межі між Feature і Epic у різних компаніях плавають — важливіша ієрархія, а не жорсткі назви в Jira.
Definition of Ready і Definition of Done
Definition of Ready (DoR)
DoR відповідає: «Чи можна починати розробку?» Типові критерії:
- є зрозумілий опис і acceptance criteria;
- залежності відомі або зняті;
- немає блокуючих відкритих питань;
- задача оцінена (якщо команда оцінює до спринту).
DoR знижує «зависання» задач у статусі In Progress через неясні вимоги.
Definition of Done (DoD)
DoD відповідає: «Коли задача дійсно готова?» Приклад для production-ready команди:
- код написано і пройшло code review;
- unit/integration-тести додано і зелені;
- QA перевірив за acceptance criteria;
- документація/API оновлена;
- задеплоєно на staging (або prod — за політикою команди).
DoD — договір команди, а не особисте «я вважаю, що готово». Без спільного DoD velocity і «завершені SP» втрачають сенс.
Події спринту: Review і Retrospective
Sprint Review
Наприкінці спринту команда показує працюючий інкремент stakeholders: не слайди «ми майже зробили», а demo. Збирають зворотний зв’язок, оновлюють пріоритети backlog. Review — про продукт, не про процес.
Sprint Retrospective
Одразу після review — ретроспектива: що пройшло добре, що заважало, що спробувати в наступному спринті. Одне конкретне покращення краще за десять абстрактних «треба краще комунікувати».
Daily Scrum
Daily — не звіт начальству, а план на найближчі 24 години: що зробив, що буду робити, що блокує. Три питання — шаблон, не dogma; головне — синхронізація і раннє виявлення блокерів.
Заблуждення про Agile
| Міф | Реальність |
|---|---|
| Story Points = години | SP — складність і ризик, не календар |
| Velocity = KPI програміста | Velocity — властивість команди і її шкали |
| Agile = без документації | Потрібна достатня документація, не тонни ТЗ |
| Scrum підходить усім | Для досліджень, саппорту, жорстких процесів відповідності вимогам часто краще Kanban або гібрид |
| Agile = хаос без планів | Планування є на кожному спринті та на рівні roadmap |
Як пов’язані всі терміни
Типовий потік:
- PO формує Product Backlog з epics і user stories.
- На Sprint Planning команда обирає елементи в Sprint Backlog.
- Stories оцінюють у Story Points через Planning Poker.
- У Sprint команда працює до Definition of Done.
- За підсумками спринту рахують Velocity.
- Sprint Review показує цінність; Retrospective покращує процес.
- Цикл повторюється.
FAQ
Чи можна перевести Story Points у години?
Формально — іноді команда калібрує «1 SP ≈ півдня», але це локальна евристика, не властивість SP. Як тільки SP перетворюють на приховані години для контролю людей, втрачається сенс відносної оцінки.
Чим Kanban відрізняється від Scrum?
Scrum — фіксовані спринти та ролі; Kanban — безперервний потік, WIP-ліміти, менше prescribed-подій. Багато команд використовують Scrumban: спринти + дошка Kanban.
Скільки триває Sprint Planning?
Залежить від довжини спринту. Правило великого пальця з Scrum Guide: до 8 годин на місячний спринт; для двотижневого — часто 2–4 години на дві частини (what + how).
Чи потрібен окремий Scrum Master у маленькій команді?
У стартапах ролі часто поєднують, але функції залишаються: хтось має захищати фокус команди та процес. Поєднання PO і SM в одній особі — ризик конфлікту інтересів.
Що таке spike?
Spike — timeboxed-дослідження («дізнатися, як працює API X»), результатом якого часто стає рішення і декомпозиція, а не production-код.
Додаткові матеріали
На stuzhuk.page зі суміжних тем:
- Bulletproof React — структура фронтенд-проєкту, коли backlog росте
- UX і ROI: дані замість думок — зв’язок user story і бізнес-цінності
- Оптимізація баз даних — технічний борг у backlog
- SEO, AEO, GEO та AISO — пріоритизація «видимості продукту» поряд із фічами
Зовнішні ресурси: Scrum Guide (2020), Agile Manifesto (UK).
Висновок
Agile — не модний словник і не культ stand-up’ів. Це спроба зробити розробку передбачуваною, гнучкою та прозорою: короткі спринти, спільний backlog, відносні оцінки, регулярний зворотний зв’язок.
Запам’ятайте зв’язку: Scrum організує роботу, Sprint задає ритм, Backlog зберігає плани, User Story описує цінність, Story Points і Planning Poker допомагають оцінювати, Velocity — прогнозувати, DoR/DoD — домовлятися про готовність. Усі інструменти існують заради одного: корисного продукту для користувачів і бізнесу.