Что делать, если владелец продукта заболел?

Простой вопрос. Как вы проводите обзор спринта и планирование спринта?

Вы когда-нибудь слышали о конференц-мостах?
@WyattBarnett нет, что это?
Конференц-связь. Нет никаких оправданий тому, чтобы не провести встречу в 2011 году. Если только вы не в самолете, а это довольно сомнительно.
Если кто-то болен, он, скорее всего, не будет участвовать в телефонной конференции.
Почему у меня такое сильное желание сказать: «Отправьте ему открытку с выздоровлением или навестите его в больнице»
@WyattBarnett, бывают случаи, когда люди недоступны. Уверяю вас, что когда моя коллега заболела раком, она не могла отвечать на рабочие звонки или участвовать в телефонных конференциях. Я не смогла этого сделать, когда умер мой любимый. Нет никакого оправдания думать, что люди — это машины, которые доступны 24 часа в сутки, несмотря ни на что.
Как владельцу продукта мне нужно выздороветь, чтобы я мог присутствовать на совещании по планированию итерации. 5 баллов.
Связанный и возможный дубликат: pm.stackexchange.com/questions/27590/…

Ответы (2)

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

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

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

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

Если Обзор Спринта и Ретроспектива Спринта представляют собой одно собрание, любой, кто не участвует в процессе напрямую, не должен участвовать в ретроспективе. Например, я упомянул, что другой представитель клиента или группы пользователей может быть участником обзора спринта вместо владельца продукта. Если этот человек не работал тесно с командой, его попросят быть молчаливым наблюдателем ретроспективы (что может быть полезно для его обучения в качестве альтернативного владельца продукта) или полностью покинуть комнату.

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

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

Соглашусь на отзыв. Но для планирования без подробного описания требований ЗП может быть сложно интерпретировать элемент невыполненной работы по продукту, верно?
Документация @xsAce?
@xsAce - я не знаю, какой инструмент вы используете, но наш инструмент позволяет расставить приоритеты для невыполненных работ и холодильника.
@Chad Мы просто используем post its
@xsAce Опубликованная история должна содержать достаточно подробностей, чтобы ее можно было понять. Опять же, это относится к управлению рисками, и могут возникнуть некоторые вопросы, но если вы находитесь в ситуации, когда вы можете добиться нулевого прогресса, что-то не так с тем, как вы управляете проектом.
@xsAce - мне трудно поверить, что вы можете собрать всю информацию, необходимую для эффективного управления проектом разработки программного обеспечения, когда вы используете публикацию для управления своими историями, отслеживания своего прогресса и расстановки приоритетов в своей работе.
@ThomasOwens Спасибо, дело в том, что мы определяем все достаточные детали истории ВО ВРЕМЯ планирования, а не заранее. Я имею в виду, что именно тогда происходит передача знаний от ПО команде. Вот почему мне трудно планировать без него. Я не в ситуации, когда нам нечего делать, всегда есть место для работы, уменьшения долга и т. д. Но включить новые истории и провести новый спринт, который добавляет прямую ценность, — это то, что у меня есть. трудно увидеть, что происходит.
@xsAce Я бы рекомендовал, чтобы PO постоянно следил за тем, чтобы истории с наивысшим приоритетом были задокументированы в достаточной степени, чтобы их можно было разработать и протестировать в его отсутствие. Хотя передача знаний на совещании по планированию хороша для того, чтобы все были на одной волне, я чувствую, что у вас должно быть достаточно информации, чтобы что-то сделать, даже если это предварительная работа. Если вы не можете предоставить что-то ценное в конце запланированного спринта из-за отсутствия человека, вам нужно пересмотреть свой процесс, чтобы исключить это всезнание от одного человека.
@ThomasOwens Хотя я согласен с тем, что пропавший без вести не должен прерывать спринт, мы здесь не говорим о члене команды. Я имею в виду, что роль PO критична и НЕОБХОДИМА для процесса. Если бы его можно было так легко пересмотреть, он бы нам вообще не понадобился. Ответственность будет разделена командой напрямую. Я думаю, что решение больше связано с компанией и поиском кого-то, кто временно заменит PO, чем с пересмотром процесса. Но спасибо
@xsAce PO является членом команды Scrum. Скрам-команда состоит из владельца продукта, межфункциональной команды разработки продукта и скрам-мастера. В некоторых случаях PO также может быть членом группы разработки продукта. Независимо от того, кто является владельцем продукта и какие другие роли он выполняет, важно учитывать время, когда он недоступен, и относиться к этому как к риску, для которого есть стратегия смягчения. Простая стратегия смягчения последствий состоит в том, чтобы иметь альтернативного PO, который информируется обо всех решениях и коммуникациях, но фактически не принимает решения, если в этом нет необходимости.
@ThomasOwens хорошо, теперь я понял твою точку зрения.
+1 за ключевой момент «... иметь альтернативного PO, который информирован обо всех решениях и сообщениях, но фактически не принимает решения, если в этом нет необходимости».
«Ваш обзор спринта может быть проведен скрам-мастером, который, кажется, хорошо подходит для этого. В конце концов, вы размышляете о производительности своей команды и о том, как вы справлялись с проблемами и добивались успехов. Скрам-мастер, как хранитель процесса, должен быть осведомлен о целях с точки зрения сюжетных точек, функций и возникших проблем. Резюме может быть представлено Владельцу Продукта по его возвращении». ..... Эй, Томас, ты хотел сказать "ретроспектива спринта" здесь? Похоже, вы говорите о ретроспективе, а не о демонстрации спринта (также известной как обзор спринта).
@ jmort253 В последней скрам-команде, в которой я был (это было ~ 9 лет назад), они были такими же. В конце спринта было 1 собрание, на котором команда демонстрировала завершенные истории и оценивала, что пошло правильно/не так во время спринта. Это был обзор и переоценка продукта и процесса перед планированием спринта. Основываясь на других вещах, которые я читаю, объединение демонстрации продукта (обзор) и обзора исполнения (ретроспектива) в одну встречу не редкость, и я бы рекомендовал обеспечить присутствие всех заинтересованных сторон. и вовлечены.
@ThomasOwens - Из того, что я читал, в ретроспективе спринта участвует только схваточная команда; в противном случае людям может быть неудобно говорить о своих проблемах, особенно если некоторые из заинтересованных сторон являются менеджерами, руководителями или клиентами. Согласно Руководству по Scrum , обзор и ретроспектива — это отдельные встречи, и, по словам Майкла Джеймса, Майка Кона и моего инструктора CSM, ретроспективу посещают только Scrum-команда (а в некоторых случаях — только SM и команда разработчиков).
[продолжение] - Возможно, стоит уточнить, что вы практиковали модифицированную версию схватки, чтобы люди не путались между обзором и ретроспективой, когда дело доходит до схватки. Надеюсь, это поможет прояснить ситуацию, и спасибо за ваши посты. Они очень помогают нам в нашем движении к Agile и Scrum!
@ jmort253 Спасибо за это. Я отредактирую, чтобы уточнить. И еще немного покопавшись, кажется, что участники ретроспективы могут быть спорным вопросом - некоторые люди говорят, что это повышает ценность PO, в то время как другие утверждают (как вы говорите), что это только для команды. Я сейчас поясню этот ответ. Буду признателен за отзывы об изменениях.

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

Что делать, если владелец продукта заболел?
СпросиСетьПолитика конфиденциальности1y, 0v