Agile

Обмеження Agile

Review: максимум 2 задачі Головна роль менеджменту в Agile: не керувати кожною хвилиною роботи, а створити умови, де команда має змогу стабільно доставляти цінність.; Головна думка принципів: Agile — це цикл “зробили маленький корисний крок, показали, отримали feedback, покращили бізнес-процес, зробили наступний крок”.; Agile проти ситуації, коли бізнес-процес стає важливішим за реальний результат.;

Замість micromanagement краще:

Agile і Product Management

Kanban корисний для:

вимоги змінюються;
програмний продукт потрібно відкривати поступово;
користувачі можуть давати feedback;
важлива швидка доставка;
команда має змогу працювати ітеративно;
є собою невизначеність;
потрібні часті релізи;
бізнес-середовище і розробка програмного забезпечення готові співпрацювати;
roadmap має змогу адаптуватися;
істотно зменшити ризик створити непотрібну функцію.;

швидший feedback;
рання доставка цінності;
краща адаптація до змін;
більша прозорість роботи;
фокус на користувачі;
менше ризику зробити непотрібний програмний продукт;
регулярне покращення процесу;
сильніша командна взаємодія;
краще керування невизначеністю;
часті релізи;
можливість поступового розвитку продукту;
краща видимість blockers;
живий backlog;
корисніша документація.; Корисні метрики:

</syntaxhighlight>

Планування	Ітеративне, адаптивне	Великий план на старті
Зміни	Очікуються й враховуються	Часто дорогі й небажані
Доставка	Частими малими інкрементами	Великим релізом після довгого циклу
Feedback	Регулярний	Часто пізній
Найкраще для	Невизначених або мінливих продуктів	Стабільних вимог і передбачуваних проєктів

Agile Manifesto або Маніфест гнучкої розробки програмного забезпечення — це короткий документ, який сформулював основні цінності Agile.; Acceptance criteria:

Agile Manifesto має 12 принципів.; Ознаки:

Definition of Done

Backlog refinement — регулярне уточнення задач у backlog.; Команда створює мінімальну версію продукту, оперативно показує користувачам, збирає feedback і вирішує, що розвивати далі.;

Agile не означає хаос, відсутність плану або нескінченні мітинги.;

Основні переважні аспекти Agile:

Як зареєстрований користувач системи,

Практична роль: Product Owner не без ускладнень “пише задачі”, а сприяє команді робити правильні речі в правильному порядку.; Agile не відкидає документацію.; Якщо програмний продукт потрібно відкривати поступово, Agile зазвичай сильніший.; Велика організація переходить від великих релізів до частішої доставки через cross-functional teams, CI/CD і product ownership.; Якщо організація не готова до прозорості й адаптації, Agile-ритуали не допоможуть.; Agile-метрики мають допомагати команді вчитися, а не карати людей.; Roadmap — приблизний напрям розвитку продукту.; Критично: Agile без довіри, feedback і реальної адаптації — це без ускладнень старий command-and-control у нових словах.;

Загальний характеристика

</syntaxhighlight>

істотно: Agile без технічної здатності часто релізити має змогу застрягти в красивих планах і рідкісних великих релізах.;

Практична роль: Scrum дає команді ритм: короткий цикл, фокус на цілі, регулярна перевірка результату й покращення процесу.;== Incremental development ==

Agile використовують для:

When він натискає "Додати в кошик"

XP пов’язують із:

story points;
t-shirt sizes;
planning poker;
no estimates у частині команд;
cycle time metrics;
historical throughput.; Scrum Guide 2020 визначає Scrum як lightweight framework, який сприяє людям, командам і організаціям створювати цінність через adaptive solutions для complex problems.; Як покупець,

Псевдо-Agile

істотно: Agile в іншій сфері треба адаптувати до реального типу роботи, а не без ускладнень копіювати Scrum-ритуали.; * фасилітувати події;

