Препарируем agile: какие артефакты подходят для заказной разработки
Проекты становилась больше, многофункциональнее, за ними многократно росли ТЗ и становились нечитаемыми.
Я спросила своих коллег, какие артефакты входят в исполнительную документацию, как они формируются, применяются в проекте. Статья будет интересна тем, кто ищет свой подход к управлению заказной разработкой. Делитесь в комментариях как документация устроена у вас.
Вводная
Комплектующие для документации мы позаимствовали из agile. Создание и взаимосвязи между артефактами в нашем варианте не всегда соотносится с традиционным agile-ом. Цель смены подхода — выстроить систему документации, которая поможет структурировать и приоритизировать разработку большого проекта, а не внедрить agile.
Проект на этапе пресейла делится на эпики — верхнеуровневые большие группы функций. Например, для личного кабинета клиента транспортной компании: посмотреть свою дислокацию, статус взаиморасчетов, подать заявку, посмотреть её статус. Эпики позволяют двигаться к цели постепенно, клиент получает часть функций регулярно.
Исполнительная документация — это ряд материалов разного формата, которые исчерпывающе описывают эпик: какие задачи пользователь хочет решить в системе, какие функции ему для этого понадобятся, сценарии, по которым пользователь взаимодействует с системой, состав и структура баз данных, архитектура интеграций, UX/UI интерфейсы. Документация формируется постепенно на разных этапах работы с эпиком.
Брифинг. Первичные требования
На брифингах клиент рассказывает о бизнес-процессах, их участниках, пользовательских предпочтениях. Аналитик по итогам встреч формирует первичную коллекцию исполнительной документации. К первичным требованиям относятся:
- User story.
- Функциональные требования.
- Workflow.
- Интерфейсы.
- Сквозные требования.
User story
User story описывают запрос пользователя: какой результат после работы с сервисом он хочет получить. Например, для клиента — получить КП, для менеджера — создать запрос со слов клиента.
В классическом Agile есть иерархическое подчинение: эпики состоят из историй. В заказной разработке элементы смешиваются и подчинение или его отсутствие зависит от системы. Иногда эпик небольшой, составляет одну историю. Иногда большой эпик делится на два-три субэпика, внутри которых есть истории. Большой эпик в такой парадигме мы называем бизнес-задачей.
На изображении видно как несколько 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 с минимальными правками становятся пользовательской документацией, которая предоставляется заказчику вместе с продуктом. Третье — цифровая система более ориентирована на пользователя. Менеджер, аккаунт, аналитик неизбежно будут много общаться с бизнесом для формирования документации. Техническое задание не всегда дает такую возможность. Особенно если основные контактные лица на стороне клиента — технические специалисты. Подытожим. Исполнительная документация состоит из трех уровней артефактов:
Некоторые системы разрастаются, эпиков становится очень много и связи между ними теряются. Разработчикам, менеджерам, клиенту сложно разобраться во взаимодействии всех фич. В таких случаях появляется дополнительный верхнеуровневый сквозной flow, который детализирует процесс от входа до выхода из системы.
Прототипирование, дизайн. Пользовательские кейсы
Use case
Сценарии — подвижная форма. Они могут быть смесью пользовательского сценария, ответа системы и функциональных требований. Целесообразность пунктов сценария определяет аналитик, опираясь на потребность разработчика. Например, для отдельных интерфейсов описывается работа frontend, если есть уникальные блоки, не описанные в сквозных требованиях.
Тимлид, разработчики конкретного эпика участвуют в согласовании кейсов, прототипа, дизайна. Только после разработческого ревью и внесения правок исполнительная документация, прототипы, дизайн уходят на согласование с клиентом. Это страхует команду от согласования технически несбалансированной системы.
Реализуем потенциал документации
С документацией я разбиваю эпик на задачи не с точки зрения интерфейсов, а с точки зрения распределения задач между специалистами. То есть все задачи адекватного объема и соответствуют логике включенности в систему в целом. Так мы можем поделить один большой интерфейс (все верно — не User story) на кусочки и отдать реализацию разным людям. Процесс разработки идет быстрее.
Зачем все это?
— Макро flow — пользовательский путь от входа до выхода из системы.
— User story — запрос пользователя и результат, который он хочет получить.
— Функциональные требования — перечень функций, которые помогают пройти User story.
— Перечень интерфейсов.
— Workflow — пути достижения User story.
— Сквозные требования к универсальным частям проекта. Техпаспорт
— user case — сценарий использования, то как пользователь взаимодействует с системой. Фактически, описание целевого результата, которое мы должны получить на выходе.