Планирование покера и многословных разработчиков [закрыто]

Моя команда состоит из 4 разработчиков; все опытные и опытные. Один из них - многословный, хорошо продуманный парень, который настаивает на том, чтобы определить техническое решение для наших историй, прежде чем мы изложим наши оценки в Planning Poker. Он отказывается оценивать, если у него нет приблизительного представления о согласованном техническом решении (что звучит разумно, верно?).

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

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

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

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

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

Похоже, ваш коллега не понимает разницы между оценкой и обязательством, или об этом не было сообщено ему во время обучения. И, так как вы пытались связать проблему с его личностью, возможно, что вся ваша команда еще не поняла это. (Но не волнуйтесь! Большая часть нашей индустрии не понимает этого. Agile - это сложно!)

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

Планирование покера вводит еще одну ошибку: вместо того, чтобы пытаться определить X, мы сопоставляем его с дискретной шкалой, наиболее популярной является шкала Фибоначчи (1, 2, 3, 5, 8 и т. Д.). Это говорит о том, что размер не так много, как он есть. Когда мы говорим, что размер истории составляет 3 балла, мы действительно говорим: «это Х плюс-минус некоторая дисперсия, и Х ближе к 3, чем к 2 или 5».

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

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

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

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

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