Delivery

В данній статті розглянемо сферу виконання - Постачання (Delivery) в різних методологіях, в PMBOK7 та SAFe.

2.6 Сфера виконання постачання (2.6 Delivery Performance Domain in PMBOK-7)

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

Ефективне виконання сфери діяльності постачання призводить до наступних бажаних результатів:

• Проекти сприяють досягненню бізнес-цілей та просуванню стратегії.
• Проекти досягають результатів, заради яких вони були започатковані.
• Вигоди від проекту реалізуються в ті терміни, в які вони були заплановані.
• Команда проекту має чітке розуміння вимог.
• Зацікавлені сторони приймають і задовольняються результатами проекту.

Наступні визначення мають відношення до сфери виконання постачання:

• Вимога (Requirement). Умова або здатність, яка повинна бути присутня в продукті, послузі або результаті, щоб задовольнити бізнес-потреби.
• Структура розбиття робіт (Work Breakdown Structure, WBS). Ієрархічна декомпозиція загального обсягу робіт, які повинна виконати команда проекту для досягнення цілей проекту і створення необхідних результатів.
• Визначення стану готовності (Definition of Done, DoD). Контрольний список усіх критеріїв, які необхідно виконати, щоб результат можна було вважати готовим для використання замовником.
• Якість (Quality). Ступінь, до якого набір притаманних характеристик відповідає вимогам.
• Вартість якості (Cost of Quality, COQ). Усі витрати, понесені впродовж життєвого циклу продукту через інвестиції у запобігання невідповідності вимогам, оцінювання продукту або послуги на відповідність вимогам, а також у разі невиконання вимог.

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

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

2.6.1 Постачання цінностей (2.6.1 Delivery Of Value)

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

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

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

Документ бізнес-кейсу часто містить бізнес-обґрунтування і прогноз очікуваної цінності проекту для бізнесу. Формат бізнес-обґрунтування залежить від обраного підходу до розробки та життєвого циклу.

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

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

Результати (2.6.2 Deliverables)

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

Вимоги (2.6.2.1 Requirements)

Вимога (Requirement) - це умова або здатність, яка повинна бути присутня в продукті, послузі або результаті, щоб задовольнити бізнес-потреби. Вимоги можуть бути дуже високого рівня, як, наприклад, у бізнес-кейсі, або дуже детальними, як, наприклад, у критеріях прийнятності компонента системи.

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

Виявлення потреб (Requirements elicitation). Виявити означає витягнути, вивести на поверхню або викликати. Збір вимог - це більше, ніж інтерв'ювання чи проведення фокус-груп. Іноді вимоги виявляють шляхом аналізу даних, спостереження за процесами, перегляду журналів дефектів або іншими методами.

Частиною з'ясування вимог є їх документування та отримання згоди зацікавлених сторін. Добре задокументовані вимоги відповідають наступним критеріям:

• Зрозумілість (Clear). Існує лише один спосіб інтерпретувати вимогу.
• Стислість (Concise). Вимога сформульована якомога меншою кількістю слів.
• Перевірюваність (Verifiable). Існує спосіб перевірити, що вимога була виконана.
• Послідовність (Consistent). Немає суперечливих вимог.
• Повність (Complete). Набір вимог відображає всі поточні потреби до продукту проектора.
• Простежуваність (Traceable). Кожну вимогу можна розпізнати за унікальним ідентифікатором.

Розвиток і виявлення вимог (Evolving and discovering requirements). У проектах, які не мають чітко визначених вимог, для розвитку вимог можна використовувати демонстрації, прототипи, розкадровки та макети. У таких ситуаціях зацікавлені сторони, швидше за все, застосовуватимуть підхід до розробки вимог за принципом "я зрозумію, коли побачу". Вимоги, що розвиваються, часто зустрічаються в проектах, які використовують ітеративний, інкрементний або адаптивний підходи до розробки. У деяких випадках з'являються нові можливості, які змінюють вимоги.

