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

---

Содержание

• На чём мы остановились

• Исходные данные

• Спонсор проекта и бизнес-требования

• Представитель пользователя и пользовательские требования

• Команда разработки и функциональные требования

• Архитектор и нефункциональные требования

• Менеджер и план проекта

• Исполнение

• Заключение

На чём мы остановились

Первая часть гайда посвящена особенностям работы с требованиями на фазе инициации на примере функционала «Общего счёта» вымышленного банка DBT. В конце материала мы передали результаты первичного анализа на оценку возможности реализации.

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

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

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

В этой статье мы продолжим работу над учебным проектом «Общий счёт», проведём детальный анализ требований, декомпозируем их до задач участникам команды разработки и составим план проекта в Yandex Tracker.

Декомпозиция будет производиться согласно иерархической структуре. Каждая задача подчиняется задаче верхнего уровня, а та — задаче уровнем ещё выше. За основу иерархической структуры возьмём пирамиду требований.

Работу с требованиями всегда нужно начинать с уточнений. С момента окончания первичного анализа прошло несколько месяцев. Это большой срок, за который могли поменяться стейкхолдеры, бизнес-процессы заказчика и даже пользовательские требования.

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

Исходные данные

Фиксируем информацию, которая понадобится нам на стадии планирования.

Цели проекта

• Уменьшить риск утечки конфиденциальных данных клиентов DBT.

• Сохранить количество активных клиентов банка за счёт повышения уровня безопасности.

• Привлечь новых клиентов за счёт функционала, аналогов которого нет у конкурентов.

Задача проекта

• Расширить функционал «Личного кабинета физического лица», добавив возможность работы с новым типом счёта «Общий счёт».

Ключевые показатели эффективности (KPI)

• Снижение на 50% количества обращений в поддержку, связанных с утечкой конфиденциальных данных клиентов.

• ≥20% активных клиентов имеют по меньшей мере один счёт с типом «Общий».

• Оборот по счетам с типом «Общий» составляет ≥20% от общего оборота активных клиентов банка.

Команда проекта

• Управление проектом: руководитель проекта (фултайм).

• Разработка требований: два системных аналитика (фултайм).

• Доработка веб-приложения «Личный кабинет физического лица»: фронтенд-разработчик (фултайм), бэкенд-разработчик (фултайм) и тестировщик (парт-тайм — 50%).

• Разработка нового сервиса «Общий счёт»: два бэкенд-разработчика (фултайм) и тестировщик (парт-тайм — 50%).

• Настройка подсистем, не требующих доработки: участники других команд — по мере необходимости и исходя из их загрузки.

• Разработка руководства пользователя: технический писатель (парт-тайм — нагрузка будет определена во второй половине работы над проектом).

Верхнеуровневое архитектурное решение

Спонсор проекта и бизнес-требования

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

Обычно спонсор планирует получить выгоду от решения проблем бизнеса или достижения бизнес-целей. У него нет возможности и потребности погружаться в нюансы пользовательских и функциональных требований. Спонсору важно видеть картину целиком.

В нашем примере мы разбили проект на несколько составляющих, которые можно реализовать относительно независимо друг от друга.

Общий счёт для физических лиц

• в веб-приложении «Личный кабинет ФЛ»;

• в приложении на Android;

• в приложении на iOS.

Общий счёт для юридических лиц

• в веб-приложении «Личный кабинет ЮЛ»,

• в приложении на Android,

• в приложении на iOS.

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

В нашем примере разработка функционала «Общего счёта» начнётся с доработки веб-приложения «Личный кабинет физического лица». Требования к этому этапу будут фиксировать в подпроекте «Web-приложение. “Общий счёт для физ.лиц”» в портфеле проектов «Общий счёт».

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

Представитель пользователя и пользовательские требования

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

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

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

В первой части гайда мы говорили о том, что бизнес-заказчик использует для декомпозиции требований карту пользовательских историй (user story map). При этом требования декомпозируются на две категории:

• пользовательские активности (user activities) — последовательные действия, которые нужно совершить пользователю для достижения своих целей;

• пользовательские истории (user stories) — более конкретное описание действий, которые пользователь должен выполнить в рамках активности. Это техника описания требований от первого лица и с использованием местоимения «я».

Процесс взаимодействия с ПО можно описать с помощью пользовательских активностей. Пользовательские истории описывают то же, но более подробно.

У нас получилось два уровня требований, декомпозированных по целям и задачам пользователей. Но при переносе карты пользовательских историй в таск-трекер мы столкнёмся с противоречием в используемых терминах. В стандартном шаблоне рабочего процесса Scrum нет типа задачи «пользовательская активность».

