Препарируем agile: какие артефакты подходят для заказной разработки

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

Вводная

Комплектующие для документации мы позаимствовали из agile. Создание и взаимосвязи между артефактами в нашем варианте не всегда соотносится с традиционным agile-ом. Цель смены подхода — выстроить систему документации, которая поможет структурировать и приоритизировать разработку большого проекта, а не внедрить agile.

Проект на этапе пресейла делится на эпики — верхнеуровневые большие группы функций. Например, для личного кабинета клиента транспортной компании: посмотреть свою дислокацию, статус взаиморасчетов, подать заявку, посмотреть её статус. Эпики позволяют двигаться к цели постепенно, клиент получает часть функций регулярно.

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

Брифинг. Первичные требования

На брифингах клиент рассказывает о бизнес-процессах, их участниках, пользовательских предпочтениях. Аналитик по итогам встреч формирует первичную коллекцию исполнительной документации. К первичным требованиям относятся:

• User story.
• Функциональные требования.
• Workflow.
• Интерфейсы.
• Сквозные требования.

User Story

User Story описывают запрос пользователя: какой результат после работы с сервисом он хочет получить. Например, для клиента — получить КП, для менеджера — создать запрос со слов клиента.

Максим Щенников

коммерческий директор

В классическом Agile есть иерархическое подчинение: эпики состоят из историй. В заказной разработке элементы смешиваются и подчинение или его отсутствие зависит от системы. Иногда эпик небольшой, составляет одну историю. Иногда большой эпик делится на два-три субэпика, внутри которых есть истории. Большой эпик в такой парадигме мы называем бизнес-задачей.

На изображении видно как несколько User Story объединены большой задачей.

В свежих проектах проектах story уже переехали в таблицы, потому что на основе таблиц удобнее создавать и вести бэклог и карту проекта.

Функциональные требования

Это функции, которые удовлетворяют пользовательский запрос, помогают пройти User Story. Например, фильтрация заявок по статусу “В работе”, сортировка, поиск, статистика.

Workflow

Блок-схема, которая описывает прохождение пользователем компонентов интерфейсов системы в зависимости от роли и задачи. Workflow готовится, если трех артефактов выше недостаточно. Например, процесс нелинейный и происхождение данных на одном из этапов непонятно. Авторизация, регистрация, подача заявки.

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

Анастасия Амосова

менеджер проектов

Некоторые системы разрастаются, эпиков становится очень много и связи между ними теряются. Разработчикам, менеджерам, клиенту сложно разобраться во взаимодействии всех фич. В таких случаях появляется дополнительный верхнеуровневый сквозной flow, который детализирует процесс от входа до выхода из системы.

Интерфейсы

Перечень интерфейсов, через которые пользователь решает свою задачу. Например, для user story “посмотреть дислокацию контейнера”, функциональное требование — реализация фильтра и поиск по контейнеру, интерфейс — реестр контейнеров.

Когда интерфейсов много, аналитик составляет их карту.

Сквозные требования

Описание работы frontend-компонентов (состояния меню, работа фильтров, отображение уведомлений), в частности таблиц. Таблицы внутри одного проекта функционируют одинаково, но по-разному на каждом проекте: с гридами или без, колонки подвижные или нет, ячейки раскрываются или нет.

Дополнительные артефакты

Наш подход наследует из технического задания документы, которые стоят отдельно от исполнительной документации, описывающей взаимодействие с пользователем. Матрица ролей и прав доступа, схема архитектуры и баз данных, стек и другие технические материалы. Они используются для подготовки кейсов и разработки. Поместить все технические требования в соответствующий раздел use case нецелесообразно. Кейсы — пользовательский сценарий, а технические требования — для разработчиков.

Со временем мы стали объединять эти технические артефакты в единый техпаспорт проекта.

Прототипирование, дизайн. Пользовательские кейсы

Когда первичные требования согласованы с клиентом, команда переходит к прототипам. Часто аналитики начинают собирать черновые варианты прототипов еще на этапе user story.

Прототип переходит на этап дизайна. После появления прототипа или дизайна пишутся use case — пользовательские сценарии.

Use Case

Use case показывает как человек взаимодействует с системой и как система ему отвечает. В идеале кейсы декомпозируют достижение конкретной user story. Но мы от user story идем не сразу к use case, как принято в Agile. Наш путь — переложить story на интерфейсы, функции, и написать сценарий использования этих двух сущностей.

Аналитик описывает действия пользователя на конкретной странице — автономные части, которые разработчики могут реализовать независимо друг от друга. Например, use case “заявки” состоит из последовательного описания действий: посмотреть, отсортировать, найти заявку в поиске, создать, редактировать заявки с разным статусом, удалить.

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

Use case включает разные разделы. Мы остановились на следующем шаблоне:

• Технические требования.
• Ссылки на общие материалы проекта.
• Предварительные условия.
• Основной сценарий.
• Альтернативный сценарий.
• Нотификации.

Технические требования

