5 признаков хороших пользовательских историй (User Stories) от Робертсонов

Итак, пользовательские требования (User Stories) написаны. Как оценить их качество? Джеймс и Сюзанна Робертсоны (James and Suzanne Robertson) выделили признаки хороших пользовательских историй.

use_cases_2

Признак 1

Указана соответствующая (relevant) роль пользователя.

Понятие «пользователь» универсально. В системе может быть, например, разграничение прав доступа, в соответствии с которым предусмотрен конкретный функционал для конкретного пользователя.

Например, покупатель интернет-магазина имеет возможность просмотра каталога товаров, добавления товара в “корзину”, осуществление покупки. Менеджер магазина имеет возможность добавления товаров в каталог, а администратор – управления учетными записями, создания и выгрузки отчетов и т.д. Как видно из примера, употребление термина “пользователь” является не очень информативным и понятным для разработчиков системы.

Признак 2

Указана возможность, а не желание. Между понятиями “хотеть” и “мочь” (то есть иметь возможность) есть разница.

Пользовательская история сформулированная в контексте “я хочу” не всегда идентифицирует бизнес-проблему, которую нужно решить. Например, “… я хочу иметь доступ к своему аккаунту с мобильного телефона …” – это технологическое решение, а не функциональная возможность системы/продукта.

Если вы говорите “я хочу”, вы предполагаете возможность рассмотрения технологического решения, то есть способов реализации функций (см. также признак 3). Если вы говорите “я могу” вы подразумеваете конкретную функцию системы или продукта, которую необходимо реализовать для решения бизнес-проблемы или удовлетворения бизнес-потребности.

Признак 3

Указываемая функциональность (функция системы/продукта) не является технологическим решением, а возможностью системы/продукта. Следует различать функциональную возможность (например, реализация аутентификации при входе покупателя в систему) и технологическое решение (например, реализация аутентификации при входе покупателя в систему с использованием 8-значного пароля) для обеспечения функциональной возможности. Пользовательская история формулируется в контексте вопроса “что”, а не “как”.

Признак 4

Указываемая функциональность – это не первая мысль, которая вам пришла в голову при создании пользовательской истории, это улучшение работы, удовлетворение бизнес-потребности, решение бизнес-проблемы, это то, что будет ценным для бизнеса.

Признак 5

Указано обоснование. Зачастую эта часть пользовательской истории опускается. Между тем, это важнейшая часть истории. В обосновании должны быть указаны реальные влияние и ценность функции системы/продукта для бизнеса.

Есть еще и 6-ой признак хорошей пользовательской истории. Написав пользовательскую историю, задайте себе вопрос: можно ли для нее (истории) написать критерии приемки (Acceptance Criteria)? Но об этом — немного позже.

Пользовательские истории (User Stories) — один из самых мощных и предпочитаемых методов бизнес-анализа, который используется командами с курсом на Agile. Не стоит упускать из виду критерии качества данного типа пользовательских требований.

Смотрите также:

  1. «Магия» Impact Map.
  2. Атрибуты качества пользовательских историй (User Stories): модель INVEST от Билла Уэйка (Bill Wake).
  3. Приемочные тесты (Acceptance Tests) в виде сценариев для пользовательских историй (User Stories).

Источники:

  1. Mastering the Requirements Process: Getting Requirements Right (3rd Edition) by James Robertson & Suzanne Robertson.
  2. The user story considered harmful by James Robertson & Suzanne Robertson – http://www.volere.org/
  3. Requirements: The Masterclass by James Robertson / Suzanne Robertson.