новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts
новый проект: журнал Unusual Concepts

Какжить,еслиБэклогПродуктапохожна винегрет

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

Недавно я заметил закономерность: если команда не может сформулировать Цель Спринта, нужно смотреть на их Бэклог Продукта. И, как правило, он похож на мое любимое блюдо, винегрет. Найти смысл в винегрете — непростая задача 🙂
Бэклог продукта

Со временем отдельные случаи превратились в паттерн и я осознал: Цель Спринта является одним из индикаторов здоровья Бэклога Продукта, потому что именно она объединяет смыслом элементы Бэклога Продукта и служит основанием для командной работы. Сам Бэклог Продукта ультимативно определяет успех продукта, это генеральный план для Скрам-команды.

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

Как понять, что ваш Бэклог — винегрет

Я выделил четыре маркера, которые помогут оценить качество Бэклога продукта.
Проверьте себя:

Если найдете у себя хотя бы два — это винегрет. И я знаю, что с этим делать.

Что делать с винегретным Бэклогом Продукта

Мой опыт подсказывает, что большая часть проблем с Бэклогом Продукта решается, если прокачать Владельца Продукта, Скрам-команду и видение Продукта, пересмотреть правила работы с Бэклогом. Вот активности, которые помогут решить проблему:

Прокачайте Владельца Продукта

Дайте реальную власть. Убедитесь, что тот, кого вы называете Владельцем Продукта, на самом деле им является. Цель настоящего Владельца Продукта — оптимизация бизнес-ценности продукта для всей организации. Владелец Продукта — лидер-слуга для организации, mini-CEO продукта и предприниматель. Не все обязаны быть довольными решениями Владельца Продукта, тем не менее, каждый обязан их уважать и соблюдать.

Спрашивайте бизнес-метрики. Убедитесь, что Владелец Продукта отвечает за бизнесовые метрики: Return On Investment (ROI), Cost Benefit Ratio, Profits and Loss (P&L) и другие. Если скоуп работ жестко зафиксирован, то это никак не стимулирует оптимизировать бизнес-ценность и заниматься приоритезацией Бэклога Продукта. Более того, в этом случае, скорее всего, Владелец Продукта даже не заинтересован в поиске бизнес-ценности. Единственное, что его будет интересовать — попадание в треугольник менеджера (time, scope, cost).

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

Помогите создать дорожную карту продукта и поставить бизнес-цели на ближайший квартал. Сделайте цели измеримыми (SMART), а также сформулируйте несколько критериев, по которым вы будете оценивать каждый элемент Бэклога Продукта. Получите поддержку и согласие у заинтересованных лиц. И в следующий раз, когда Василий Петрович прибежит к Владельцу Продукта с просьбой включить важную фичу в Бэклог, он сможете ответить: «Василий Петрович, мы договорились, что в ближайший квартал снижаем операционные расходы. Как ваша идея поможет нам?»

Прокачайте работу с продуктом

Убедитесь, что Скрам-команда разрабатывает именно продукт. Да-Да, я серьезно. Если команда получает некие данные, а после Спринта передает их другим командам в измененном виде, то вряд ли это продукт. Обычно такие псевдо-продукты имеют название, похожее на Frontend System, Backend System, Core System, Platform.

Настоящий Продукт — это нечто, что приносит бизнес-ценность пользователю (внешнему или внутреннему). Сами по себе данные никакой бизнес ценности не несут, в этом случае Скрам-команда локально оптимизирует часть цепочки по поставке ценности. Попытайтесь сформировать команду с фокусом на клиенте end-to-end, чтобы максимально использовать преимущества Скрама.

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

Перестаньте дербанить команду на другие проекты. Когда Команда Разработки работает над несколькими продуктами/проектами одновременно, фокус теряется. Люди теряют много сил на переключениях, а работа превращается в утомительный марафон. Сделайте все возможное для того, чтобы Команда Разработки фокусировалась на одном продукте или сервисе.

Прокачайте Бэклог Продукта

Свяжите задачи с бизнес-целями. Используйте технику Impact Mapping для связи бизнес-целей с задачами в Бэклоге Продукта. На мой взгляд, это одна из наиболее мощных продуктовых техник, которая помогает понять «А не фигней ли занимается команда?»

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

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

Подводим итоги

Бэклог — мощный инструмент и генеральный план для Скрам-команды. Если им заниматься спустя рукава, невозможно двигаться дальше. Вспомните, легко ли вам удается формулировать Цель спринта. Возможно, это сигнал о том, что Бэклог стал похож на винегрет, и это мешает вам доставлять ценность.

