Вимоги в SAFe: як організувати ваш беклог?

Методологія Agile станом на 2023-й є, мабуть, найпоширенішою в сегменті розробки. Вона дозволяє швидко та адаптивно реалізовувати як невеликі, так і масштабні проєкти, оптимізуючи при цьому витрати бюджету та залучення ресурсів.

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

Інструкції SAFe (Scaled Agile Framework) шостої ітерації, за даними опитування Digital.ai, займали близько 53% загальної ніші у 2022-му. Це свідчить про досить високу популярність фреймворку у розробників.

Наші фахівці дослідили тему ефективності SAFe та зібрали для вас матеріал, в якому розказали про:

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

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

Гарантуємо, ви отримаєте масу цікавої та корисної інформації, навіть якщо зазвичай не працюєте по SAFe.

Модель вимог в SAFe 6.0

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

Ключове положення: все має бути задокументовано текстом, а не передаватись в команді вербально. І ось чому:

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

Загалом SAFe фокусується більше на стратегічних задачах, наприклад:

баченні портфоліо;
беклозі портфоліо;
ART беклозі;
командному беклозі;
епіках;
фічах;
користувацьких історіях.

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

Загальний погляд: бачення проєкту та його вплив на формування вимог

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

Саме тому доцільно розпочати з ключового, а саме – з бачення проєкту (продукту).

Підготовка бачення

Бачення продукту – основний компонент для формування вимог та специфікацій всього проєкту. Він відповідає на ключові питання, а саме:

«Навіщо взагалі розробляється цей продукт?»;
«Яку проблему він вирішує?»;
«Які головні гіпотези ми хочемо перевірити?»;
«Хто наш кінцевий користувач?»;
«Для кого ми взагалі створюємо цей продукт?».

Окрім цього, він включає певні основні нефункціональні вимоги.

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

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

Саме тому при розробці (навіть не за інструкціями SAFe) має бути бачення, сформоване BA чи PO, PM тощо.

Портрет бренду

Загальна концепція розвитку компанії у SAFe називається Portfolio Canvas. Це умовне полотно (анкета, шаблон, профіль), де відображається, чому та як бренд йде певним шляхом, яких цілей він прагне досягти.

Зазвичай цим питанням займається топменеджмент компанії, проте навіть команді розробки, не кажучи про PM, PO, BA тощо, варто знати особливості позиціювання та планів бренду.

Portfolio Canvas дещо порівняний з Business Model Canvas та включає наступні позиції:

Потоки цінностей. Чим цінний продукт, які болі закриває для клієнтів і ринку.
Рішення. Як вирішуються ті чи інші питання, як реалізований функціонал та його особливості.
Портрет клієнтів. Хто ЦА продукту, які в неї потреби в широкому та вузькому планах.
Канали просування. Яким шляхом реалізується продукт: онлайн чи офлайн, методи та інтенсивність реклами.
Відносини з клієнтами. Який UX отримує ЦА продукту, як його можна покращити чи оптимізувати.
Бюджет. Які ресурси доступні для підтримки та модернізації рішення, його адаптації чи трансформації.
Метрики KPI. Яка ефективність діяльності компанії (провайдера) загалом.

Окрім зазначеного, в цьому шаблоні мають бути вказані ключові:

партнери,
напрями діяльності,
ресурси.

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

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

Стратегічні теми

Як і в будь-якому проєкті, в розробці необхідне повне бачення цінності та цілей продукту. Безпосередньо SAFe для цього використовує модель OKR (Objective/Key Results), яка реверсивно описує цілі, тобто з точки результатів (очікуваних).

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

Збільшення послуг ринку до 75% за 18 місяців.
Збільшення рейтингу мережевого промоутера з 35 до 60.
Покращення показників бізнесу з 60% до 80%.
Отримання близько 15% нових клієнтів за наступні 12 місяців.

Тобто тут можуть бути описані як короткострокові цілі, так і довгострокові або ж взагалі глобальні.

Бачення та стратегічні теми і є тим ключовим бекграундом, який дозволяє будувати проєкт, його беклог. За відсутності цього ані команда, ані стейкхолдери, ані тим паче клієнти не зрозуміють головного: а навіщо їм взагалі потрібен конкретний продукт?

