Ці практики бізнес-аналізу допомагають команді закласти основу для успіху, визначити й задокументувати правильне рішення, а також керувати процесом розробки. Ця стаття завершує серію про 20 найважливіших практик роботи з вимогами, які варто застосовувати кожній команді розробників програмного забезпечення. Це не магічні рішення для всіх ваших проблем з вимогами, але вони допоможуть вам у значній мірі зібрати інформацію, яка необхідна вашій команді для створення успішних рішень.
У попередніх статтях було описано шістнадцять найважливіших практик вимог, які повинна виконувати кожна команда розробників програмного забезпечення. Ці практики застосовуються незалежно від підходу до розробки, який обирає команда, області застосування або виду продукту, який вони створюють. Тут описано ще чотири, які доповнюють повний набір з двадцяти основних практик вимог. Ця стаття адаптована з книги «Основи вимог до програмного забезпечення: основні практики успішного бізнес-аналізу» Карла Вігерса та Кендаз Хокансон.
Практика №17: Визначте межі рішення
Коли ви запускаєте нову ініціативу, ви можете не знати точно, де саме провести межу між тим, що має і не має включати рішення. Питання, подібні до наведених нижче, допомагають бізнес-аналітику зрозуміти, які програмні системи, апаратні компоненти та ручні операції входять до сфери застосування обраного рішення.
- Які бізнес-процеси, функції та події будуть частиною рішення? Які з них залишаться поза ним?
- Які програмні системи будуть частиною рішення? Як будуть виглядати їхні інтерфейси?
- Де починаються та закінчуються відповідальності кожної системи?
- Які набори даних, джерела та операції будуть включені в рішення?
- Як ми вписуємо наше рішення в решту нашого Всесвіту?
- Як ми знаємо, де зупинитися?
Чіткі межі рішення допомагають команді оцінти нові запити на функціональність та визначити, до якої системи вони повинні належати, якщо такі є. Контекстна діаграма корисна для відображення класів користувачів, апаратних пристроїв та будь-яких інших систем, які взаємодіють із продуктом. Карта екосистеми виходить за рамки безпосереднього контексту однієї системи, щоб відобразити загальне уявлення про рішення.
На Рисунку 1 продемонстровано карту екосистеми для запропонованого веб-сайту для онлайн-замовлень у ресторані. Кінцеве рішення дозволить підключити новий сайт до існуючої бази меню та систем розміщення замовлень у ресторані, а також до системи обробки онлайн-платежів. Це передбачатиме удосконалення інтеграції системи розміщення замовлень з новою системою відстеження замовлень та зовнішнім стороннім додатком доставки.
Рисунок 1. Карта екосистеми відображає, як поточні та майбутні системи ресторану взаємопов’язані.
З появою нових вимог, бізнес-аналітик може використовувати бачення продукту, бізнес-цілі та межі рішення, щоб визначити, чи слід реалізовувати кожну запитувану вимогу, та який компонент повинен відповідати за неї. Такий підхід допомагає гарантувати, що обсяг, обмеження та інтерфейси рішення добре зрозумілі та доведені до відома всіх зацікавлених сторін.
Практика №18: Створюйте та оцінюйте прототипи
Людям легше критикувати те, що їм пропонують, ніж вигадувати щось абсолютно нове. Саме ця ідея лежить в основі надання користувачам прототипів — часткових, попередніх або можливих рішень — та ранніх версій робочого програмного забезпечення.
Користувачі можуть взаємодіяти з прототипом, щоб прояснити і визначити свої справжні потреби. Прототип охоплює цю нечітку межу між вимогами та дизайном, допомагаючи тим, хто оцінює перейти від концепцій до фізичної реальності. Кілька видів прототипів можуть допомогти у досягненні цих цілей.
Прототип дизайну взаємодії надає користувачам візуальне представлення, яке допомагає їм оцінити, чи дозволить рішення, що ґрунтується на поточному наборі вимог, ефективно виконувати їхню роботу. Прототип технічного дизайну дозволяє команді розробників досліджувати проблеми під капотом перед прийняттям рішення щодо технічного підходу. У Таблиці 1 перераховано деякі причини для створення цих двох класів прототипів.
Таблиця 1. Деякі причини для створення двох класів прототипів
Працюючи з користувачами над створенням та оцінкою прототипу, пам’ятайте про ці поради:
- Залучайте правильних учасників, виходячи з того, чого ви намагаєтеся навчитися.
- Зробіть прототип якомога простішим.
- Створюйте сценарії, щоб спрямовувати користувачів на виконання певних дій або сценаріїв.
- Не навчайте оцінювачів прототипів, як використовувати прототип.
- Використовуйте оцінку зворотнього зв’язку для вдосконалення вимог.
Практика №19: Створіть глосарій
Бізнес-аналіз схильний до всіх недоліків як усної, так і письмової комунікації. Спільний глосарій допомагає учасникам уникнути непорозумінь. Тому кожен проєкт має накопичувати глосарій термінів, скорочень, акронімів і синонімів, щоб забезпечити однакове їх розуміння всіма учасниками. Глосарій на рівні підприємства, який охоплює кілька проектів, є цінним багаторазовим активом.
Залежно від сфери бізнесу, може існувати багато синонімів та близьких за значенням слів. Якщо ваш бізнес фізичний або це інтернет-магазин, чи є різниця між клієнтом, відвідувачем, покупцем, замовником та учасником? Чи всі відділи вашої організації сприймають клієнта однаково? Чи розрізняє ваш ресторан гостей, клієнтів, постійних клієнтів та відвідувачів?
Важливо ретельно розрізняти такі терміни там, де вони з’являються у вашій діловій документації чи документації програмного забезпечення. Глосарій слугує вичерпним ресурсом для всієї цієї інформації, допомагає проєктувати бази даних і навіть може допомогти розробникам зробити їхній код більш зрозумілим.
Деякі терміни мають специфічні для певної предметної області значення, які відрізняються від того, як ці слова використовуються в іншому контексті або у повсякденному спілкуванні. Деякі терміни можуть навіть мати кілька значень у контексті програми. Одна абревіатура або акронім може означати багато речей, але всі учасники проекту повинні розуміти, яка з них відноситься до контексту вашого проекту. Глосарій – це інвестиція в чітку та ефективну комунікацію, що є головною метою всієї роботи над вимогами.
Практика №20: Встановлення та підтримка базових вимог
Кожній команді розробників потрібно визначити набір вимог, до виконання яких вони можуть зобов’язатися протягом певного часового проміжку або циклу розробки: це і є базові вимоги. Базовий набір вимог фіксує групу вимог як знімок у часі. Він відображає, що на той момент ці вимоги вважаються коректними, повними і такими, що сприятимуть досягненню бажаних бізнес-результатів.
Будь-які зміни, що вносяться до вимог після того, як були визначені базові вимоги, повинні пройти через процес управління змінами команди. Затвердження цих змін встановлює новий базовий набір вимог. Встановлення базових вимог не означає, що зміни не відбудуться; вони можуть відбутися. Однак, базовий набір гарантує всім учасникам, що команда може просуватися вперед у розробці з мінімальним ризиком значних змін.
Визначаючи базовий набір вимог команда має два основні варіанти: обмежена в часі або обмежена в обсязі. Базовий план з часовими рамками починається зі встановлення часових рамок: ітерація, група ітерацій або запланований реліз. Потім команда розподіляє найбільш пріоритетні вимоги зі свого набору вимог або продуктового беклогу до базових вимог, поки не буде заповнено потенціал команди щодо розробки та тестування протягом визначеного часового проміжку. На відміну від цього, базовий набір, обмежений обсягом робіт, складається з логічно згрупованого набору функцій, вимог або користувацьких історій, які можуть бути розроблені, протестовані та впроваджені разом.
Ви можете мати кілька базових наборів вимог у процесі одночасно, наприклад, один, який розроблений і знаходиться на етапі тестування, і один, який все ще перебуває на етапі розробки (Рис. 2). При внесенні змін переконайтеся, що ви знаєте, до якого базового набору відноситься кожна з них, щоб усі члени команди завжди знали, над чим вони працюють – і над чим не працюють.
Рисунок 2. Бізнес-аналітик може одночасно керувати кількома базовими наборами, щоб підтримувати зусилля з розробки та тестування.
Узгодження зацікавлених сторін щодо обсягу робіт, який необхідно виконати, є важливою передумовою для початку або продовження розробки. Управління базовим сценарієм до розгортання гарантує, що всі учасники розуміють, що саме буде виконувати та деліверити команда.
Ця стаття завершує серію статей про 20 найважливіших практик роботи з вимогами, які варто застосовувати кожній команді розробників програмного забезпечення та систем. Це не магічні рішення для всіх ваших проблем з вимогами, але вони допоможуть вам у значній мірі зібрати інформацію, яка необхідна вашій команді для створення успішних рішень.
Оригінальна стаття – The final 4 essential requirements practices, переклад Олександра Серебрянська (Business Analysis Community Kyiv), ревью – Іван Вільчавський. Оригінальні зображення зі статті автора.