Рассказывают, как система реагирует на действия пользователя. В какой момент работы с системой создать новую запись, по какому шаблону её назвать, какой выбор предложить пользователю в селекте, какие теги присвоить. Технические требования идут первыми в Use case, потому что помогают разработчикам изначально правильно верстать фронт и подтягивать бэк.

Ссылки на общие материалы проекта

• Ссылка на сквозные требования.
• Ссылки на прототип интерфейсов этого эпика.
• Ссылка на User story, workflow.

Предварительные условия

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

Основной сценарий

Последовательные шаги, которые выполняет пользователь для достижения результата в Use case. Если путь сильно отличается в зависимости от роли пользователя в системе, то для каждой прописывается отдельный сценарий. Если роли имеют просто разные уровни доступа, то сценарий регулирует таблица прав доступа по ролям (аналитик оставляет ссылку на неё рядом с пунктом).

Ирина Казанская

аналитик

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

Альтернативный сценарий

В agile есть понятие "негативный сценарий", мы решили совместить негативный и альтернативный, чтобы не увеличивать количество сущностей.

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

Альтернативный — отличный от основного путь, который приводит к аналогичному результату. Например, редактировать запись через иконку "карандаш" или через строку "редактировать" в выпадающем списке меню.

Нотификации

Список уведомлений, которые система присылает в ответ на действия пользователя. Выносится отдельно, чтобы разработчик смог их проверить.

Ольга Завьялова

аналитик

Тимлид, разработчики конкретного эпика участвуют в согласовании кейсов, прототипа, дизайна. Только после разработческого ревью и внесения правок исполнительная документация, прототипы, дизайн уходят на согласование с клиентом. Это страхует команду от согласования технически несбалансированной системы.

В некоторых проектах use case модифицированы по просьбам разработчиков. На первый план вышли функциональные требования — список элементов, которые нужно реализовать. Полноценные кейсы переехали вниз документа. Разработчики обращаются к описанию, если возникают вопросы.

По схеме Agile дальше идут test case. Так и было, когда мы только переходили на исполнительную документацию. Со временем этот артефакт оказался рудиментарным. Все тестирование проходит внутри команды: аналитик, QA. Тестировщиков вне контекста проекта нет. Специалисты, знакомые с системой, не нуждаются в детализированных test case.

Реализуем потенциал документации

Что мы имеем к моменту оценки и дальнейшей разработки эпика:

• User story — запросы пользователей.
• Функциональные требования — список функций.
• Интерфейсы — перечисление интерфейсов, которые должны быть в системе для реализации функционального требования.
• Workflow — описание связей между интерфейсами, компонентами и пользователями.
• Сквозные требования к проекту — описание универсальных компонентов и фич системы.
• Дополнительные артефакты — схемы, связанные с архитектурой, ролями в системе.
• Use case — сценарии использования системы через призму интерфейсов и функций.
• Прототипы, дизайн (фактически не являются документацией, но макеты и прототипы на следующих этапах работы передаются разработчикам).

В сущности мы имеем много файлов, которые описывают работу и визуал системы в конкретном эпике. Теперь нужно применить исполнительную документацию на практике.

Декомпозиция эпика

Тимлид декомпозирует эпик на задачи. Переводит с языка менеджера на язык программиста. Материалы, на основе которых он формирует задачи, — use case и интерфейсы.

Владислав Афанасьев

тимлид

С документацией я разбиваю эпик на задачи не с точки зрения интерфейсов, а с точки зрения распределения задач между специалистами. То есть все задачи адекватного объема и соответствуют логике включенности в систему в целом. Так мы можем поделить один большой интерфейс (все верно — не User story) на кусочки и отдать реализацию разным людям. Процесс разработки идет быстрее.

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

Покер-оценка

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

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

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

Разработка

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

Да, все детали не останутся в памяти. Вопросы "А как здесь сделать?" будут задаваться. А ответы "Это же написано в кейсе, вот тебе документ, иди, почитай" будут получаться. Проблема решается многократным повторением и внедрением культуры обращения к документации. Мы на этом пути.

Зачем все это?

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

Второе — use case с минимальными правками становятся пользовательской документацией, которая предоставляется заказчику вместе с продуктом.

Третье — цифровая система более ориентирована на пользователя. Менеджер, аккаунт, аналитик неизбежно будут много общаться с бизнесом для формирования документации. Техническое задание не всегда дает такую возможность. Особенно если основные контактные лица на стороне клиента — технические специалисты.

Подытожим. Исполнительная документация состоит из трех уровней артефактов:

1. Макроуровень:
   • Макро flow — пользовательский путь от входа до выхода из системы.
2. Средний уровень:
   • User story — запрос пользователя и результат, который он хочет получить.
   • Функциональные требования — перечень функций, которые помогают пройти User story.
   • Перечень интерфейсов.
   • Workflow — пути достижения User story.
   • Сквозные требования к универсальным частям проекта. Техпаспорт.
3. Микроуровень:
   • User case — сценарий использования, то как пользователь взаимодействует с системой. Фактически, описание целевого результата, которое мы должны получить на выходе.