Відповідно, це призведе до проблем, таких як, наприклад:

Помилкові пріоритети розробки.
Некоректне формування дорожньої карти.
Невірне сприйняття продукту аудиторією.
Нерозуміння специфіки командою.
Втрата певної долі ЦА та ринку загалом.

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

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

Рівні вимог в SAFe й шаблони формування беклогів

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

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

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

Шаблон епіка портфоліо

Цей макет потрібен в тих випадках, коли в продукт слід внести досить значні зміни:

Переглянути глобально продуктивність додатка.
Оптимізувати UI/UX, звівши його до одного формату у всьому продукті.
Розширити безпеку, умовно, додавши двофакторну аутентифікацію у всі функції.
Внести певні нефункціональні зміни, переглянути концепцію.
Розширити функціонал продукту тощо.

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

Зазвичай має класичний формат та включає:

Назву епіка.
Власника (хто пропонує концепт).
Опис епіка, що складається з:
- тезисів про цінність ідеї;
- кому потрібно це нововведення;
- хто це робитиме;
- опису рішення;
- умови (якщо, як);
- очікуваного результату (то, …);
- оскільки (не включено, не відповідає);
- актуальному (функціоналу продукту, його UI/UX).
Вигоди для бізнесу.
Метрики оцінки ефективності на ранніх етапах.
NFRs (нефункціональні вимоги).

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

Шаблон аналітичного епіка

Ремарка: саме на цьому етапі найчастіше гинуть ідеї. Близько 80% концепцій розбиваються через сувору дійсність ринку, потреб клієнтів. І саме BA дає нам можливість зрозуміти неефективність ідеї до того, як в неї буде інвестовано перші бюджети.

Епік аналізу досить маленький і має всього кілька сторінок. Зазвичай в ньому описується:

Що входить в аналіз.
Який мінімум функцій можна включити у MVP.
Скільки розроблятиметься цей MVP.
Які затрати на створення початкової ітерації продукту.
Який потенційний профіт від реалізації цього проєкту.

Також в аналізі розкриваємо питання інвестицій, потреб ринку і ЦА. Оцінюємо, чи вигідна взагалі ця розробка. Якщо так – продовжуємо проєкт, якщо ні, закриваємо концепцію та рухаємось далі.

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

Загалом же бізнес-аналіз дає компанії ключове: ROI певної ідеї чи навіть цілого проєкту. Тому помилково вважати, що BA є ситуативним. Скоріше, навпаки, він розкриває потенціал концепції, трансформуючи його з рожевої мрії в практичну демонстрацію всіх «за» і «проти». Також надає вичерпну інформацію про потенційну прибутковість ідеї.

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

Техніки реалізації: від загальних до профільних

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

WSJF (Weighted Shortest Job First): оптимізація в основі всього

Уявіть ситуацію, коли є умовна команда на 500-1000 працівників, які одночасно виконують десятки, а то і сотні проєктів. Як ви встановите пріоритети розробки? Правильно, за допомогою WSJF методики.

WSJF дозволяє обрахувати вигідність роботи за рядом показників (1,2,3,5,8,13,20 балів за моделлю Фібоначчі). А саме:

Цінність для ЦА та бізнесу. Враховує те, наскільки важливими для всіх зацікавлених сторін є той чи інший продукт (функція).
Дедлайн. Цей параметр встановлюється залежно від того, наскільки швидко треба реалізувати щось. Наприклад, нову функцію до свят чи проєкт в рамках співпраці з певною корпорацією, де прописані жорсткі рамки.
Зменшення ризиків/збільшення можливостей. Індекс цього показника розраховується з огляду на те, чи закриває розробка певні болі продукту (ринку), чи відкриває якісь можливості для бізнесу.

Відповідно, далі сума значень (що присвоїли кожному параметру) ділиться на обсяг роботи. Умовно мобільне, кросплатформове чи хмарне ПЗ. Чим вищий результат отримує певний проєкт, тим вище його пріоритет реалізації.

Наприклад:

Робота	Цінність	Дедлайн	RR/OE	CoD	Масштаб	WSJF
Гібрид	5	8	1	14	3	4.7
Хмара	3	5	3	11	8	1.38
Мобільне	1	1	5	7	1	7