И такой список типов задач отображается не только в Yandex Tracker, но и в Jira и других популярных таск-трекерах. Это противоречие связано с тем, что команда, анализирующая поведения пользователей, и команда разработки смотрят на продукт с разных сторон, имеют разные цели и используют разные теоретические базы. Но то, что термины называются по-разному, не значит, что методологии команд друг другу противоречат. Конечно, мы можем добавить в трекер новые типы задач, но у нас уже есть несколько уровней иерархии. Если добавить дополнительные, поддерживать актуальность требований будет сложнее. Поэтому мы попробуем обойтись стандартным набором типов задач.

С пользовательскими активностями поможет Epic — этот тип задач позволяет группировать истории и задачи, связанные общей темой. В Epic могут входить истории  из разных очередей и спринтов. Пользовательские активности можно считать частным случаем Epic. В этом случае пользовательская активность — это Epic, дочерние истории которого объединены целью пользователя, и эта цель будет достигнута после реализации всех входящих в Epic историй. Также в Epic’е могут быть сгруппированы истории, которые относятся к одному бизнес-процессу.

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

CRUD — это аббревиатура, обозначающая четыре основные операции управления данными: create, read, update и delete (destroy). То есть создание, чтение, обновление и удаление. Мы совершаем эти действия с любой информацией и в любых системах.

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

Например, если клиент может открыть счёт (create), то у него должна быть возможность и закрыть его (delete). А ещё мы должны дать ему возможность видеть открытые счета в личном кабинете (read). Если клиент совершает операции пополнения и списания (update), то может захотеть и посмотреть выписку по счёту (read).

Помимо сущностей, создаваемых клиентом, мы можем найти и те, которые появляются в системе независимо от его действий. Например:

• если в системе появился новый продукт — «Общий счёт», значит, кто-то его добавил и кто-то может его удалить (отключить);

• если клиент может прочитать договор об обслуживании «Общего счёта», значит, кто-то этот договор составил и может его изменить.

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

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

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

Теперь мы можем переносить активности из карты пользовательских историй в таск-трекер как Epic’и. Это не значит, что мы больше не будем вносить изменения в список Epic’ов — мы просто создаём структуру, к которой будет добавляться детальное описание требований. Эта структура может меняться по мере детализации.

Карта пользовательских историй создавалась с бизнес-заказчиком в режиме мозгового штурма. Пользовательские активности и истории записывались в свободном формате. При этом участники мозгового штурма старались придерживаться общеизвестного шаблона записи истории: «пользователь — задача — цель» (role — feature — reason).

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

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

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

Команда разработки и функциональные требования

Истории из карты пользовательских историй можно перенести в задачи с типом Story в таск-трекере. В этой части термины преимущественно совпадают, но формат описания деталей может сильно отличаться в разных командах и даже у разных аналитиков.

Гибкие методологии управления разработкой не предполагают деления требований на типы. Считается, что любое из них можно описать в формате user story или job story. Это правда так, но есть нюанс. Формат user story хорошо подходит для маленьких команд (до семи человек) и относительно простых предметных областей. 

Джефф Паттон в книге «Пользовательские истории. Искусство гибкой разработки ПО» акцентирует внимание на том, что пользовательские истории нужно рассказывать — именно в процессе обсуждения историй должны выявляться требования и проектироваться система. При этом истории вовсе не обязательно детально описывать и актуализировать. Джефф Паттон утверждает: чтобы вспомнить детали обсуждения, достаточно посмотреть на доску со стикерами или даже на фото доски.

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

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

Изначально критерии приёмки (acceptance criteria) назывались приёмочными тестами (acceptance tests), потому что они должны напоминать команде разработки о том, что ей нужно протестировать после реализации истории. Критерии приёмки отвечают на вопрос: «Что команда должна проверить перед тем, как представить функцию пользователям?».

Участники команды разработки проверяют карточку истории в три этапа:

• аналитик выявляет и записывает критерии приёмки на карточке истории;

• аналитик записывает шаги, которые нужно выполнить для проверки критериев, в сценариях приёмки;

• тестировщики дополняют сценарии приёмки и формируют тест-кейсы — сценарии для проверки функциональности.

Таким образом, для одной истории нам нужно указать:

• название;

• роль пользователя;

• задачу;

• цель пользователя;

• предусловия;

• последовательность действий пользователя при выполнении задачи и отклики системы.

Если приглядеться, окажется, что пользовательская история, дополненная сценариями и критериями приёмки, в точности повторяет набор обязательных полей шаблона описания Use Case по Алистеру Коберну.

Алистер Коберн — один из основателей Agile-манифеста. Он знаком аналитикам по своей книге «Современные методы описания функциональных требований к системам» и формату описания вариантов использования (use case).

