Сценарий использования. Модель или диаграмма Use Case

1.

2.

Практика к блоку 2 – Use Cases / Сценарий
использования

3.

Сценарий использования
инициирует взаимодействие с системой
реагирует на действия субъекта
описывает взаимодействие между субъектом и системой,
последовательность событий, в результате которой субъект получает
некоторую бизнес-ценность.
Как и в user story, результатом
use case является бизнес-ценность.

4.

Модель или диаграмма Use Case
совокупность сценариев, полностью описывающая поведение системы

5.

Модель
Actor
Пользователи с различными ролями
Другие системы: приложения, устройства
Связи:
Обобщение: частные случаи
Include / Включение: повторно используемые подсценарии
Extend / Расширение: альтернативные сценарии
Функция системы
имя функции в форме глагола с пояснительными словами
Система
Система в которой происходит сценарий
<<Include>>
<<Extend>>
Выставить оценки в
журнал
Электронный журнал

6.

7.

Сценарий использования

8.

9.

10.

Частые ошибки
Субъекты:
Инициатором действий является система, а не субъект;
Сценарий:
Вместо сценария описываются функциональные
требования к системе, без указания порядка действий;
Не описаны альтернативные сценарии.
Диаграмма:
Диаграмма излишне детализируется: отображается не логика поведения, а способ
реализации, что превращает ее в аналог UML диаграммы последовательности
действий;
Не все описанные в сценарии альтернативные потоки отображены на схеме;
Альтернативные потоки отображены не как расширения, а как самостоятельные
сценарии;
Слишком детальная диаграмма: 30+ сценариев.

11.

Практика к блоку 2 – User Story /
Пользовательские истории

12.

Бэклог
это перечень рабочих задач, расположенных в порядке важности, для команды
разработчиков. Бэклог может содержать следующие сущности:
User Story/ Пользовательские истории – простое описание небольшого компонента
желаемой функциональности на понятном пользователю языке. Описываемая
функциональность должна быть независимой и нести определенную бизнес ценность.
Дефекты они же bug , задачи на исправление ошибок в ПО.
Рефакторинг перепроектирование кода, переработка кода.
Задачи поддержки – внешней и внутренней.
И так далее.

13.

Жизненный цикл истории (в Scrum)
Жизненный цикл пользовательской истории в контексте Scrum методологии
подразумевает, что существует кросс-функциональня команда, все участники
которой на 100% своего рабочего времени могут заниматься разработкой
пользовательской истории.
ВАЖНО: История содержит все типы работ, которые необходимо
выполнить для доставки ценности пользователю

14.

Этапы жизненного цикла
пользовательской истории:
Определение = требования + проектирование
Разработка = код и все с ним связанное (включая работу
аналитика, стейкхолдеров, архитекторов и прочее)
Тестирование = приемочные автотесты и
дополнительное тестирование
(зависит от компании)

15.

роль в системе
Как <роль> я могу <активность> для того чтобы <бизнес-ценность>
решение
Обычно уже готовое решение,
которое аналитик помогает
сформулировать пользователю на
основании бизнес ценности/
потребности
потребности
Самая важная часть истории,
которую нельзя терять.
Начинаем с нее!

16.

Формулировка
«Я могу сделать что-то» –это уже готовое решение.
Часто пользователь изначально сообщает какие именно действия он хочет
производить в рамках разрабатываемой системы.
Задача аналитика: определить какую потребность (бизнес-ценность)
пользователь желает удовлетворить с помощью активности и проверить
соответствует ли оно определенной бизнес-ценности.
Проверить, не навязывается ли невыполнимое решение или решение, которое
требует больше одной истории.

17.

Формулировка
Решение детализируется вместе с командой.
Например, такая история (которая принадлежит всей команде и выполняется всей командой):
US1: Как клиент мобильного оператора, я хочу видеть расход своего трафика в реальном
времени, чтобы уменьшить его.
Может быть разбита (декомпозирована) на следующие задачи:
Task 1.1 Описание критериев приемки - аналитик
Task 1.2 Реализация - разработчик
Task 1.3 Написание приемочных тестов - тестировщик
Task 1.4 Прогон приемочных тестов - тестировщик
Task 1.5 Обновление руководства пользователя - аналитик/ технический писатель

18.

Use Cases vs User Stories
Два разных, не противоречащих друг другу подхода/ среза знаний;
В проекте может быть использован один любой подход или смешанный подход;
Иногда: юзкейсы могут мапиться на пользовательские истории;
Иногда: пользовательские истории могут мапиться на юзкейсы.

19.

Definition of Done (DoD)
Acceptance Criteria –критерии приемки: задача/US выполнена с т.з. конечного пользователя.
Acceptance Criteria сылается / маппится на DoD.
Definition of Done –критерии готовности: задача/US считается успешно завершенной, если
история прошла через все этапы принятые в проекте/ задачи команды.
История не может считаться выполненной, пока не выполнены условия DoD.
Acceptance Tests – приемочные тесты.

20.

Definition of Done (DoD)
US 1: Как клиент мобильного оператора, я хочу видеть расход своего трафика в реальном
времени, чтобы уменьшить его
Definition of Done
Acceptance Criteria
Успешно завершено тестирование в соотв. с
критериями приемки;
AC1: Доступный клиенту трафик отображается на
главном экране личного кабинета.
Пройдено нагрузочное тестирование;
AC2: Статистика обновляется каждые 60 сек.
Владелец продукта (Product Owner) принял
задачу;
AC3: На отдельном экране отображается статистика
расхода трафика с детализацией по дням.
Обновлена пользовательская документация.
AC4: При нажатии на день, пользователь переходит
на экран с детализацией по часам.

21.

Definition of Ready (DoR)
критерии готовности : готовность истории к планированию в спринт
Зачем?
Избежать начала работы над фичами, которые:
не имеют ясного определения критериев завершенности/ приемки
истории (есть пробелы, слишком абстрактный);
недостаточно проработаны, чтобы достаточно достоверно оценить.
Вовлечь в разработку историй всю команду.

22.

User Story Mapping / Карта пользовательских историй
Для чего?
Для выравнивания понимания интересов пользователя у всей команды
Для проектирования пользовательского опыта
Для определения границ проекта (чтобы эти границы понимала вся команда)
Что потребуется?
Стикеры или инструмент типа Miro
Вся команда
Начальное понимание пользовательского сценария
1-2 ч времени
Задача:
Спроектировать по шагам действия пользователя в продукте

23.

User Story Mapping / Карта пользовательских историй

24.

User Story Mapping / Карта пользовательских историй

25.

User Story Mapping / Карта пользовательских историй

26.

User Story Mapping / Карта пользовательских историй

27.

User Story Mapping / Карта пользовательских историй

28.

ДЗ-1
Подготовить юзер стори мэп и описать стори;
Описать юз кейсы (можно по этим же сторям).
Необходимо создать сервис для записи пациентов к врачу.
Клиент регистрируется через сайт или моб приложение. После регистрации клиент выбирает
отделение и врача, к которому он хочет записаться. У каждого врача есть свое расписание, где
отображаются свободные и занятые окно. Если есть подходящее свободное окно, то клиент выбирает
его и записывается на примем. После записи пациента, администратор клиники получает заявку. Для
подтверждения записи администратор звонит клиенту по указанному номеру. Если клиент
подтверждает запись, то администратор подтверждает эту запись у себя в личном кабинете. Если
клиент записался по ошибке, то администратор отменяет запись, либо редактирует ее, если клиент
решил изменить время или врача. После подтверждения заявки, пациенту приходит смсуведомление о записи. В личном кабинете врача, появляется список пациентов на прием, если
пациент был в клинике ранее, то у врача есть возможность посмотреть его карту. Когда наступает
дата приема, клиент приходит в клинику. После проведения приема, у пациента в личном кабинете
появляется информация о приеме.