Многим знакома эта техника, но тем не менее, не упущу возможность немного академически переписать ее из BABOK. Итак, Пользовательские истории используются для передачи требований клиента к команде доставки, разработчику, если говорить проще. Они представляют собой описание потребностей клиента и выражаются в виде небольшого, краткого описания функции, которая как рази и обеспечивает ценность. Такой подход хорошо проявил себя с позиции облегчения взаимодействия и сотрудничества между заинтересованными сторонами.
Обычно пользовательская история не занимает более одного-двух предложений, написанных клиентами, владельцами продуктов или аналитиками, которые описывают что-то ценное для заинтересованной стороны. Истории предоставляют владельцу продукта механизм для определения объема, координации и приоритизации добавляемой пользовательской ценности в процессе реализации ценностей продукта до пользователей. История пользователя записывается в журнал невыполненной работы (Backlog).
Такая техника не просто представляет потребности заинтересованных сторон в качестве краткой и доступной для прочтения информации, но и отлично себя проявляет в качестве хорошего инструмента исследования требований прибегая к форме бесед, тестов и дополнительных представлений требований по мере необходимости. Истории лаконичны и их легко изменять по мере прояснения потребностей заинтересованных сторон, либо по мере развития этих потребностей.
Обычно используемой конструкцией для обеспечения качества в пользовательских историях является критерий "INVEST", суть которого заключается в том, чтобы пользовательские истории были:
- (I) Независимость: представляет собой функцию, которая может быть поставлена независимо от других функций.
Пример: "ввод PIN-кода банкомата" не зависит от "суммы вывода" - (N) Договороспособность: команда может договориться о том, как доставить продукт.
- (V) Ценность: выражает ценность для клиента.
Пример: "ввод PIN-кода банкомата" позволяет только правильному человеку получить доступ к счету. - (E) Измеримость: команда может оценить усилия по достижению результатов на основе прошлого опыта.
- (S) Соответствие объему: для того, чтобы команда завершила работу за одну итерацию. В общем, чем меньше, тем лучше.
- (T) Проверяемость: может быть объективно проверен заинтересованным лицом.
Важно: Не все элементы невыполненной работы должны быть записаны в виде пользовательских историй. Однако истории пользователей - это распространенный метод, используемый, когда они подчеркивают ценность клиента.
Атрибуты пользовательской истории
Название карточки (необязательно)
Название истории пользователя описывает действие, которое пользователь хочет выполнить с помощью решения. Как правило, это целевая фраза с активным глаголом, аналогичная тому, как называются прецеденты использования.
Формат
Обязательной структуры для Пользовательских историй не существует, и организации могут формально определять свои собственные форматы и закреплять их в соглашениях по проектированию. Однако наиболее распространенный формат включает в себя три компонента:
- роль пользователя или персона,
- необходимое действие, поведение или особенность [что], и
- выгода или бизнес-ценность, полученная Пользователем при реализации истории [почему].
Пример формата 1
"Как <роль>, мне нужно <особенность>, чтобы <цель или значение>."
Как владелец текущего банковского счета, я должен получить доступ к своему счету, чтобы снять наличные.
Пример формата 2
"Для того чтобы <ценность бизнеса>, как <роль>, мне нужно <поведение>."
Для того чтобы снять наличные со своего счета, мне как владельцу текущего банковского счета необходим доступ к своему счету.
Важность беседы в коменде
Предполагаемая цель Пользовательских историй состоит в том, чтобы общаться между заинтересованными сторонами и командой доставки. История пользователя намеренно не захватывает все, что нужно знать о потребностях клиента. Хорошо написанная история пользователя вызывает разговор между членами команды.
Подтверждение
Специалисты по бизнес-анализу подтверждают, что поставляемый товар удовлетворяет потребности, выраженные в пользовательской истории. Это чаще всего выражается в виде качетвенных критериев. Критерии принятия определяют границы пользовательской истории и помогают проверить и подтвердить соответствие решения предполагаемым потребностям пользователя.
Критерии помогают команде определить минимальное количество необходимых функций. Они в основном используются владельцем продукта и заинтересованными сторонами для проверки и подтверждения полноты реализации требований, а также служат основой для приемочных испытаний, регрессионных тестов, исследовательских тестов и других тестов.
Управление пользовательскими историями
Существует множество способов использования пользовательских историй в рамках инициативы. Все перечисленные ниже методы зависят от историй пользователей:
- Уточнение Отставания,
- Декомпозиция Истории,
- Разработка сюжета, а также