Если в вашей команде участвует больше двух человек, то однозначное и детальное описание требуемой функциональности просто необходимо, чтобы синхронизировать действия всех участников. Форма описания функциональности (или постановка) может отличаться в зависимости от квалификации и потребностей команды, возможности подробного описания требований заказчиком и других условий. Я хочу описать три основных варианта процессов работы с требованиями и показать как это можно использовать в DEVPROM.

Водопадная модель

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

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

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

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

Итерационная модель

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

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

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

Отсутствие формализованных требований

Данный вариант пришел из Agile практик и предлагает отказаться от формализации требований, то есть их составления, а вместо этого описывать желаемое поведение приложения путем создания так называемых историй пользователя (user story). Такой подход удобен для легковесного итерационного процесса, где не требуется явно выделять роли аналитика и тестировщика.

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

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

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

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

Анализ бизнес потребностей

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

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

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

Кстати, когда-то давно, 6 лет назад, мы еще не знали про Scrum, но уже работали по такой же схеме :)

Как можно здесь организовать работу аналитика? Очень просто - включать в журнал пожелания (product backlog) отдельные пожелания по сбору требований (в DEVPROM их можно отмечать тегом Аналитика, для быстрого доступа). Эти пожелания живут обычной жизнью и так же приоритезируются, как и остальные пожелания.

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

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

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

Согласитесь, нет ничего приятнее для proxy product оунера, чем одним кликом посмотреть все вопросы, требующие обсуждения с заказчиком, а так же их важность для команды (приоритеты).

P.S. В проекте может выделенного аналитика не быть - тогда его место займет команда. Но об этом в одном из следующих постов про сбор требований в Agile проектах.