Комментарии, вопросы, пожелания приветствуются.
Буду рад ответить на ваши вопросы: alimbekovr@hotmail.com.

5 заметок с тегом

Scrum

Роман Пихлер Управление продуктом в SCRUM Agile методы для вашего бизнеса

Аннотация

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

Роман Пихлер Управление продуктом в SCRUM Agile методы для вашего бизнеса

Роман Пихлер Управление продуктом в SCRUM Agile методы для вашего бизнеса
Издательство: Манн, Иванов и Фербер— 2017

Скачать краткий конспект в формате Word или pdf.

Купить цифровую книгу в Ozon или ЛитРес, бумажную книгу в FLIP или Ozon.

Введение

Не так давно попала мне в руки новая книга по Scrum Романа Пихлера — Управление продуктом в SCRUM Agile методы для вашего бизнеса. Книга оказалось очень интересной, понятной и она содержит много полезных нюансов, которых нет в скрайм-гайде. Наиболее интересные моменты постараюсь описать в этом конспекте.

Характеристики правильного владельца продукта

Визионер и человек действия способный оценить трудоемкость всех этапов работы вплоть до ее завершения. Он может описывать требования, тесно сотрудничать с командой, принимать или отвергать рабочие результаты и руководить проектом, отслеживая и предсказывая его прогресс.
Лидер и командный игрок, отвечая за успех продукта, он обеспечивает руководство всеми, кто занят разработкой, и готов принимать сложные решения. Например, укажет, отложить дату запуска или ограничиться меньшей функциональностью. В то же время владелец продукта — командный игрок, он вступает в тесное сотрудничество с другими членами scrum-команды и не обладает формальной властью над ними. Мы можем определить владельца продукта как primus inter pares — первого среди равных в том, что касается продукта.
Пропагандист и переговорщик- этот человек общается с разными сторонами, объединяя клиентов, пользователей, разработчиков, инженеров, маркетологов, сотрудников отдела продаж, операционных сотрудников и руководство.
Наделенный полномочиями и преданный делу — владелец продукта должен обладать полнотой власти для принятия решений, касающихся любых аспектов — подбора подходящих членов команды, определения того, какая функциональность будет входить в тот или иной релиз, и т. д
Доступный и квалифицированный владелец продукта должен быть доступным и иметь нужный уровень квалификации. Его роль обычно предполагает полную занятость. Важно предоставить владельцам продукта достаточно времени для эффективного выполнения своих обязанностей. Если человек перегружен, от этого страдает результат, а получившийся продукт бывает не оптимальным.

Распространенные ошибки при выборе владельцев продукта

  1. Владелец продукта с недостаточными полномочиями
  2. Перегруженность владельца продукта
  3. Частичный владелец продукта
  4. Удаленный владелец продукта
  5. Заместитель владельца продукта
  6. Комитет владельцев продукта

Техники формирования видения продукта

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

Распространенные ошибки при формировании видения продукта

  1. Отсутствие видения
  2. Пророческое видение
  3. Аналитический паралич
  4. «Мы-лучше-знаем-что-нужно-клиентам»
  5. «Большое — значит хорошее»

Работа над бэклогом продукта

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

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

Планирование релиза

Планирование релиза начинается с принятия решения о том, какая из составляющих проекта — время, затраты или функциональность — должна остаться неизменной для запуска успешного продукта. Необходим ли запуск именно в указанную дату? Жестко ли задан бюджет на разработку? Нужно ли реализовать все требования, отраженные в бэклоге продукта? Одновременная фиксация времени, бюджета и функциональности невозможна. По крайней мере одна из составляющих должна играть роль высвобождающего клапана. Самое удачное решение — ограничить время и делать гибкой функциональность.
Фиксирование функциональности — плохой вариант. Даже при наличии видения продукта его точные свойства, функциональность и особенности не известны сразу. Они открываются постепенно, на основе отзывов клиентов и пользователей. Появляются новые требования, бэклог продукта развивается по мере того, как scrum-команда больше узнает о потребностях клиентов и возможностях их удовлетворения. Попытка фиксировать функциональность вредит способностям команды адаптировать продукт к отзывам пользователей. В результате получится не тот продукт, который могут полюбить покупатели.
План релиза — это своего рода карта, показывающая нам направление. Он показывает, насколько мы приблизились к выпуску продукта и когда он состоится. Можно сказать, что план релиза — это расширенная версия диаграммы сгорания работ. Он не только содержит больше информации, но и более комплексный. План релиза основывается на четырех факторах: элементах бэклога продукта, оставшегося объема работ, скорости команды и времени. План релиза не является фиксированным. Он меняется вместе с развитием бэклога продукта, а также нашего понимания оставшегося объема работ и скорости. Как и диаграмму сгорания работ, план релиза лучше всего составлять и обновлять совместными усилиями команды во время демонстрации результатов спринта