Илья Павличенко Аджайл Коуч Unusual-Concepts

Плюсануть
Поделиться
Отправить
Класснуть
Линкануть
Вотсапнуть
Запинить
Ещё по теме
Большие элементы в Бэклоге продукта (PBI) — причина неприятных сюрпризов и повышенной вариативности в Спринте. Чем больше задача, тем больше неизвестных. Большие PBI с трудом вмещаются в Спринт, а Владелец Продукта и стейкхолдеры могут долго не видеть результатов работы Скрам-команд. Недавно я начал работать с двумя фиче-командами. Владелец Продукта поместил наверх Бэклога одну огромную фичу, которая, по предварительной оценке, должна была занять команды на много Спринтов вперёд. На актуализации Бэклога Продукта присутствовали обе команды в полном составе (Multi-Team PBR). Мы декомпозировали, оценили и подготовили Бэклог Продукта к планированию за восемь шагов.

Шаг 1. Определить связь PBI с бизнес-целью

Мы обсудили, что связывает PBI с ближайшей бизнес-целью: с увеличением конверсии заявок с сайта (CR). Если ранее вы не определили бизнес-цель, то техника Impact Mapping и её вариация Extended Impact Mapping точно помогут на этом шаге.

Шаг 2. Описать PBI в формате «кто, что и зачем»

Я часто использую такой формат описания элементов Бэклога Продукта:
  • кто — пользовательский сегмент или персона;
  • что — краткое описание задачи;
  • зачем — бизнес-ценность или ценность для пользователя.
Владелец Продукта и команды обсудили это в открытой дискуссии. Я зафиксировал сказанное на флипчарте, чтобы к информации было легко вернуться.

Шаг 3. Разбить PBI в малых группах

Мы сформировали четыре группы по 3–5 человек и отправили их на рабочии станции в опенспейсе, где они в течение 20 минут декомпозировали PBI. Ребята использовали паттерны разбиения и другие техники, в частности, User Story Mapping. Если команды ещё не владеют навыками декомпозиции, нужно провести обучающий воркшоп. Восемь шагов для работы с большими элементами в Бэклоге Продукта (PBI)

Шаг 4. Представить варианты разбиения

У нас получились четыре варианта декомпозиции. Теперь я хотел, чтобы мы нашли самое ценное в каждом из них. Для этого мы прошлись по каждой рабочей станции, где нам презентовали каждый из вариантов разбиения. На каждой станции мы пробыли не более пяти минут. Восемь шагов для работы с большими элементами в Бэклоге Продукта (PBI)

Шаг 5. Провести финальную «склейку»

Я попросил Владельца Продукта и нескольких представителей команд сделать финальную «склейку» различных вариантов декомпозиции. Для этого мы принесли все флипчарты и повесили их на стену. Владелец Продукта выбирал наиболее удачные части и размещал их на финальной версии. Восемь шагов для работы с большими элементами в Бэклоге Продукта (PBI)

Шаг 6. Оценить и приоритезировали полученные фичи

К этому моменту гигантская фича была разбита на более мелкие элементы. Я попросил представителей из каждой команды провести экспресс-оценку при помощи «рубашечных размеров». Затем Владелец Продукта упорядочил все полученные фичи. В итоге мы получили 11 фич, самые приоритетные из которых должны были комфортно поместиться в двухнедельном Спринте. Восемь шагов для работы с большими элементами в Бэклоге Продукта (PBI)

Шаг 7. Прояснить приоритетные PBI

Каждая группа, взяв одну фичу из верхушки Бэклога Продукта, прояснила её на рабочей станции. Через 20 минут на каждой станции появились:
  • описание фичи,
  • обновлённая оценка,
  • приемочные критерии,
  • бизнес- и пользовательская ценности.
Далее мы сделали несколько раундов «мирового кафе», двигаясь по часовой стрелке. На каждой станции был человек, который принимал обратную связь и рассказывал о фиче.

Шаг 8. Обсудить полученную ценность

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

Выводы

  • Предпочитайте использовать Multi-Team PBR, когда Бэклог Продукта актуализируют сразу несколько команд.
  • Всегда начинайте обсуждение PBI со связи с бизнес-целью.
  • Декомпозируйте элементы Бэклога Продукта с помощью паттернов разбиения и техники User Story Mapping.
  • Работайте в малых группах и форматах мирового кафе, трейдшоу или коктейльной вечеринки.
  • Для лучшего взаимодействия используйте бумагу, флипчарты, ножницы или стикеры.
 
