BPMN, прототипы, Jira. Язык описания бизнес - процессов

1.

2.

Нотация BPMN
BPMN (Business Process Model and Notation) - это язык моделирования бизнеспроцессов, который является промежуточным звеном между
формализацией/визуализацией и воплощением бизнес-процесса. С помощью
моделирования мы можем описать любые бизнес-процессы, и они могут выполняться
в самых разных системах управления.
Язык описания бизнес-процессов основан
на следующих базовых объектах:
• Event – Событие;
• Activity – Действия;
• Gateway – Шлюзы или Развилки;
• Flow – Поток;
• Date – Данные;
• Artefact – Артефакты;
• Pool (Пул) — Дорожки, набор.

3.

События в BPMN
День рождения — это событие? Еще какое! Вообще, в нашей жизни все начинается
с событий. Так и на схемах процессов нужны стартовые события. Первый и самый
простой тип стартового события — неопределенное событие:
Неопределенный тип событий используется, когда мы описываем абстрактный процесс.

4.

События в BPMN
Помимо разделения на три основных типа, ещё есть разделение на типы по характеру
работы события. Самые востребованные:
• Пустое. Используется чаще всего в описании «подпроцесса» или когда
проектировщик диаграммы просто поленился.
• Сообщение. Используется в тех случаях, когда, например, инициатором запуска
процесса выступает новое сообщение в топике, либо запрос.
• Таймер. Почти все сценарии, которые связаны со временем. Например, запуск
процесса в 12:00 каждый день.
• Ошибка. Событие, которое чаще все используют как завершающее. Зачастую,
описывая процесс, затрагиваются и негативные сценарии, именно для них
используют событие с ошибкой (исключение).

5.

Действия в BPMN
Действия (или задачи) в BPMN используются для отображения функционала,
реализуемого программой. Как и события, они подразделяются на различные типы
и обладают своими особенностями. Однако, исходя из моего опыта, при описании
бизнес-процесса с аналитической точки зрения для IT-команды использование всех
вариантов действий оказывается нецелесообразным, ведь не все до конца понимают
нюансы их различий.
• Обычное действие используется для описания активности, которую нельзя никак
разбить.
• Подпроцесс. Это действие используется, когда необходимо в описываемый
процесс внедрить ещё один (который, например, уже описан) как его часть, либо
для дальнейшей декомпозиции действия.

6.

Шлюзы в BPMN
Шлюзы — это элементы, которые используются для введения в процесс развилок,
различных условий или дополнительной логики. Чаще всего используются три типа
шлюзов: «исключающее ИЛИ», «И» и «включающее ИЛИ».

7.

Исключающее ИЛИ
«Исключающее ИЛИ». Такой шлюз требуется для разделения выполнения процесса на один из
вариантов. То есть это работает, как выбор, и в процессе выполняется либо одна ветка, либо
другая. Примеры:

8.

Шлюз И
«И». Шлюз используется для распараллеливания процесса на две ветки, которые исполняются
одновременно. Примеры:

9.

Включающее ИЛИ
«Включающее ИЛИ». Этот шлюз сочетает в себе функции двух вышеописанных: выполнение
процесса может как распараллелиться на все ветви, так и разбиться на определённые,
удовлетворяющие условию.

10.

Ошибки
Очень важно отметить, как двигается «токен» выполнения процесса по потоку и какие бывают
нюансы. Это позволит чётко и осознанно понимать работу шлюзов, как делать НАДО, как можно,
но НЕ СТОИТ, а как точно НЕЛЬЗЯ.
Найдите ошибку ниже:

11.

Дорожки и Потоки
Потоки — тут всё очень просто: это стрелка, которая отображает последовательность действий
в процессе.
Дорожки (пулы) — эти элементы являются необязательными, на практике обычно используются
для отображения разделения на микросервисы или роли, а также взаимодействий со смежными
системами. Дорожка представляет из себя подписанный прямоугольник, внутри которого
укладываются те элементы, которые выполняются внутри или причастны к микросервису или
системе, или роли. В этом примере с помощью дорожек процесс декомпозируется на отдельные
микросервисы, системы, в которой он (процесс) выполняется.

12.

13.

Зачем аналитик делает
прототипы/макеты
Системный аналитик использует прототип не ради красивой картинки, а как рабочий
инструмент в процессе сбора, фиксации и согласования требований.
Уточнение требований с бизнесом
— Текстовые описания часто понимаются по-разному. Прототип позволяет быстро
показать, что имелось в виду, и получить обратную связь: "Да, это то, что мы хотим".
Формализация бизнес-процесса через интерфейс
— Прототип помогает проверить, что весь пользовательский сценарий покрыт: есть ли
все кнопки, хватает ли данных на экране, можно ли пройти путь от начала до конца.
Облегчение коммуникации между участниками
— Дизайнер, разработчик, тестировщик, заказчик — все смотрят на одну и ту же
визуальную модель, а не трактуют ТЗ по-своему.

