Что делать, если член команды пропускает планирование спринта?

Допустим, член команды находится в ежегодном отпуске. Он не будет посещать планирование спринта, но вернется к середине итерации / спринта. Допустим, у него есть 50% -ая емкость, то есть, поскольку он будет доступен для следующей половины итерации, мы должны:

1. запланировать с ним сессию после его возвращения.

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

3. не назначайте его для выполнения каких-либо задач и назначайте его для задач, не связанных со спринтом, например, с шипами и т. д.

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

5. пусть он посидит с другим разработчиком и некоторое время занимается парным программированием.

6. что-нибудь еще..

мне интересно знать, что ты делаешь ..

Примечание: мы делаем (1), и это не правильно.

Планирование - это выполнение обязательств и разделение преданных пользовательских историй на задачи.

запланировать с ним сессию после его возвращения.

Определенно нет. Планирование сессии после его возвращения не имеет смысла, потому что обязательство должно было быть уже выполнено.

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

Определенно нет. Не должно быть никакого планирования, когда текущий спринт не завершен = результат текущего спринта неизвестен, и никто не знает, будут ли завершены все пользовательские истории, и клиент будет удовлетворен ими при рассмотрении.

не назначайте его для выполнения каких-либо задач и назначайте его для задач, не связанных со спринтом, например, с шипами и т. д.

Определенно нет. Он вернется, и его потенциал должен быть использован для спринта.

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

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

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

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

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

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

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

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

Трудные времена говорят о том, насколько профессиональна команда. В команде среднего размера в нашей компании всегда есть человек, который пропускает встречу по планированию спринта. Мы не криминализируем его / ее. Мы считаем, что он достаточно зрел, чтобы принять ее решение :)

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

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

Люди всегда стремятся к отдыху :-) не навреди.

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