Опубликовано

Прокачайте PBR при помощи Example Mapping

В этой статье мы поделимся с вами техникой Example Mapping для командной работы над спецификациями. Мы применили эту технику на Актуализации Бэклога Продукта (PBR) с продуктовой группой LeSS. Попробуйте и вы!

Об Example Mapping мы узнали из блога Мэтта Вина — автора тестового фреймворка Cucumber. Хотим отметить очевидные плюсы техники:

  • добавляет структуру в обсуждение элементов Бэклога Продукта; 
  • помогает найти пробелы в знаниях;
  • позволяет создать первоначальную версию приёмочных тестов сразу на PBR.

Мы уже писали о важности эффективного проведения Акутуализации Бэклога Продукта (PBR) в статье Эффективный PBR часть I. Статья, которую вы сейчас читаете, детально раскрывает технику Example Mapping.

Example Mapping для PBR

“Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации”
— Мэлвин Конвей 

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

  • Каждая команда – это самоуправляемая, кросс-функциональная, колоцированная, и долгоживущая структурная единица.

Наилучший способ взаимодействия в такой команде — это собрать всех необходимых людей в одном месте и обменяться имеющимися знаниями. 

На встречу были приглашены 5 команд из продуктовой группы LeSS, стейкхолдеры из смежных подразделений, которые выступали главными заказчиками функциональности и, конечно же, Владелец Продукта. 

Наша цель заключалась в  том, чтобы детально проработать TOP-5 элементов Бэклога Продукта. 

Порядок действий был следующий:

1. Обозначили 5 хранителей знаний (экспертов) на каждому из выбранных элементов. Эти люди оставались на станциях все время.

2. Образовали смешанные группы из 5 команд, которые присоединились к экспертам.

3. Мы подготовили вымышленный пример фичи “Предотвращение нелегального использования топливной карты” и обучили группы технике Example Mapping

И объяснили цветовое обозначение для стикеров:

  • История — описание элемента Бэклога Продукта
  • Правило — это один из критериев по которому мы поймем что фича реализована как задумывалась, иначе говоря голубые стикеры — это критерии приёмки фичи
  • Пример — конкретный пример описывающий правило, Действие => Результат
  • Вопрос — если на текущий момент в группе возникает вопрос, на который группа не может в таком составе ответить, вопрос пишется на розовый стикер для дальнейшего прояснения

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

4. Запустили World Cafè — фасилитационный формат, где есть “хозяин” станции, в нашем случае им являлся эксперт, к которому присоединились группы участников. Группы работали на станциях: проясняли требования и наполняли флипчарт, используя Example Mapping.

По истечении времени группа переходила на следующую станцию и работала там с другим экспертом. И так продолжалось до тех пор пока все группы не побывали на всех станциях. 

5. После того как все группы побывали на всех станциях произошла презентация результатов работы.

Что у нас получилось:

  • Обратили внимание, что на одной из станции образуется большое количество вопросов. Оказалось, что много информации уже было написано в базе знаний, но прошло порядочно времени. Знания забылись. Мы нашли ноутбук, залезли в БЗ и выгрузили ключевые моменты на стикеры.
  • Большое количество голубых стикеров — сигнал к тому что эта фича большая. Хорошая новость! Ее можно разбить прямо по правилам!  
  • Все 5 команд продуктовой группы познакомились в равной степени с каждым элементом Бэклога Продукта (PBI), а значит каждая команда сможет взять любой из них на Планировании Спринта.
  • Правила, описанные на зелёных стикерах, уже в первый же день работы в Спринте могут использоваться для автоматизации приемочного тестирования. Более того, подход test-first теперь становится неизбежным 🙂

Попробуйте и Example Mapping! Будем рады услышать от вас идеи, ваши находки и улучшения 🙂

Напоминаем, что 14-16 октября у нас состоится первый тренинг Professional Scrum Developer (PSD) на русском языке — лучший тренинг для Скрам-команд, которые создают реальное программное обеспечение. На тренинге мы подробно разберём тему PBR, а также другие темы эффективной работы.

Читайте и другие наши посты про PBR в нашем блоге: Эффективный PBR часть I и Мультикомандное уточнение Бэклога Продукта

Опубликовано

Из первых уст. Инсайты с конференции Liberating Structures European Gathering, Hamburg, August, 2019

Привет! Маленькая мечта сбылась: познакомилась с создателями освобождающих структур на конференции Liberating Structures European Gathering!

Конференция,  больше похожая на митап, проходила 8-9 августа 2019 в Гамбурге. Я ехала подготовленная — у меня было много вопросов к создателям освобождающих структур Генри Липмановичу (Henry Lipmanowicz) и Кейту МакКэнделсу (Keith McCandless).

Могу сказать, что за два дня переосмыслила всю концепцию освобождающих структур. Мои инсайты:

Читать далее «Из первых уст. Инсайты с конференции Liberating Structures European Gathering, Hamburg, August, 2019»
Опубликовано

Скрам — это дизайн совершенства!

В этой статье хочу поддержать тех, кто начал использовать Скрам и чувствует некоторое разочарование. На тренинге рисовалась идеализированная картинка, которая не “налезла” на реалии организации. Как говорит один мой друг: “ожидания и реальность”. Поясню, почем не нужно расстраиваться. Давайте разберемся. 

Проблема с холодильниками

В 50-х годах компания General Electrics выпускала холодильники с дверцами двух видов: открывающихся или на правую, или на левую сторону. Компания никак не могла найти баланс между выпуском двух вариантов. Когда спрос одной модели превышал предложение, то покупатели вынуждены были ждать и уходили к конкурентам. Когда предложение превышало спрос, холодильники простаивали на складах и приносили убытки.

Было испробовано несколько стратегий:

  • Сначала менеджмент вообще ничего не предпринимал.
  • Отдел продаж начал прогнозировать спрос в регионах.
  • Подключили математическую статистику для уточнения прогнозов.

Результаты улучшились, но не устраивали менеджмент. Проблема разрешилась только тогда, когда General Electrics стала выпускать универсальные холодильники, двери которых настраивались на открытие в любую сторону.

“Решение” (resolution) и “растворение” (dissolving) проблем

История с холодильниками иллюстрирует различные подходы к управлению: игнорирование проблемы, поиск приемлемого, а затем более эффективного решения, и, наконец, “растворение” проблемы. 

Можно контролировать/управлять проблемами, приспосабливаясь к ним, а можно фундаментально устранять.

В системном мышлении считается, что наилучший способ решить проблему — сделать так, чтобы она не возникла вновь. Для этого нужно перестроить систему, т. е. изменить способы работы и взаимодействия частей системы.

Эффективный менеджмент заключается реструктуризации системы, а не решении проблем (Рассел Эйкофф, Воссоздание корпорации).

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

Проблема“Решение” проблемы“Растворение” проблемы
Распределенные команды и негативные последствия (недоверие, асинхронные зависимости, высокие издержки и потери при коммуникации).Эффективные электронные инструменты, качественная фасилитация, очные встречи, например, раз в квартал и т. д.Колоцированные команды, сидящие в одном помещении за одним столом.
Экономические потери, вызываемые очередями (длинные циклы, повышенная вариабельность, сниженное качество и мотивация).Управление очередями, сигнальные карточки (канбан), WIP-лимиты.“Идеальный поток”, работа в стиле one-piece flow, использование техник моб-программирования, swarming.
Зависимости между командамиУправление зависимостями (выделенные координаторы, встречи).Команды без зависимостей (кросс-функциональные и кросс-компонентные), которые непрерывно интегрируются.
Необходимость в координацииВыделенные координаторы, специальные централизованные встречи, координационные роли и подразделения.Создание условий для возникающей самоорганизации (децентрализованные техники координации, колокация команд, непрерывная интеграция в коде).
Читать далее «Скрам — это дизайн совершенства!»
Опубликовано

7 токсинов доверия в команде

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

Что же является причиной снижения уровня доверия в команде. Ниже мой список основных токсинов.

Читать далее «7 токсинов доверия в команде»
Опубликовано

Что такое продукт?

Что такое продукт? 

Перевод оригинальной статьи Ellen Gottesdiener “What is your product?”

«Что такое продукт?» Это ключевой вопрос, который я недавно опубликовала в своем докладе в преддверии конференции Agile Cincinnati.

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

Каждый в продуктовой разработке должен иметь общий для всех, последовательный и четкий ответ на вопрос: «Что такое продукт?»

Image copyright by EBG Consulting

У компании должен быть общий для всех сотрудников, последовательный и четкий ответ на вопрос: «Что такое продукт?»
Изображение от EBG Consulting

Пять принципов

Существует пять принципов, которые помогают определить продукт:

Читать далее «Что такое продукт?»
Опубликовано

Традиционное и системное мышление

Перевод статьи Сезарио Рамоса Systems and traditional thinkers

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

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

«95 % проблем в бизнесе возникают на уровне систем и только 5 % на уровне людей».

Э. У. Деминг

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

Но что представляет собой система? Р. Л. Акофф предложил лучшее, на мой взгляд, определение:

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

Читать далее «Традиционное и системное мышление»
Опубликовано

Эффективный PBR часть I

В этой статье я опишу что, с моей точки зрения, может обеспечить эффективность PBR в Скрам.

Почему PBR важен

PBR не является официальным событием в Скраме, но он снижает вариативность элементов Бэклога Продукта (PBI) перед тем как они попадут в Спринт. Когда верхние элементы Бэклога Продукта приходят в состояние “ready”, то в Спринте у команды возникает меньше “сюрпризов”, а вероятность достижения Цели Спринта возрастает.

Разработчики общаются с клиентами напрямую

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

  • промежуточные артефакты (BRD, спецификации и т.д.);
  • многочисленные передачи, как результат, искажение и потеря информации;
  • низкая скорость принятия решений;
  • отсутствие эмпатии у разработчиков по отношению к клиентам/пользователям продукта;
  • непонимание разработчиками бизнес-домена.

Стейкхолдеры (внутренние, клиенты, пользователи) в хорошем Скраме общаются с Командой Разработки напрямую. Интервью с пользователями, уточнение требований напрямую со стейкхолдерами является нормальной активностью Команды Разработки. 

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

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

Читать далее «Эффективный PBR часть I»
Опубликовано

Trust Toolbox: палитра командных инструментов

Возвращаясь к теме командного доверия, сегодня хочется поделиться набором полезных инструментов. Для удобства составили список инструментов и категоризовали их с точки зрения фокуса и места использования (Персональный — Командный, Удаленная — Локальная).

Что же у нас получилось.

Читать далее «Trust Toolbox: палитра командных инструментов»
Опубликовано

Правильное ведение хозяйства

или ежедневный чистый продукт

https://sites.google.com/a/scrumplop.org/published-patterns/_/rsrc/1555448727626/value-stream/good-housekeeping/GoodHousekeeping_Head.jpg?height=317&width=320

Кто-то взял инструмент и не вернул его обратно. Команде приходится искать его. Еще хуже, команда шлет письмо всем сотрудникам, а это отвлекает от работы и отнимает время. Крайняя мера — команда приобретает новый инструмент.

…Команда разработки двигается к Цели Спринта.

✥ ✥ ✥

Если вокруг беспорядок, вы тратите время и силы на поиск того, с чего нужно начать.

Если участник команды вынужден спрашивать, с чего начать работу, — это пустая трата времени. Если участник команды вынужден наводить порядок перед началом работы, это пустая трата времени. Если участник команды работает в беспорядке и переделывает за кем то работу, это пустая трата времени. Если участник команды не знает прогресс по продукту и повторяет сделанное другим, это тоже пустая трата времени и сил. Если участник команды спрашивает, что делать дальше, это пустая трата времени.

Слишком большой объем информации на Доске информации путает сотрудников и мешает отделить главное от второстепенного. Это отнимает время.

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

Пустая трата времени возникает из-за работы в условиях неясного прогресса.

Поэтому:

Каждый день продукт (код) и рабочее пространство должны быть абсолютно чистыми.

Читать далее «Правильное ведение хозяйства»
Опубликовано

Illegitimus Non Interruptus (без стука не входить)

…Скрам-команда обслуживает многих стейкхолдеров, и все они борются за внимание команды. Команда получает запросы и требования от стейкхолдеров, от каждого клиента, от отделов продаж и маркетинга. Кроме того, в ходе работы появляются баги и это тоже требует внимания. Частота и важность этих запросов меняется. Иногда их объем и срочность просто чрезмерны.

✥ ✥ ✥

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

Скрам-команда — общий ресурс, который закрывает потребности многих стейкхолдеров. Трагедия общин — это дилемма, возникающая, когда множество людей, действуя независимо и рационально, руководствуясь своими личными интересами, в конечном итоге истощают общий ресурс, даже если очевидно, что такой результат не отвечает чьим-либо долгосрочным интересам. Впервые описал эту дилемму американский эколог и философ Гаррет Хардин в знаменитой статье «Трагедия общин» («The Tragedy of the Commons»), опубликованной в журнале Science в 1968 году.

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

Желательно, чтобы Скрам-команда отвечала за результаты своей работы (“eat your own dog food”). Если выявляется дефект, команде нужно его исправить как можно быстрее. Если создается специальная команда для исправления дефектов, Скрам-команда не будет обращать внимание на скрытые дефекты.

Это, а также другие причины постоянно мешают работе Скрам-команды.





 Читать далее «Illegitimus Non Interruptus (без стука не входить)»