kazminaviktoriya1
Перейти в профиль
Выйти из профиля
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Спринт 9/18: Agile-практики → Тема 5/7: DEEP-критерии бэклога продукта → Урок 2/2
Айсберг бэклога продукта
В прошлых уроках спринта вы познакомились с DEEP-критериями бэклога продукта. В этом уроке вы закрепите понимание этих критериев с помощью метафоры айсберга.
Для начала предлагаем освежить знания. Выберите DEEP-критерий, которым руководствуется системный аналитик в каждой описанной ситуации.
Получив обратную связь от пользователей, СА меняет порядок элементов бэклога, перенося самые важные на текущий момент элементы наверх.
Приоритизированный
Бэклог продукта должен быть приоритизированным, а команда разработки должна реализовывать его элементы в строгом соответствии с приоритетами. Это нужно для того, чтобы точно успеть выполнить самую важную работу в каждой итерации.
СА организует встречу с командой разработки для обсуждения новых элементов бэклога продукта и определения их размера.
Оценённый
Бэклог продукта должен быть оценённым, потому что он используется для планирования проекта и итераций.
Реализация элемента бэклога начнётся только через несколько итераций, поэтому СА записывает в таск-менеджер только название элемента.
Оптимально детализированный
Бэклог продукта должен быть оптимально детализированным, потому что в ходе разработки ПО возникнут новые идеи, а от старых идей откажутся. Системный аналитик не уточняет детали элементов, реализация которых начнётся нескоро.
Во время обсуждения бэклога продукта СА удаляет из него неактуальные элементы.
Изменчивый
Бэклог продукта должен содержать только ту работу, которую точно нужно сделать команде разработки, только в этом случае прогнозы сроков реализации будут более точными.
Айсберг бэклога продукта
Автор DEEP-критериев Майк Кон предложил метафору айсберга, которая отражает состав бэклога продукта, соответствующего этим критериям.
Представьте себе айсберг — большую глыбу льда, плывущую в глубоком синем море. Вы видите только заострённый пик айсберга, возвышающийся над поверхностью воды. А большая его часть скрыта от ваших глаз.
Представили? А теперь представим в виде айсберга бэклог продукта и мысленно разделим его на четыре части:
- Верхушка.
- Средняя часть.
- Подножие.
- Подводная часть.
Чем ближе элемент к верхушке айсберга, тем выше его приоритет, тем больше о нём известно команде разработки и тем больше он ей понятен. И наоборот: чем ближе к поверхности воды находятся элементы, тем ниже их приоритет и тем больше связанной с ними неопределённости.
В подводной части скрываются ещё неизвестные команде разработки элементы. Их суть и приоритет непредсказуемы.
В каждой части айсберга расположены элементы бэклога продукта с примерно одинаковыми оценками размера.
На верхушке находятся небольшие элементы, для реализации которых команде разработки понадобится несколько дней. Команда может включать в итерацию множество таких элементов.
В середине видимой части айсберга расположены элементы, размер которых больше тех, что на пике, но меньше тех, что находятся в нижней части айсберга. Элементы здесь имеют слишком большой размер, чтобы команда разработки могла успеть их реализовать в течение одной итерации.
У подножия айсберга находятся элементы большого размера. На их реализацию команде разработки нужно несколько итераций.
Размер элементов, расположенных в подводной части, команде разработки неизвестен.
Верхушка
Верхушку айсберга образуют небольшие элементы бэклога продукта. Это самые важные на текущий момент элементы. Также они более понятны команде разработки и более детально описаны.
В уроке «INVEST-критерии» вы узнали, что истории должны быть масштабируемыми (Sized Appropriately). Они должны иметь размер, подходящий для использования на разных этапах разработки и для разных целей. Истории бывают высокого, среднего и низкого уровня.
Другие категории элементов бэклога также могут иметь разный масштаб. Части айсберга отражают эти уровни.
На верхушке айсберга расположены элементы низкого уровня, подходящие для реализации командой разработки в рамках одной или нескольких итераций. Это должны быть элементы небольшого размера, чтобы команда разработки успела реализовать несколько из них в течение короткой итерации.
Команда разработки включает в бэклог итерации только элементы, расположенные на верхушке айсберга. Когда составляется бэклог итерации, верхушка как будто «срезается». После этого айсберг бэклога продукта напоминает скорее плато.
Рассмотрим детали этой метафоры на примере разработки уже знакомого вам клиентского приложения банка. Предположим, что после выполнения первой итерации в бэклоге продукта остались следующие функции:
Эти функции расположены в бэклоге продукта в порядке снижения приоритета.
До начала следующей итерации системному аналитику следует озаботиться возвращением айсберга в первоначальную форму. Чтобы это сделать, ему нужно совместно с пользователями и командой разработки обсудить расположенные в средней части айсберга элементы и вертикально декомпозировать их.
Теперь рассмотрим среднюю часть айсберга бэклога продукта.
Средняя часть
Середину видимой части айсберга образуют элементы среднего размера. Это менее важные на текущий момент элементы бэклога, которые команда разработки планирует включить в следующие итерации. Они менее понятны команде разработки и содержат меньше деталей, чем элементы верхушки айсберга.
Посмотрите на элементы среднего уровня, направленные на достижение целей заинтересованных лиц. Они слишком большого размера, чтобы команда разработки могла включить их в итерацию без вертикальной декомпозиции.
Например, в средней части айсберга расположена функция «Выписка по счёту клиента».
Обсудив функцию и оценив её размер, команда разработки поняла, что не сможет реализовать её в течение одной итерации. Поэтому команда разработки решила вертикально декомпозировать эту функцию, используя технику разбивки по группам элементов данных:
- Номер.
- Дата.
- Информация о клиенте.
- Информация о счёте и остатке
- Факсимиле.
Команда приняла решение о разбивке по группам данных выписки, потому что у них разные источники — различные системы банка. Например, информация о клиенте хранится в CRM-системе, а логотип банка — в дизайн-системе.
Все эти элементы после декомпозиции будут соответствовать INVEST-критериям, в частности критерию «Ценный» (Valuable). Вы уже знаете, что определить ценность элемента помогает вопрос: «Можно ли вообще не реализовывать его?» Выписка должна включать все перечисленные выше группы элементов данных, иначе клиенты не смогут её использовать.
Несмотря на то что выписка может быть предоставлена клиентам только после реализации всех вышеперечисленных элементов, команда разработки может в конце итерации продемонстрировать заказчикам их часть. Благодаря этому получится оперативно учесть обратную связь от заказчика.
Например, заказчик может вспомнить, что выписка по счёту должна формироваться ещё и на английском языке. Эта обратная связь будет влиять на другие элементы бэклога продукта, относящиеся к выписке.
Также, увидев реализованную часть выписки, заказчик может обратить внимание на формат даты выписки и попросить команду разработки заменить «14.01.2022» на «14 января 2022 года».
В результате вертикальной декомпозиции команда разработки добавила в бэклог продукта элементы небольшого размера, восстановившие заострённый пик айсберга:
Подножие
У подножия видимой части айсберга расположены элементы большого размера. Это элементы бэклога продукта, которые команда разработки планирует реализовать через несколько итераций. Они содержат ещё меньше деталей, чем элементы средней части айсберга.
Посмотрите на элементы высокого уровня. Они сформулированы общо, без углубления в детали.
Например, у подножия айсберга бэклога продукта расположена функция «Выписки по кредиту». Заказчик попросил повысить её приоритет, и команда разработки вертикально декомпозировала эту функцию, чтобы переместить её в среднюю часть айсберга. В результате обсуждения функции команда разработки выяснила, что к выпискам по кредиту относятся разные документы:
- График платежей.
- Справка о задолженности по кредиту.
- Справка об уплаченных процентах по кредиту.
Элемент бэклога «Выписки по кредиту» был заменён входящими в него документами. Таким образом, после вертикальной декомпозиции и изменения приоритетов бэклог продукта стал выглядеть так:
Подводная часть
Тёмные воды моря скрывают будущие элементы бэклога продукта от команды разработки и даже заказчиков и пользователей, но вполне могут в какой-то момент всплыть на поверхность. Новые элементы могут быть любого уровня: низкого, среднего или высокого.
Например, команда разработки могла вспомнить, что забыла добавить элемент бэклога продукта для оформления выписки по счёту (логотипа банка и других элементов фирменного стиля). Заказчик мог вспомнить, что в ближайших итерациях нужно автоматизировать формирование справки по арестам и взысканиям, а после этого команде разработки нужно будет заняться справками для государственных органов.
После добавления этих элементов бэклог продукта стал выглядеть так:
Кроме разных уровней, новые элементы могут иметь разный приоритет. Например, может появиться элемент высокого уровня, который должен оказаться сначала у подножия айсберга. Но появляются новые обстоятельства, из-за которых реализовать его нужно в ближайшей итерации. Такое случается, например, в случае публикации нового нормативного правового акта (НПА), который влияет на работу компании.
В этом случае команде разработки нужно как можно скорее обсудить новый элемент, чтобы он стал более понятен и содержал больше деталей. Ей также нужно вертикально декомпозировать его таким образом, чтобы размер получившихся элементов соответствовал верхушке айсберга.
Эпики и темы
Команде удобнее работать с бэклогом продукта, когда она использует эпики и объединяет его элементы в темы.
Эпик
Функции большого размера называют эпиками. Они образуют подножие айсберга.
Эпик (Epic) — это функция большого размера с меньшим количеством деталей.
Если элемент бэклога продукта называется эпиком, то команда разработки будет понимать, что ей нужно обсудить его детали и вертикально декомпозировать его.
Например, к эпикам относятся:
- Выписки по депозиту.
- Справки для государственных органов.
Название функции подразумевает, что заказчик ожидает несколько выписок по депозиту и несколько справок для государственных органов.
Выписки по депозиту и справки — это функции большого размера. Они содержат мало деталей, так как команде разработки пока неизвестно, какие именно выписки и справки ожидает заказчик. При этом команде разработки рано обсуждать эти эпики, потому что они пока менее важные, чем остальные элементы бэклога продукта.
Тема
Эпики и другие элементы бэклога могут быть объединены в тему.
Тема (Theme) — это набор связанных по определённому принципу элементов бэклога.
Их может объединять бизнес-процесс, или они все могут быть необходимы для достижения цели.
Темой также может стать НПА, который требует реализации множества элементов бэклога в разное время. Например, предоставление банком справок по арестам и взысканиям или справок для государственных органов вполне может являться требованием НПА.
В изначальном представлении эпик был всего лишь историей большого размера, которая располагается у подножия айсберга. Но в некоторых таск-менеджерах эпик представляет собой набор элементов бэклога. Поэтому тему можно заменить на «набор связанных историй», а эпики называть «большими функциями».
Добавление в элементы бэклога названия темы даёт команде разработки больше информации об этих элементах. Зная тему, к которой относится элемент, системный аналитик может сократить его описание, а используемые в нём термины будут понятнее команде разработки.
Например, команда может объединить одной темой «Выписка по счёту» расположенные на пике айсберга элементы и сократить их описание. Таким образом, команде разработки станет проще воспринимать написанное. Она будет лучше понимать важность реализации элемента и будет внимательнее к нему относиться.
Оценка размера эпиков и тем
Любой элемент бэклога продукта, в том числе эпики и темы, нужно оценить по размеру независимо от того, в какой части айсберга он находится. Оценка размера эпика может помочь команде разработки спрогнозировать количество итераций, которые ей понадобятся для его реализации. Оценка размера темы поможет заказчику понять, какая часть работы команды приходится на реализацию всей темы.
Чем ниже в бэклоге продукта располагается элемент, тем меньше точность его оценки. Такая ситуация неизбежна, потому что не все детали таких элементов известны в момент оценки. Эту особенность стоит учитывать, чтобы не тратить слишком много времени на оценку размера элементов с низким приоритетом.
Легче всего оценивать величины в пределах одного порядка. Например, вы можете достаточно точно оценить относительные размеры мандарина и грейпфрута. Результаты оценки будут намного менее точными, если вас попросят оценить относительные размеры маленького лесного орешка и огромной тыквы.
Важно подбирать для сравнения элементы похожего размера. Команда разработки оценивает эпики и темы в Story Points. Она представляет оценки числами в пределах одного порядка — например, используя числа 13, 20, 40 и 100. Тогда как размер функций и других категорий элементов бэклога она оценивает, используя числа 1, 2, 3, 5 и 8.
Выберите, в какой части айсберга бэклога продукта должны располагаться описанные элементы.
Функция, которую команда разработки сможет реализовать за несколько итераций
Средняя часть айсберга
Если команда разработки не может реализовать функцию за одну итерацию, такая функция требует вертикальной декомпозиции. Полученные функции меньшего размера команда может переместить в верхнюю часть айсберга.
Декомпозированные элементы бэклога продукта с наивысшим приоритетом
Верхушка айсберга
Элементы небольшого размера, которые имеют высокий приоритет, располагаются в верхней части айсберга. Такие элементы готовы к тому, чтобы попасть в бэклог итерации.
Функции большого размера и с наименьшим количеством деталей
Подножие айсберга
Минимально детализированная функция — это эпик. Эпики располагаются у подножия айсберга.
Все эти элементы могут оказаться и в подводной части айсберга, потому что их детали ещё неизвестны команде. Там могут находиться элементы любого размера и важности, и только когда они окажутся на поверхности, команда сможет их оценить.
Product Backlog Refinement
Команда разработки должна стремиться держать бэклог продукта в актуальном состоянии. Для этого члены команды регулярно встречаются для проведения Product Backlog Refinement.
Product Backlog Refinement, PBR (уточнение бэклога продукта) — это непрекращающийся процесс работы над бэклогом продукта с целью приведения его в соответствие DEEP-критериям.
На встречах PBR команда разработки:
- Обсуждает бэклог продукта.
- Добавляет детали в описание его элементов.
- Оценивает размер элементов.
- Вертикально декомпозирует элементы.
- Добавляет, изменяет и удаляет элементы.
На встречах должна присутствовать вся команда разработки. Системный аналитик может также пригласить заказчиков, пользователей и других заинтересованных лиц.
Не стоит пытаться за одну встречу привести весь бэклог продукта в идеальный вид. В первую очередь усилия участников должны быть сосредоточены на тех элементах, которые расположены на верхушке и в средней части айсберга.
Командам разработки рекомендуется посвящать PBR около 10% времени итерации. Системному аналитику стоит следить за тем, чтобы бэклог продукта всегда соответствовал DEEP-критериям, и своевременно организовывать встречи для проведения PBR.
Подведём итоги
Айсберг — это метафора бэклога продукта, соответствующего DEEP-критериям.
Айсберг бэклога продукта состоит из четырёх частей:
- Верхушки.
- Средней части.
- Подножия.
- Подводной части.
Чем ближе элемент к верхушке, тем:
- Выше его приоритет.
- Он более понятен.
- Меньше его размер.
И наоборот, чем ближе элемент к поверхности воды, тем:
- Ниже его приоритет.
- Он менее понятен.
- Больше его размер.
В подводной части скрываются ещё неизвестные команде разработки элементы. Их приоритет, суть и размер непредсказуемы.
Команда разработки может включить в бэклог продукта эпики и темы.
Эпик (Epic) — это функция большого размера.
Эпики и другие элементы бэклога продукта могут входить в тему.
Тема (Theme) — это набор связанных по определённому принципу элементов бэклога.
Размер эпиков и тем, как правило, оценивают в 13, 20, 40, 100 Story Points. Размер функций и других категорий элементов бэклога оценивают в 1, 2, 3, 5 и 8 Story Points.
Регулярные встречи для проведения Product Backlog Refinement (PBR) помогают поддерживать соответствие бэклога продукта DEEP-критериям.
Чат поддержки