14.

Зачем аналитик делает прототипы
Предотвращение недоразумений до начала разработки
— Прототипы выявляют противоречия и упущения до, а не после — когда "уже
написали и переделывать дорого".
Ускорение согласования и утверждения
— С заказчиком проще согласовать прототип, чем читать 20 страниц ТЗ. Это экономия
времени и снижение рисков.

15.

Как обосновать необходимость
прототипа
Для бизнеса:
• "Мы согласуем с вами сценарии в виде макета — это сэкономит ваше время и
деньги"
• "Прототип — это инструмент понимания: вы видите, что получите"
• "По прототипу можно тестировать гипотезы, даже без разработки"
Для команды:
• "Прототип поможет дизайнеру быстрее отрисовать UI"
• "По нему тестировщик сможет понимать требования до конца"
• "Для разработчика — это основа для UI-контрактов"
Для себя:
• "Прототип — это средство проверки логики требований"
• "Позволяет быстрее найти дыры в сценариях"

16.

Типовые ситуации, когда прототип
обязателен
Ситуация
Почему нужен прототип
Новый продукт
Только визуализация покажет, как это
должно работать
Много пользовательских сценариев
Чтобы не забыть шаги, состояния и
варианты
Заказчик "не технарь"
Он не понимает ТЗ, но поймёт картинку
Нет готового дизайна
Разработчик берет за основу макет и
разрабатывает по готовым ранее
блокам/формам/дизайну
Требуется быстрое согласование
На уровне "каркаса"
Речь идёт о доработке старого
интерфейса
Надо показать, что меняется и как
Много логики завязано на визуальные
элементы
Например: видимость блоков,
доступность кнопок, валидация

17.

Jira
Жира или Джира

18.

Что и зачем?
Jira — это система для управления проектами и
задачами.
Она нужна, чтобы фиксировать работу, распределять
её между людьми, отслеживать прогресс и видеть
результат.

19.

Из чего состоит?
Эпик (Epic)
Что это: большая цель или крупный блок работы,
который нельзя закрыть за одну итерацию.
Пример: «Личный кабинет пользователя».
Срок жизни: обычно несколько спринтов или
месяцев.
Вложенность: эпик объединяет stories (и задачи),
относящиеся к одной большой теме.

20.

Из чего состоит?
История (User Story)
Что это: описание функционала глазами пользователя.
Формат: «Как <роль> я хочу <действие>, чтобы <ценность>».
Пример: «Как зарегистрированный пользователь, я хочу менять
пароль в личном кабинете, чтобы восстановить доступ без
обращения в поддержку».
Вложенность: истории входят в эпики.

21.

Из чего состоит?
Задача (Task)
Что это: единичная работа, не обязательно связанная
с пользователем напрямую. Может быть технической.
Пример: «Настроить интеграцию с почтовым
сервисом».
Когда использовать: для вещей, которые не
выражаются через пользовательскую ценность, но
нужны для реализации.

22.

Из чего состоит?
Подзадача (Sub-task)
Что это: разбиение одной истории или задачи на
маленькие куски, которые выполняет отдельный
исполнитель.
Пример:
«Сделать форму смены пароля на фронтенде»
«Написать API для смены пароля»
«Написать тесты для API»
Вложенность: подзадачи принадлежат одной
задаче/истории. Они не живут сами по себе.

23.

Из чего состоит?

24.

Стори и таска
Story (User Story) — ориентирована на
пользователя и описывает ценность: «Что
должен получить пользователь и зачем».
Task — ориентирована на команду и
описывает техническую или внутреннюю
работу: «Что нужно сделать, чтобы всё
работало».

25.

А что писать то?

26.

Шаблон
Название: короткое, отражает цель.
Описание:
• Контекст: зачем этот эпик нужен.
• Цель: что бизнес/пользователь получит.
• Scope (область): что входит, а что не входит.
• Критерии завершения (Definition of Done): по каким признакам
считаем эпик реализованным.
Эпик
Пример
Название: Личный кабинет пользователя
Описание:
• Контекст: пользователи хотят управлять своими профилем и
настройками.
• Цель: реализовать личный кабинет, где можно менять личные
данные, пароль и загружать аватар.
• Scope: включает работу с данными профиля, пароль, аватар. Не
включает уведомления и платёжные данные.
• Критерии завершения:
• Все основные истории (смена пароля, смена email, загрузка
аватара) закрыты.
• 70% пользователей заходят в ЛК в течение месяца после релиза.

27.

Шаблон
• Название: «Как <роль> я хочу <действие>, чтобы <ценность>».
• Описание: уточнение контекста (почему важно, на какие сценарии
влияет).
• Acceptance Criteria (Критерии приёмки): список условий, при
которых история считается сделанной.
• Definition of Done (DoD): что должно быть выполнено (код, тесты,
документация, проверка на стенде).
Пример
Название: Смена пароля
Описание:
• Как зарегистрированный пользователь, я хочу менять пароль в
настройках личного кабинета, чтобы восстанавливать доступ без
обращения в поддержку.
• Acceptance Criteria:
• Пользователь может ввести старый и новый пароль.
• Новый пароль проверяется на сложность.
• После смены пароля старый становится недействительным.
• Пользователь получает уведомление об успешной смене.
• DoD:
• Реализован и протестирован API.
• Сделана форма на фронте.
• Написаны unit и интеграционные тесты.
• Проверено на тестовом окружении.
Сторя

28.

Таска
Шаблон
• Название: действие (глагол + объект).
• Описание: зачем эта работа нужна, какой результат ожидается.
• Definition of Done: критерии завершения.
Пример
• Название: Настроить SMTP-сервер для отправки писем
• Описание: нужно подключить SMTP для отправки писем
подтверждения при смене пароля.
• DoD:
• Сервер настроен и доступен из приложения.
• Отправка письма работает на тестовом окружении.
• Ошибки логируются.

29.

Саб таска
Шаблон
• Название: очень конкретное действие.
• Описание: что именно нужно сделать и как проверить.
• Definition of Done: результат работы.
Пример
• Название: Сверстать форму смены пароля
• Описание: форма в личном кабинете с полями «Старый пароль»,
«Новый пароль», «Подтверждение пароля».
• DoD:
• Поля отображаются корректно.
• Валидация на фронте работает.
• Ошибки показываются пользователю.

30.

А чем отличаются AC и
DOD?
Acceptance Criteria (AC) — что именно должно работать для
пользователя.
Пример: «При смене пароля старый становится недействительным,
новый проверяется на сложность».
Definition of Done (DoD) — как команда понимает, что задача
полностью завершена.
Пример: «Код написан, покрыт тестами, проверен на тестовом сервере,
задокументирован».
DOR (Definition of Ready) — «Определение готовности». Это набор
критериев, которым должна соответствовать задача (user story, epic,
feature), чтобы команда могла взять её в работу.
Кратко:
AC - функционал глазами пользователя.
DoD - качество и процесс глазами команды.
DOR - про готовность к выполнению задачи

31.

Поля
• Summary (Название) — краткое, понятное заголовок задачи.
• Description (Описание) — детали: зачем, что нужно сделать,
контекст.
• Assignee (Исполнитель) — кто отвечает за выполнение.
• Priority (Приоритет) — насколько задача важна.
• Status (Статус) — стадия работы («To Do», «In Progress», «Done»).
• Reporter (Автор) — кто создал задачу.
• Issue Key (Ключ задачи) — уникальный идентификатор вроде PROJ123.
• Labels (Метки) — теги для поиска/группировки.
• Comments (Комментарии) — обсуждения внутри задачи.
• Attachments (Вложения) — файлы, скрины, документы.
• Created / Updated (Дата создания и изменения) — история задачи.

32.

Диаграмма прецедентов

33.

Что это?
Диаграмма прецедентов (Use Case Diagram) — это визуальная модель
из UML, показывающая какие функции системы доступны внешним
акторам (пользователям, другим сервисам) и как они взаимодействуют
с системой.

34.

Из чего состоит?
1. Акторы (Actors)
Кто взаимодействует с
системой: пользователь,
администратор, внешний
сервис.
Обозначение: «человечек»
или имя актора.
2. Прецеденты (Use Cases)
Функции системы, которые
доступны акторам.
Обозначение: овалы с
названием действия
(«Создать бронирование»).

35.

Из чего состоит?
3. Система (System Boundary)
Прямоугольник, внутри которого находятся все прецеденты.
Показывает, что именно относится к системе.
4. Ассоциации (линии связи актор ↔ прецедент)
Простые линии, показывающие, что актор инициирует use case И
характер линий может быть include и extend.
Include — обязательный общий шаг.
Extend — необязательное дополнительное поведение.

36.

Как строить?
1. Определить акторов
Кто взаимодействует с системой: пользователь, администратор,
внешний сервис.
2. Выделить прецеденты (use cases)
Какие действия эти акторы хотят выполнить: «Войти», «Создать
бронирование», «Отменить бронирование» и т. д.
3. Установить связи актор → прецедент
Соединяем акторов с прецедентами, которые они инициируют.
4. Выявить связи между прецедентами (include, extend).

37.

Вопросы
1. Что такое BPMN?
2. Типы событий?
3. Характерны событий?
4. Что такое шлюзы?
5. Их типы?
6. Для чего делать прототипы?
7. Что такое Jira? Зачем нужна?
8. Что такое эпик? Примеры?
9. Что такое стори? Примеры?
10.Что такое задача? Примеры?
11.Как эпик, стори и задача соотносятся друг с другом?
12.Разница между стори и таской?
13.Что такое AC, DOD, DOR и в чем разница?
14.Что такое диаграмма прецедентов и из чего она состоит?