Скрам – это тактический фреймворк для создания продуктов, при условии, что вы заранее определите, что стоит создавать. Но даже после успешной фазы подготовки продукта вы можете столкнуться с трудностями при создании нужных вещей правильным способом, если ваш продуктовый бэклог не поддерживает принцип «что посеешь, то и пожнешь».
Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
Бэклог продукта в соответствии с руководством по Скрам
Прежде всего, давайте посмотрим на текущее издание Скрам Гайда о назначении бэклога продукта:
Бэклог продукта – это пополняемый, упорядоченный список того, что необходимо для улучшения продукта. Это единственный источник работы, выполняемой Скрам-командой.
Элементы бэклога продукта, которые могут быть выполнены Скрам-командой в течение одного спринта, считаются готовыми для выбора на мероприятии по планированию спринта. Обычно они приобретают такую степень прозрачности после мероприятий по уточнению. Уточнение бэклога продукта – это акт разбивки и дальнейшего определения элементов бэклога продукта на более мелкие и точные элементы. Это постоянная деятельность по добавлению деталей, таких как описание, порядок и размер. Атрибуты часто меняются в зависимости от сферы деятельности.
Разработчики, которые будут выполнять работу, отвечают за определение оценки. Владелец продукта может влиять на разработчиков, помогая им понять и выбрать компромиссные варианты.
Немного про Скрам
Скрам, будучи тактическим фреймворком, хорош тем, что позволяет эффективно передавать подтверждённые гипотезы в руки клиентов, чтобы замкнуть цикл обучения, позволяя проверить первоначальное предположение и процесс принятия решения для создания инкремента, и впоследствии адаптировать подготовку к следующему спринту.
Скрам не очень хорош в формулировании гипотез и проведении экспериментов, их проверке или подмене, иначе называемых исследованием продукта. Оно не является тактикой, но представляет часть работы позиционирования команды для достижения успеха. Если вы посмотрите на диаграмму потока выше, то часть Скрам – тактика – находится в правой части, а часть исследования продукта – операции – в левой. Существует множество возможностей для работы с левой частью процесса, например, бережливый стартап, дизайн-мышление, дизайн-спринты, метод Lean UX, подход Dual-Track Agile и это лишь некоторые из них.
В любой момент времени Скрам-команде необходимо одновременно и непрерывно практиковать исследование продукта и поставку продукта (или разработку продукта). Однако эта необходимость не обязывает втискивать все элементы работы в бэклог продукта. Напротив, по опыту, Скрам-команды работают ниже своих возможностей, когда они не придерживаются строгого соблюдения ведения двух разных артефактов для обеих частей процесса:
1. Должен быть прозрачный артефакт для отслеживания идей, гипотез, экспериментов и результатов. (Мне нравится называть часть этого артефакта анти-продуктовый бэклог, живое хранилище запросов, которые Скрам-команда решает не рассматривать).
2. Второй артефакт – это, конечно же, бэклог продукта. Эффективная Скрам-команда прикладывает много усилий для поддержания этого артефакта в работоспособном состоянии. Бэклог продукта, пригодный к использованию, отражает непрерывные усилия Скрам-команды по исследованию продукта в целом – выработке обоснованного мнения о том, какая идея может быть ценной для клиентов, и постановке этих подтверждённых гипотез в соответствующие пункты бэклога продукта.
На этом этапе все члены Скрам-команды понимают, почему команда выбирает именно эту возможность, а не другие, что должны создать разработчики, как они этого добьются и, возможно, уже на этом этапе, кто будет над этим работать.
Как правило, объем бэклога продукта составляет 3-6 спринтов работы, и, учитывая, что владелец продукта упорядочивает элементы бэклога продукта по ценности, команда Скрам также хорошо понимает, когда они могут работать над этим.
Общие антипаттерны бэклога продукта
Несмотря на относительную простоту, процесс создания и уточнения бэклога продукта часто страдает от различных антипаттернов. Я выделил пять различных категорий антипаттернов для бэклога продукта:
1. Приоритизация через посредников: один или несколько стейкхолдеров определяет приоритеты бэклога продукта. (Сильной стороной Скрам является твёрдая позиция Владельца продукта. Владелец продукта – единственный человек, который решает, какие задачи станут элементами бэклога продукта. Следовательно, Владелец продукта также принимает решение об упорядочивании бэклога продукта. Лишите его этих полномочий, и Скрам превратится в довольно мощный водопадный процесс 2.0).
2. Перегрузка: бэклог продукта содержит больше элементов, чем Скрам-команда может выполнить за 3-6 спринтов. Эта практика, скорее всего, приведёт к напрасным усилиям: Вы будете дорабатывать рабочие элементы, которые разработчики никогда не превратят в инкременты. Более того, вкладывая все усилия заранее, вы можете стать жертвой заблуждения о невозвратных затратах, предоставляя меньше ценности, чем возможно).
3. Устаревшие запросы: бэклог продукта содержит элементы, к которым не обращались несколько недель или больше. (Обычно это длительность трёх-четырёх спринтов. Если владелец продукта накапливает элементы бэклога, возникает риск, что прежние элементы станут устаревшими, что сделает ранее вложенный труд Скрам-команды неактуальным).
4. Все детализировано и оценено: Все пункты бэклога продукта полностью детализированы и оценены. (Это слишком много предварительной работы и чревато неправильным распределением времени Скрам-команды. Уточнение элементов бэклога продукта является непрерывной работой только до того момента, когда Скрам-команда чувствует себя комфортно, превращая эти элементы в инкременты).
5. INVEST? Скрам-команда не применяет принцип INVEST к элементам бэклога. (Неспособность создать независимые, ценные и небольшие элементы работы увеличивает риск неудачи реализации во время спринта. Поэтому Скрам-команде рекомендуется инвестировать – без каламбура – в надлежащую практику уточнения бэклога продукта, чтобы решить возможные проблемы до начала работы).
6. Компонентно-ориентированные элементы: элементы бэклога продукта нарезаны по горизонтали на основе компонентов, а не по вертикали на основе сквозной функциональности. (Это может быть вызвано либо вашей организационной структурой, либо эффектом, называемым законом Конвея. В этом случае преодолейте этот организационный долг, перейдя к кросс-функциональным командам, чтобы улучшить способность Скрам-команды к выполнению задач. В противном случае Скрам-команде следует инвестировать в воркшоп по написанию лучших элементов бэклога продукта).
7. Отсутствие критериев приёмки: пункты бэклога продукта, которые нуждаются в дополнительных критериях приёмки, не имеют их списка. (Нет необходимости иметь все критерии приёмки готовыми в начале цикла уточнения, хотя они сделали бы задачу гораздо более доступной. Тем не менее, все элементы бэклога продукта должны соответствовать определению выполненной работы и, возможно, специфическим требованиям на уровне элемента работы. Если определение выполненного не обеспечивает последних, то необходимые теперь критерии приёмки должны быть результатом процесса уточнения).
8. Слишком подробные критерии приёмки: существуют элементы бэклога продукта с обширным списком критериев приёмки. (Это другая крайность: Владелец продукта охватывает каждый крайний случай без согласования с разработчиками. Как правило, трёх-пяти критериев приёмки более чем достаточно. Если вы считаете, что вам нужно больше критериев, это может указывать на то, что элемент работы слишком велик и нуждается в разделении).
9. 100% впрок: Скрам-команда создаёт бэклог продукта, охватывающий весь проект или продукт заранее, потому что считается, что объем выпуска ограничен. (Позвольте задать вопрос: как вы можете быть уверены в том, что знаете сегодня, что нужно предоставить через шесть месяцев, когда вы работаете над сложной, адаптивной проблемой? Разве невозможность предсказать будущее не является в первую очередь причиной того, что вы используете Скрам?)
10. Только имя: бэклог продукта содержит пункты, которые состоят не более чем из названия. (Создание шума путём добавления многочисленных “напоминаний” в бэклог, что затуманивает сигнал, который он должен давать, снижает способность скрам-команды создавать ценные инкременты для клиентов. Идеям не место в бэклоге продукта; они являются частью системы исследования продукта).
11. Нет исследований: бэклог продукта содержит мало или вообще не содержит спайков или ограниченных по времени исследовательских задач. (Этот эффект часто связан с тем, что Скрам-команда тратит слишком много времени на обсуждение будущих проблем вместо того, чтобы исследовать их с помощью спайков в рамках непрерывного процесса уточнения бэклога продукта).
Антипаттерны Владельца продукта
1. Хранилище идей: Владелец продукта использует бэклог продукта как хранилище идей и требований. (Большой бэклог продукта, вероятно, считается признаком “хорошей” Скрам-команды: вы полностью прозрачны, и это является доказательством вашей полезности для организации. Однако “занятость” не равна ценности для клиентов и организации. Дополнительный шум, создаваемый огромным количеством проблем, также может помешать выявлению ценных вещей. Наконец, размер бэклога продукта может оказывать эффект давления на заинтересованные стороны, поскольку они чувствуют себя перегруженными. Как следствие, раздутый идеями бэклог продукта может помешать критичному взаимодействию с ними).
2. Частично выделенный Владельца продукта: Владелец продукта не работает ежедневно над бэклогом продукта. (Бэклог продукта должен представлять собой наилучшее использование времени разработчиков в любой момент времени. Предположим, что обновление бэклога продукта происходит лишь время от времени, например, незадолго до начала планирования следующего спринта. Из-за отсутствия уточнения, скорее всего, много ценного останется за кадром. Ценность бэклога продукта в значительной степени обусловлена открытым обсуждением между Владельцем продукта и разработчиками.
В хорошей Скрам-команде разработчики постоянно оспаривают у Владельца продукта ценность предлагаемых элементов бэклога продукта. Такой подход, основанный на принципе “сдержек и противовесов”, снижает вероятность того, что Владелец продукта станет жертвой предубеждения предвзятости, тем самым снижая риск того, что Скрам-команда примет неверное инвестиционное решение при планировании следующего спринта. Как говорится: любите проблему клиента, а не своё решение).
3. Копирование: Владелец продукта создаёт элементы бэклога продукта, разбивая документы с требованиями, полученные от заинтересованных сторон, на более мелкие фрагменты. Уточнение элементов Бэклога продукта – это командная работа. Более того, использование таких методов, как шаблоны пользовательских историй, помогает всем понять “Зачем”, “Что” и “Как”.
4. Доминирующий Владелец продукта: Владелец продукта создаёт элементы бэклога продукта, предоставляя не только “Почему”, но и “Как” и “Что” (просто придерживайтесь руководства Скрам и его встроенных “сдержек и противовесов”: разработчики отвечают на вопрос “Как”: техническая реализация; команда разработки и Владелец продукта сотрудничают по вопросу “Что”: какой объем необходим для достижения желаемой цели?)
5. Автор пользовательских историй: Владелец продукта вкладывает слишком много времени в создание элементов Бэклога продукта, делая их слишком подробными. (Если элемент работы выглядит завершённым, разработчики могут не увидеть необходимости в дальнейшей проработке. Таким образом, “жирный” элемент Product Backlog снижает уровень вовлеченности команды, ставя под угрозу создание общего понимания. Кстати, этого не происходило в те времена, когда мы использовали индексные карточки, учитывая их физическое ограничение).
6. Владелец продукта “Я всё знаю”: Владелец продукта не привлекает заинтересованные стороны или экспертов в предметной области к процессу уточнения. (Владелец продукта, который считает себя всезнающим или является коммуникационным шлюзом, представляет собой риск для успеха Скрам-команды. Способные Скрам-команды в целом и владельцы продуктов в частности хорошо знают, когда нужно обратиться к другим людям, чтобы лучше понять суть вопроса).
Антипаттерны продуктового бэклога на уровне портфеля и дорожной карты продукта
1.Дорожная карта? Бэклог продукта не синхронизирован с дорожной картой продукта. (Бэклог продукта должен быть достаточно подробным для достижения текущей цели продукта. По моему опыту, для выполнения целей среднесрочного планирования часто может потребоваться до трёх-четырёх спринтов. За границами этого, в бэклоге стоит сосредоточиться на темах из дорожной карты продукта в общих чертах, указывая на предстоящую цель продукта, но не делая ничего слишком конкретного. Риск не реализации этих тем на данном этапе слишком высок. В этом отношении бэклог продукта отражает “скользящую” выборку дорожной карты продукта в любой момент времени).
2.Годичные дорожные карты: План портфеля организации, планы релизов или дорожные карты продуктов создаются раз в год заранее, и в течение этого времени к ним больше не обращаются. (Если бэклог продукта остаётся согласованным с этими планами, то это, вероятно, вводит водопадное планирование через чёрный ход. Agile планирование всегда является “непрерывным”, чтобы снизить риск неправильного распределения усилий на устаревшие планы. Этот вид “скользящего планирования” также применим к дорожным картам продуктов, которые полезно пересматривать как минимум каждые 6-12 недель, в зависимости от отрасли).
3.Секретные дорожные карты: Планирование портфеля, план выпуска или дорожная карта продукта не видны всем, кто участвует в создании инкремента продукта. (Если вы не знаете, куда идёте, любая дорога приведёт вас туда. Общая картина имеет решающее значение для успеха любой Скрам-команды. Она должна быть доступна всем, поскольку успех продукта – это командная игра, зависящий от идей, взглядов и навыков каждого члена команды и стейкхолдера).
4. Зыбкие цели: планирование портфеля, план выпуска или дорожная карта продукта не считаются достижимыми и правдоподобными теми, кто должен их выполнять. (Если это отражено в бэклоге продукта, то проработка рабочих элементов, скорее всего, будет напрасной).
Антипаттерны разработчиков
1.Покорная Скрам-команда: разработчики покорно выполняют все требования Владельца продукта. (Оспаривать у Владельца продукта, является ли его выбор рабочих элементов наилучшим использованием времени разработчиков – это самая благородная обязанность каждого члена команды: Почему мы это делаем? Скрам не работает без того, чтобы все соблюдали баланс, встроенный в структуру. Легко влюбиться в “своё решение”, а не в решение реальной проблемы клиента. Если разработчики просто делают все, что проталкивает владелец продукта, общая ценность, созданная Скрам-командой, скорее всего, будет ниже её потенциала. Вот почему вам нужны миссионеры в вашей команде, а не просто наёмники).
2. Какой ещё технический долг? Разработчики не требуют достаточного времени для устранения технического долга и дефектов, для сохранения стандарта качества продукта. Вместо этого они полностью погружаются в фабрику фичей, выпуская одну за другой. (Моё эмпирическое правило гласит, что разработчики должны рассматривать возможность выделения до 20% своего времени на исправление дефектов и рефакторинг кодовой базы. Высококачественный технический стек является основой для того, чтобы Скрам-команда могла адаптировать следующие шаги к полученным урокам и последним тенденциям рынка. Техническое совершенство является предпосылкой любой формы гибкости бизнеса; сохранение этого состояния – непрерывный процесс, требующий постоянных и значительных инвестиций).
3. Никакого простоя: Разработчики не требуют от владельца продукта 20% времени простоя – или незапланированных мощностей. (Это пересекается с планированием спринта, созданием целей спринта и способностью команды прогнозировать. Поднять этот вопрос никогда не рано. Если потенциал команды всегда используется на 100 %, её производительность будет снижаться. Все будут сосредоточены на выполнении своих задач. Будет меньше времени на поддержку членов команды или на работу в паре. Мелкие проблемы больше не будут решаться немедленно. И, в конечном счёте, отношение “я занят” приведёт к тому, что все члены команды перестанут понимать, зачем они делают то, что делают).
Антипаттерны скрам-команды
1.Зачем привлекать Скрам-команду? Владелец продукта не вовлекает всю Скрам-команду в процесс уточнения бэклога продукта и вместо этого полагается только на “ведущего инженера” и дизайнера. Более того, разработчиков устраивает такой подход, поскольку он позволяет им писать больше кода, что они предпочитают, а не выяснять, что стоит создавать. (Когда пытаешься решить сложную проблему, нет экспертов, но есть много конкурирующих идей. Поэтому ограничение активных участников деятельности по уточнению несколькими членами команды вместо всей Скрам-команды увеличивает риск стать жертвой предубеждения самоуверенности, поскольку разнообразие мнений искусственно ограничивается).
2. Нет времени на уточнение: Скрам-команда не проводит достаточного количества сессий по уточнению бэклога продукта, что приводит к некачественному бэклогу продукта. (Руководство по Скрам 2017 изначально рекомендовало тратить до 10 % времени Скрам-команды на уточнение бэклога продукта. Это разумное бизнес-решение: нет ничего дороже, чем плохо разработанная функциональность, приносящая мало пользы или вообще не приносящая пользы).
3. Слишком много уточнений: Скрам-команда проводит слишком много сессий по уточнению, в результате чего получается слишком подробный бэклог продукта. (Слишком много проработок тоже вредно для здоровья. Наступает момент, когда предельная отдача от дополнительных усилий по уточнению равна нулю или, возможно, даже отрицательна – подумайте об усталости мозга. Единственный способ для Скрам-команды понять, верна ли предыдущая проверка гипотез, лежащих в основе новой функциональности – это разработать и донести это решение. Нет никакого способа выяснить это за столом переговоров, дорабатывая и бесконечно обсуждая вопрос).
Заключение
Даже если вы успешно определили, что стоит реализовать в дальнейшем, ваш бэклог продукта и процесс его уточнения, скорее всего можно улучшить. Просто донесите это до команды и рассмотрите возможные антипаттерны бэклога продукта на следующей ретроспективе. По моему опыту, это самый простой способ повысить эффективность работы Скрам-команды и, соответственно, её авторитет среди стейкхолдеров и клиентов.
