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.
История из собственного опыта. Или перспектива имеет значение
На одном из проектов я документировала требования по управлению доступом для пользователей в виде матрицы. В таблице были указаны галочками, какие действия разрешены, а какие нет, для разных типов пользователей.
В то же время, поскольку блок управления доступом являлся чрезвычайно важным компонентом системы, я задокументировала требования к интерфейсу для различных типов пользователей с помощью aceptance tests.
Интересно, что с требованиями посредством матрицы эффективно работала команда разработки. А с требованиями в виде тестов приемки – команда тестирования. QA пользовались ими для мануального тестирования, а затем для написания автоматизированных тестов.
После запуска продукта не было зафиксировано ни одного дефекта в области управления доступом для пользователей.
Критерии приемки для анализа стратегических решений
Критерии оценки и приемки – это также мощные техники для анализа стратегических решений.
Возвратимся к нашему примеру с системой оценки финансовых рисков. Представим, что нам нужно реализовать блок с отчетностью.
Кроме понимания, какие именно потребности мы хотим закрыть системой отчетности (вечный вопрос "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