kazminaviktoriya1
Перейти в профиль
Выйти из профиля
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Бэклог продукта
В этом уроке вы узнаете, что такое бэклог продукта, из каких элементов он состоит и каким критериям он должен соответствовать. Вы также узнаете, что такое бэклог итерации и чем он отличается от бэклога продукта.
Что такое бэклог продукта
Бэклог продукта похож на стопку бумаг на столе офисного клерка. В этой стопке — вся его работа на многие дни вперёд. Наверху стопки лежат самые важные на данный момент бумаги, а внизу — менее важные.
Каждый день работник берёт лист бумаги с верхушки стопки, заполняет его, передаёт на проверку коллеге и берёт следующий лист.
Иногда коллега приносит ему новую стопку бумаг. Они вместе обсуждают срочность их обработки и кладут часть менее важных бумаг под низ существующей стопки, часть более важных — в середину, а отдельные, самые важные, кладут наверх. И так происходит день за днём.
Команда разработки работает с бэклогом продукта так же, как работник офиса — со стопкой бумаг. В бэклоге продукта — вся работа команды. В каждой итерации она выполняет самую важную работу и передаёт результат пользователям.
Иногда пользователи просят команду выполнить новую работу. Они вместе обсуждают её важность и определяют подходящее для неё место в бэклоге продукта.
Бэклог продукта (Product Backlog) — это список всех работ, которые команде разработки предстоит выполнить для реализации ПО. Он используется для планирования работы над проектом, оценки сроков и стоимости реализации.
Что входит в бэклог продукта
В спринте «Проектирование пользовательских интерфейсов» вы узнали, что продукт включает в себя не только использование ПО, но и, например, разработку рекламных кампаний, проектирование наружной рекламы, маркетинговые исследования, опросы удовлетворённости клиентов и прочее.
В гибкой модели разработки бэклог продукта часто включает в себя только ту работу, которая связана с реализацией ПО. Команда разработки записывает туда реализацию требований от пользователей, добавление новых функций и улучшение существующих.
Допустим, пользователи обнаружили в ПО ошибки, а команде недостаёт знаний по определённым технологиям и опыта работы с ними. Команде может потребоваться заново переписать часть кода или изменить архитектуру, например, чтобы ПО могло работать с возросшим количеством пользователей. Все эти задачи команда вносит в бэклог продукта в своём таск-менеджере.
Таким образом, в бэклог продукта входят:
- Функции.
- Дефекты (баги).
- Техническая работа.
- Получение знаний.
Функции
Функции — это характеристики ПО и возможности, которые пользователи ожидают получить и которые помогут им в достижении целей.
Источником функций для бэклога продукта выступают пользователи.
Например, функциями мобильного приложения для прослушивания музыки могут быть добавление понравившихся треков в избранное, возможность делиться списком избранных через социальные сети и так далее.
Как правило, функции в бэклоге продукта системный аналитик описывает в виде:
- Пользовательских историй (User Story).
- Историй о работе (Job Story).
Дефекты
Дефекты, или баги, — это обнаруженные в ПО проблемы, которые пользователи хотят устранить.
Например, в приложении для прослушивания музыки дефект проявляется, когда в избранное добавляют 999-й трек. Команда разработки может исправить баг сразу, если он важный, а может отложить в бэклог проекта. Важность дефекта команда определяет самостоятельно или совместно с пользователями.
Источниками таких элементов бэклога выступают пользователи, обнаружившие дефект при использовании ПО, или члены команды, например тестировщики и системные аналитики.
Техническая работа
Техническая работа — это работа, скрытая от пользователей, цель которой — упростить внесение изменений в ПО.
В отличие от функций, техническая работа не приносит пользователям моментальной пользы. Но она важна для команды, так как упрощает реализацию функций и исправление дефектов, а значит, увеличивает темп работы.
Источником таких элементов бэклога выступает команда разработки.
Например, разработчики предлагают пересмотреть часть архитектуры или полностью переписать её программный код, чтобы упростить дальнейшее внесение изменений или улучшить характеристики ПО, скажем быстродействие.
Получение знаний
Получение знаний — это работа, также скрытая от пользователей, цель которой — получить новые знания о том, как реализовать функцию.
Допустим, команда хочет проверить свои предположения — для этого она создаёт прототип ПО, проводит эксперимент с новой технологией, оценивает разные варианты реализации функций.
Источником таких элементов бэклога тоже выступает команда разработки. Она может осознать потребность в знаниях, если ожидаемая пользователями функция должна быть разработана с помощью недавно появившихся технологий.
Например, пользователи хотят использовать возможности приложения для прослушивания музыки с помощью «силы мысли». Команда разработки раньше не работала над нейроинтерфейсами, поэтому они могут включить в бэклог множество элементов, направленных на получение знаний об этой технологии. Не обладая этими знаниями, команда не сможет оценить объём функции, а значит, и назвать пользователям сроки её реализации.
Такой элемент бэклога называют спайком (Spike).
Соотношение элементов
Обычно в бэклоге больше функций, чем других категорий элементов. Дефекты встречаются значительно реже.
Но бывает и так, что дефектов в бэклоге больше, чем функций. Например, 150 дефектов и 30 функций. В таком случае команде разработки стоит бросить все силы на то, чтобы скорее исправить дефекты и сбалансировать бэклог продукта.
Технической работы и спайков будет немного. Дело не в том, что эта работа неважна, напротив, это неотъемлемая часть процесса разработки ПО. Просто эта работа обычно выполняется сразу после добавления в бэклог. Команда не будет включать туда получение знаний, которые потребуются только через год. Если команда включает в бэклог продукта техническую работу или получение знаний, она рассчитывает выполнить её в ближайших итерациях.
Ведите список работ в одном месте
Системному аналитику следует вносить все работы в таск-менеджер, где команда разработки ведёт свой бэклог продукта. Он должен быть единственным источником работы, которую команде необходимо выполнить для реализации ПО.
Случается, что часть элементов бэклога описана не только в таск-менеджере, но и в электронной почте, мессенджере, документах, а часть не описана вовсе и есть лишь в голове у системного аналитика. Это мешает команде понять объём предстоящей работы, а значит, и планировать сроки её выполнения.
К тому же команда может не сделать того, что было действительно важно пользователям, потому что системный аналитик описал нужные им функции в сообщении, которое затерялось в переписке.
Наконец, членам команды просто неудобно переключаться между разными источниками рабочих задач.
Системный аналитик должен убедиться, что вся работа для команды описана в одном месте — в таск-менеджере в виде элементов бэклога продукта.
Прочитайте описания элементов бэклога и определите, о какой категории элементов идёт речь.
Реализация возможностей ПО, необходимых для достижения целей пользователей.
Функция
Чтобы ПО соответствовало ожиданиям пользователей, команда разработки реализует важные для них функции.
Работа, направленная на упрощение реализации функций и исправление дефектов.
Техническая работа
Чтобы команда разработки быстрее разбирала бэклог продукта, она выполняет техническую работу.
Отклонения от ожидаемого пользователями поведения ПО.
Дефект
Чтобы ожидаемые функции работали корректно, команда разработки исправляет дефекты ПО.
Работа, направленная на поиск вариантов реализации функций.
Получение знаний
Чтобы команда могла оценить объём функции и назвать пользователям сроки её реализации, она выполняет работу, направленную на получение знаний.
От документов к обсуждению
Бэклог продукта заменяет традиционные документы с требованиями, такие как спецификация требований к ПО. Его появление в IT-индустрии символизирует перенос акцента с документов на обсуждение.
Джефф Паттон (Jeff Patton), автор книги «Пользовательские истории. Искусство гибкой разработки ПО», пишет:
Огромное количество людей до сих пор верит, что есть некий идеальный способ составлять документы. Поэтому они думают, что, когда люди читают документ и у них возникают некие разногласия, это происходит лишь из-за небрежности автора или читателя. На самом деле ни то ни другое не верно.Правильный ответ: просто не занимайтесь документами. Перестаньте пытаться составлять идеальные документы.Возьмите и напишите что-нибудь, неважно как. Затем проведите эффективное обсуждение с использованием и слов, и картинок, чтобы прийти к общему мнению.
Документы важны и в отдельных случаях незаменимы. Нет ничего плохого в том, чтобы записывать информацию. Но некоторые команды разработки слишком сильно полагаются на письменную коммуникацию и слишком мало внимания уделяют устной.
В гибкой модели системный аналитик может по-прежнему составлять документы. Он делает это не во время подготовки к реализации ПО, а после. Он описывает результаты реализации — чтобы сохранить знания о ПО, например, если потребуется предоставить компании документацию проекта.
DEEP-критерии бэклога продукта
Бэклог продукта должен быть оптимально детализированным, оценённым, постоянно изменяющимся и отсортированным по важности для пользователей. Эти характеристики называют DEEP-критериями бэклога:
- Detailed Appropriately — оптимально детализированный.
- Estimated — оценённый.
- Emergent — изменчивый.
- Prioritized — приоритизированный.
Акроним DEEP придумал Майк Кон (Mike Cohn), который является одним из основателей Scrum Alliance.
Оптимально детализированный
В гибкой модели СА учитывает неопределённость, связанную с продуктом, и знает, что в ходе разработки пользователи неизбежно предложат новые функции и откажутся от старых.
Системный аналитик не уточняет детали элементов бэклога, реализация которых начнётся нескоро, — достаточно описать их в таск-менеджере так, чтобы команда разработки могла отличить их друг от друга. Например, он записывает только название элемента. Так СА тратит меньше сил на описание несрочных задач и экономит время пользователей и команды разработки на их обсуждении.
При этом системный аналитик добавляет больше деталей в элементы бэклога, расположенные наверху. В каждой итерации команда реализует часть верхних элементов бэклога и передаёт результат пользователям.
Таким образом, чем выше стоит элемент в бэклоге продукта, тем раньше команда приступит к его реализации и тем больше ей должно быть о нём известно. Чем ниже стоит элемент, тем позже его реализуют и тем меньше деталей он должен содержать.
Системному аналитику стоит убедиться, что элементы бэклога, которые будут реализованы в текущей итерации, более понятны команде разработки и содержат больше деталей, чем элементы, которые предстоит реализовать в последующих итерациях.
Оценённый
Команда разработки оценивает размер бэклога продукта, чтобы ответить на важные для любого проекта вопросы:
- Когда команда разработки завершит реализацию?
- Сколько будет стоить реализация?
Пользователям важно понимать, когда они смогут протестировать реализованные функции. А заказчики могут на основании сроков определить стоимость реализации бэклога продукта.
Стоимость влияет на достижение целей заказчиков, то есть на их бизнес-требования. Если стоимость превысит ценность от реализации функций, заказчики могут завершить проект досрочно.
Системный аналитик следит за тем, чтобы элементы бэклога продукта были оценены командой разработки. Определять сроки реализации бэклога вы научитесь в этом спринте.
Изменчивый
Системный аналитик и команда разработки неизбежно меняют состав элементов бэклога по мере того, как узнают больше о пользователях и их ожиданиях, находят дефекты, сталкиваются с новыми для них технологиями и обнаруживают потребность в новых знаниях.
Бэклог продукта должен находиться в актуальном состоянии, то есть содержать только ту работу, которую точно нужно сделать команде разработки. Это помогает команде предоставлять пользователям и организации более точные прогнозы сроков реализации бэклога.
Системный аналитик поддерживает актуальность бэклога продукта, своевременно добавляя и удаляя элементы.
Чтобы системному аналитику не было мучительно больно удалять подробно описанные элементы, стоит помнить про оптимальную детализацию: не добавлять детали требований в элементы, к реализации которых команда приступит только в будущих итерациях.
Приоритизированный
Элементы бэклога продукта должны быть отсортированы в порядке убывания важности для пользователей или команды разработки. Самые важные на данный момент элементы располагаются наверху, менее важные — внизу.
Пользователи и команда разработки совместно определяют приоритеты элементов бэклога, а затем команда реализует их в строгом соответствии с этими приоритетами.
Пользователям важнее всего функции ПО и дефекты, а команде — техническая работа и получение знаний, о которых пользователи не задумываются. Команда разработки объясняет пользователям важность технической работы или получения знаний и возможные последствия для работоспособности функций ПО. Так пользователям и команде проще соблюдать баланс реализованных элементов бэклога.
Системный аналитик следит за тем, чтобы порядок элементов соответствовал их приоритету для пользователей или команды разработки.
Соотнесите DEEP-критерий бэклога продукта и его назначение.
Эта характеристика помогает команде разработки экономить время на описании и обсуждении элементов.
Оптимально детализированный
Системный аналитик должен убедиться, что элементы бэклога продукта, которые будут реализованы в текущей итерации, более понятны команде разработки и содержат больше деталей, чем элементы, которые предстоит реализовать в последующих итерациях.
Эта характеристика помогает команде разработки спрогнозировать сроки и стоимость разработки ПО.
Оценённый
Системный аналитик должен следить за тем, чтобы элементы бэклога продукта были оценены командой разработки.
Эта характеристика помогает команде разработки предоставлять пользователям и организации более точные прогнозы сроков реализации бэклога.
Изменчивый
Системный аналитик должен поддерживать бэклог продукта в актуальном состоянии.
Эта характеристика помогает реализовывать в первую очередь самые важные для пользователей или команды разработки элементы бэклога.
Приоритизированный
Системный аналитик должен следить за тем, чтобы порядок элементов соответствовал их приоритету для пользователей или команды разработки.
Бэклог итерации
Кроме бэклога продукта, есть бэклог итерации или спринта. Спринт — это всего лишь другое название итерации, свойственное подходу Scrum.
Бэклог итерации — это план действий для реализации элементов бэклога продукта, который команда разработки предполагает выполнить в итерации.
Итерация — шаг на пути к реализации ПО. Иными словами, пройдя несколько итераций, команда разработки завершает реализацию всех ожидаемых пользователями функций ПО.
Бэклог итерации состоит из:
- Нескольких элементов бэклога продукта.
- Всех задач, которые нужно выполнить для реализации этих элементов.
Команда включает в бэклог итерации самые важные на данный момент элементы из бэклога продукта, учитывая при этом темп реализации. То есть только элементы, расположенные наверху бэклога, и только те из них, которые команда предполагает реализовать во время итерации. Своё предположение команда основывает на темпе реализации прошлых итераций.
Также в бэклог итерации команда включает план действий по реализации каждого элемента. То есть добавляет к элементу задачи, необходимые для его реализации.
Задача — это работа над элементом бэклога продукта, которую распределяют между собой члены команды разработки.
Например, в бэклог итерации можно добавить разработку прототипа экрана, реализацию экрана, реализацию таблицы базы данных, тестирование экрана, описание результатов в документации и другие элементы.
В составлении бэклога итерации участвует вся команда разработки. Системный аналитик помогает команде, отвечая на вопросы участников о деталях требований.
Выберите, какие описания соответствуют бэклогу продукта, а какие — бэклогу итерации.
Подведём итоги
Бэклог продукта (Product Backlog) — это список всех работ, которые команде разработки предстоит выполнить для реализации продукта. Он используется для планирования работы над проектом, оценки сроков и стоимости реализации.
Бэклог продукта состоит из четырёх категорий элементов:
- Функции.
- Дефекты (баги).
- Техническая работа.
- Получение знаний.
Он должен соответствовать DEEP-критериям:
- Detailed Appropriately — оптимально детализированный.
- Estimated — оценённый.
- Emergent — изменчивый.
- Prioritized — приоритизированный.
Бэклог продукта должен быть единственным источником задач для команды разработки. Системному аналитику стоит убедиться, что вся предстоящая работа описана в одном месте — в таск-менеджере в виде элементов бэклога продукта.
Бэклог итерации — это план действий для реализации элементов бэклога продукта, который команда разработки предполагает выполнить в итерации.
Бэклог итерации состоит из:
- Нескольких элементов бэклога продукта.
- Всех задач, необходимых для реализации этих элементов.
Задача — это работа над элементом бэклога продукта, которую распределяют между собой члены команды разработки.
Системный аналитик помогает команде составлять бэклог итерации, отвечая на вопросы участников о деталях требований.
Чат поддержки