Бэклог продукта

1.

Leantech AI Lab
Раздел 6. Бэклог продукта

2.

Что такое бэклог продукта
Бэклог продукта похож на стопку бумаг на столе офисного клерка. В этой стопке — вся его работа
на многие дни вперёд. Наверху стопки лежат самые важные на данный момент бумаги, а внизу —
менее важные.
Каждый день работник берёт лист бумаги с верхушки стопки, заполняет его, передаёт на проверку
коллеге и берёт следующий лист.
Иногда коллега приносит ему новую стопку бумаг. Они вместе обсуждают срочность их обработки и
кладут часть менее важных бумаг под низ существующей стопки, часть более важных — в
середину, а отдельные, самые важные, кладут наверх. И так происходит день за днём.
Бэклог продукта (Product Backlog) — это список всех работ, которые команде разработки предстоит
выполнить для реализации ПО. Он используется для планирования работы над проектом, оценки
сроков и стоимости реализации.

3.

Что входит в бэклог продукта?
В гибкой модели разработки бэклог продукта часто включает в себя только ту работу, которая связана с реализацией ПО. Команда
разработки записывает туда реализацию требований от пользователей, добавление новых функций и улучшение существующих.
Допустим, пользователи обнаружили в ПО ошибки, а команде недостаёт знаний по определённым технологиям и опыта работы с ними.
Команде может потребоваться заново переписать часть кода или изменить архитектуру, например, чтобы ПО могло работать с возросшим
количеством пользователей. Все эти задачи команда вносит в бэклог продукта в своём таск-менеджере.
Таким образом, в бэклог продукта входят:
•Функции.
•Дефекты (баги).
•Техническая работа.
•Получение знаний.
5

4.

Функции
Функции — это характеристики ПО и возможности, которые пользователи ожидают получить и
которые помогут им в достижении целей.
Источником функций для бэклога продукта выступают пользователи.
Например, функциями мобильного приложения для прослушивания музыки могут быть добавление
понравившихся треков в избранное, возможность делиться списком избранных через социальные
сети и так далее.
Как правило, функции в бэклоге продукта системный аналитик описывает в виде:
Пользовательских историй (User Story).
Историй о работе (Job Story).
Дефекты
Дефекты, или баги, — это обнаруженные в ПО проблемы, которые пользователи хотят устранить.
Например, в приложении для прослушивания музыки дефект проявляется, когда в избранное
добавляют 999-й трек. Команда разработки может исправить баг сразу, если он важный, а может
отложить в бэклог проекта. Важность дефекта команда определяет самостоятельно или совместно
с пользователями.
Источниками таких элементов бэклога выступают пользователи, обнаружившие дефект при
использовании ПО, или члены команды, например тестировщики и системные аналитики.

5.

Техническая работа
Техническая работа — это работа, скрытая от пользователей, цель которой — упростить внесение
изменений в ПО.
В отличие от функций, техническая работа не приносит пользователям моментальной пользы. Но
она важна для команды, так как упрощает реализацию функций и исправление дефектов, а значит,
увеличивает темп работы.
Источником таких элементов бэклога выступает команда разработки.
Например, разработчики предлагают пересмотреть часть архитектуры или полностью переписать
её программный код, чтобы упростить дальнейшее внесение изменений или улучшить
характеристики ПО, скажем быстродействие.
Получение знаний
Получение знаний — это работа, также скрытая от пользователей, цель которой — получить новые знания о том, как
реализовать функцию.
Допустим, команда хочет проверить свои предположения — для этого она создаёт прототип ПО, проводит эксперимент с
новой технологией, оценивает разные варианты реализации функций.
Источником таких элементов бэклога тоже выступает команда разработки. Она может осознать потребность в знаниях, если
ожидаемая пользователями функция должна быть разработана с помощью недавно появившихся технологий.
Например, пользователи хотят использовать возможности приложения для прослушивания музыки с помощью «силы
мысли». Команда разработки раньше не работала над нейроинтерфейсами, поэтому они могут включить в бэклог множество
элементов, направленных на получение знаний об этой технологии. Не обладая этими знаниями, команда не сможет
оценить объём функции, а значит, и назвать пользователям сроки её реализации.
Такой элемент бэклога называют спайком (Spike).

6.

