Декомпозиція проекту, розподіл ролей і створення юзкейсів

Наскільки добре Ви розумієте той проект, над якими працюєте? Швидше за все Ви відповісте, що знаєте його від А до Я. І це чудово! Але на скільки добре при цьому в проекті орієнтується Ваша команда і сам клієнт? Трохи подумавши кожен відповісти, що у всіх є достатнє розуміння того, що відбувається. Але чому ж тоді виникають ситуації, коли програмісти зробили щось не те; виникають проблеми у взаємодії з клієнтом; у клієнта не виправдовуються очікування і взагалі оцінка не збіглася з дійсністю? А ще в кінці виявляється, що якесь архіважливе питання вилетіло з голови і починається метушня ...

Так що ж робити, щоб розуміння логіки проекту було ідеальним, а оцінки були максимально точними і прозорими?

Декомпозиція проектів

Перше і головне правило — декомпозиція. На перший погляд це здасться складним і незрозумілим словом. З’ясуймо, що ж це таке.

Для цього перенесемося на мить в шкільні роки, коли було багато веселощів, забав і всіма улюбленої ... геометрії! Уявіть, що Вам дали завдання виміряти площу фігури: нічого складного, чи не так? Але фігура ця не просто прямокутник або квадрат; вона — амебоподібної форми, площу якої просто неможливо виміряти доступними геометрії методами. Так буває і з проектами — легке на перший погляд завдання може виявитися за фактом схожою фігурою зрозумілих форм. Але Ви ж ще учень в школі (не забули ще про це?), якому 2-ка ніяк не потрібна. І як же полегшити собі долю, є припущення?

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

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

Існують наступні види розбиття проектів. За функціональністю:

1. горизонтальний (завдання розбиваються на кшталт роботи);

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

За способом демонстрації:

• візуальний (завдання розбиваються на вікна та сторінки дизайн інтерфейсу) — вона візуально більш зрозуміла клієнту;

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

Найчастіше використовується вертикальний тип, оскільки він має наступні переваги:

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

• по-друге, кожен такий блок несе в собі цінність для бізнесу, такі завдання набагато простіше буде пріоритезувати;

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

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

• додавання товару в кошик

• перегляд товарів в кошику

• видалення товару з кошика

• оформлення покупки (введення особистих даних, вибір способу доставлення і способу оплати)

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

Кожен такий етап потрібно описувати у вигляді користувацьких історій по кожній з ролей.

Розподіл ролей в проекті

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

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

Що таке User Story?

User Story — це коротке формулювання, що описує дії, які повинна робити система для конкретної ролі (взаємодія користувача і системи). Є 2 варіанти опису: текстовий і діаграма. Який з них вибрати — рішення виключно вашої команди. Як на мене, написання текстових сценаріїв зручніше, оскільки:

• User Story в такому форматі буде завжди зрозуміло замовнику і команді. Оскільки замовники люблять міняти якісь нюанси проекту, то в написанні саме текстових історій є величезний плюс — клієнт може все ще раз перечитати і на початковому етапі проекту поправити те, що він хоче бачити інакше;

• текст завжди можна легше відредагувати, ніж діаграми.

Однак багато колег схиляються на користь тексту і візуального матеріалу разом.

Що ж повинно бути в User Story? Спочатку повинна йти Роль (хто?), за нею Мета (який намір?), далі Дія (що потрібно зробити?) І Результат (що користувач отримав від системи?).

Наприклад, з покупкою товару в інтернет-магазині, один із сценаріїв може бути:

Вище представлений узагальнений варіант, який можна доповнити стовпцем з коментарем, де вказати, які саме поля буде заповнювати користувач. Завжди треба дивитися на те, чи буде щось змінюватися, якщо користувач вибере доставку кур'єром, наприклад, або якщо він вибере той чи інший спосіб оплати. Якщо так, то потрібно розписувати окремі сценарії: «Вибір доставлення кур'єром», «Вибір доставлення на відділення», «Вибір способу оплати післяплатою / картою» і т.д.

Розбивати User Story потрібно по: видам операцій (створення, перегляд, редагування, видалення); ролям і правам доступу; окремим блокам системи; негативним і позитивним сценаріями.

Винагорода за майстерність

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

І, звичайно ж — це протидія появі у Вас, як проджект-менеджера, «головного болю»!