CC BY
114СшВ
ОПИСАНИЕ БИЗНЕС-ПРОЦЕССОВ С ИСПОЛЬЗОВАНИЕМ КАРТ ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ
DESCRIPTION OF BUSINESS PROCESSES USING USER STORY MAPPING
УДК 004.04
Хапов Андрей Владимирович, студент кафедры «Системы обработки информации и управления», Московский государственный технический университет им. Н.Э. Баумана (национальный исследовательский университет), г. Москва
Маслеников Константин Юрьевич, ассистент кафедры «Системы обработки информации и управления», Московский государственный технический университет им. Н.Э. Баумана (национальный исследовательский университет), г. Москва
Khapov A.V. andrey141409@gmail.com Maslenikov K.Yu. kmaslenikov@yandex.ru
Аннотация
В статье рассмотрен вариант описания бизнес-процессов под названием user story mapping, или карта пользовательских историй. В настоящее время существует множество нотаций и методологий для работы с бизнес-процессами и требованиями к ним, однако статья описывает преимущества использования метода user story mapping, его гибкость и возможность использования для описания практически любого процесса. Создание
сторимапа показано на примере, созданном с помощью сервиса Miro: это подчеркивает простоту и наглядность метода, а также возможность использования его на любом носителе, будь то электронные или бумажные варианты.
Annotation
The article considers a variant of describing business processes called user story mapping. Currently, there are many notations and methodologies for working with business processes and requirements for them, however, the article describes the advantages of using the user story mapping method, its flexibility and the possibility of using it to describe almost any process. The creation of a story map is shown using an example created using the Miro service: this emphasizes the simplicity and clarity of the method, as well as the possibility of using it on any medium, electronic or paper versions.
Ключевые слова: сторимап, пользовательская история, понимание, бизнес-процесс, требование
Keywords: story map, user story, understanding, business process, requirement
Введение
При проектировании корпоративной информационной системы большую роль играет сбор функциональных требований заказчика. Одним из способов для моделирования потребностей пользователя является создание бизнес-процессов. Создание совершенно любого бизнес-процесса начинается, прежде всего, с его описания. Бизнес-процессы принято описывать в определенной форме: в виде текста, таблиц, графиков, рисунков, схем, а также графов.
В свою очередь, комбинации форм описания, складываются в определенные нотации и модели, например, Business Process Model and Notation (BPMN), Integrated DEFinition (IDEF), extended Event Driven Process
Chain (eEPC) и другие. Каждая такая нотация имеет свою специфику, правила построения, преимущества и недостатки.
Однако в данной статье мы рассмотрим принципиально иной вариант описания бизнес-процессов: карта пользовательских историй (user story mapping) [1].
Карта пользовательских историй
Как правило, формальные описания процессов не дают пользователю единого понимания. Это значит, что ни сторона заказчика, ни сторона исполнителя далеко не всегда разделяют видение друг друга [2].
Поэтому в данном случае на помощь и приходит пользовательская история. Это не просто изложение требований в письменной форме, а, так как любая из историй влечет за собой обсуждение, - важный ключ к пониманию того, как конкретно пользователи будут пользоваться продуктом для достижения с его помощью тех целей и выполнить те задачи, которые ему необходимы. Результатом такой дискуссии должно стать соглашение о том, какой именно продукт будет разрабатываться.
Важной составляющей работы над пользовательскими историями является не только говорение, но и письмо [3]: любые тезисы и идеи можно записывать. Так, во-первых, ценные мысли не пропадут из головы, а во-вторых, карта историй станет полнее и нагляднее.
Так как же выглядит пользовательская история? Очень просто: для ее построения нужен всего лишь набор стикеров (или карточек). Один стикер -один тезис или одно действие. Как правило, он представляет собой атомарное требование либо простейший шаг пользователя. Затем эти стикеры могут складываться во фрагменты небольших процессов, которые, в свою очередь, будут объединяться в одну большую цельную историю.
Конечно, фрагменты не должны располагаться в хаотичном порядке. Их последовательность и является последовательностью действий, которую совершает пользователь при использовании продукта. При составлении
сторимапа важно в первую очередь добиться его целостности при прочтении слева направо. А после того, как достигнут конец пользовательской истории, можно начать прорабатывать подробности отдельно взятых шагов. На каждом из них нужно отвечать на следующие вопросы:
- в чем заключается особенность действий пользователя на данном этапе?
- какие альтернативные варианты развития событий могут быть на этом
шаге?
- как исправить ситуацию, если что-то пойдет не так?
Ответы на эти вопросы помогают по-настоящему детализировать и представить себе продукт, который планируется создать.
Помимо этого, преимуществом сторимапа также является то, что он может помочь объединить несколько небольших проектов в один [4]. Например, в некоторой созданной системе есть возможность объединять много пользователей и подсистем. Сторимап позволяет мыслить как единое целое и понять ценность для совместного выпуска продукта. Таким образом, достигается самая важная цель, о которой уже было сказано выше: расширяется понимание, устраняются все недочеты и пробелы, которые могут помешать пользователю на пути к решению его задачи.
Именно так: необходимо решать в первую очередь пользовательскую задачу, то есть концентрироваться на результате, который будет получен на выходе из системы.
Также большим удобством сторимапа является то, что отображенные на нем детали можно разбивать на релизы (проще говоря, этапы планирования) [5]. Релизы располагаются друг под другом, будучи разделенными горизонтальными линиями. Первый релиз располагается выше всех, он же содержит в себе наиболее важные для продукта опции, без которых невозможно обойтись, а ниже уже располагаются те вещи, без которых на первом этапе продукт вполне сможет обойтись.
Построение карты пользовательских решений с помощью Miro
Удобством «стикер-формата» также является и то, что его можно использовать не только вживую, но и онлайн. Неплохие возможности в этом плане предоставляет Miro (бывший RealTimeBoard) - сервис для совместной работы, созданный в Перми почти десять лет назад [6].
Создать свою пользовательскую историю в нем совсем несложно: достаточно начать добавлять элементы sticky note с помощью пользовательской панели слева или используем клавишу N. Таким образом можно добавить сколько угодно стикеров. Ниже пример (см. рис.) того, как можно вкратце изобразить с помощью сторимапа процесс поступления в
университет абитуриентом.
Рис. Сторимап "Подача документов для участия в конкурсе" Все очень просто. Оранжевыми стикерами мы обозначаем шаги (действия) пользователей системы. Концепция сторимапа позволяет наглядно отобразить ролевую модель системы. В данном случае роли - это абитуриент и сотрудник приемной комиссии, отмеченные соответствующими иконками. Простота и наглядность - очевидные преимущества сторимапов.
Белыми стикерами обозначаются пояснения к оранжевым, то есть детали, которые необходимо учесть при дальнейшей разработке системы,
чтобы пользователь мог достичь свою конечную цель - подачу заявки на участие в конкурсе, при этом верно заполнив все поля заявки и приложив необходимые документы.
Желтым стикером обозначаются альтернативные шаги. Так, например, для выбора бакалавриата в качестве уровня образования альтернативой станут магистратура и специалитет. Это значит, что, выбери абитуриент эти параметры, сценарий может незначительно (а в иных случаях - и очень существенно) измениться.
Красные стикеры - это цели, или «activities», иными словами, группы шагов, объединенные между собой каким-то подпроцессом для достижения микроцели в рамках одного большого процесса под названием «Подача документов для участия в конкурсе».
Также на рисунке обозначены релизы. Как видно, в первый релиз включаются все основные необходимые функции продукта, а уже на втором релизе появляется, к примеру, возможность регистрации по номеру телефона. Это полезная функциональность для развития продукта, однако не является ключевой на первом этапе его создания.
Естественно, в примере приведен не совсем подробный сторимап. Он описывает лишь саму концепцию user story mapping. Но, как уже стало понятно, его преимущество заключается в бесконечной расширяемости. У каждого лица, участвующего в разработке системы, есть возможность добавить свои замечания, идеи и пожелания, и все это можно сделать, всего лишь добавив на карту очередной стикер.
Заключение
Таким образом, моделирование бизнес-процессов на этапе сбора требований заказчика при проектировании корпоративной информационной системы с помощью пользовательского сторимаппинга, кроме простоты техники и эффективности, предполагает следующие преимущества: взгляд со стороны пользователя готовой системы (минимизация между
функциональностью и ценностью для пользователя); последовательная
история; визуализация.
Литература
1. Паттон, Д. Пользовательские истории. Искусство гибкой разработки ПО. СПб: Питер, 2017. 390 с
2. Курс «Постановка задачи на разработку ПО» [электронный ресурс]. URL: https://stepik.org/course/1128/syllabus (дата обращения: 15.07.2020)
3. Кон, М. Пользовательские истории: гибкая разработка программного обеспечения. Киев: Диалектика, 2018. 256 с
4. Хамбл Д., Фарли Д. Непрерывное развертывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ. М.: Вильямс, 2016. 432 с
5. Льюис К. User Story Confusion: Creating and Breaking Them Down: Carnsa Development Series, #3. Alderbank House, 2018. 72 с
6. Блог платформы Miro [электронный ресурс]. URL: https://habr.com/ru/company/miro/ (дата обращения: 15.07.2020)
Literature
1. Patton, J. User Story Mapping: Discover the Whole Story, Build the Right Product. Saint Petersburg: Piter, 2017. 390 p.
2. Course «Setting the task for software development» [online source]. URL: https://stepik.org/course/1128/syllabus (request date: 2020/07/15)
3. Cohn, M. User Stories Applied: For Agile Software Development. Kyiv: Dialektika, 2018. 256 р.
4. Humble J, Farley D. Continuous software deployment. Automation of assembly, testing and implementation of new software versions. Moscow: Williams, 2016. 432 р.
5. Lewis C. User Story Confusion: Creating and Breaking Them Down: Carnsa Development Series, #3. Alderbank House, 2018. 72 p
6. Miro platform blog [online source]. URL: https://habr.com/ru/company/miro/ (request date: 2020/07/15)
