+7 (499) 638-64-11
Попробовать
Постановка и автоматизация процессов разработки ПО

Управление бэклогом продукта

18.01.2012 19:06

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

Описание

Баклог продукта, изначально пришедший из Scrum, используется во многих методологиях Agile и вводится в начале проекта. Баклог или журнал незавершенной работы – это постоянно меняющийся документ, который развивается во время выполнения проекта по мере накопления знаний о продукте и клиентах. Владелец продукта (Product Owner) отвечает за упорядочение элементов баклога на основе знаний и пользе бизнесу, важности фич или других соответствующих критериев. При управлении баклогом, элементы должны быть упорядочены так, чтобы наиболее важные элементы находились в верхней части списка и упорядочены по убыванию приоритета. В XP (eXtreme Programming) незавершенная работа по функциональности может управляться как журнал историй пользователя. Бизнес-аналитик может выступать в качестве владельца продукта или помогать ему.

 

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

 

Незавершенную работу иногда называют «портфелем вариантов» (portfolio options), в который как раз инвестирует бизнес. Используются также такие термины как «основной список историй» и «список приоритетных функций».

Артефакты

Элементы бэклога

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

Надлежащий уровень детализации

Элементы из верхних строчек журнала должны быть разработаны в ближайших релизах, поэтому они должны быть достаточно подробными, чтобы команда разработчиков тщательно их оценила и имела возможность распределить задачи, необходимые для их реализации. Элементы с более низким приоритетом могут быть описаны лишь высокоуровнево и недостаточно точно, но, когда приоритет повысится, они должны быть проработаны более подробно. Большие элементы журнала, иногда называемые эпосами (epics) или приращением коммерческой ценности (business value increments), также могут быть разбиты на несколько, более подробных элементов, то есть подвергнуться проработке путем декомпозиции на истории пользователей. Некоторые аспекты истории пользователя могут быть важными в ближайшее время, а другие - менее важными. Эта возможность делить истории в журнале помогает сохранить частоту выпуска полезного продукта. Например, добавление новой функции может подразумевать предварительное жесткое программирование (hardcode) и добавление новой истории в журнал, чтобы позже добавить возможность некоторой динамической настройки продукта.

Точность оценки

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

Определение приоритета

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

Управление изменениями в баклоге

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

 

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

Особенности использования

Преимущества

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

Недостатки

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

 

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

--

Усилиями членов IIBA и экспертами сообщества Agile был разработан черновик The Agile Extension of the BABOK, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.

 

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

 

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

Еще интересные статьи на эту тему: