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

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

 

Что такое список требований (backlog) к разрабатываемому программному средству?

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

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

 

Начните с двух «R»

Дорожная карта (Road map) и требования (Requirements) к команде являются основой списка требований к разрабатываемому проекту. План-график разбивается на несколько стадий, каждая из которых будет иметь ряд требований, а также нюансов и пожеланий заказчика. Давайте рассмотрим «дорожную карту» для вымышленного продукта под названием «Команды в космосе».

 

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

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


Что может повлиять на приоритетность заказчика?

  • Клиентский приоритет.

  • Срочность получения обратной связи.

  • Относительная сложность реализации.

  • Симбиозные отношения между рабочими элементами (например, B проще, если мы сначала сделаем A).

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

 

Поддержка списка требований в рабочем состоянии

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

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

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

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

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

 

Анти-шаблоны для отслеживания обновлений

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

  • Команда ограничивает элементы в списке требований теми, которые ориентированы на клиентов.

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

 

Как список требований сохраняет гибкость команды?

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

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

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

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

Обратите внимание: Заказчики диктуют приоритеты задач в списке требований, а команда разработчиков должна диктовать скорость через список требований. Опаска здесь в том, что могут возникать «трения» с заказчиком, который хочет «подтолкнуть» работу команды. Как правило это случается с новыми заказчиками, сотрудничество с которыми еще не «притеролсь».