допомагати команді з самоорганізацією;
захищати фокус;
прибирати blockers;
навчати Scrum;
допомагати Product Owner;
покращувати взаємодію зі stakeholders;
підтримувати ретроспективи.; істотно: Agile-команда має доставляти не без ускладнень features, а користувацьку цінність.;

Agile Metrics

Agile добре поєднується з UX, якщо команда не зводить усе до “оперативно намалювати макет і віддати в розробку”.; Scrum — один із найвідоміших Agile-фреймворків.; Це контейнер для фокусу, feedback і навчання.;== Product Owner ==

Enterprise transformation

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
'''істотно:''' якщо WIP limit постійно порушується, це сигнал не “збільшити ліміт”, а розібратися, чому платформа перевантажена.;== Тематичні мітки ==
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

</div>

</div>

* фокусуватися на outcomes, а не лише output;
* тримати backlog пріоритезованим;
* писати зрозумілі acceptance criteria;
* показувати working software часто;
* робити retrospectives із реальними діями;
* підтримувати technical excellence;
* не перевантажувати sprint;
* обмежувати WIP;
* використовувати CI/CD;
* мати Definition of Done;
* не використовувати velocity як KPI;
* залучати користувачів і stakeholders;
* оновлювати roadmap;
* документувати важливі рішення для бізнесу;
* прибирати blockers;
* підтримувати sustainable pace.;== Agile і документація ==

'''Continuous Integration''' або '''CI''' — практика частого об’єднання змін у спільну гілку з автоматичними перевірками.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
Повторити цикл
'''Проста ідея:''' Lean питає: “Що справді створює цінність, а що без ускладнень займає час?”
того, щоб додати більше зустрічей забезпечується через '''Найлюдяніший факт:''' Agile народився не; додатково реалізовано а щоб люди в команді швидше вчилися, краще домовлялися й частіше створювали щось корисне.; Sprint Review корисний для:
'''Практична роль:''' user story сприяє говорити не лише про функцію, а про користувача й цінність.;</div>
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Story points не повинні напряму перетворюватися в години як “1 point = 1 день”.; Їх можна коротко пояснити так:

'''істотно:''' sprint — це не без ускладнень “дедлайн кожні два тижні”.; Його основа — Agile Manifesto з 4 цінностями й 12 принципами, а практична реалізація має змогу відбуватися через Scrum, Kanban, XP, Lean або змішані підходи.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
Це не означає, що процеси, інструменти, документація, контракти й плани не потрібні.; '''Feedback loop''' — цикл отримання інформації про результат і зміни поведінки на основі цієї інформації.; Він означає найменший корисний програмний продукт для навчання.; Але початково Agile Manifesto був не про мітинги.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

'''Retrospective''' — зустріч, де команда аналізує, як працювала, і домовляється, що покращити.;</div>

<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">

'''Головна перевага:''' Agile сприяє команді швидше вчитися на реальному продукті, а не на припущеннях у документах.; '''Estimation''' в Agile застосовується для приблизного розуміння складності, ризику або розміру задач.; * Найкращий Agile зазвичай виглядає не як хаос, а як спокійна команда з короткими feedback loops і високою якістю.;</div>

Як [тип користувача],

* automated tests;
* linting;
* build;
* static analysis;
* security scans;
* integration checks;
* швидке виявлення помилок.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
== Agile Manifesto ==
</div>

MVP не означає поганий або недороблений програмний продукт.;== Retrospective ==

</div>

== Приклади сценаріїв використання ==
'''Daily Scrum''' — коротка щоденна зустріч Scrum-команди для синхронізації роботи.;

Інкремент 1: каталог товарів

Product і design-команда тестує прототипи, збирає feedback і передає в delivery лише краще перевірені рішення для бізнесу.; WIP limits допомагають:

Хороші практики Agile

Типовий формат:

Kanban

Що ми можемо змінити вже в наступному sprint?; Поширені підходи:

Помилка: використовувати story points як інструмент тиску на людей.;

Iterative development

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

