Критерии приемки и Definition of Done: техники BABOK®Guide и Guide to Product Ownership Analysis

курсы BABOK, авторизованное обучение BABOK с примерами, обучение BABOK®Guide, техники BABOK®Guide курсы обучение, подготовка к экзамену по BABOK®Guide ECBA CCBA CBAP, авторизованные курсы IIBA россия, обучение курсы, обучение курс Product Ownership для бизнес-аналитика, обучение бизнес-аналитиков, обучение бизнес-анализу, курсы для аналитиков, курсы по бизнес-анализу, бизнес-аналитик обучение, курсы обучение системных и бизнес-аналитиков, Школа прикладного бизнес-анализа

В этой статье рассмотрим, чем техника BABOK®Guide «Критерии приемки и оценки» отличается от определения выполненного, почему Definition of Done не равно Definition of Ready, что такое определение доставки и как все это связано с верификацией и валидацией требований. Примеры применения Agile-практик и техник Guide to Product Ownership Analysis к разработке и анализу нефункциональных требований к ПО при их спецификации в SRS и ТЗ.

Критерии приемки и оценки для анализа нефункциональных требований: техники BABOK®Guide

Анализ нефункциональных требований – это техника не только классического бизнес-анализа из BABOK®Guide. Новый профильный справочник IIBA®, Guide to Product Ownership Analysis, тоже упоминает эту технику как способ исследования требований к продукту, определяющий критерии, по которым можно судить о работе продукта, а не о конкретном (функциональном) поведении. В продуктовой парадигме нефункциональные требования фиксируются в понятиях определений или критериях приемки.

BABOK отмечает, что критерии приемки и оценки (Acceptance and Evaluation Criteria) определяют измеримые и проверяемые показатели для объективной оценки и последовательного сравнения решений, а также их альтернативных дизайнов.

Несмотря на объединение в одну технику, критерии приемки по смыслу отличаются от критериев оценки. Критерии приемки нужны для определения требований, результатов или условий, которые должны быть выполнены, чтобы решение считалось приемлемым для стейкхолдеров. Иначе говоря, они описывают минимальный набор требований, которые должны быть выполнены, чтобы реализация конкретного решения имела смысл и помогают определить, может ли решение или его компонент удовлетворять требованию. Обычно критерии приемки применяются к одному возможному решению, а результаты такой проверки дискретны: «принято» или «не принято».

В случае выбора между несколькими решениями используются критерии оценки – метрики для оценки набора требований, которые позволяют ранжировать альтернативы по их ценности для стейкхолдеров. Каждый критерий оценки выражается единицах измерения определенного атрибута решения: стоимость, производительность, удобство использования и прочие нефункциональные требования, которые отражает потребности стейкхолдеров. Если какие-то свойства не могут быть измерены напрямую, применяются прокси-метрики, бенчмаркинг, экспертные оценки или методы скоринга.

BABOK подчеркивает, что критерии приемки и оценки могут применяться к одному и тому же набору оцениваемых атрибутов, т.е. нефункциональных требований. При этом бизнес-аналитик должен прежде всего определить, что конкретно представляет собой ценность для стейкхолдеров, т.е. какие именно характеристики решения (нефункциональные требования) наиболее важны, например, затраты на внедрение и эксплуатацию или производительность. В частности, при оценке нескольких альтернатив, решения с более низкой стоимостью и высокой производительностью ранжируются выше. А для одного решения критерии в контрактах и приемочных тестах определяются как требования минимальной производительности и максимальной стоимости.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.

Концепция определений из Guide to Product Ownership Analysis

Однако, критерии приемки и оценки нужны для уже готового решения, а при разработке ТЗ и спецификации требований бизнес-аналитику пригодится концепция определений, приведенная в Guide to Product Ownership Analysis. Выделяются следующие определения (Definitions of…)

  • определение готовности (Definition of Ready) – согласованный командой разработки список критериев, которые должны быть соблюдены, чтобы признать элемент бэклога (требование, задача, баг) готовым для начала реализации, т.е. взять его в работу;
  • определение доставки (Definition of Delivery) – согласованный командой разработки список критериев, которые должны быть соблюдены, чтобы признать элемент бэклога (требование, задача, баг) необходимым для включения в выпуск (релиз) продукта;
  • определение выполненного (Definition of Done) – согласованный командой разработки список критериев, которые должны быть соблюдены, чтобы признать элемент бэклога (требование, задача, баг) выполненным, т.е. реализованным так, как предполагалось изначально.

Таким образом, Definition of Done (DoD) применяется для приемочных испытаний готового продукта, например, успешное прохождение 95% тестов. Definition of Ready можно рассматривать как чек-лист для верификации требования, т.е. что оно является атомарным, непротиворечивым, полным и пр. А Definition of Delivery пригодятся в задаче валидации требований, т.е. подтверждении того, что они имеют ценность для стейкхолдеров.

Помимо концепции определений, в продуктовой разработке также выделяют критерии приемки (Acceptance Criteria, AC), смысл которых практически не отличается от техники BABOK с похожим названием, что мы рассмотрели выше. AC тесно связаны с DoD: при приемо-сдаточных испытаниях DoD является необходимым условием, а AC – достаточным. Проще говоря, DoD позволяют проверить, что задача/требование реализованы, а AC – что реализованы именно так, как надо стейкхолдерам. Поэтому в отличие от Definition of Done и Definition of Ready, Acceptance Criteria для каждой задачи/требования будут уникальными.

Например, для нефункционального требования по производительности «Система должна обрабатывать не менее 90% пользовательских запросов за время не более 1 секунды при количестве подключений до 1000», критериями приемки здесь будут следующие:

  • система обрабатывает большинство запросов не дольше 1 секунды;
  • доля запросов, которые обрабатываются дольше 1 секунды, не превышает 10%;
  • система поддерживает до 1000 одновременных подключений.

Определения выполненного будут такие:

  • пользователи имеют возможность посылать запросы в систему;
  • система корректно обрабатывает запросы пользователей, т.е. выполняет необходимые вычисления и преобразования данных;
  • система успешно прошла более 95% тестов.

От процессов к продуктам: Product Ownership и Agile-практики для бизнес-аналитика

Код курса
POAP
Ближайшая дата курса
11 июля, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.

Освоить эту и другие техники Guide to Product Ownership Analysis, а также попутно познакомиться с BABOK®Guide и Agile-расширением к нему, вы сможете на нашем новом курсе «От процессов к продуктам: Product ownership и Agile-практики для бизнес-аналитика».

А тем, кто хочет познакомиться с содержанием BABOK®Guide на практических примерах, приглашаю вас на курсы нашей Школы прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

 

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Добавить комментарий

Поиск по сайту

Напишите нам, мы онлайн!