Управління вимогами (Managing requirements). Незалежно від того, чи вимоги задокументовані заздалегідь, чи розвинулися в процесі виконання проекту, чи були виявлені, існує потреба в управлінні ними. Неефективне управління вимогами може призвести до переробок, розширення обсягу робіт, незадоволення замовника, перевитрати бюджету, відставання від графіка і загального провалу проекту. Тому в багатьох проектах призначають одну відповідальну особу за управління вимогами. Це може бути бізнес-аналітик, власник продукту, інженер з оцінки вартості або інша особа. Особи, які керують вимогами, можуть використовувати спеціалізоване програмне забезпечення, журнали відставання, картотеки, матриці простежуваності або інші методи, щоб забезпечити належний рівень гнучкості та стабільності вимог, а також узгодити нові та мінливі вимоги з усіма зацікавленими сторонами.

Визначення обсягу (2.6.2.2 Scope Definition)

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

Декомпозиція обсягу робіт (Scope decomposition).

Обсяг робіт може бути визначений за допомогою технічного завдання, яке визначає основні результати, пов'язані з проектом, і критерії прийняття кожного результату. Обсяг робіт також може бути визначений шляхом декомпозиції на більш низькі рівні деталізації за допомогою структури розбиття робіт (Work Breakdown Structure, WBS).

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

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

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

Історія користувача - це короткий опис результату для конкретного користувача, який є обіцянкою для розмови для уточнення деталей. Команда проекту визначає деталі історії в останній відповідальний момент, щоб уникнути марнотратного планування у разі зміни обсягу робіт. Історія - це чітке і стисле представлення вимоги, написане з точки зору кінцевого користувача.

Рухомі цілі завершення (2.6.2.3 Moving Targets of Completion)

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

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

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

На Рисунку 2-21 показано сценарій розробки нового розумного годинника. Початковий графік показує 12 місяців на розробку годинника з початковим набором можливостей і функцій. Оскільки конкуренти випускають подібні продукти, початковий набір можливостей і функцій збільшується, щоб залишатися актуальним на ринку. Це відсуває дату запуску на 14-й місяць. На 13-му місяці інший конкурент запускає продукт з ще більшими можливостями. Додавання цих можливостей відтермінує запуск до 16-го місяця. У якийсь момент буде прийнято рішення, чи випускати продукт як є, навіть якщо він не має найновіших функцій, чи продовжувати оновлювати функції до запуску.

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

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

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

Якість (2.6.3 Quality)

Постачання (Delivery) - це більше, ніж просто обсяг і вимоги. Обсяг та вимоги зосереджуються на тому, що має бути надано. Якість (Quality) фокусується на рівнях продуктивності, яких необхідно досягти. Вимоги до якості можуть бути відображені в критеріях завершення, визначенні виконаної роботи, технічному завданні або документації з вимогами.

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

Витрати на накладні витрати, навчання та аудит процесів покладаються на організацію, хоча вони використовуються в рамках проекту. Невід'ємною рисою проектів є збалансування потреб у якості процесів і продуктів з витратами, пов'язаними із задоволенням цих потреб.

• "Вартість якості" Cost of Quality (COQ) в PMBOK® 7 (2.6.3.1)
• Вартість змін (Cost of Change) в PMBOK® 7 (2.6.3.2)

Субоптимальні результати (2.6.4 Suboptimal Outcomes)

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

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

Ефективне управління проектами може мінімізувати негативні результати, але такі можливості є частиною невизначеності при спробі створити унікальний результат.

Взаємодія з іншими сферами виконання (2.6.5 Interaction With Other Performance Domains)

Область результативності виконання є кульмінацією роботи, виконаної в сфері виконання планування. Каденція виконання ґрунтується на способі структурування роботи в Області Підходу до розробки та Області виконання життєвого циклу. Сфера виконання проектних робіт уможливлює виконання шляхом встановлення процесів, управління фізичними ресурсами, управління закупівлями і так далі. Члени проектної команди виконують роботу в цій сфері діяльності для відповідних зацікавлених сторін. Характер роботи над створенням результатів впливатиме на те, як команда проекту долає невизначеність, що впливає на проект.

