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

Привет, на связи Анна Бушуева, я маркетолог в команде разработки Ареал. Полтора года назад мы начали переходить от классических технических заданий к “гибкой” исполнительной документации. Процесс был естественным. Проекты становилась больше, многофункциональнее, за ними многократно росли ТЗ и становились нечитаемыми.

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

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

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

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

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

User story

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

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

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

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

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

Workflow

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

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

Интерфейсы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нотификации

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

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

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

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

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

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

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

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

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

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

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

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

Разработка

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

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

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

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

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

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