Відповідно, пріоритет виглядатиме так:

Мобільний додаток.
Кросплатформове ПЗ.
Хмарне рішення (чи міграція).

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

NFRs, або просто технічна частина беклогу

Зазвичай фінансові питання (мається на увазі бізнес-питання) виносяться в пріоритет, а технічні, як правило, ігноруються чи просто виносяться за рамки. Але не у випадку з SAFe.

Як правило, SAFe об’єднує все зазначене в одну інфраструктуру, яку ми можемо назвати загальним беклогом. З тією різницею, що у технічних аспектах використовується поняття Enables, яке й характеризує їх як тригери для роботи чогось (над чимось, якось і т.д.).

Виділяють чотири ключові типи Enables:

Дослідницькі. Загалом включає аналіз, вивчення певної інформації, як-от особливості, цінності функцій, рішень, їх ефективності, кейси використання тощо.
Архітектурні. Фокусується на змінах, насамперед тих, що стосуються технологічної частини продукту (проєкту), як-от технічний стек, його компоненти тощо.
Інфраструктурні. Стосується більш організаційно-технічних питань, як-от зміни робочого оточення, SDK, створення певних скриптів тощо.
Відповідності. Відповідає на питання, чи враховані вимоги та стандарти індустрії в цьому продукті, чи його специфікації актуальні для сучасного ринку тощо.

Унікальність Enables полягає в тому, що вони протягом всього проєкту матимуть одні назви та змінюватимуть вкрай рідко. Власне, за інструкціями SAFe, вони будуть тісно вплетені в беклоги та переплітатимуться з певними бізнес-ідеями. Єдиний нюанс – масштаби самого Enabler, які можуть змінюватись від епіка до умовного користувацького кейса.

Декомпозиція епіків: від масштабного до мінімального

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

Тобто отримуємо приблизно таку ієрархію:

Епік. Щось глобальне, як-от ідея, концепція чи умовне бачення продукту.
Можливості. Фрагмент, який відповідає за певну частину загальної ідеї.
Особливості. Компонент (умовно – функція) яка складає частину від можливості.
Користувацькі кейси. Мікрозадачі, які вирішуються в рамках певних процесів.

Шаблон концепції декомпозиції виглядає наступним чином:

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

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

User Stories: як «користувач» я б хотів «щось», щоб «отримати», тому «це» важливо для бізнесу

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

Проте все ж є ряд рекомендацій, яких варто дотримуватись, щоб створювати ефективні кейси. Наприклад:

Завжди ставте себе на місце користувача і дивіться на ту чи іншу функцію (особливість) його очима.
Описуйте різні кейси застосування «чогось» та оцінюйте їх з огляду на UX.
Орієнтуйтесь на реальні болі та потреби, щоб якомога ефективніше закривати їх.
Використовуйте певні дії як тригер, від якого можете відштовхнутись для деталізації процесу взаємодії з певним компонентом.
Порівнюйте цінність для користувачів з цінністю для бізнесу, відшукуючи золоту середину в контексті балансу інвестицій/дохідності.

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

Загалом User Story – це найнижчий рівень вимог SAFe (застосовується на рівні команд), проте він досить ефективний в плані реальної оцінки того, що продукт може дати ЦА, яку користь від цього отримає бізнес. Не дарма ж такі кейси вважаються ледь не стандартом IT-індустрії та широко розповсюдженні як в розробці, так і в QA, BA тощо.

Підсумуємо

Потенційна структура беклогу буде цілком залежати від масштабу проєкту та команди розробки. Якщо ви працюєте на рівні Team Lead, а штат складають +-10 фахівців, то вам буде достатньо організувати беклог через User Story, можливо, через особливості й в мінімальній мірі через епіки.

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

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

Рекомендуємо застосовувати SAFe 6.0 для реалізації ефективної та оптимізованої роботи зі специфікаціями вашого проєкту. Якщо ви наразі шукаєте для себе сертифікаційні курси, що допоможуть вам поглибити свої знання та отримати підтвердження вашої професійності, рекомендуємо вам наші курси: