В построении отлаженного механизма поставки заказного ПО особую роль занимает коммуникация. Наиболее частые ошибки в коммуникации проявляются при передаче информации между специалистами, работающими в разных технологических стеках. Еще чаще проблемы могут возникать, когда такая коммуникация происходит между специалистами из разных компаний (заказчик-клиент).
Так, в частности, случается при передаче артефактов (объектов, применяемых или создаваемых в процессе разработки) от бизнес-аналитика со стороны заказчика системному аналитику со стороны исполнителя.
Исходя из нашей практики взаимодействия с партнерами, мы хотим поделиться примером того, как может проходить бизнес-анализ с последующей передачей артефактов системным аналитикам для продолжения реализации цикла поставки ПО, а также рассказать о том, как применение DocOps-практик позволяет создать единую технологическую среду для всех участников процесса разработки. Этот комбинированный подход, с учетом цикличного характера процесса изменений в артефактах, успешно применяется на различных проектах и позволяет избегать ошибок, которые могут привести к дополнительным временным и материальным затратам.
Итак, все начинается с возникновения желания в разработке чего-то нового. Назовем это «идеей» или «потребностью», которая на первый взгляд может показаться довольно конкретной. Например, «нам нужна CRM».
Бизнес-аналитик на стороне заказчика изучает возникшую потребность и фиксирует ее в виде бизнес-требований. Далее он проводит декомпозицию требований на отдельные пользовательские истории (User Stories, способ описания требований к разрабатываемой системе, сформулированных как одно или несколько предложений по определенному шаблону).
Шаблон для составления пользовательских историй содержит информацию о ролевой модели и ролевых действиях, которые должен выполнить тот или иной пользователь, а также информацию о том, зачем вообще это нужно делать.
Базируясь на практике взаимодействия с заказчиками, рекомендуем учитывать следующие моменты:
- Пользовательские истории должны быть направлены на достижение общей цели потребности/идеи. Все остальное можно полностью отсечь или переместить в отдельную очередь с низким приоритетом.
- Совокупность пользовательских историй должна образовывать ролевую модель будущей системы или продукта, а также определять верхнеуровневые бизнес-процессы, которые нужно автоматизировать.
- Пользовательские истории являются основой для составления вариантов использования продукта.
Для большей наглядности некоторые бизнес-требования — где процессы имеют состояния и есть переходы между состояниями — визуализируются с помощью различных блок-схем. Например, BPMN (нотация моделирования бизнес-процессов и их описание в XML) или других нотаций для описания блок-схем. При моделировании важно понимать, что шаги в описании процесса должны соответствовать пользовательским историям.
Отрисовка схем текущего состояния не обязательна, но она позволяет выделить изменения в бизнес-процессах, которые бывает необходимо закрепить в организационно-распорядительной документации заказчика. Иногда этот процесс занимает много времени и проходит несколько болезненно, поэтому ему заранее стоит уделить должное внимание.
Набор отрисованных процессов с привязкой к ним пользовательских историй по сути определяет содержание будущей разработки, а также позволяет разбить на этапы процесс создания ПО.
Следующий шаг — подготовка базовых требований к экранным формам. Здесь речь необязательно идет о дизайне GUI, UX/UI и технологиях разработки — это все выносится на потом. Цель данного шага — определить точки взаимодействия «человек-машина».
Как правило, пользователь общается с системой посредством графического интерфейса (GUI). Все переходы процесса от пользовательских ролей к системе и обратно (а для этого система должна быть одним из участников процесса и явно выделена на схеме в отдельную дорожку) определяют необходимость присутствия в этом месте какой-либо экранной формы, а перечень передаваемых данных определяет ее содержание.
Далее требуется сформулировать функциональные и нефункциональные требования. Они должны быть четкими и однозначными — по факту это граничные условия для решения задачи.
К функциональным требованиям могут быть отнесены:
- Формат и состав входящих и/или исходящих данных.
- Ограничения по использованию технологий.
- Порядок выполнения действий при реализации функционала.
- Интеграция с информационными системами.
- Прочие требования, которые напрямую влияют на реализуемую функциональность.
Нефункциональные требования при этом являются дополнительными. Это могут быть требования к безопасности или к быстродействию решения. К тому, что напрямую не влияет на функциональность разрабатываемого ПО, но все равно должно учитываться при дальнейшем системном анализе и разработке.
После этого бизнес-аналитик указывает критерии оценки приема работы — набор показателей, по которому в дальнейшем будет тестироваться и приниматься работа.
Наконец, требуется установить приоритеты для заданного функционала, чтобы при выборе задач, которые попадут в разработку, в первую очередь отбирались те, что обладают наивысшим приоритетом.
Таким образом, набор требований готов для передачи системному аналитику на стороне исполнителя. Осталось только зафиксировать готовые требования в виде одной или нескольких задач, используя для этого один из трекеров задач.
Итак, мы разобрались с тем, в каком виде передаются артефакты от бизнес-аналитика системному. Но как быть дальше? Мы продемонстрировали предпочтительный формат коммуникации, однако в реальных проектах с обменом информации дело обстоит чуть сложнее, ведь сам процесс разработки является цикличным: требования динамичны и на любом этапе могут быть изменены. Кроме того, в таком процессе также задействованы тестировщики, менеджеры проектов и другие члены команды, которые работают вместе. У каждого из них свой набор инструментов, процессов и практик.
Например, у отдела тестирования есть системы управления тестированием (Test Management System), в которых они ведут тест-кейсы и проводят различные тестирования. У аналитиков это, в основном, Confluence, Notion и, часто, стандартные офисные программы, а у разработчиков важнейшими инструментами обычно выступают система контроля версий Git, Task Tracker и инструменты DevOps.
Здесь на помощь приходят DocOps-практики: в них все процессы и инструменты знакомы каждому участнику процесса разработки ПО. Более того, благодаря этим практикам и аналитики, и тестировщики, и разработчики, и менеджеры проектов могут быть активно задействованы в цикличном процессе создания документации, так как их работа сосредоточена в едином пространстве.
Переход на общий инструментарий — Git и связанные с ним процессы — не только предоставляет возможность сохранять документацию для разных версий продукта (циклов изменений) в актуальном виде, но и облегчает взаимодействие между сотрудниками, позволяет отслеживать все изменения, вносить их коллективно и при необходимости легко возвращаться к предыдущим версиям.
В своей DocOps-практике мы используем открытый инструментарий: язык разметки Markdown, Git и генератор сайтов Hugo.