Соотношение элементов
Обычно в бэклоге больше функций, чем других категорий элементов. Дефекты встречаются значительно реже.
Но бывает и так, что дефектов в бэклоге больше, чем функций. Например, 150 дефектов и 30 функций. В таком
случае команде разработки стоит бросить все силы на то, чтобы скорее исправить дефекты и сбалансировать
бэклог продукта.
Технической работы и спайков будет немного. Дело не в том, что эта работа неважна, напротив, это
неотъемлемая часть процесса разработки ПО. Просто эта работа обычно выполняется сразу после
добавления в бэклог. Команда не будет включать туда получение знаний, которые потребуются только через
год. Если команда включает в бэклог продукта техническую работу или получение знаний, она рассчитывает
выполнить
в ближайших
итерациях.
Ведитееёсписок
работ
в одном
месте аналитику следует вносить все работы в таск-менеджер, где команда разработки ведёт свой
Системному
бэклог продукта. Он должен быть единственным источником работы, которую команде необходимо выполнить
для реализации ПО.
Случается, что часть элементов бэклога описана не только в таск-менеджере, но и в электронной почте,
мессенджере, документах, а часть не описана вовсе и есть лишь в голове у системного аналитика. Это мешает
команде понять объём предстоящей работы, а значит, и планировать сроки её выполнения.
К тому же команда может не сделать того, что было действительно важно пользователям, потому что
системный аналитик описал нужные им функции в сообщении, которое затерялось в переписке.
Наконец, членам команды просто неудобно переключаться между разными источниками рабочих задач.
Системный аналитик должен убедиться, что вся работа для команды описана в одном месте — в таскменеджере в виде элементов бэклога продукта.

7.

DEEP-критерии бэклога
продукта
Бэклог
продукта должен быть оптимально детализированным,
оценённым, постоянно изменяющимся и отсортированным по важности
для пользователей. Эти характеристики называют DEEP-критериями
бэклога:
Detailed Appropriately — оптимально детализированный.
Estimated — оценённый.
Emergent — изменчивый.
Prioritized — приоритизированный.
Акроним DEEP придумал Майк Кон (Mike Cohn), который является
одним из основателей Scrum Alliance.

8.

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

9.

Оценённый
Команда разработки оценивает размер бэклога продукта, чтобы ответить на важные для любого
проекта вопросы:
Когда команда разработки завершит реализацию?
Сколько будет стоить реализация?
Пользователям важно понимать, когда они смогут протестировать реализованные функции. А
заказчики могут на основании сроков определить стоимость реализации бэклога продукта.
Стоимость влияет на достижение целей заказчиков, то есть на их бизнес-требования. Если
стоимость превысит ценность от реализации функций, заказчики могут завершить проект досрочно.
Системный аналитик следит за тем, чтобы элементы бэклога продукта были оценены командой
разработки. Определять сроки реализации бэклога вы научитесь в этом спринте.

10.

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

11.

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

12.

Бэклог итерации
Кроме бэклога продукта, есть бэклог итерации или спринта. Спринт — это всего лишь другое
название итерации, свойственное подходу Scrum.
Бэклог итерации — это план действий для реализации элементов бэклога продукта, который
команда разработки предполагает выполнить в итерации.
Итерация — шаг на пути к реализации ПО. Иными словами, пройдя несколько итераций, команда
разработки завершает реализацию всех ожидаемых пользователями функций ПО.
Бэклог итерации состоит из:
Нескольких элементов бэклога продукта.
Всех задач, которые нужно выполнить для реализации этих элементов.
Команда включает в бэклог итерации самые важные на данный момент элементы из бэклога продукта, учитывая при этом
темп реализации. То есть только элементы, расположенные наверху бэклога, и только те из них, которые команда
предполагает реализовать во время итерации. Своё предположение команда основывает на темпе реализации прошлых
итераций.
Также в бэклог итерации команда включает план действий по реализации каждого элемента. То есть добавляет к элементу
задачи, необходимые для его реализации.
Задача — это работа над элементом бэклога продукта, которую распределяют между собой члены команды
разработки.роме бэклога продукта, есть бэклог итерации или спринта. Спринт — это всего лишь другое название итерации,
свойственное подходу Scrum.
Бэклог итерации — это план действий для реализации элементов бэклога продукта, который команда разработки
предполагает выполнить в итерации.
Итерация — шаг на пути к реализации ПО. Иными словами, пройдя несколько итераций, команда разработки завершает
реализацию всех ожидаемых пользователями функций ПО.

13.

Контакты спикера
Нина Портман
меил
телефон
12

14.

О нас
Компания Leantech AI Lab была основана
в 2014 году группой профессионалов в
области разработки программного
обеспечения, объединенных
идеей создания высококачественных
программных продуктов.
Более 100 ИТ-специалистов;
Аккредитованная ИТ-компания;
Команда работает в Московском часовом поясе;
Имеются как офисные сотрудники, так и удаленные.
3