Техника описания функциональных требований по Коберну никак не противоречит принципам гибких методологий — варианты использования также можно обсуждать с командой и актуализировать по мере обсуждения. Отличие в том, что в гибких методологиях очень абстрактно описаны процессы декомпозиции и документирования — все преимущества этого подхода можно получить только в сверхмотивированной кроссфункциональной команде, все участники которой очень любят общаться друг с другом (только никто не пишет, где такую команду найти ?). А вот Коберн даёт детальное описание инструментов работы с требованиями, применять которые можно независимо от особенностей команды. 

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

• краткое название истории — оно будет отображаться на доске, в карточке и использоваться при устном обсуждении;

• описание мотивации пользователя, заполненное по шаблону «пользователь — задача — цель», внутри карточки истории. Оно нужно, чтобы мы не забывали о проблеме пользователя и могли рассказать о его потребностях команде разработки, которая не участвовала в построении карты пользовательских историй;

• предусловия — шаги, которые должны быть пройдены, чтобы сценарий истории был успешно выполнен. Используется для создания тестовых данных;

• основной сценарий — описание последовательности действий пользователя и откликов на них системы, когда всё идет по плану.

• альтернативные сценарии — описание последовательности действий пользователя и откликов на них системы в случаях, когда что-то пошло не так. Используются для написания тестовых сценариев, проработки экранов ошибок в прототипе интерфейса и так далее;

• описание данных — включает названия сущностей и их атрибутов (тип данных, доступность для редактирования, значение по умолчанию, максимальное значение). Используется для составления словаря и модели данных, формирования списков параметров запросов и ответов при проектировании API.

На первой итерации детализации требований лучше писать все истории (варианты использования) для одного Epic’а на одной странице в Wiki. В процессе детализации часто возникает потребность изменить структуру, и на одной странице это сделать значительно проще. Рассмотрим на примере Epic’а «Открытие общего счёта».

1. Создаём страницу, название которой совпадает с названием Epic’а.

2. Добавляем ссылку на Epic в название страницы, а ссылку на страницу в описание Epic’а.

3. Детально описываем все истории, входящие в Epic по шаблону.

После описания основных сценариев для каждой истории структура требования в рамках Epic’а вряд ли изменится — теперь описание каждой истории можно переносить на отдельные страницы в Wiki и создавать истории в таск-трекере.

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

Диаграммы последовательности, детализированные до уровня потоков данных, помогут нам:

• уточнить список подсистем, участвующих в реализации истории;

• быстрее разобраться в документации к API уже реализованных систем, ведь теперь мы приблизительно понимаем, какие методы нужно искать в документации;

• описать требования к API создаваемого с нуля сервиса — «Общий счёт» (теперь мы знаем, какие данные сервис будет получать на вход и передавать сторонним системам на выходе).

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

Мы помним, что настройкой и доработкой каждой из подсистем занимается отдельная команда. Одна история описывает одно пользовательское требование, но его реализация может потребовать доработки множества подсистем. Для каждой истории список подсистем будет свой. Определим этот список на основании диаграммы последовательности и внесём его в таск-трекер — в карточку истории в виде компонента или тега.

В дальнейшем мы сможем отфильтровать истории по компоненту или тегу и сформировать бэклог для конкретной команды разработки.

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

Нефункциональные требования не определяют бизнес-процессы, но имеют решающее значение для понимания, как в итоге будет выглядеть система. К ним относится надёжность, безопасность, масштабируемость, производительность, доступность и другие требования к особенностям эксплуатации системы.

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

Источники функциональных требований чаще всего интуитивно понятны, поэтому их документирование не вызывает трудностей. А вот определить нефункциональные требования, а после задокументировать их, гораздо сложнее. Они накладывают ограничения на систему и определяют качество её работы.

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

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

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

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

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

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

• Я как сотрудник отдела сопровождения хочу, чтобы система была доступна 99% времени. А о проведении технических работ, при которых система будет недоступна, сообщали не менее чем за сутки — это снизит количество негативных отзывов.

• Я как DevOps-инженер хочу, чтобы обновление системы проводилось через систему CI/CD. Это сократит время на «кастомное» обновление системы и поможет быстро откатить обновление, если понадобится.

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

Описание истории также можно дополнить сценариями — ссылками на инструкции по настройке определенной системы, репозитория, фреймворка или библиотеки.

Если в истории описаны требования к безопасности и производительности, нужно уделить особое внимание альтернативным сценариям.

Истории, созданные на основании нефункциональных требований, можно сгруппировать в Epic «Первоначальная настройка среды разработки». Если учитывать, что верхнеуровневое архитектурное решение входит в число исходных данных стадии планирования, то настройку сред разработки и тестирования можно проводить параллельно с детализацией пользовательских и функциональных требований. Так и разработчики не заскучают, и времени на реализацию уйдёт меньше.

Менеджер и план проекта