Прогнозирование скорости

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

Критерии готовности

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

Вывод

Отличная книга для тех, кто только начал знакомится с фрэймворков Scrum так и для тех, кто уже в теме, эта книга поможет взглянуть по-новому. Рекомендую.

Игры для практического закрепления Scrum и Kanban

В одном из своих прошлых постов я делился опытом игры на тренинге по информационной безопасности Kaspersky Industrial Protection Simulation. В конце поста я выражал заинтересованность по созданию игры для проведения тренинга по Scrum. Как оказалось я был не одинок в своем желании.

Совсем недавно я проводил тренинг по Agile, Scrum и Kanban и для практического закрепления искал в Интернете разные игры и нашел пару интересных вариантов, о которых расскажу.

Scrum Card Game — игра симулятор. Скачать игру можно на сайте, есть, в том числе и русская версия. Автор распространяет игру на условиях Creative Commons, то есть вы ее изменять преобразовывать и так далее.

Scrum Card Game — это простая игра-симуляция, которая позволяет участникам почувствовать динамику работу по Scrum, получить навык работы спринтами и обсудить много вопросов связанных с тем, что случается в реальной работе Scrum команд. Количество людей в команде по 4-5-6 человек, желательно поровну. Играть могут не более 6 человек в одной команде.

Цель игры: Каждая группа — независимое подразделение, нацеленное на создание нового приложения для рынка. Побеждает наиболее продуктивная команда.

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

Scrum Card Game
Scrum Card Game

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

GetKanban это командная игра для закрепления практик Kanban. Идеальный размер команды 6 игроков. В игре есть 4 роли, каждая из которых требует к себе внимания и будет хорошо, если в команде будет два дополнительных участника, которые помогут игрокам, исполняющим роли. Если же в команде будет более 7 человек, то некоторые игроки будут выпадать из игры.

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

GetKanban
GetKanban

Игра нереально заразительная и интересная. Содержит разные события и ваше решение брать их или не брать влияет в  дальнейшем на игру результат. Игра достаточно долгая, мы играли 2 часа и я даже не заметил, как пролетело время. Очень динамично развиваются события. Фото с игры:

По этой игре я тоже для себя буду делать наборы для проведения тренингов.

Если вам или вашей команде нужен тренинг — семинар по Agile, Scrum или Kanban (в том числе с применением вышеуказанных игр) прошу писать на почту alimbekovr@hotmail.com

Новая редакция Scrum Guide — ценности

Впервые с 2013 года, в июля 2016 выпущено обновление руководства по Scrum Кеном Швабером и Джеффом Сазерлендом, и самое большое изменение в этой версии Руководства является добавление раздела Scrum ценностей.

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

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

Успешное использование Scrum зависит от людей, которые разделяют и используют эти пять ценностей. Люди, берут на себя обязательства по достижению целей команды. Члены команды имеют смелость сделать правильный выбор и работать над решением трудных проблем. Каждый человек сосредотачивается на работе над спринтом и целями команды во время спринта. Scrum команды и ее заинтересованные стороны согласились открыто говорить о всей работе и проблемах, возникших с выполнением работы. Члены Scrum команды уважают друг друга, как способных, независимых людей.

Новая редакция Scrum Guide - ценности

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

Эти ценности звучат легко? Ну, есть несколько недоразумений и общие проблемы при применении этих ценностей. Вот несколько примеров.

Ценность Непонимание Правильное значение ценности
Обязательство Совершение чего либо, что вы не понимаете, потому что вам сказал так ваш босс. Посвящает себя команде и цели спринта.
Сосредоточенность Сосредоточенность на сохранении клиента счастливым Сосредоточенность на спринте и его цели.
Открытость Рассказывать всем все обо всей вашей работе Подчеркивать, когда у вас есть проблемы и проблемы, которые препятствовали успеху
Уважение Думать, что вы помогаете команде, будучи героем Помочь людям, чтобы они узнали то, в чем вы хороши и не судить людей за то, что другие не умеют.
Смелость Даже после того, как было принято решение продолжать тормозить Быть прозрачным, но готовым к изменением, даже если это означает признание того, что вы не правы, или что ваше мнение не направлено в направление, куда идет команда.

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

Ценности  — определяют поведение людей, а поведение определяет результаты.

Успешность использования Scrum напрямую зависит от того, насколько люди разделяют пять ценностей.

Ctrl + ↓ Ранее