Приклад: Під час refinement команда: Практична роль: Product management відповідає на питання “що й навіщо робити”, а Agile сприяє робити це малими перевіреними кроками.; Практична порада: Agile roadmap краще будувати навколо цілей і outcomes, а не лише списку features із жорсткими датами.; Sprint охоплює:

Практична роль: Kanban сприяє побачити, де робота застрягає, і не брати більше задач, ніж команда реально має змогу завершити.; User story — короткий характеристика потреби користувача.; * Scrum.org materials about Scrum.; Помилка: думати, що Agile сам по собі врятує погану архітектуру, слабку комунікацію або відсутність product vision.; * користувачів;

замовників;
analytics;
support;
QA;
sales;
product metrics;
production incidents;
retrospectives;
usability tests;
stakeholders.;

User Story

UX у Agile має змогу включати: Практична роль: хороший refinement робить sprint planning спокійнішим і точнішим.;</syntaxhighlight>

API contracts;
architecture decisions;
onboarding guides;
runbooks;
user-facing docs;
acceptance criteria;
decision records;
diagrams;
troubleshooting;
security notes.;

я хочу зберігати товари в кошику,

істотно: user story без acceptance criteria часто залишає забагато місця для різних трактувань.;== Product Backlog == Проста аналогія: incremental development — це не будувати весь корабель у темряві, а спершу зробити човен, перевірити воду й поступово добудовувати.; Agile Що допомогло нам у цьому sprint?; Це спосіб краще зрозуміти роботу й ризики.;== Extreme Programming ==

Практична роль: CI сприяє команді оперативно бачити, коли зміна щось зламала.;== Приклад user story ==

MVP

Корисна документація:

WIP limit — обмеження кількості задач, які можуть одночасно перебувати в роботі.;

Практична роль: цей цикл показує Agile як навчання через маленькі реальні результати.;

daily перетворився на звіт менеджеру;
sprint planning — це без ускладнень роздача задач згори;
retrospective нічого не змінює;
backlog не пріоритезується;
feedback користувачів ігнорується;
scope фіксований, дата фіксована, команда без ускладнень “має встигнути”;
velocity використовують для тиску;
команда не має права впливати на бізнес-процес;
working software показують рідко;
технічний борг ігнорується.; Інкремент 2: кошик

Testing: максимум 2 задачі

Definition of Done — спільне розуміння того, коли робота справді завершена.;== Sprint Review ==

комунікації;
якості;
blockers;
процесу review;
тестування;
planning;
deployment;
взаємодії з Product Owner;
technical debt;
настрою команди;
інструментів;
workload.; Саме з цієї причини команда має змогу мати всі “agile-ритуали”, але не бути agile по суті.; DevOps додає:

Kanban-дошка має змогу мати колонки:

Incremental development означає, що програмний продукт росте частинами.; Він сильний там, де є собою невизначеність і потреба оперативно адаптуватися, але слабшає без довіри, якості, реального Product Ownership і здатності часто доставляти програмний продукт.; Sprint — короткий фіксований цикл роботи в Scrum.; Якщо вимоги справді стабільні, Waterfall має змогу працювати.; Це інструмент планування, а не батіг.;

Agile часто сприймають як набір мітингів: daily standup, sprint planning, review, retrospective.; * швидкому feedback;

частій доставці цінності;
адаптації;
командній взаємодії.; Scrum — лише один із способів реалізувати Agile-підхід.; :contentReference [oaicite:1]{index=1}

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

Agile добре підходить, якщо:

Agile і менеджмент

прогнозування;
планування capacity;
розуміння стабільності;
обговорення змін у процесі;
виявлення перевантаження.;== Estimation ==

Головна користь: retrospective перетворює досвід команди на конкретні покращення.; істотно: Agile не проти документації, планів або процесів.; Якщо користувач системи не має змогу отримати цінність, це не MVP, а без ускладнень обрізаний прототип.;

