Команди розробників часто скаржаться на розширення обсягу роботи. Але як взагалі відобразити обсяг робіт у проєкті з розробки програмного забезпечення?
Кожна команда розробників програмного забезпечення (ПЗ) обговорює обсяг проєкту (scope), і члени проєктної команди часто скаржаться на нескінченне розростання обсягу (scope creep). На жаль, у галузі програмного забезпечення немає єдиного визначення цих термінів, а в літературі з інженерії вимог немає чітких вказівок щодо того, як відображати обсяг. У цій статті розглянуто деякі визначення цих термінів та описано кілька методів визначення обсягу в проєктах з розробки ПЗ.
Що таке обсяг?
Обсяг можна визначити як набір функціональних можливостей, які за домовленістю із зацікавленими сторонами має бути реалізований протягом певній ітерації, збірки або релізу продукту. Обсяг визначає межу між тим, що входить до певного окресленого комплекту робіт, а що ні. Коли керівник проєкту погоджується, що його команда реалізує конкретний набір функціональних можливостей відповідного рівня якості до визначеної дати, він встановлює обсяг цієї роботи. Коли власник продукту зобов’язується реалізувати певний набір історій користувача в межах етапу розробки або спринту, він визначає обсяг цього етапу розробки.
Обсяг будь-якої частини проєкту являє собою підмножину кінцевого бачення продукту, крок на шляху від запуску проєкту до остаточної доставки продукту. Кожен запланований період роботи починається з визначення затвердженого списку функціональностей, які команда має намір реалізувати упродовж цього періоду. Цей затверджений список є орієнтиром для зміни обсягу робіт.
Бачення та обсяг
Документ з баченням та обсягом робіт є ключовим артефактом проєкту з розробки ПЗ. Інші назви такого високорівневого документа-настанови – це статут проєкту, документ з вимогами ринку або бізнес-кейс. Бачення та обсяг робіт – це два пов’язані поняття. Я розглядаю їх як бачення продукту та обсягу проєкту. Бачення продукту – це:
Довгострокове стратегічне бачення основної мети та форми нової системи.
У розділі 5 моєї книги «Вимоги до програмного забезпечення, 3-тє видання» описано, як написати стислий та сфокусований опис бачення продукту за допомогою шаблону з ключовими словами. Після цього ми можемо визначити обсяг проєкту як:
Частину основного бачення продукту, яку охоплює поточний проєкт. Обсяг проєкту визначає межу між тим, що входить у нього, і тим, що залишається поза його межами.
Остання частина цього визначення є найважливішою. Обсяг визначає, чим є продукт, а чим він не є, що він робитиме, а що ні, що він міститиме, а що ні. Чітко визначені межі обсягу формують правильні очікування у зацікавлених сторін проєкту. Межі визначають точки взаємодії між системою і зовнішнім світом, при чому система може бути як програмним застосунком, так і комбінацією автоматизованих елементів та ручних процесів. Визначення обсягу допомагає керівнику проєкту оцінити ресурси, необхідні для реалізації цього проєкту, та допомагає йому взяти на себе реалістичні зобов’язання. По суті, опис обсягу визначає межі того, за що відповідає керівник проєкту.
Ваше визначення обсягу також має містити перелік конкретних обмежень або винятків — що виходить за межі проєкту. Очевидно, що ви не можете перерахувати все, що виходить за межі обсягу, оскільки це був би весь відомий всесвіт, за винятком крихітної частини, яка входить до обсягу цього проєкту. Натомість обмеження мають окреслювати функціональні можливості, які читач міг би очікувати побачити в проєкті, але які до нього не включено. Один проєкт, в рамках якого створювали веб-сайт для національної команди з регбі, включав такі винятки з обсягу робіт для початкового релізу:
- сайт не міститиме віртуальних або фентезі інтернет-ігор з регбі
- на сайті не буде можливості придбати квитки
- на сайті не буде можливості робити ставки
- демографічні дані для розсилок не збиратимуться
- форуми не входять до обсягу робіт на Етапі 1.
Деякі зацікавлені сторони в цьому проєкті могли очікувати, що ці функціональні можливості будуть включені до першого релізу. Перелік їх як винятків чітко показує, що вони не будуть реалізовані. Це своєрідний спосіб управління очікуваннями.
Діаграма контексту
Діаграма контексту – це перевірена часом модель аналізу, яка бере свій початок з революції структурованого аналізу 1970-х років. Попри свій вік, діаграма контексту залишається корисним способом зображення середовища, в якому існує система програмного забезпечення. На рисунку 1 показано частину діаграми контексту для гіпотетичної системи замовлення в корпоративній їдальні.
Діаграма контексту показує назву системи або продукту, що нас цікавить, у колі. Коло представляє межу системи. Прямокутники поза колом представляють зовнішні сутності, які також називаються термінаторами. Зовнішніми сутностями можуть бути різні класи користувачів, актори, організації, інші системи, до яких підключається ця система, або апаратні пристрої, що взаємодіють із системою.
Точки взаємодії між системою та цими зовнішніми сутностями показані підписаними стрілками, які називаються потоками. Потоки являють собою рух даних, сигналів керування або фізичних об’єктів між системою та зовнішніми сутностями. Якщо вважається, що «система» включає як програмний застосунок, так і ручні операції, то потоки можуть представляти рух фізичних об’єктів. Однак, якщо «система» це суто автоматизована система, потоки повинні представляти дані або сигнали керування.
Контекстна діаграма показує обсяг проєкту на високому рівні абстракції. Ця діаграма свідомо не розкриває внутрішню структуру системи та не уточнює, які функції чи можливості входять до обсягу. Функціональна поведінка системи лише опосередковано відображається через позначені потоки, які з’єднують систему із зовнішніми сутностями.
Навіть потоки позначені на високому рівні абстракції, просто щоб зберегти прийнятний рівень складності діаграми. Потоки даних можна розкласти на окремі елементи даних у словнику даних проєкту або моделі даних. Пари вхідних і вихідних потоків даних вказують на типи транзакцій або варіанти використання, які виконуватиме система, однак ці елементи не відображено явно на діаграмі контексту.
Попри обмеження, які зумовлені високим рівнем абстракції, діаграма контексту є корисним засобом для представлення обсягу проєкту. На одному курсі з вимог, де я викладав, бізнес-аналітикиня показала мені діаграму контексту для свого поточного проєкту. Перед цим вона показала її керівнику проєкту. Керівник проєкту зазначив, що було прийнято рішення зробити одну із зовнішніх сутностей — іншу інформаційну систему — частиною системи, що розробляється. Проводячи паралелі з діаграмою на рисунку 1, це було б ніби ми перемістили систему нарахування заробітної плати всередину кола. Тобто, обсяг проєкту щойно розширився. Ця бізнес-аналітикиня очікувала, що зовнішня система буде відповідальністю когось іншого, але тепер система стала її проблемою. Діаграма контексту надає інструмент, який допомагає зацікавленим сторонам проєкту досягти спільного розуміння того, що знаходиться за межами системи.
Діаграма варіантів використання
Варіанти використання є ефективним методом дослідження вимог користувачів. Уніфікована мова моделювання (UML) містить нотацію діаграми варіантів використання. На рисунку 2 показано частину діаграми варіантів використання для нашої системи замовлення в кафетерії. Прямокутний блок представляє межі системи, аналогічно колу на діаграмі контексту. Схематичні фігурки людей поза блоком представляють акторів, тобто сутності, які знаходяться поза контекстом системи, але певним чином взаємодіють з системою. Актори приблизно відповідають зовнішнім сутностям, показаним прямокутниками на діаграмі контексту.
На відміну від діаграми контексту, діаграма варіантів використання забезпечує обмежену видимість внутрішніх механізмів системи. Кожен овал всередині меж системи представляє окремий варіант використання — буквально, випадок використання — в якому актори взаємодіють із системою для досягнення певної мети.
Стрілки на діаграмі варіантів використання вказують, які актори беруть участь у кожному варіанті використання. Стрілки не відображають потоки, як на діаграмі контексту. Стрілка від актора до варіанту використання вказує на те, що цей первинний актор може ініціювати варіант використання. Стрілка, що вказує від варіанту використання до актора, означає, що цей вторинний актор бере участь в успішному завершенні варіанту використання. Окрім відображення цих зв’язків із зовнішніми акторами, діаграма варіантів використання може зображувати логічні зв’язки та залежності між варіантами використання.
Діаграма варіантів використання дає більш детальне уявлення про обсяг системи, ніж контекстна діаграма, оскільки показує не лише точки взаємодії із зовнішнім світом, а й загальний огляд внутрішньої структури системи. Проте існує практичне обмеження: будь-яка велика система програмного забезпечення матиме десятки варіантів використання з багатьма зв’язками між акторами та між собою. Відображати всі ці об’єкти в межах однієї системної межі швидко стає незручно. Відповідно, аналітику потрібно моделювати групи пов’язаних варіантів використання або створювати кілька діаграм варіантів використання з різними рівнями деталізації. Таким чином втрачається простота однієї діаграми, яка відображає об’єкти з обох сторін межі системи.
Рівні елементів функціональності
Клієнти, маркетологи та розробники часто говорять про елементи функціональності продукту (product features), проте в індустрії програмного забезпечення немає стандартного визначення цього терміна. Я вважаю, що елемент функціональності (feature) це:
Набір логічно пов’язаних функцій, що надають користувачеві певні можливості та дозволяють досягти бізнес-цілі.
Ми можемо розглядати кожен елемент функціоналу продукту як такий, що має серію рівнів, які відображають наростальний ступінь функціональних можливостей або збагачення функціоналу. Кожен реліз продукту реалізує певний набір нових елементів функціоналу і, можливо, покращує функціонал, який був частково реалізований в попередніх релізах, починаючи з рівнів найвищого пріоритету функцій найвищого пріоритету. Таким чином, один зі способів описати обсяг конкретного релізу продукту — це визначити конкретний рівень кожного елементу функціоналу, який команда реалізує у цьому релізі. Послідовність релізів представляє наростальні рівні функціональних можливостей — і, отже, дедалі вищу цінність для користувача — що створюється протягом певного періоду часу.
Щоб проілюструвати цей підхід до визначення обсягу роботи, розглянемо наступний набір елементів функціоналу з нашої системи замовлення в кафетерії:
FE-1: Створення та змінення меню кафетерію
FE-2: Замовлення страви з меню кафетерію на винос або з доставкою
FE-3: Замовлення страв з доставкою з місцевих ресторанів
FE-4: Реєстрація для оплати харчування
FE-5: Замовлення доставки їжі
FE-6: Створення, зміна та скасування підписок на харчування
FE-7: Складання рецептів та списків інгредієнтів для страв на замовлення з їдальні
На рисунку 3 зображено дорожню карту елементів функціоналу, різні рівні для цих елементів, які планується впровадити в майбутніх релізах. FE-2 та FE-5 на рисунку 3 представляють елементи функціоналу з трьома рівнями покращення. Повна функціональність кожного з цих елементів функціоналу надається поступово в трьох запланованих релізах.
| Елемент функціоналу | Реліз 1 | Реліз 2 | Реліз 3 |
| FE-1 | повністю реалізовано | ||
| FE-2 | стандартні індивідуальні страви лише з обіднього меню; замовлення на доставку може бути оплачене лише шляхом відрахування з заробітної плати (залежить від FE-4) | приймаються замовлення на сніданки і вечері на додаток до обідів; приймаються платежі дебітними і кредитними картками | приймаються групові замовлення на події та зустрічі |
| FE-3 | не реалізовано | не реалізовано | повністю реалізовано |
| FE-4 | реєструється оплата лише шляхом відрахування з заробітної плати | реєструється оплата за допомогою дебітної і кредитної картки | |
| FE-5 | обіди доставляються лише по території будівель компанії | додано доставку з кафетерію до обраної точки за межами території компанії | додано доставку з ресторанів до усіх наявних точок доставки |
| FE-6 | реалізовано за наявності часу | повністю реалізовано | |
| FE-7 | не реалізовано | не реалізовано | повністю реалізовано |
Рисунок 3: Приклад дорожньої карти елементів функціоналу
Підхід з розбиттям на рівні елементів функціоналу є найбільш описовим з цих трьох методів визначення обсягу проєкту. Аналітик також може вказати залежності між елементами функціоналу або їх рівнями. Наприклад, рівень FE-2, запланований на Реліз 1, має дозволити користувачам оплачувати харчування шляхом відрахувань із заробітної плати. Тому функціональність FE-4, яка дозволяє користувачам зареєструватися для отримання відрахувань із заробітної плати, не може бути відкладена до наступного релізу.
Візуальним способом подання цієї ж інформації є дерево елементів функціоналу (feature tree). У дереві елементів функціоналу, елементи та піделементи функціоналу зображаються у вигляді розгалуженої діаграми-дерева, подібної до діаграми “риб’ячого кістяка” (fishbone diagram), як показано на рисунку 4. Ви можете використовувати різні кольори, щоб відрізнити елементи функціоналу, призначені для конкретних релізів або ітерацій розробки.
Рисунок 4. Групування дерева елементів функціоналу
Визначення обсягу на Agile-проєктах
У традиційних проєктах з розробки ПЗ передбачуваний обсяг робіт визначається або презентується відразу. Після цього керівник проєкту та команда розробників оцінюють зусилля, вартість та час, які необхідні для реалізації цього обсягу робіт. Відбуваються переговори, беруться зобов’язання, і неминучі зміни обсягу робіт під час проєкту призводять до відповідних коригувань у планах та зобов’язаннях.
Натомість Agile проєкти працюють за часовими рамками. Обсяг робіт, який може вміститись у кожну ітерацію з фіксованою тривалістю, обмежується швидкістю команди, виміряною на попередніх ітераціях або оціненою на основі досвіду аналогічних проєктів.
Agile проєкти вибирають, які елементи будуть реалізовані в певній ітерації, з беклогу продукту, який містить історії користувачів та інші робочі елементи, готові до включення до проєкту у потрібний час. Власник продукту визначає обсяг за допомогою беклогу ітерації – підмножини робочих елементів, які команда планує виконати протягом ітерації. В Scrum-проєкті це називається беклогом спринту.
Деякі проєкти також визначають карту історій користувача, яка показує дії, кроки та деталі історій користувача, які визначають обсяг усього продукту, ітерації або певної функції чи частини користувацького досвіду. Як пояснює Говард Подесва у «Практичному посібнику з гнучкого планування та аналізу» (2021), карта історій пропонує візуальне відображення послідовності, в якій будуть реалізовані історії користувача, щоб забезпечити правильну послідовність роботи — тобто планування обсягу — на довший період часу.
Планування майбутнього
Чим віддаленіші перспективи планування, тим менш визначеним стає обсяг робіт і тим більш імовірною є зміни обсягу під впливом змін у проєкті та бізнес-середовищі. Однак, формування бачення продукту та окреслення меж проєкту забезпечують надійну основу для подальшої роботи на проєкті, що дозволяє команді утримувати стратегічний курс і максимально задовольняти зацікавлених сторін.
Оригінальна стаття – Defining Project Scope: What’s In, What’s Out, переклад Олександра Дідух, ревью – Іван Вільчавський, зображення з оригінальної статті.