Конвеєр безперервної поставки в SAFe (Continuous Delivery Pipeline, CDP)

Конвеєр безперервної доставки (Continuous Delivery Pipeline, CDP) - це робочі процеси, діяльність та автоматизація, необхідні для супроводу нової функціональності від ідеї до надання цінності кінцевому користувачеві на його вимогу.

Як показано на Рисунку 1, конвеєр складається з чотирьох аспектів:

• Безперервне дослідження Continuous Exploration (CE),
• Безперервна інтеграція Continuous Integration (CI),
• Безперервне розгортання Continuous Deployment (CD) та
• Реліз на вимогу (Release on Demand)

...кожен з яких описаний в окремій статті.

Деталі CDP

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

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

Традиційні практики схильні сприймати випуски як великі монолітні шматки. Однак реальність така, що цінність релізу не обов'язково означає підхід "все або нічого". На прикладі супутника елементи системи складаються з супутника, наземної станції та веб-ферми, яка передає отримані супутникові дані кінцевим користувачам. Деякі елементи можуть випускатися щодня - наприклад, функціональність веб-ферми. Інші елементи, такі як апаратні компоненти самого супутника, можуть виходити в ефір лише під час кожного циклу запуску.

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

Чотири аспекти конвеєра безперервної поставки

Конвеєр безперервної поставки SAFe містить чотири аспекти: безперервне дослідження, безперервна інтеграція, безперервне розгортання та випуск на вимогу. CDP дозволяє організаціям відобразити свій поточний конвеєр у новій структурі, а потім використовувати безперервне вдосконалення для надання цінності клієнтам.

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