* marketing;
* education;
* design;
* HR;
* operations;
* research;
* content production;
* product discovery;
* hardware у частині сценаріїв;
* organizational change.; Справжній Agile — це дисципліна коротких feedback loops, working software, customer collaboration, technical excellence і командного навчання.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Що заважало?; Це спосіб не витрачати місяці життя команди на створення того, що нікому не потрібно.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Реалізувати малий інкремент

<syntaxhighlight lang="text">

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Velocity корисна для:
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
Lean-підхід звертає увагу на:
In Progress: максимум 3 задачі

зменшити multitasking;
швидше завершувати задачі;
виявляти bottlenecks;
покращувати flow;
не перевантажувати команду;
підвищувати якість.; * individuals and interactions over processes and tools;
working software over comprehensive documentation;
customer collaboration over contract negotiation;
responding to change over following a plan.; Це servant-leader і фасилітатор процесу.; Але механічне перенесення software-практик не завжди функціонує.; * XP нагадує, що гнучкість без тестів, refactoring і технічної якості оперативно ламається.; Практична роль: ретроспектива має закінчуватися не розмовою, а маленькою конкретною зміною.;

Product Backlog не є собою статичним документом.;

Continuous Delivery потребує:

</div>

* демонстрації working increment;
* обговорення змін у продукті;
* уточнення backlog;
* перевірки припущень;
* взаємодії зі stakeholders;
* адаптації плану.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
- Якщо email існує, платформа надсилає лист із посиланням
'''Практична роль:''' без feedback loop Agile перетворюється на короткі Waterfall-цикли без справжнього навчання.;== 4 цінності Agile ==

Він виділяє 4 цінності:

== Continuous Delivery ==

</div>

</div>

== 12 принципів Agile ==

'''Continuous Delivery''' — практика, коли програмний продукт можна часто й безпечно доставляти користувачам.;=== SaaS-продукт ===

'''Головне правило:''' Agile має допомагати команді доставляти цінність і вчитися, а не без ускладнень створювати красиву дошку задач.; '''Практична роль:''' review — це не без ускладнень презентація “що зробили”, а розмова про те, чи рухається програмний продукт у правильний бік.; Це радше набір цінностей, принципів і практик, які можуть реалізовуватися через '''Scrum''', '''Kanban''', '''Extreme Programming''', '''Lean''', Scrumban або власні командні процеси.; Команда функціонує sprint-ами, має backlog, релізить невеликі покращення й відстежує product metrics.; '''істотно:''' Scrum Master — це не начальник команди й не секретар зустрічей.;=== Support і maintenance ===

я хочу [дія або можливість],
<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">
== Agile і Waterfall ==

Небезпечні метрики:

Сценарій: додавання товару в кошик
<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">
Приклад:
|-
| Люди й взаємодія важливіші за процеси й інструменти
| Команда, комунікація й довіра важливіші за красиву дошку задач
|-
| Working software важливіше за вичерпну документацію
| Реальний працюючий результат показує прогрес краще, ніж великий документ без продукту
|-
| Співпраця з клієнтом важливіша за узгодження контракту
| Краще часто уточнювати потреби, ніж один раз підписати вимоги й не дивитися на реальність
|-
| Реакція на зміни важливіша за слідування плану
| План потрібен, але він має змінюватися, коли з’являються нові знання
|}

Хоча Agile Manifesto виник у software development, Agile-підходи використовують і в інших сферах:
'''Практична роль:''' iterative development надає можливість не чекати фінального релізу, щоб зрозуміти, що програмний продукт рухається не туди.;</div>

* automation;
* CI/CD;
* infrastructure as code;
* monitoring;
* reliability;
* deployment discipline;
* collaboration між dev і ops.;</div>

Agile-підхід застосовується там, де вимоги можуть змінюватися, користувацькі потреби не до кінця зрозумілі на старті, а програмний продукт краще розвивати поступово через feedback.; Воно означає планування на різних рівнях.; * Матеріали щодо Scrum, Kanban, Extreme Programming, Lean, product management, DevOps, CI/CD, software delivery, retrospectives, user stories, estimation, metrics і technical debt.;<syntaxhighlight lang="text">

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