На этом этапе мы выстроили иерархическую структуру требований: Портфель проектов → Проект → Epic → История (Story). Достаточно указать даты начала и завершения для каждого типа задачи, и Yandex Tracker сам построит план проекта.

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

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

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

Исполнение

На этом этапе проектная команда выполняет работы по плану:

• назначает и контролирует выполнение задач;

• общается со стейкхолдерами;

• управляет рисками.

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

В водопадной модели каждый следующий этап начинается только после завершения предыдущего. Проект движется от анализа входных данных к проектированию, разработке, тестированию и, наконец, внедрению. Но в гибких методологиях грани между фазами планирования и исполнения сильно размыты. По сути мы множество раз проходим через цикл Деминга—Шухарта (Plan-Do-Check-Act — планирование-действие-проверка-корректировка), чтобы максимально оперативно реагировать на изменения в требованиях.

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

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

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

На проект выделили двоих аналитиков, и нам нужно распределить между ними задачи. Сделать это не так просто. Процессам выявления и анализа требований свойственна неопределённость. Мы не знаем, какие требования будут выявлены и как они повлияют друг на друга, но благодаря первичному анализу на стадии инициации у нас есть общее представление о ролях пользователей и декомпозиции требований на пользовательские активности. Когда мы перенесём Epic’и в таск-трекер, мы сможем распределить их между аналитиками (указать аналитика в качестве исполнителя у задачи с типом «Epic»).

Определив, какие данные поступают на вход процесса, описываемого в Epic’е, и какие данные будут на выходе, аналитики смогут детализировать истории Epic’а относительно независимо друг от друга.

При этом аналитик может самостоятельно определить глубину проработки требований в рамках историй своего Epic’а:

• если для реализации истории нужно обратиться к сторонней системе, требования могут быть дополнены выдержками из документации сторонней системы;

• если подсистемы, участвующие в истории, хранят данные, требования могут быть дополнены словарём и моделью данных;

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

Это похоже на деление задач между аналитиками на основании бизнес-процессов (вертикальная декомпозиция). На практике также часто встречается деление задач между аналитиками на основании подсистем (горизонтальная декомпозиция). Например, один аналитик описывает требования к сервису «Продукты», другой к сервису «Общий счёт», а третий — к сервису отправки уведомлений. Такой подход позволяет аналитику хорошо изучить, как работает его подсистема. Но метод хорошо работает, когда в компании небольшое количество подсистем и не требуется значительная доработка в рамках ранее определённых бизнес-процессов. Если же большая часть бизнес-процессов затрагивает несколько подсистем, например при микросервисной архитектуре, выделение отдельных аналитиков на каждый микросервис приведёт к тому, что в итоге никто не сможет сказать, как работает бизнес-процесс от начала и до конца. Если мы этого не знаем, мы не сможем проверить, были ли достигнуты цели пользователя и стейкхолдеров после доработки системы.

Разобрались с задачами аналитиков — перейдём к работе других специалистов.

Дизайнер

В нашем примере дизайнер создаёт макеты для веб-приложения «Личный кабинет физического лица». Мы можем подключить дизайнера к проекту сразу, как только аналитик распишет основные сценарии в рамках одного Epic’а. При этом можно указать в Epic’е соответствующий тег или компонент и настроить доску задач для дизайнеров так, чтобы на ней отображались все Epic’и и истории с этим тегом или компонентом.

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

Подробнее о согласовании макетов мы поговорим в статье о фазе контроля.

Разработчик

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

Разработчики смогут обсудить истории на груминге и планинге, провести покер-планирование и создать дочерние задачи. При этом у нас появится более-менее точная оценка трудозатрат по той или иной истории, а её саму можно будет декомпозировать на задачи так, чтобы каждая занимала не больше одного рабочего дня.

Тестировщик

Тестировщик (QA-инженер) — это специалист, который проверяет соответствие реализованного ПО требованиям. Проверить соответствие ПО функциональным требованиям достаточно просто, и можно сделать это в рамках истории. Значительно сложнее проверить, что ПО соответствует нефункциональным требованиям, так как для этого нужно обладать обширными техническими навыками. И совсем не просто проверить, что ПО решает проблемы пользователя и бизнеса — для этого нужно глубоко погрузиться в контекст проекта.

Кажется, что работа тестировщика начинается после того, как разработчики завершили свои задачи и нужно их протестировать. Но это не так. В DBT задачи для QA-инженера создаются в разрезе Epic’ов — тестировщик назначается как второй исполнитель в карточке и приступает к работе после определения основных и альтернативных сценариев. На базе функциональных требований создаются план тестирования и тестовые сценарии. В тестовую среду заносятся данные, и начинается работа над проектированием автотестов.

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

Заключение

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

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

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

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

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