Історія та основні постулати Agile
Agile (від англійського слова – спритний, спритний) – узагальнюючий термін, що охоплює різні методи управління проектами та організації праці, засновані на гнучких принципах на противагу традиційним жорстким принципам. Такі методи та прийоми роботи розроблялися в 1990-х роках серед програмістів, а в 2001 році група розробників програмного забезпечення (ПО) склала «Маніфест гнучкої розробки» (Agile Manifesto). Пізніше зазначені у ньому принципи виявилися корисними й інших сферах, як-от маркетинг, надання послуг, виробництво високотехнологічних пристроїв, освоєння нових ніш, управління окремими робочими групами у великих корпораціях.
Щоб краще зрозуміти принципи Agile, варто коротко описати колишній підхід, якому вони протиставлені.
Колишня модель розробки ПЗ називалася каскадною або водоспадною (waterfell model). Згідно з цією моделлю, розробники переходять від однієї стадії до іншої строго по порядку і тільки після того, як повністю завершена колишня стадія:
1. Визначення вимог.
2. Упорядкування плану.
3. Створення.
4. Тестування.
5. Використання.
6. Підтримка.
Така модель була зручна тим, що гарантувала якість продукту та його відповідність заздалегідь відомим вимогам. Крім того, вона добре відповідала загальноприйнятим у XX столітті методам управління промисловим виробництвом з його упором на ієрархію, стандартизацію та звітність.
Але згодом стали помітні недоліки моделі. ПЗ ускладнювалося, а ділове середовище ставало все більш непередбачуваним. Заявлені на початку розробки технічні вимоги до кінця процесу могли застаріти чи змінитись, а в ході роботи виникали нові, раніше непередбачені вимоги та обставини. Враховувати їх часто бувало вже надто пізно, і розробники воліли зовсім відмовлятися від випуску продукту, втрачаючи гроші та час. Крім того, деякими особливостями готового продукту (до 60% функціоналу) клієнти користувалися рідко або не користувалися зовсім, адже на їхню розробку витрачалися час та ресурси. У таких умовах перевагу отримували компанії, які першими випускали нехай і не зовсім «вилізані», але більш менш робочі версії затребуваних у користувачів продуктів.
Цінності Agile
Що ж допомагало цим гнучким компаніям та колективам розробників випереджати конкурентів? «Маніфест» постулює чотири основні цінності:
• Люди та взаємодія важливіші за процеси та інструменти.
• Працюючий продукт важливіший за вичерпну документацію.
• Співпраця із замовником важливіша за погодження умов контракту.
• Готовність до змін важливіша за дотримання початкового плану.
Автори додають: «Не заперечуючи важливості того, що праворуч, ми таки більше цінуємо те, що ліворуч».
12 принципів Agile
На додачу до цінностей автори «Маніфесту» перераховували 12 принципів, на яких мають будуватися робота та управління проектом:
1. Потрібно задовольняти потреби замовника завдяки ранньому та регулярному постачанню цінного ПЗ.
2. Зміни вітаються навіть у пізній стадії розробки.
3. Випускати працюючий продукт слід якнайчастіше, від кількох тижнів до кількох місяців.
4. Розробники та представники бізнесу мають співпрацювати щодня.
5. Над проектом мають працювати мотивовані розробники, яким створено комфортні умови.
6. Найефективніший спосіб обміну інформацією – безпосереднє усне спілкування.
7. Основний показник прогресу – працюючий продукт.
8. Процес має бути стійким, мати постійний ритм і в ідеалі тривати невизначено довго.
9. Увага до технічної досконалості та якості має бути постійною.
10. Головне – простота, тобто мистецтво мінімізації та відмови від зайвого.
11. Кращі рішення народжуються у команд, що самоорганізуються.
12. Команда повинна регулярно аналізувати свою роботу, коригуючи її за необхідності.
На додаток до цих принципів, автори книги перераховують три Platinum-принципи, прийняті в їх організації Platinum Edge:
• Опиратися формальності.
• Думати, як команда.
• Візуалізація краща за текст.
У «Маніфесті» не вказувалися якісь конкретні методи роботи та управління, тому загальні принципи Agile відбилися у різних практичних методах та прийомах, серед яких — екстремальне програмування (XP), ощадна розробка продукту (lean product development, заснована на виробничій системі японської компанії) Toyota) та Scrum. Автори книги описують насамперед метод Scrum, доповнюючи його прийомами з інших методів та своїми власними розробками.
Що таке Scrum і як він працює
Основні принципи Scrum
Спочатку під Scrum 1 малася на увазі методологія гнучкої розробки ПЗ, згодом перенесена на організацію праці в інших сферах. Сам термін Scrum запозичений із регбі – це сутичка гравців перед подачею м’яча.
Суть методу полягає в тому, що продукт розробляють не послідовно, одну частину за іншою, згідно з заздалегідь складеним жорстким планом, а циклами, в кінці кожного з яких виходить відносно працюючий результат. Такий результат (реліз) можна навіть випустити на ринок, одночасно продовжуючи доводити його до пуття в наступних циклах.
Цикли розробки називаються спринтами (від англійської sprint – невеликий забіг, ривок). Через циклічність цього його ще називають ітеративним (від слова «ітерація» — повторення).
Мета методу – випустити не ідеальний, на думку розробників, продукт, а версію, яка багато в чому відповідає вимогам замовників, виправдовує більшість надій клієнтів та дозволяє отримати розумну вигоду.
Для методу Scrum характерні специфічні ролі в команді, артефакти (використання в роботі фізичних чи віртуальних об’єктів) та події (дії, що виконуються у визначеному порядку).
Scrum-команда та ролі в ній
Власне Scrum-команда складається з розробників, власника продукту та Scrum-майстра. Усередині Scrum-команди виділяють команду розробників, а вона може входити до команди проекту, до якої належать також зацікавлені особи (stakeholders) — це можуть бути замовники комерційного проекту або адміністратори компанії, на замовлення якої здійснюється проект.
Основних ролей у Scrum-команді три:
1. Розробники – це фахівці, які мають інтереси не тільки у своїй вузькій галузі, а й у суміжних областях і тому готові прийти один одному на допомогу і розуміють особливості праці своїх колег.
Наприклад, це можуть бути програмісти, налагоджувачі, тестувальники, дизайнери та художники.
Розробники за сприяння інших членів Scrum-команди самі визначають собі завдання та знаходять оптимальні способи їх виконання.
Чисельність команди розробників – від трьох до дев’яти осіб.
За статистикою, швидше діють команди із шести осіб, але дешевше обходяться команди із чотирьох-п’яти осіб.
Якщо чисельність команди більша, неминуче з’являються різні фракції та групи за інтересами, що уповільнює роботу та ускладнює керівництво проектом. Менший розмір також недоцільний, тому що протягом спринту всі члени команди повинні працювати над одними й тими самими завданнями з різних сторін (хтось пише код, хтось робить оформлення).
2. Власник продукту – людина, яка підтримує зв’язок команди із замовниками та представниками бізнесу. Крім того, він служить посередником між командою та іншими підрозділами організації на кшталт відділів маркетингу та продажу, юридичного відділу та служби підтримки. До його обов’язків входить враховувати в проекті інтереси різних сторін, у тому числі можливих користувачів та клієнтів. У традиційному менеджменті його назвали б менеджером проекту, але в Scrum-команді немає вертикальної ієрархії.
3. Scrum-майстер – людина, яка проводить наради, стежить за дотриманням принципів Scrum, управляє інвентарем і об’єктами, вирішує конфлікти всередині команди і захищає команду від факторів, що відволікають. Його теж не можна назвати менеджером у традиційному сенсі, тому що він не віддає жодних наказів розробникам та не визначає їх завдання.
Для злагодженої роботи всім членам команди важливо перебувати в одному місці (кімнаті, залі, відсіку) — це так звана колокація, яка відповідає цінностям та принципам Agile.
Усі спілкування наскільки можна проводити безпосередньо. Якщо це неможливо, то за участю візуальних засобів зв’язку, хоча таких ситуацій слід уникати. Багато питань вирішуються набагато швидше за безпосереднього усного спілкування, ніж, припустимо, електронною поштою.
Також ніщо не повинно відволікати членів команди від роботи над проектом — жодних сторонніх замовлень, малокорисних офіційних нарад, стороннього шуму, заповнення купи непотрібних паперів. За цим має стежити Scrum-майстер.
Крім Scrum-майстра в команді може бути і Agile-ментор – зовнішній спеціаліст з Agile, особливо на початкових стадіях освоєння методики.
Артефакти та інструменти
Інструменти, що використовуються при управлінні проектом, повинні бути по можливості простими і наочними. Вітається використання білих дощок, інформація на яких доступна всім відповідно до принципу відкритості. Робочі інструменти (наприклад, комп’ютери) також повинні бути по можливості мобільними, щоб члени однієї команди могли легко обмінюватися інформацією.
До основних Scrum-артефактів належать такі:
• Беклог (журнал) продукту. Список повних вимог до продукту та очікуваних функцій. Складається на початку першого спринту власником продукту з урахуванням побажань замовників та інших заінтересованих осіб. Протягом роботи беклог змінюється, оскільки під час роботи з’ясовуються нові вимоги, фактори, перешкоди та можливості. Власник продукту розставляє вимоги пріоритету, і їх порядок також може змінюватися.
• Беклог (журнал) спринту. Список завдань на черговий спринт, що визначаються Scrum-командою на основі пріоритетних вимог та завдань у белог продукту. Змінювати його можуть лише розробники. Вони ж за сприяння Scrum-майстра визначають відносну цінність кожного завдання, формулюють історії та критерії їхньої готовності.
• Інкремент продукту. Відчутний результат роботи одного спринту (наприклад, впровадження нової функції на сайті). Показується замовникам та іншим заінтересованим особам з метою оцінки виконаної роботи та отримання зворотного зв’язку.
Події Scrum
• Спринт. Цикл розробки, всередині якого відбуваються інші події, а у фіналі створюється продукт із потенційною функціональністю. Тривалість спринту фіксована – від тижня до місяця.
Чим коротший спринт, тим більша гнучкість розробки, швидше виходять релізи та надходять відгуки від споживачів. Чим довше спринт, тим менше факторів, що відволікають.
Важливо дотримуватись встановленої тривалості спринтів і не змінювати її в ході роботи над окремим проектом, тому що тільки так можна оцінювати швидкість та ефективність роботи.
• Планування спринту. Проводиться на початку кожного спринту. На цій нараді команда визначає мету спринту, формулює собі завдання та складає беклог спринту.
• Щоденна нарада (Scrum). Проводиться на початку кожного дня, переважно стоячи, і триває трохи більше 15 хвилин. На ньому розробники говорять про те, що команда зробила за минулий день, що запланувала сьогодні і які перешкоди можуть перешкодити її роботі.
• Огляд результатів спринту (демонстрація). Команда демонструє продукт з інкрементом усім зацікавленим особам та вислуховує їх відгуки та побажання. Незавершені функції не можна демонструвати. Демонстрація повинна бути строго функціональною, без будь-яких прикрас та зайвих презентацій слайдів, бажано в робочому середовищі (наприклад, на екрані смартфона, якщо ця програма для смартфона). Триває не більше одного? чотири години (залежно від довжини спринтів).
• Ретроспектива спринту. Підсумкова нарада Scrum-команди, на якій всі члени команди висловлюють свою думку про минулий спринт, фіксують вдалі рішення та пропонують способи вирішення проблем. Тут можуть визначитися нові вимоги до продукту. На плануванні спринту і на ретроспективі можуть бути інші особи крім членів Scrum-команди, і це навіть заохочується через принцип відкритості, але вони не мають права голосу. Триває не більше 45 хвилин? три години (залежно від довжини спринтів).
Типова схема моделі Scrum
Як проходять проекти з використанням методу Scrum
Автори книги у своїй компанії Platinum Edge розробили план «Дорога до цінності» (Roadmap to Value), що охоплює всю роботу над проектом від задуму до створення задовільного продукту (кінцевим він не називається, тому що працювати над ним можна й надалі, як і підтримувати його) після запуску).
Цей план складається із семи стадій:
1. Створення концепції товару. 2. Створення дорожньої карти товару.
3. Планування релізу.
4. Планування спринту.
5. Спринт із щоденними нарадами.
6. Огляд результатів спринту (демонстрація).
7. Ретроспектива спринту.
Стадії 3–7 повторюються, доки не буде представлений задовільний продукт або доки проект не зупинять. Розглянемо деякі ці стадії докладніше.
Концепція продукту
Концепція продукту? це короткий опис, де немає докладних функціональних вимог. Вона відповідає на такі питання, як: «Хто буде користуватися цим продуктом?», «У яких ситуаціях ним користуватимуться?», «Яку вигоду отримають його користувачі?», «Яка вигода від нього для компанії?» і т. д. Концепцію складає власник продукту під час обговорення із замовниками та іншими зацікавленими особами. Для великих проектів оновлювати її слід щонайменше раз на рік.
Дорожня картка продукту
Дорожня карта – це вже докладніше опис проекту з перерахуванням всіх вимог щодо нього та його передбачуваних функцій , яку також становить власник продукту. До дорожньої карти можна включати користувацькі історії. Тут же слід накидати найзагальніші терміни для виконання кожної вимоги, оскільки вони все одно змінюватимуться під час роботи.
Дорожню карту рекомендується коригувати щонайменше двічі на рік.
Вимоги та функції розташовуються у порядку пріоритету із зазначенням ризиків та залежностей від інших функцій чи проектів; їх також можна розподіляти за більш загальними групами, темами або «епічними історіями».
При складанні дорожньої карти потрібно радитися не лише із замовниками, а й з усіма зацікавленими особами чи відділами, які можуть мати якесь відношення до проекту або залежати від нього (маркетинг, продаж, бухгалтерія, юридичний відділ, служба підтримки користувачів тощо) .). На основі дорожньої карти власник продукту складає беклог продукту.
Планування релізу
Це необов’язкова стадія, тому що деякі Scrum-команди працюють без релізів і просто демонструють продукт з інкрементом наприкінці кожного спринту. Але якщо виходять релізи продукту, на основі яких збирають дані про реакції користувачів, деякі спринти можуть бути релізними і відрізнятися тим, що основна їх мета – підготовка до демонстрації релізу.
Планування спринту
Перед початком кожного спринту Scrum-команда проводить нараду щодо планування спринту.
Рекомендована тривалість такої наради — не більше двох годин, якщо спринт триває один тиждень (чотири години, якщо триває два тижні, і т. д.).
На цьому етапі планування зростає роль декомпозиції, тобто деталізації вимог та зіставлення їх із конкретними завданнями. Головну роль у своїй грають розробники. З бэклога товару вони вибирають пріоритетні вимоги і обговорюють, як їх можна реалізувати як функцій чи характеристик продукту. Далі функції розбиваються завдання — елементи. Вважається, що в ідеальному випадку один елемент повинен виконуватись за один день, максимум за 12 годин.
Один з ефективних форматів для деталізації вимог і розбивки їх на елементи — історії користувача. Розглянемо його докладніше.
Історія користувача — це опис будь-якої функції продукту з точки зору користувача. Для наочності корисно уявити типових користувачів продукту як вигаданих персонажів.
Наприклад: Джейсон? молодий користувач із технічною освітою, зацікавлений у персональних послугах; Керол? власниця невеликого підприємства, зацікавлена у послугах для бізнесу тощо; можна навіть використати невеликі фотографії для візуалізації.
Саму ж історію можна подати у вигляді картки, на якій описано дію певного користувача та результат цієї дії. Крім цього можуть бути вказані назва історії, її складність (оцінка в окулярах), номер картки, ім’я складника та критерії готовності (на обороті).
Користувальницька історія для банківського мобільного додатка:
Назва: «Переказ коштів між картами»
Як: пересічний користувач (Джейсон)
Я хочу: переказати кошти між своїми картками
Щоб: на кожній з них виявилася потрібна мені сума
Окуляри: 5
Автор: Дженніфер
Критерії готовності
Оцінка складності в окулярах важлива як завдання пріоритетів, але й наступного аналізу виконаної роботи та визначення швидкості спринту.
Оцінка виставляється в умовних та абстрактних окулярах історії. Поза форматом історій оцінки можна давати будь-яким наміченим на спринт функцій продукту та елементам. Кожна історія чи завдання отримує оцінку в залежності від своєї складності (трудомісткості, часу на реалізацію в робочому годиннику і т. д.). На історію з оцінкою 5 піде більше часу та зусиль, ніж на історію з оцінкою 2 або 1.
Присвоєння очок історіям або функціям відбувається в процесі так званого планування покеру.
Планування покеру. Кожному розробнику видається колода карток з числами. Автори книги вважають за краще використовувати карти з числами з ряду Фібоначчі: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 і т.д.
У ряді Фібоначчі кожне наступне число дорівнює сумі двох попередніх; так завдання та історії не дробляться на рівні частини, що могло б сприйматися як сума дрібніших рівних завдань.
Крім цих карт є картка з питанням, що означає, що розробник не розуміє суті завдання. Далі виконуються такі кроки:
1. Власник продукту вибирає (пріоритетний) елемент з беклогу продукту та зачитує його опис команді.
2. Розробники обговорюють елемент та задають уточнюючі питання.
3. Кожен розробник потай оцінює елемент.
4. Усі розробники одночасно показують карти зі своїми оцінками.
5. Якщо всі показали однакові оцінки, згода досягнута та елемент отримує оцінку.
6. Якщо оцінки різні, проводиться обговорення елемента; Спочатку висловлюються ті, хто поставив найбільшу і найменшу оцінку.
7. Розробники знову виставляють оцінки.
8. Якщо загальна згода не досягнута після трьох раундів, Scrum-майстер допомагає розробникам досягти її або пропонує розбити завдання на дрібніші елементи.
Кожному елементу не рекомендується надавати оцінку більше восьми очок.
Важливо пам’ятати, що очкам відповідає щось реальне. Це лише суб’єктивна оцінка розробників конкретної команди.
Окуляри не можна використовувати для визначення ефективності різних команд («Поки ви прохолоджуєтеся тут, інша команда набрала 40 очок!»).
Не можна й підганяти свою діяльність під окуляри, щоб створювати видимість роботи. Узгоджені елементи вносяться в беклог спринту. Далі його не можна буде міняти.
Якщо в процесі спринту виникне якась нова ідея, розробники повідомляють про неї власнику продукту, а той вирішує, чи помістити її в беклог продукту, чи беклог наступного спринту, чи обговорити її корисність із замовниками.
Швидкість спринту — це сума всіх історій користувача/елементів, виконаних за спринт.
Якщо перший спринт команда завершила роботу над шістьма історіями з очками 8, 5, 5, 3, 2, 1, її швидкість дорівнює 24, і за плануванні другого спринту розробникам варто орієнтуватися цього число. У третій та наступні спринти швидкість може коригуватися. Тому так важливо підтримувати задану довжину спринту та рівномірний темп роботи, а також не допускати авралів та вигорянь. Без цього неможливі більш менш об’єктивний аналіз і планування спринтів.
Після перших чотирьох спринтів зазвичай швидкість вирівнюється і з’являється можливість точніше розрахувати тривалість роботи над проектом. Для цього власник продукту множить середню швидкість на загальну суму оцінок завдань, що залишилися в белогу.
Якщо середня швидкість дорівнює 20, а беклог продукту, що залишився, містить 800 очок, то проект займе ще 800/20 = 40 спринтів, тобто 40 тижнів для однотижневих і 80 тижнів для двотижневих спринтів.
Спринт
Після планування спринту починається робота в рамках спринту зі щоденними короткими нарадами (скрамами), що тривають не більше 15 хвилин на день. Під час роботи Scrum команда може використовувати різні способи візуалізації робочого процесу. Серед них варто зазначити такі:
• Канбан-дошки. Дозволяють відстежувати розробку перерахованих у белогу спринту завдань. Кожне завдання представлене у вигляді картки або стікера, які можна переміщати колонками «Зробити», «У розробці», «Прийняти» та «Здано». (Кількість колонок може бути різною залежно від стилю роботи команди, наприклад, може бути колонка «Тестується».) Власник продукту аналізує готові елементи та переводить їх у розряд «Здано».
• Діаграма згоряння. Показує завершений і решту обсягів робіт в окулярах історій і в годинах, дозволяє порівнювати темп роботи з ідеальним. Для її побудови по горизонталі відзначають дні спринту, по вертикалі зліва – кількість робочих годин (всіх розробників), а по вертикалі праворуч – кількість очок.
Ідеальний графік (план) поєднує точку наявних робочих годин і очок на початку спринту з нульовою точкою наприкінці спринту. Якщо реальний графік піднімається над ідеальним, це означає, що команда відстає від запланованого. Якщо реальний графік опускається під ідеальний? команда випереджає план. У будь-якому разі це привід задуматися, наскільки правильно вона встановила собі обсяг завдань. При надто швидкому завершенні графіка варто додати елементи наступного спринту і орієнтуватися наступного разу на більше.
Особливу увагу слід приділяти тестуванню продукту. У каскадній моделі тестують готовий продукт на етапі, коли працювати над помилками часто вже пізно. В Agile-моделях тестування має проводитись одночасно з розробкою.
Якщо йдеться про програмне забезпечення, рекомендується проводити автоматичне тестування, наприклад, обкатувати програму вночі після закінчення денних робіт. Для підвищення надійності рекомендується використовувати такі методи, як парне кодування, коли один розробник пише програму, а інший відразу аналізує її і дає поради.
Під час роботи над одним елементом не слід розпорошуватися та перескакувати на інші елементи чи сторонню роботу. Метод, коли всі члени команди одночасно працюють над однією історією, називається “свормінг” (від англійського слова swarm – рій, полчище).
Два складні моменти під час використання Scrum
В ідеальному випадку над невеликим та середнім проектом має працювати лише одна команда. Тут “більше” не означає “краще”. Коли для роботи над дуже великими та складними проектами мобілізують декілька Scrum-команд, виникають проблеми узгодження , тому що різні команди можуть мати різні швидкості та стилі роботи, але через певні інтервали потрібно продемонструвати загальний робочий інкремент.
Один із способів узгодження – так званий вертикальний слайсинг. Вимоги до продукту поділяються за темами або групами та призначаються різним командам, які працюють синхронними спринтами. Окрема інтеграційна команда Scrum стежить за інтеграцією елементів різних команд. Після щоденної Scrum-наради команд проводиться «скрам скрамів», на якому присутні представники всіх команд. Власник продукту інтеграційної команди складає єдиний беклог проекту. У дуже складному та великомасштабному проекті команди можуть об’єднуватись у п’ятірки, і проводиться «метаскрам» за участю власників проектів та Scrum-майстрів цих п’ятірок. Відповідно, після індивідуальних проводять і загальні огляди з ретроспективами.
Проблеми виникають і під час переходу компанії на модель Scrum. Багато проблем пов’язані з тим, що компанія намагається поєднувати традиційні каскадні методи з Agile-методами, що робити не рекомендується. Пілотний проект не повинен бути критично важливим, але має представляти цінність для компанії.
При формуванні Scrum-команди потрібно залучати активних фахівців та правильно підібрати ролі відповідно до їхньої компетенції. У переході допомагає Agile-менеджер, який має за плечима досвід роботи в Agile-проектах. Існують різні організації, що пропонують допомогу з переходу на Scrum-модель, які проводять навчання та видають сертифікати.
10 найкращих думок
1. Agile – це загальний термін для різних методів управління проектами та організації праці , заснованих на принципах самоорганізації, готовності до змін, простоти, співробітництва та відкритості.
2. Головне в Agile – не жорстке дотримання плану і не ідеальний кінцевий продукт, а створення працездатного продукту, наскільки можна в короткі терміни.
3. Один з Agile-методів – метод Scrum , в основі якого лежать повторювані робочі цикли однакової довжини – спринти, кожен з яких триває від одного до чотирьох тижнів.
4. Основні ролі Scrum-команди: розробники, власник продукту та Scrum-майстер. Оптимальна кількість розробників – від трьох до дев’яти. Зі Scrum-командою протягом усього процесу активно співпрацюють замовники та інші зацікавлені особи.
5. Власник продукту складає беклог (журнал) продукту – список вимог до продукту із зазначенням їхнього пріоритету; розробники під час планування спринту складають беклог спринту – список функцій та елементів, які потрібно реалізувати протягом спринту.
6. Щодня проводиться коротка нарада (Scrum), після якої команда спільно працює над елементами, одночасно тестуючи їх. Scrum-майстер стежить за дотриманням правил scrum і усуває відволікаючі фактори.
7. У своїй роботі Scrum-команда користується такими засобами, як користувацькі історії, канбан-дошки та діаграми згоряння. Швидкість спринту в умовних окулярах історій допомагає визначати ефективність всього процесу та аналізувати роботу над проектом.
8. Наприкінці кожного спринту Scrum-команда демонструє, наскільки можна у робочих умовах, результат своєї роботи — інкремент, реліз чи елементи продукту, в ідеальному разі готові до впровадження. Вислухавши зауваження та побажання, команда проводить ретроспективу спринту – аналіз своїх дій.
9. Додаткові вимоги, що виникають у процесі роботи та тестування, власник продукту вносить у беклог продукту. Далі цикл повторюється до отримання задовільного продукту відповідно до спільно встановлених критеріїв.
10. Не варто поєднувати Agile та традиційні каскадні методи управління проектами. Пілотний проект не повинен бути критично важливим, але має представляти цінність для компанії.
1 . Читайте саммарі «Scrum: як працювати вдвічі менше, встигаючи вдвічі більше» і «Scrum: коротка інструкція та введення в Agile»