</div>

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

* перевірити прогрес до Sprint Goal;
* побачити blockers;
* узгодити план на день;
* оперативно виявити ризики;
* зменшити потребу в зайвих окремих статус-мітингах.; Його сенс — синхронізація команди.;== Цікаві факти про Agile ==

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

== Коли варто використовувати Agile ==

* discovery;
* interviews;
* prototypes;
* usability testing;
* design spikes;
* design system;
* user journey mapping;
* analytics;
* A/B testing;
* continuous research.; - Після зміни пароля старі reset-посилання стають недійсними

Agile тісно пов’язаний із product management.;== Roadmap ==
Провести retrospective
Команда:

- Посилання має обмежений час дії

</div>

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

* формує product goal;
* пріоритезує backlog;
* уточнює user stories;
* спілкується зі stakeholders;
* пояснює потреби користувачів;
* приймає рішення для бізнесу про scope;
* сприяє команді розуміти цінність задач.; Він постійно уточнюється, переоцінюється й перепріоритезується.; !;</div>
'''Kanban''' — Agile-підхід, що фокусується на візуалізації роботи, обмеженні work in progress і плавному потоці задач.; Якщо команда щодня проводить standup, але нічого не змінює після feedback, не доставляє цінність і боїться переглядати план, це радше театр Agile, а не Agile.; * cycle time;
* lead time;
* throughput;
* defect rate;
* escaped defects;
* deployment frequency;
* change failure rate;
* customer satisfaction;
* team health;
* work in progress;
* predictability.; * код написаний;
* code review пройдено;
* тести проходять;
* acceptance criteria виконані;
* документація оновлена;
* security checks пройдені;
* feature deployed;
* monitoring/logging додані;
* UX перевірено;
* немає критичних bugs.; щоб [цінність або причина].; Суть

'''істотно:''' Agile-план — це не кам’яна табличка, а гіпотеза, яку регулярно перевіряють і оновлюють.;== Agile і UX ==

Вона сприяє:
Інкремент 3: checkout
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
</div>
== Sprint ==
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
'''Небезпека:''' найгірша реліз Agile — це коли команда отримує більше мітингів, але не отримує більше довіри, ясності й функціональні можливості покращувати роботу.; - користувач системи має змогу ввести email на сторінці відновлення

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

* вимоги в цілому стабільні й жорстко регульовані;
* немає доступу до користувачів або feedback;
* stakeholders хочуть лише fixed scope, fixed date і fixed budget без компромісів;
* команда не має права приймати рішення для бізнесу;
* організація використовує Agile лише як контрольну систему;
* немає технічної здатності часто доставляти;
* потрібне суворе compliance-документування без гнучкості;
* проєкт краще описується класичним engineering plan.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
</div>
'''Практична порада:''' Agile найкраще функціонує для продуктів, де навчання під час розробки є собою не винятком, а нормою.;</div>
== Acceptance Criteria ==
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Показати working software
'''Проста аналогія:''' Agile — це як навігація в дорозі: маршрут потрібен, але якщо попереду ремонт або затор, розумніше змінити шлях, ніж вперто їхати за старим планом.; як ілюстрація:
Ретроспектива має змогу торкатися:

<syntaxhighlight lang="text">
'''Критично:''' Agile не означає “оперативно й брудно”.; Backlog → Ready → In Progress → Review → Testing → Done
Як ми зрозуміємо, що стало краще?; * потребує зрілої команди;
* погано функціонує без довіри;
* вимагає активної участі Product Owner;
* не вирішує автономно технічні проблеми;
* має змогу перетворитися на хаос без пріоритетів;
* має змогу стати “театром мітингів”;
* не замінює інженерну якість;
* не підходить однаково для всіх типів проєктів;
* потребує дисципліни delivery;
* погані метрики можуть зіпсувати поведінку;
* stakeholders мають бути готові до прозорості й змін.; Критерій
</div>

