Мультикомандное уточнение Бэклога Продукта

Перевод оригинальной статьи Сезарио Рамоса «Multi-team Backlog Refinement»

В этой небольшой статье я поделюсь с вами некоторыми советами по мультикомандному Уточнению Бэклога Продукта.

Что такое Уточнение Бэклога Продукта?

Уточнение Бэклога Продукта (Product Backlog Refinement, PBR) — это мероприятие, которое регулярно проводят Скрам-команды, чтобы прояснить и уточнить Элементы Бэклога Продукта (Product Backlog Items, PBI), которые предстоит взять в работу в следующих Спринтах. В однокомандном Скраме команда обычно проводит одну или несколько подобных встреч за Спринт. 

Ниже приведены примеры связанных с этим событием активностей:

  • Понимание того, какую проблему надо решить: Владелец Продукта рассказывает несколько последовательных историй и связывает их с текущими бизнес-целями. Команда обсуждает “почему мы это делаем?”, “как понять, что мы решаем нужную проблему?”. Некоторые команды используют карту историй (story mapping), карту влияния (impact mapping), игры «Speedboat», «Я и моя тень» и технику «5 почему». 
  • Разбивка больших элементов для более простого обсуждения и изучения.
  • Оценка элементов.
  • Понимание потребностей клиента: команда обсуждает“Почему пользователь хочет этого?”, “Правильно ли мы решаем его проблему?”. Некоторые команды используют доску историй (storyboard)  до и после, карты Pain Gain.
  • Прояснение элементов: Некоторые команды используют технику спецификации на примерах (Specification By Example) и создают приемочные тесты для пользовательских историй, используют описание историй с помощью спецификаций языка Gherkin, таблицы потоков и/или таблицы решений.
  • Определение планов исследовательского тестирования: Выявление рисков при достижении цели, выявление фич, которые требуют ручного тестирования. Некоторые команды используют план исследовательского тестирования (Exploratory Test Charter) для каждой фичи и проводят сессии исследовательского тестирования всей командой.
  • Создание первоначального дизайна: Моделирование на магнитной доске, прототипы дизайна…

Читать далее «Мультикомандное уточнение Бэклога Продукта»

PBR в LeSS (кейс МТС Касса часть 9-я)

Уточнение Бэклога Продукта (PBR) в LeSS

В масштабируемом Скраме PBR становятся обязательным событием (а не активностью). Это происходит, потому что в крупных продуктовых группах PBI получаются очень большими и возникает необходимость в масштабном обучении и координации между командами. Появляется необходимость планировать минимальное количество встреч с клиентами и пользователями. В LeSS есть несколько вариантов проведения PBR (руководство «Типы Уточнений Бэклога Продукта»):

  • Общее Уточнение Бэклога Продукта с представителями команд, которое предполагает высокоуровневый анализ и видение, оценку и разбиение элементов (руководство «Общее Уточнение Бэклога Продукта»).
  • Мультикомандное Уточнение Бэклога Продукта. Несколько команд в одной комнате уточняют несколько PBI одновременно (предпочтительно) (руководство «Мультикомандное Уточнение Бэклога Продукта»).
  • Однокомандное Уточнение Бэклога Продукта. Проводится как в Скраме для одной команды.

Нет каких-либо особых правил по комбинированию PBR, однако LeSS рекомендует проводить мультикомандные PBR. Давайте остановимся на их подробнее. Читать далее «PBR в LeSS (кейс МТС Касса часть 9-я)»

Планирование в LeSS (кейс МТС Касса 8-я часть)

Первая часть Планирования Спринта

За час до Первой Части Планирования Спринта Владелец Продукта и двое бизнес-аналитиков вносили финальные изменения в Бэклог Продукта. Затем представители всех команд (обычно по два человека от команды) принимали участие в Первой части Планирования Спринта.

Агенда встречи. Мы обычно придерживались следующей агенды:

  • обновляем Бэклог Продукта (вернуть невыполненную работу в Бэклог Продукта и оцениваем объем оставшейся работы);
  • Владелец Продукта очередной раз кратко описывает основные моменты в Бэклоге Продукта и при необходимости поясняет отдельные детали элементов (это уже было на PBR);
  • повторно рассматриваем Критерии Готовности (DoD);
  • представители команд выбирают стикеры с PBI из верхней части столбца «Ready» и прикрепляют их на дорожки своих команд на доске;
  • находим возможности для совместной работы команд (зависимости) и визуализируем их на доске;
  • решаем, нужна ли мультикомандная Вторая часть Планирования Спринта (когда между командами есть зависимости);
  • определяем общую Цель Спринта для продуктовой группы и/или отдельные Цели Спринта для команд.

Читать далее «Планирование в LeSS (кейс МТС Касса 8-я часть)»

Как LeSS фундаментально решает организационные проблемы

