BA toolkit - Part 1: Переосмислення критеріїв приймання
- Anastasiia Kraievska
- 15 трав.
- Читати 5 хв
Ми, аналітики, працюємо в динамічних середовищах, де навіть найбільш звичні інструменти можуть набувати нової цінності, якщо подивитись на них ширше.
У цій статті я покажу, як звичний інструмент Acceptance criteria відкриває нові горизонти - від валідації функціоналу до аналізу стратегічних рішень та покращення комунікації з командою. Час поглянути на знайоме по-новому.
Критерії приймання та оцінювання. Визначення
BABOK говорить про те, що критерії приймання (acceptance criteria) використовуються для фіксування вимог, які повинні бути реалізованими для того, щоб запропоноване рішення (solution) було прийнятим ключевими зацікавленими особами.
У свою чергу, критерії оцінювання (evaluation criteria) - це параметри, по яким порівнюються опції при порівнянні кількох варіантів (BABOK, Chapter 10.1.1).
Давайте розглянемо як це працює на практиці.
Як ми звикли використовувати критерії приймання
Для документування функціональних вимог
Найчастіше критерії приймання використовуються разом з юзер сторі (user story). Це чи не найпопулярніше комбо для документування вимог в Agile проєктах! У тексті сторі читач отримує контекст і цінність (value) функціоналу, а в критеріях приймання - детальну інформацію, що саме в цій сторі повинно бути реалізовано. Зазвичай це пронумерований список унітарних тверджень - вимог - реалізацію яких легко перевірити на наявність (верифікація) та можна протестувати функціонально (валідація).
Як ми не звикли використовувати критерії приймання
Для написання acceptance tests
Критерії приймання можна трансформувати в тести приймання (acceptance tests). Ці тести зазвичай пишуть у форматі Given - When - Then. Такий підхід є основою TDD - test driven development - це коли тести пишуться перед тим, як буде писатись код. Gherkin language - інша поширена назва формату Given - When - Then.
Given <чітка передумова, яка виконується>
When <щось відбувається (ініційоване або користувачем, або іншою системою)>
Then <те, що стається в результаті>
Для прикладу розглянемо онлайн систему для оцінки фінансових ризиків. Уявімо, що є клас користувачів, які вносять ризики у систему - Basic user. І є клас користувачів, які оцінюють ймовірність настання ризиків - Manager.
User story:
As a Manager I want to be able to enter a numeric assessment of the risk, so that an appropriate risk mitigation strategy can take place.
Acceptance criteria:
Risk assessment is a field associated with the risk.
Allowed values for risk assessment: integer, 1 <= {value} < 100.
Acceptance tests у вигляді тексту:
Given:
A manager opens the risk profile without a risk assessment.
When:
The manager enters the risk assessment,
Then:
Risk assessment is associated with the risk and is saved to the risk profile.
У вигляді таблиці:
Таблиця 1 - Приклад acceptance tests
ID | Given | When | Then |
AT1 | A manager opens the risk profile without risk assessment. | The manager enters a valid* risk assessment. | Risk assessment is associated with the risk and is saved to the risk profile. |
AT2 | A manager opens the risk profile with the risk assessment and edits it. | The manager enters a valid* risk assessment. | The updated risk assessment is associated with the risk and is saved to the risk profile. |
*valid risk assessment - integer, 1 <= {value} < 100.
Історія з власного досвіду. Або перспектива має значення
На одному з проєктів я задокументувала вимоги по керуванню доступом для користувачів у вигляді матриці. У таблиці будо вказано галочками, які дії дозволені, а які ні, для різних типів користувачів.
В той же час, оскільки блок керування доступом був надзвичайно важливим компонентом системи, я задокументувала вимоги до інтерфейсу для різних типів користувачів за допомогою acceptance tests.
Цікаво, що з вимогами у вигляді матриці ефективно працювала команда розробки. А з вимогами у вигляді тестів приймання - команда тестування. QA користувались ними для мануального тестування, а потім і для написання автоматизованих тестів.
Після запуску продукту, не було зафіксовано жодного дефекту в області керування доступом для користувачів.
Критерії приймання для аналізу стратегічних рішень
Критерії оцінювання та приймання - це також потужні техніки для аналізу стратегічних рішень.
Повернемось до нашого прикладу з системою оцінки фінансових ризиків. Уявімо, що нам потрібно реалізувати блок зі звітністю. Ми знаємо, що це буде приблизно 5 звітів з різним зрізом даних.
Крім розуміння, які саме потреби ми хочемо закрити системою звітності (вічне питання “why?”), потрібно також розуміти на основі чого ми будемо робити свій вибір. В цьому нам допоможуть критерії оцінювання та приймання.
Приклади критеріїв оцінювання:
Частота оновлення даних
Доступність для користувачів
Маштабованість: підтримка високорівневих та деталізованих звітів.
Ці характеристики ми будемо порівнювати при аналізі опцій.
Тобто при наборі різних варіантів, ми обираємо важливі для нас характеристики - критерії оцінювання. Для цих характеристик формуємо ознаки - критерії приймання, - згідно яких запропонована опція підходить нам чи не підходить (pass or fail).
Приклад критеріїв приймання:
Дані у фінальному звіті оновлюються близько до реального часу (near to real time).
Рішення може бути використане будь яким членом організації без попереднього встановлення додаткового програмного забезпечення, але базуючись на правах доступу цього користувача.
Рішення надає можливість агрегувати дані для високорівневих звітів та декомпозувати для занурення в деталі.
Таким чином ми відбираємо варіанти, які потенційно могли б задовольнити нашу потребу.
Припустимо, що для нашого прикладу зі звітністю ми визначили наступні три варіанти рішення:
Продовження існуючої системи у вигляді додаткового модуля - складова системи зі збереженням елементів інтерфейсу.
Платформа візуальної аналітики, наприклад, Tableau.
Excel файл з вбудованими графічними елементами та можливістю завантаження даних при настанні нового звітного періоду.
Тепер оцінимо чи відповідає кожний варіант поставленим критеріям.
Таблиця 2 - Аналіз рішень на основі критеріїв приймання
В результаті очевидно, що варіант рішення у вигляді Excel файлу не задовольняє визначені нами критерії приймання.
За допомогою правильного визначення критеріїв оцінювання та приймання ми звузили вибір прийнятного рішення до двох варіантів.
Переваги техніки
Техніка передбачає документування вимог у вигляді тексту (natural language), який легкий для розуміння людьми.
При документуванні функціональних вимог легко протестувати будь якій зацікавленій особі, не тільки тестувальнику/-ниці, оскільки техніка не потребує особливих знань нотацій, моделювання.
Тести приймання легко трансформуються в тест кейси.
При аналізі стратегічних рішень критерії приймання дозволяють більш широко подивитись на поставлену проблему, не зациклюватись на очевидному рішенні, а дослідити і інші доступні варіанти.
Недоліки
При документуванні функціональних вимог багато тексту важко сприймається читачами. Навіть якщо це пронумерований список. До того ж, natural language text більше піддається неоднозначному трактуванню порівняно з техніками, що, наприклад, включають в себе моделювання.
Підказка: варто оцінити доречність застосування тільки тексту. За потреби користуватись іншими техніками документування вимог: діаграми, таблиці і т.д.
Інтуїтивно ми більше фокусуємось на дії, яку виконує користувач чи система. В такому випадку легко пропустити нефункціональні вимоги як в рамках фічі, так і при аналізі стратегічного рішення в цілому.
Підказка: чек лісти (check lists) класно допомагають не пропускати елементи у функціональних вимогах. А список критеріїв приймання до нефункціональних вимог можна зробити частиною темплейту чи процедури аналізу стратегічних рішень.
Дилема вибору
Ви напевно помітили, що ми так і не обрали одне рішення серед відібраних двох прийнятних. Хоча вони обоє задовольняють критерії приймання, але яке ж з них підходить краще?
Відповісти на це питання нам допоможе інша техніка бізнес аналізу, а саме - зважена матриця рішень (weighted decision matrix). Про неї ми поговоримо в наступній частині.
А наразі, дякую всім, хто прочитав статтю. Пишіть у коментарях чи було корисно! Буду рада знайомству та спілкуванню.
About the Author
Anastasiia Kraievska, Product Owner, CBAP, PSPO I, PSM I and ISTQB certified with over 13 years of experience in IT, most recently specializing in non-financial risk management at Deutsche Bank. Connect with me via Linkedin.
Disclaimer: The opinions and views expressed in this article are my own and do not necessarily represent those of my organization.
Comments