Андрей Толмачев рассказывает, как разрешить взаимное недовольство Владельца Продукта и Команды Разработки.

Условия задачи

Представьте такую ситуацию. Вы — новый Скрам-мастер. Ваша Команда Разработки состоит из системного аналитика, двух разработчиков и двух специалистов по тестированию. Длина Спринта — две недели. Команда работает со сложной системой на старой платформе, поэтому для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты. В течение последнего Спринта Команда не успела сделать работу, взятую в Спринт, поэтому на Ретро Владелец Продукта допытывается, кто чем занимался в течение Спринта. Владелец Продукта жалуется, что Команда работает очень медленно. Члены Команды жалуются, что бизнес контролирует и микроменеджит их. Как разрешить взаимное недовольство Владельца Продукта и Команды Разработки? Давайте разбираться.

Что происходит

Для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты — это означает, что элемент будет готов к выпуску только через три Спринта. В таком случае истинная длина Спринта равна шести неделям — это больше, чем допускает Руководство по Скраму.
Максимальная продолжительность Спринта — один календарный месяц. При большем сроке планирования возможны изменения целей, увеличение сложности и рост рисков.
Руководство по Скраму Когда Команда редко поставляет готовый Инкремент, то редко получает обратную связь от стейкхолдеров и клиентов. В результате:
  • возрастает риск сделать не то, что надо. Способность реагировать на изменения падает;
  • стабильность процесса падает, прогнозировать работу сложно. Например, тестирование выявляет дефекты через недели после разработки. Баги обнаруживаются поздно, поэтому объём «поддержки» будет меняться от Спринта к Спринту;
  • рабочий процесс перестаёт быть прозрачным.
По этим причинам Команда Разработки теряет доверие Владельца Продукта и стейкхолдеров, следовательно, давление возрастает и начинаются конфликты.

Решение

Скрам-мастер не может решить проблему самостоятельно, но может помочь своей Команде следующим образом:
  • объяснить описанную выше системную динамику и её вредные последствия. Скрам-команда должна понимать, что правило Скрама про Done Increment каждый Спринт — это естественное системное решение их проблемы;
  • помочь сформулировать или пересмотреть минимальный DoD, который может быть выполнен в течение Спринта и который обеспечит готовность Инкремента к релизу;
  • научить Команду Разработки правильно декомпозировать элементы Бэклога. Небольшие элементы в Бэклоге Продукта способствуют ранней поставке, оптимизации ценности Продукта и улучшению потока работы;
  • помочь договориться взять в следующий Спринт хотя бы один небольшой элемент Бэклога, но довести его до состояния Done;
  • визуализировать поток работы. Прозрачность — залог успеха;
  • устранить простои в работе. Для этого Скрам-мастер обучает Команду хорошим инженерным практикам, например, общему владению кодом, стимулирует развитие T-shaped или E-shaped людей в Команде, заключает командные соглашения;
  • объяснить Владельцу Продукта, что причина задержек — технический долг и убедить его выплатить.
Используйте Ретроспективу, чтобы найти лучшие решения по устранению препятствий. Помните, что эти решения — эксперименты, не факт, что они принесут ожидаемый эффект. Поэтому инспектируйте результаты прошлых решений и адаптируйте решения на следующих Ретроспективах.

Итоги

Готовый Инкремент в конце Спринта — это важнейшие правило Скрама, которое помогает избежать роста рисков, потери предсказуемости и гибкости. Описанные причинно-следственные связи полезно знать, чтобы понимать, почему Скрам требует соответствующий DoD, готовый к релизу Инкремент каждый Спринт. Следующие действия могут помочь в достижении этой цели:
  • декомпозиция работы на небольшие PBI;
  • визуализация потока работы в Спринте и поиск основных узких мест;
  • устранение «простоев» работы с помощью командных соглашений, хороших инженерных практик и развития T-shaped или Е-shaped людей;
  • планомерная ликвидация технического долга.
Комментарии
Илья, 20 июня 2017

Уже в переводе, на следующей неделе появится в блоге Scrum.org Рад, что статья оказалась полезной.

Станислава, 20 июня 2017

Прекрасная статья! Мне нужна такая на английском, я сразу нашему ПО отправлю! Есть что-то похожее, или мне переводить? =)