Короткая статья текста по следам презентации, которую я показывал на последнем митапе, посвященному LeSS.

Презентацию в формате PDF можно скачать по ссылке.

Быстрые и фундаментальные решения

Часто спрашивают «почему именно LeSS, а не другой фреймворк для масштабирования?» Один из аргументов — LeSS дает системные фундаментальные решения. Считаю важным предлагать организациям и их руководителям не симптоматическое лечение, которое лишь на время приносит облегчение, чтобы затем вернуться с еще большими побочными эффектами, а фундаментальные решения организационных вопросов. Давайте капнем глубже.

Читать далее «Как LeSS фундаментально решает организационные проблемы»

LeSS в MTC Кассе 7-я часть (первый Спринт, визуализация, координация)

Первый Спринт

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

Изучив Бэклог Продукта, дизайнеры и разработчики Android увидели, что в первом Спринте для них мало работы. Поэтому в ходе Спринта они много времени занимались обучением и помогали другим. Это обычная ситуация: первый Спринт выявляет так называемый «долг знаний», который всегда скрыто присутствует в функциональных подразделениях. Особенно это касается масштабных внедрений, когда речь идёт о крупных подразделениях — и крупных «долгах знаний». Этот новый «организационный перенос навыков» (если использовать формулировки из первой статьи о Скраме в Harvard Business Review за 1986 год) был очень непривычен участникам группы. Люди не понимали, почему нужно учиться вместо того, чтобы «делать что-то полезное».

Мы обнаружили несколько проблем, которые не учли во время запуска. Например, как справляться со срочными задачами и багами, поступающими от группы технической поддержки. Также мы не учли заранее, как будем проводить регрессионное тестирование. К сожалению, налицо был большой технический долг, а доля автоматического тестирования была мала. Читать далее «LeSS в MTC Кассе 7-я часть (первый Спринт, визуализация, координация)»

LeSS в MTC Кассе 6-я часть (Initial PBR)

Initial PBR

Видение Продукта и бизнес-модель. Очень полезно корректировать понимание продукта разработчиками — не только на уровне общего видения, но и с более глубоким погружением в бизнес-модель. Продуктовая группа в LeSS — это часть более широкой организационной среды, включающей маркетинг, продажи, нормативно-правовое соответствие, юридическую поддержку и т. д. Поэтому мы начали Первоначальное Уточнение Бэклога Продукта с того, что команды создали канвасы бизнес-моделей, а затем объединили их в один. Мы последовательно обсуждали все аспекты бизнес-модели, а Владелец Продукта нас поправлял.

Попробуйте воркшоп по разбиению задач

Типичная проблема: команды не могут разбить PBI на более мелкие элементы. Задача становится еще важнее, если есть фиче-команды, потому что нам надо снизить вариативность в более мелких наборах фич и таким образом уменьшить общую длительность цикла. Мы предложили командам воркшоп по разбиению задач, в котором участвовали все команды.

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

Через 20 минут мы снова объединились и попросили каждую группу поделиться своими результатами. Мы отметили самые удачные варианты разбиения. Я обычно приносил памятки с шаблонами разбиения элементов на все PBR в ходе первых Спринтов, чтобы всегда иметь их под рукой при необходимости.

Попробуйте оценочную и корреляционную сетку.

Когда над одним Бэклогом Продукта работает несколько команд, необходимо синхронизировать оценки. Пилотная фиче-команда уже имела опыт оценивания в относительных величинах и имела много готовых элементов Бэклога Продукта. Мы сформировали оценочную сетку, где отобразили готовые элементы как образец для сравнения. Затем провели воркшоп, на котором пилотная фиче-команда объяснила остальным разработчикам эталонные PBI и помогла им скорректировать стори-поинты.

Фасилитация первого мультикомандного Уточнения Бэклога Продукта (PBR). Ранее команды по внедрению LeSS получали спецификации от выделенной аналитической группы. Теперь они должны были самостоятельно уточнять детали по каждому элементу. Мы пригласили в комнату экспертов в предметных областях. Команды разбились на четыре смешанные группы и начали работу на станциях, каждая у своей стены. На каждой станции эксперт помогал участникам прояснить детали PBI. Через 25 минут все переместились по часовой стрелке на следующую станцию (кроме экспертов). На каждом флипчарте уже были заметки, диаграммы и объяснения, оставленные предыдущей группой, что очень помогло вникнуть в тему. Так командам понадобилось чуть больше часа, чтобы прояснить три PBI. После перерыва мы ещё раз повторили процесс.

LeSS в МТС Кассе 5-я часть (выборы Скрам-мастеров и запуск сообществ)

Выбор Скрам-мастеров

Скрам-мастер в LeSS — это выделенная роль на полный рабочий день, предполагающая работу с 1–3 командами. Мы хотели нанять опытного Скрам-мастера до того, как изменим организационную структуру. К сожалению, у нас не получилось. Поэтому я в итоге решил стать вторым Скрам-мастером, пока мы не найдем замену.

Путём голосований и обсуждений команды выбирали Скрам-мастера, с которым хотели работать. Мы ускорили этот процесс, предложив им составить списки того, что они ожидали от Скрам-мастера. В них попали некоторые интересные моменты. Например: команда может выдать Скрам-мастеру «чёрную метку», и он не должен обижаться, если команда его уволит.

Запуск сообществ

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

Некоторые из них начали работу уже через несколько дней, остальные — в ходе первых двух Спринтов. Мы убедились, что Скрам-мастер помог им определить:

  • цель сообщества;
  • рабочие договорённости.

Разработчики также регулярно встречались и с удовольствием участвовали в работе сообществ. Я помню встречу, посвященную автоматизированному тестированию, которая проводилась с применением моб-программирования. Одна девушка-дизайнер тоже приняла участие, потому что хотела начать изучать автоматизацию. Люди хотели учиться!

LeSS в МТС Кассе 5-я часть (от Lean Coffee до DoD)

Попробуйте организовать Lean Coffee!

На ранних стадиях внедрения уровень неуверенности и подавленности может зашкаливать. Все модели управления изменениями подчеркивают ценность коммуникаций, а формат Lean Coffee — прекрасный способ организовать наиболее эффективное общение. При этом можно вести открытый диалог и устранять «слепые пятна». Я разослал всем приглашения на сессию Lean Coffee по электронной почте и подумал: «А что, если никто не придёт? Это будет полный провал». К счастью, народ собрался, и у нас получилась замечательная дискуссия. После тренинга оставалось много вопросов, и на встрече в формате Lean Coffee все смогли получить на них ответы. Я использую такой формат встреч уже давно, и опыт подсказывает мне, что количество посетителей обычно отражает уровень интереса в группе к определённой теме.

Выбор Владельца Продукта

Кандидатурой на роль Владельца Продукта, естественно, оказался Технический директор, так как он один из основателей компании и знает рынок, бизнес и клиентов лучше, чем кто-либо ещё. Выбор был настолько очевиден, что я не ожидал никаких подвохов, однако они появились через несколько месяцев. Читать далее «LeSS в МТС Кассе 5-я часть (от Lean Coffee до DoD)»

LeSS в МТС Кассе 4-я часть (обучение LeSS)

Дальнейшие шаги по внедрению LeSS

Летом 2017 года я посетил в Милане мастер-класс Крэга Лармана по LeSS. Одна из самых запомнившихся рекомендаций звучала так: «Думай как политик, а не как инженер». Хотя Владелец Продукта подталкивал меня внедрить LeSS как можно быстрее, совет Крэга помог мне притормозить внедрение. После успеха пилотной фиче-команды я увидел, что уровень доверия со стороны менеджмента вырос. К тому времени мы получили полную поддержку от руководства компании. Круто! С другой стороны, я понял, что многие разработчики из компонентных команд скептически относились к идее LeSS. Мы решили обучить их, чтобы перемены в компании были добровольными, а не вынужденными (руководство «Три принципа внедрения»).

Бэклог трансформации

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

  • провести сертифицированный тренинг по основам LeSS (Certified LeSS Basics, CLB);
  • провести несколько семинаров в формате Lean Coffee для ответов на частые вопросы по LeSS;
  • создать первоначальный Бэклог Продукта;
  • создать HitMap;
  • организовать мастер-класс по самостоятельному формированию команд;
  • сформулировать цель для совершенствования;
  • выбрать Скрам-мастеров в командах;
  • разработать Критерии Готовности (DoD);
  • запустить работу сообществ и найти компонентных менторов;
  • провести первоначальное Уточнение Бэклога Продукта (PBR).

Если вспомнить, то мы потратили полтора месяца, чтобы подготовить изменения и создать подходящую для внедрения LeSS организационную структуру. Читать далее «LeSS в МТС Кассе 4-я часть (обучение LeSS)»

LeSS в МТС Кассе 3-я часть (разработка стратегии компании)

Воркшоп по стратегии компании

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

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

После упражнения с заглавной статьей для делового журнала мы стали формулировать краткое видение. Мы хотели прийти к консенсусу всех участников сессии (это почти 30 человек). Мы потратили на это несколько часов, но оно того стоило — участники сказали, что по-настоящему вдохновились видением. Было оно таким:

каждый предприниматель РФ СМБ выбрал помощником своего бизнеса нашу экосистему B2B-сервисов.

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

Мы объединили людей с помощью вполне яркого и вдохновляющего видения компании и затем разработали дорожную карту. Это оказалось отличным стартом в создании Бэклога Продукта.