Кожен інкремент додає частину цінності.;</div>
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Product Owner зазвичай:

{| class="wikitable"

Можливі проблеми:

And кількість товарів у кошику збільшується на 1

* свідомим;
* випадковим;
* архітектурним;
* тестовим;
* інфраструктурним;
* документаційним;
* security-related;
* пов’язаним із dependencies.;<syntaxhighlight lang="text">
'''істотно:''' MVP має бути viable.;</div>
</div>
'''Проста думка:''' Agile-документація має бути достатньою, живою й корисною.;</div>
== Lean ==
Agile і DevOps добре доповнюють одне одного.;== Agile у не-software сферах ==
'''Небезпека:''' якщо метрика стає способом тиску, люди починають оптимізувати метрику, а не програмний продукт.; '''Помилка:''' daily standup не має бути звітом кожного розробника перед менеджером.;== Agile і DevOps ==

Поширені помилки:

* product vision;
* product roadmap;
* release plan;
* sprint plan;
* daily plan;
* backlog refinement.; '''Scrum Master''' — роль, яка сприяє команді правильно використовувати Scrum, прибирати перешкоди й покращувати бізнес-процес.; Given користувач системи відкрив сторінку товару

Velocity

Інкремент 6: купони й рекомендації

Agile Planning

істотно: Agile не означає “без структури”.; * Agile не є собою синонімом Scrum.;

Scrum Master має змогу:

Scrum має:

Типові рівні:

user stories;
bugs;
technical debt;
research tasks;
improvements;
experiments;
UX changes;
infrastructure work;
security tasks;
documentation tasks.;

Velocity — приблизна кількість story points, яку команда завершує за sprint.; Якщо команда постійно ігнорує якість, швидкість скоро падає.;

Коли Agile має змогу бути невдалим вибором

Уточнити acceptance criteria Agile має змогу бути не найкращим вибором, якщо:

Technical debt — технічний борг, який виникає, коли команда обирає швидше рішення для бізнесу, що має змогу ускладнити майбутні зміни.; як ілюстрація, інтернет-магазин можна робити так: Практична роль: XP нагадує, що Agile без інженерної якості оперативно перетворюється на швидке виробництво technical debt.;== Scrum ==

Некорисна документація:

Команда використовує Kanban, WIP limits і постійний потік задач без жорстких sprint-ів.;

{{SEO

Product Backlog — впорядкований список усього, що має змогу бути потрібно продукту.;

Див.; додатково

Зібрати feedback

Scrum Master

істотно: хороша user story описує не без ускладнень кнопку, а потребу користувача й перевірні умови готовності.;

Рекомендовано:

створювати ясність цілей;
прибирати організаційні перешкоди;
підтримувати команди;
давати контекст;
допомагати із пріоритетами;
не ламати WIP;
не змінювати задачі хаотично всередині sprint;
підтримувати learning culture;
вимірювати outcomes, а не зайнятість.; Де ми втратили найбільше часу?; * Kanban має змогу бути agile без sprint-ів.;== Backlog Refinement ==

Вибрати найцінніші задачі

Головна думка: Agile — це не набір церемоній, а спосіб мислення: створювати цінність маленькими кроками, уважно слухати feedback і постійно покращувати як програмний продукт, так і спосіб роботи команди.; Agile не є собою одним конкретним фреймворком.; * Agile не забороняє документацію, а просить не ставити документацію вище за реальний програмний продукт.; Waterfall — це послідовний підхід, де етапи йдуть один за одним: requirements, design, development, testing, release.; Практична роль: backlog — це не смітник для усіх ідей, а живий список пріоритетів продукту.;

Sprint Goal;
вибір задач;
розробку;
тестування;
демонстрацію результату;
ретроспективу;
підготовку наступного циклу.; * software development;
web applications;
mobile apps;
SaaS-продуктів;
startup-продуктів;
enterprise software;
internal tools;
product discovery;
digital transformation;
UX/UI роботи;
DevOps;
continuous delivery;
data products;
AI/ML продуктів у частині сценаріїв;
командної роботи з високою невизначеністю.;

</syntaxhighlight>

Sprint Review — подія, де команда показує результат sprint і збирає feedback.; Product Owner — роль у Scrum, відповідальна за цінність продукту й упорядкування Product Backlog.; Waterfall

Приклад Agile-циклу

Вони можуть враховувати:

Story Points

!; * waste;

value stream;
flow;
bottlenecks;
continuous improvement;
respect for people;
small batches;
fast feedback;
built-in quality.; щоб повернути доступ до акаунта, якщо забув пароль.;== Цікавий факт ==

Continuous Integration

Technical Debt

Критично: якщо менеджмент тисне на velocity, команда має змогу почати “роздувати” оцінки, і метрика втратить сенс.; Хто відповідальний за цю зміну?; Висновок: Waterfall не завжди поганий, а Agile не завжди кращий.;

CI охоплює:

Roadmap має змогу показувати:

Agile має обмеження.; Extreme Programming або XP — Agile-підхід, який робить сильний акцент на інженерних практиках.; * Agile часто провалюється не через ідеї Agile, а через культуру контролю, страху й фіктивної прозорості.; Lean вплинув на Agile через ідеї усунення waste, покращення flow і фокус на цінності.; Agile Manifesto прямо підкреслює, що речі справа мають цінність, але речі зліва цінуються більше.;

'''Agile''' — це гнучкий підхід до software development і product delivery, який сприяє командам працювати в умовах змін, часто доставляти цінність, отримувати feedback і покращувати бізнес-процес.; '''Псевдо-Agile''' або '''Agile theater''' — ситуація, коли команда має зовнішні атрибути Agile, але не має суті.; * Retrospective — одна з найцінніших практик, якщо після неї справді змінюється поведінка команди.; '''MVP''' або '''Minimum Viable Product''' — мінімальна реліз продукту, яка надає можливість перевірити важливу гіпотезу або дати користувачу базову цінність.; '''істотно:''' estimation — це не обіцянка до хвилини.; Він був про інший спосіб думати про розробку: менше поклоніння процесу заради процесу, більше working software, співпраці й реакції на зміни.;== Джерела ==

* Agile Manifesto дуже короткий, але вплинув на десятиліття software development.; Часто він триває 1–4 тижні.; * Scrum Guide 2020.; Agile фокусується на:
</div>
</div>

<syntaxhighlight lang="text">

=== UX discovery ===

Протестувати

* product vision;
* customer discovery;
* roadmap;
* prioritization;
* backlog management;
* outcome metrics;
* experiments;
* stakeholder alignment;
* release planning;
* feedback loops.; '''Перевага:''' Agile сприяє не чекати ідеального плану на рік, а швидше створити першу корисну версію, отримати feedback і покращити програмний продукт.; '''Проста ідея:''' Done — це не “я закомітив код”, а “користувач системи або програмний продукт реально отримав готовий результат”.;== Типові помилки початківців ==

Agile feedback має змогу приходити від:

* Agile Manifesto.; Оновити backlog
Agile planning не означає відсутність планування.; '''Практична роль:''' DevOps сприяє Agile-команді реально доставляти зміни часто, а не лише планувати їх у sprint.; Backlog має змогу містити:
Інкремент 5: кабінет користувача
</div>
Але velocity небезпечно використовувати як KPI.;== Feedback loop ==
- Новий пароль має пройти validation

'''Підказка:''' Agile варто починати не з вибору інструмента, а з питання: як команда буде швидше отримувати feedback і перетворювати його на кращий програмний продукт?; * Agile Alliance materials about Agile principles.; Acceptance criteria корисні для:

'''Story points''' — відносна оцінка складності задачі.; Then товар з’являється в кошику

== Висновок ==

* support teams;
* maintenance;
* DevOps;
* operations;
* continuous delivery;
* команд із нерівномірним потоком задач;
* bug fixing;
* service teams.;</div>
'''Найлюдяніший факт:''' Agile — це не метод “працювати швидше за будь-яку ціну”.; UX сприяє зрозуміти, що саме буде цінним.; * розуміння scope;
* тестування;
* розмови між бізнесом і розробкою;
* зменшення неоднозначності;
* definition of done;
* QA.;== Work In Progress Limit ==

* думати, що Agile означає “без плану”;
* копіювати Scrum без розуміння;
* проводити daily як формування звітів;
* не робити retrospectives;
* ігнорувати technical debt;
* не мати Product Owner;
* не мати Definition of Done;
* брати в sprint більше, ніж реально можливо;
* міняти sprint scope щодня;
* оцінювати людей за story points;
* плутати busy work із value;
* писати user stories без користувацької цінності;
* не показувати working software;
* не збирати feedback;
* використовувати Jira як заміну мисленню.;</div>

* pair programming;
* test-driven development;
* continuous integration;
* simple design;
* refactoring;
* collective code ownership;
* small releases;
* coding standards;
* customer involvement.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

уточнює user stories;
розбиває великі задачі;
додає acceptance criteria;
оцінює складність;
виявляє залежності;
уточнює пріоритети;
видаляє застарілі задачі.; Definition of Done має змогу включати:

Інкремент 4: оплата

Scrum Team;
Product Owner;
Scrum Master;
Developers;
Product Backlog;
Sprint Backlog;
Increment;
Sprint;
Sprint Planning;
Daily Scrum;
Sprint Review;
Sprint Retrospective.; Agile — це гнучкий підхід до розробки програмного забезпечення, керування продуктами й командної роботи, який робить акцент на швидкій доставці цінності, адаптації до змін, тісній співпраці з користувачами й регулярному покращенні процесу.; Agile змінює роль менеджменту.;== переважні аспекти Agile ==

Приклад retrospective questions

найвищий пріоритет — задовольнити клієнта через ранню й безперервну доставку цінного software;
зміни вимог приймаються навіть пізно в розробці;
working software доставляється часто;
бізнес-середовище і розробники працюють разом регулярно;
проєкти будуються навколо мотивованих людей;
face-to-face conversation є собою дуже ефективним способом комунікації;
working software — головна міра прогресу;
sustainable development важливий для довгого темпу;
технічна якість і хороший design підсилюють agility;
simplicity — мистецтво не робити зайвої роботи;
найкращі архітектури й рішення для бізнесу виникають із self-organizing teams;
команда регулярно аналізує, як стати ефективнішою, і змінює поведінку.;=== Startup MVP ===

Daily Scrum або Daily Standup

!; щоб повернутися до покупки пізніше.; !;

velocity як KPI;
кількість story points на людину;
кількість закритих задач без оцінки цінності;
utilization 100%;
порівняння команд за points.; Acceptance criteria — умови, за якими команда розуміє, що задача виконана правильно.; Цінність

product goals;
major features;
themes;
outcomes;
release windows;
strategic priorities;
dependencies;
ризики;
assumptions.;

automated tests;
CI;
deployment pipeline;
feature flags;
rollback strategy;
monitoring;
small changes;
reliable environments;
database migration discipline.; я хочу скинути пароль через email,

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

Який один експеримент ми спробуємо?; * Working software у принципах Agile є собою головною мірою прогресу.; * Principles behind the Agile Manifesto.;

Product management в Agile охоплює:

</syntaxhighlight>

це не “робити без плану”, а планувати короткими циклами, часто перевіряти результат і оперативно змінювати напрям, якщо реальність показала щось нове виступає ключовою рисою Основна ідея: Agile.;

Сформулювати product goal

Technical debt має змогу бути: