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

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

Перевод оригинальной статьи Сезарио Рамоса «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) для каждой фичи и проводят сессии исследовательского тестирования всей командой.
  • Создание первоначального дизайна: Моделирование на магнитной доске, прототипы дизайна…

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

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

6 причин, почему внедрение Канбана может оказаться неудачным

Перевод оригинальной статьи «6 Reasons You May Fail with Kanban Implementation«.

Внедрение Канбана в организации может показаться лёгким процессом, но на самом деле тут есть свои подводные камни. Если вы не уделите должного внимания деталям, внедрение может пойти не так. Читать далее «6 причин, почему внедрение Канбана может оказаться неудачным»

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

Почему фокус на Velocity убивает Agility

В этой статье я расскажу об опасной динамике, которая возникает в случае, когда Владелец Продукта, Скрам-мастер и/или менеджмент организации фокусируют Команду Разработки на Velocity.

О чем говорит Velocity.

Концепция Velocity означает:

Скорость, с которой Команда Разработки конвертирует элементы Бэклога Продукта в ГОТОВЫЙ К РЕЛИЗУ инкремент продукта.

Обратите особое внимание на выделенные слова. Velocity применима тогда, когда Команда Разработки может доставлять каждый Спринт готовый к релизу инкремент. В этом случае Done = DoD = releasable.

Но даже в этом случае Velocity не показывает:

  • Была ли решена проблема клиента.
  • Занимаемся ли мы самыми приоритетными проблемами клиента.
  • Объем поставленной ценности.
  • Степень удовлетворенности клиента.

Velocity лишь показывает, что команда была чем-то занята.

Является ли это достоверной оценкой успешности ваших продуктов и сервисов? Оценивают ли клиенты ваши продукта по тому, насколько были заняты сотрудники компании?

Если хотите, Velocity отражает объем “выработки” Команды Разработки. К сожалению, этого недостаточно для создания успешных продуктов и сервисов. Читать далее «Почему фокус на Velocity убивает Agility»

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

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

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

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

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

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

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

Владелец Продукта, а не прокси

Перевод оригинальной статьи Кена Швабера «Product Owner, not proxies»

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

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

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

Я никоим образом не предполагал, что Владелец Продукта станет бизнес-аналитиком, отвечающим за разработку технических требований.

Читать далее «Владелец Продукта, а не прокси»

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

Как вырастить T-специалистов?

Перевод оригинальной статьи Джейсона Уипа “How to develop T-shaped people”.

Предположим, мы согласны с тем, что Т-специалисты — ценные сотрудники. Что мы можем сделать, чтобы вырастить их в нашей команде?

Самое эффективное — это начать обучение на задачах из смежных процессов

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

Такое обучение на смежных задачах помогает сгладить передачу ролей. Читать далее «Как вырастить T-специалистов?»

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

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

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

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

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

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

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

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

Скрам-мастер — перспективная профессия 2019 года по версии LinkedIn

Компания Scrum.org совместно с Agile of Product опубликовали исследование о Скрам-мастерах, проведенное в 2018 году. В опросе приняли участие более 2500 участников. Полную версию отчета можно скачать по ссылке.

Ниже вы найдете самые интересные, с нашей точки зрения, детали отчета.

  • LinkedIn включил Скрам-мастера в список наиболее перспективных профессий 2019 года. Подробнее об этом можно почитать в статье «LinkedIn most promising jobs 2019»
  • Возраст половины из опрошенных Скрам-мастеров от 30 до 39 лет.
  • 71% Скрам-мастеров — мужчины.
  • 26% Скрам-мастеров работают в компаниях размером более 10000 человек, 18% до 10000, 16% до 1000, 11% до 250.
  • 58% респондентов сказали, что в данных момент их компания находится в процессе трансформации.
  • SAFe, LeSS, Nexus самые популярные фреймворки, которые используются компаниями для масштабирования (23%, 9%, 11% соответственно).
  • 78% Скрам-мастеров имеют опыт работы менее 5 лет, 35% менее двух.
  • 39% Скрам-мастеров имеют официальный титул «Скрам-мастер», 15% «Agile Coach».
  • 31% Скрам-мастеров бывшие менеджеры проектов,  25% разработчики, 9% бизнес-аналитики, 8% QA.
  • 81% команд используют Kanban вместе со Скрамом, 55% DevOps, 34% TDD.
  • Топ-3 сертификации для Скрам-мастеров Professional Scrum Master (PSMI), Certified Scrum Master (CSM), Professional Scrum Product Owner (PSPOI).

Надеюсь эта информация будет полезной для вас!

Scrum ON!

 

 

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

Почему T-специалисты?

Перевод оригинальной статьи Джейсона Йипа “Why T-spaped people”.

Т-специалист разбирается во многих областях и как минимум в одной является экспертом.

В противовес узкому специалисту («I-shaped») и специалисту широкого профиля (который «умеет всё, да по чуть-чуть»), T-специалист («T-shaped») является экспертом по меньшей мере в одной области, но при этом разбирается во многих других. Таких T-специалистов еще называют «generalizing specialist».

«I-shaped» vs Специалист широкого профиля vs «T-shaped»

Т-специалист адаптируется к различным требованиям

Продуктовой команде приходится выполнять много различных задач, и для каждой из них необходимы разные навыки. Читать далее «Почему T-специалисты?»

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

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

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

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

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

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

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