Backlog


Хорошо составленный бэклог продукта выглядит как Айсберг: мелкие задачи вверху, большие внизу. А что находится под толщей воды – неизвестно никому.

Почему ваш продуктовый бэклог должен выглядеть как айсберг

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

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

изображения сайта www.mountaingoatsoftware.com

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

Зачем составлять бэклог, который эволюционирует с течением времени

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

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

Всё меняется

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

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

Скорее всего, изменятся те задачи, которые будут реализованы в будущем.

Отсутствие необходимости

Новелист Э. Л. Доктороу писал, что «написать роман – все равно что ехать ночью в тумане. Вы видете только в пределах освещения фар, но таким образом преодолеваете весь путь до конца».

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

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

Дефицит времени

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

Если на данный момент достаточно поверхностно описать будущую задачу, то это всё, что нужно сделать.

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

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

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

Как постепенно уточнять бэклог продукта

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

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

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

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

Простое и надёжное правило – выделять 10% времени в каждом спринте на уточнение бэклога для подготовки к предстоящим спринтам.

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

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

Что происходит, когда сама команда уточняет бэклог

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

При уточнении этих элементов бэклога командам следует обратить внимание на то, что они подразумевают под “пониманием” и “достаточной детализацией”.

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

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

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

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

Основано на статье Майка Кона Why Your Product Backlog Should Look Like an Iceberg