Пользовательские истории сильны в определении функциональности продукта с точки зрения пользователя и клиента: каждая пользовательская история описывает единицу функциональности продукта, например, “Являясь провайдером приложения, я бы хотел зарегистрироваться в центре приложений, чтобы иметь возможность пользоваться его услугами”. Сосредоточив внимание на отдельной области функциональности продукта, история позволяет команде понять, внедрить и протестировать требование.

Данное преимущество также является и слабой стороной: пользовательские истории не достаточно хорошо подходят для того, чтобы выразить взаимосвязь между различными фичами и описать пользовательские рабочие процессы.

Для того чтобы показать, как разные истории сочетаются друг с другом, я посчитал полезным дополнить пользовательские истории упрощенными моделями, первоначально созданными для вариантов использования: контекстные диаграммы и диаграммы деятельности.

Контекстная диаграмма с эпиками

Контекстная диаграмма, которая изображает пользовательские роли и эпики, крупные истории и истории с низкой степенью детализации, превосходно подходит для предоставления обзора функциональности продукта. Давайте посмотрим на пример - диаграмму, в общих чертах демонстрирующую интернет магазин приложений, названный “Центр Приложений”:

Application Center – Центр Приложений Provider – Провайдер User - Пользователь Administrator - Администратор Register - Зарегистрироваться Access sales data – Доступ к данным по реализации товара Upload application – Загрузить приложение Find application – Найти приложение Connect with other users – Соединить с другими пользователями Review application – Просмотреть приложение Reset password – Сбросить пароль Approve or reject application – Одобрить или отклонить приложение

Приведенная выше диаграмма демонстрирует три роли пользователя: провайдер, пользователь и администратор. Она показывает, как эти роли взаимодействуют с эпиками, описывающими функциональность Центра Приложений. Отсюда мы можем понять, например, что и пользователь, и администратор могут просматривать приложение – чтобы активировать рейтинги конечного покупателя и рабочего персонала.

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

Диаграмма деятельности с историями

С целью выполнения работы, пользователи довольно часто предпринимают несколько шагов и взаимодействуют с различными элементами функциональности. Диаграммы деятельности отлично подходят для определения последовательностей и рабочих процессов путем подсоединения индивидуальных пользовательских историй. Они также поддерживают создание комплексных тестовых сценариев, которые выходят за рамки одной истории.

Давайте посмотрим на пример, который детализирует эпик “Зарегистрироваться”, указанный в приведенной ранее контекстной диаграмме. На нем показаны ключевые шаги, необходимые пользователю для регистрации в Центре Приложений:

	Provide company details – Предоставить данные компании Enter user name and password – Ввести имя пользователя и пароль Valid? – Действительный? No – Нет Yes – Да Accept T&C – Принять Сроки и Условия Пользования

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

Советы по моделированию пользовательской истории

Моделирование пользовательских историй представляет собой удобный инструмент в арсенале владельца продукта. Но, как и любой другой инструмент, он требует правильного применения. Следующие советы помогут вам создать идеальную диаграмму:

1. Коллективное моделирование. Моделирование пользовательской истории служит для создания общего понимания желаемой функциональности продукта. Используйте контекстные диаграммы и диаграммы деятельности для того, чтобы отобразить суть общения, а не заменить его! Создавайте и обновляйте ваши диаграммы коллективно, вовлекая в этот процесс команду и, в случае необходимости, заинтересованных лиц.
2. Фокусирование внимания. Применяйте моделирование избирательно и описывайте только надлежащие аспекты. Фокусируйте свое внимание только на полезных элементах баклога продукта и опускайте остальные. Не используйте слишком большое количество информации или ненужных деталей.
3. Простота. Создавайте свои диаграммы простыми и легкими для восприятия. Лучше используйте дополнительные диаграммы для иллюстрации будущих аспектов, вместо того чтобы загромождать модель слишком большим количеством информации. Сложно-структурные диаграммы, как правило, не несут в себе никакой практической пользы.
4. Используйте белые доски и лекционные плакаты вместо электронных инструментов. Простые, физические приспособления стимулируют участие и коллективную работу. Они позволяют избежать ощущения совершенствования и завершенности.

Подведение итогов

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

--

Оригинал статьи: http://agile.dzone.com/news/user-story-modelling

Автор: Roman Pichler

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Критерии приёмки для требований в Agile
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• 5 причин использовать Story Mapping в вашем следующем проекте
• Оценка трудоемкости при планировании релиза в Agile