• Безперервні дослідження (Continuous Exploration, CE) зосереджуються на створенні узгодженості щодо того, що потрібно побудувати. У КД використовується дизайн-мислення, щоб переконатися, що підприємство розуміє ринкову проблему/потребу клієнта і рішення, необхідне для задоволення цієї потреби. Воно починається з ідеї або гіпотези про те, що матиме цінність для клієнтів, як правило, у відповідь на відгуки клієнтів або дослідження ринку. Потім ідеї аналізуються і далі досліджуються, що призводить до розуміння і зближення того, що потрібно як мінімальний життєздатний продукт (Minimum Viable Product, MVP) або мінімальна ринкова функція (Minimum Marketable Feature, MMF). Це формує простір рішень для вивчення того, як існуючі архітектури та рішення можуть або повинні бути модифіковані. Нарешті, конвергенція відбувається завдяки розумінню того, які можливості і функції, якщо вони будуть реалізовані, зможуть задовольнити потреби клієнтів і ринку. У сукупності вони визначаються і розставляються за пріоритетністю в програмному бэклозі (Program Backlog).
• Безперервна інтеграція (Continuous Integration, CI) зосереджується на виборі функцій з Програмного бэклогу та їх впровадженні. В рамках CI застосування інструментів дизайн-мислення в проблемному просторі фокусується на вдосконаленні функцій (наприклад, розробка карти користувацьких історій), що може мотивувати більше досліджень і використання інструментів простору рішень (наприклад, зворотний зв'язок з користувачами на паперовому прототипі). Після того, як конкретні функції чітко зрозумілі, Agile-команди починають їх реалізовувати. Завершена робота піддається контролю версій, збирається та інтегрується в повноцінну систему або рішення, а також тестується наскрізь перед тим, як бути затвердженою в тестовому середовищі.
• Безперервне розгортання (Continuous Deployment, CD) бере зміни з тестового середовища і розгортає їх у виробництво. На цьому етапі вони перевіряються і контролюються, щоб переконатися, що вони працюють належним чином. Цей крок робить функції доступними у виробництві, де бізнес визначає відповідний час для випуску їх для клієнтів. Цей аспект також дозволяє організації реагувати, відкочувати або виправляти помилки, коли це необхідно.
• Реліз на вимогу (Release on Demand, RoD) - це можливість зробити цінність доступною для клієнтів одночасно або поетапно, виходячи з потреб ринку та бізнесу. Це дає бізнесу можливість випускати продукцію в оптимальний для ринку час і ретельно контролювати рівень ризику, пов'язаного з кожним випуском. Реліз на вимогу також охоплює критично важливу діяльність, яка зберігає стабільність і постійну цінність рішень протягом тривалого часу після релізу.

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

Хоча одна функція проходить через потік створення цінності послідовно, команди працюють над усіма аспектами паралельно. Це означає, що ARTs та Потяги рішень безперервно застосовуються протягом кожного РІ та кожної ітерації в РІ:

• Досліджують цінність для користувача
• Інтегрувати та демонструвати цінність
• Безперервне розгортання у виробництво
• Випускати цінність, коли це потрібно бізнесу

Почніть з відображення поточного робочого процесу

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

Це, в свою чергу, змушує організації відкладати релізи, збільшуючи їх розмір і сферу застосування ("Ми випустимо, коли вони будуть достатньо великими"). Це суперечить Принципу 6 SAFe, який закликає обмежувати кількість незавершеного виробництва (Work in Process, WIP) і зменшувати розмір партій.

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

Після того, як поточний конвеєр відображено на карті, можна додати метрики для вимірювання потоку цінності, розуміння затримок і визначення можливостей для вдосконалення (наприклад, усунення затримок або зменшення обсягу переробок). Використовуються чотири основні метрики [1] (Рисунок 4):

• Час процесу (Process Time) - це час, необхідний для виконання роботи за один крок. Наприклад, на рисунку 4 крок "Проектування" займає чотири години.
• Час виконання (Lead Time) - це час, необхідний з моменту завершення роботи на попередньому кроці до завершення роботи на поточному кроці. Іншими словами, час виконання = час затримки з попереднього кроку + час виконання поточного кроку. На Рисунку 4 час виконання від створення ідеї до її визначення є змінним. На перших етапах створення системи мапування часто не існує чітких метрик для певних кроків. У такому випадку, решту процесу можна вдосконалити, поки збираються метрики для змінної частини.
• Час затримки (Delay time) - це час, коли робота не виконується. Продовжуючи з Рисунку 4, робота, прийнята менеджером продукту, затримується на 696 годин, перш ніж вона буде розгорнута на стадії. Розуміння та усунення непотрібних затримок має вирішальне значення для покращення потоку цінності.
• Відсоток завершеності і точності (Percent Complete and Accurate, %C&A) - це відсоток роботи, яку наступний етап може обробити без необхідності доопрацювання. Часто затримки спричинені низькою якістю на попередніх етапах. Відсоток завершених і точних показників допомагає визначити кроки, на яких може мати місце низька якість, що призводить до збільшення часу виконання і, як наслідок, до затримок у створенні цінності. Рисунок 4 показує, що у 20% випадків робота, яка переходить від етапу "Проектування" до етапу "Кодування", потребує доопрацювання. Покращення показника %C&A також має важливе значення для покращення потоку цінності. Показник %C&A окремого кроку розширюється до відсотка завершеності та точності, який відображає ймовірність того, що елемент пройде через весь робочий процес без переробки. З кумулятивним показником %C&A у 35%, цей робочий процес переробляє більше половини своїх елементів.

Узгодьте поточний робочий процес з безперервним конвеєром поставок

Після того, як поточний потік зрозумілий, його можна відобразити в Конвеєрі безперервного постачання SAFe. Картування допомагає організації прийняти загальну ментальну модель і забезпечує ефективний засіб для інформування про зміни та вдосконалення. На рисунку 5 видалено позначку "Безперервний", оскільки на цьому етапі процес навряд чи нагадує автоматизований конвеєр.

Визначте можливості для вдосконалення

Команди шукають можливості підвищити ефективність кожного кроку, а отже, скоротити загальний час виконання проекту. Це стосується як часу процесу, так і якості (відсоток завершеності та точності) кожного кроку. Чим вищий цей показник, тим менше потрібно переробляти, і тим швидше робота просувається через систему.

Як показано на Рисунку 6, час затримки (час між кроками) часто є найбільш важливим початковим фактором. Час затримки - це перенаправлення, очікування та інші втрати, що не створюють доданої вартості. Цей процес має дві значні затримки і значну кількість переробок на першому етапі процесу розгортання.

Зменшення затримок, як правило, є найшвидшим і найпростішим способом скоротити загальний час виконання проекту. Іншою пріоритетною сферою для вдосконалення є будь-який крок з низьким показником % C&A, оскільки зменшення кількості переробок дозволяє команді зосередитися на створенні цінності (наприклад, для програмного рішення замість виправлення помилок команда може зосередитися на нових функціях).

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

Відстеження безперервної доставки

Якщо розглядати безперервне надання послуг як єдине ціле, то це тривалий процес. Дійсно, це може бути найбільш важливою можливістю кожного тренінгу з ART та пошуку рішень. Важливо, щоб зацікавлені сторони могли візуалізувати і відстежувати поточну роботу, навіть якщо значна її частина автоматизована. Їм потрібна можливість встановлювати ліміти незавершеного виробництва (Work in Process, WIP), щоб підвищити пропускну здатність, а також виявляти і усувати вузькі місця. Саме таку роль відіграє програмний канбан, як показано на рисунку 7.

Канбан-системи складаються з низки станів, кожен з яких коротко описаний нижче:

• Воронка (Funnel) - це стан фіксації всіх нових функцій або вдосконалення існуючих функцій системи.
• Аналізування (Analyzing) - Функції, які найкраще відповідають баченню, потрапляють на етап аналізу для подальшого вивчення. Тут вони уточнюються за допомогою ключових атрибутів, включаючи гіпотезу про вигоду для бізнесу та критерії прийнятності.
• Програмний бэклог (Program backlog) - Після аналізу більш пріоритетні функції переміщуються в бэклог, де вони ранжуються.
• Реалізація (Implementing) - На кожній межі програмного інкременту (PI) найкращі функції з програмного бэклогу переходять на стадію реалізації, де вони розробляються та інтегруються в базову версію системи.
• Валідація на етапі впровадження (Validation on staging) - Функції, які готові до зворотного зв'язку, переходять на етап валідації на етапі впровадження, де вони інтегруються з рештою системи в середовищі впровадження, а потім тестуються і затверджуються.
• Розгортання у виробництво (Deploying to production) - коли є достатня потужність, функції розгортаються у виробничому середовищі, де вони очікують на реліз.
• Випуск (Releasing) - коли достатня цінність відповідає ринковим можливостям, функції випускаються, а гіпотеза про користь оцінюється.
• Готово (Done) - коли гіпотеза задоволена, подальша робота над функцією не потрібна, і вона переміщується в стовпчик "Готово".

Включення конвеєра безперервної доставки за допомогою DevOps

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

Зовнішні два кільця представляють конвеєр безперервної доставки з його чотирма аспектами і 16 видами діяльності, об'єднаними в замкнутий цикл навчання. Внутрішні кільця представляють області практики DevOps, які "живлять" CDP. Кожен домен містить конкретні практики та інструменти, які учасники потоку створення цінності використовують для виконання заходів CDP. Підхід CALMR SAFe до DevOps, показаний в центрі малюнка, - це спільне мислення, яке керує поведінкою і прийняттям рішень в рамках всієї системи.

Крім того, радар здоров'я DevOps від SAFe дозволяє АРТs швидко оцінити продуктивність своїх конвеєрів доставки і визначити конкретні практики DevOps, які можуть бути застосовані для їх оптимізації.

Дивіться серію статей про DevOps для отримання більш детальної інформації про те, як впроваджувати та оптимізувати безперервні конвеєри доставки.

Джерела:

• 2.6 Delivery Performance Domain in PMBOK-7
• https://www.scaledagileframework.com/continuous-delivery-pipeline/
• https://www.scaledagileframework.com/agile-product-delivery/
• https://www.scaledagileframework.com/enterprise-solution-delivery/