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

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

ЧТО ТАКОЕ СПИСОК ТРЕБОВАНИЙ (BACKLOG) К РАЗРАБАТЫВАЕМОМУ ПРОГРАММНОМУ СРЕДСТВУ?

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

ПОДДЕРЖКА СПИСКА ТРЕБОВАНИЙ В РАБОЧЕМ СОСТОЯНИИ

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

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

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

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