Правильно ли оценивать участников Scrum в соответствии с количеством успешных пользовательских историй?

Когда мой менеджер сказал команде, что « теперь успешные пользовательские истории будут рассматриваться для оценки! »

Мы сидели там какое-то время в шоке, и это был один из нескольких моментов, которые он нам дал: «)

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

Дайте мне знать, что вы, люди, думаете? и как мы можем убедить его?

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

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

Инстинкты ваших команд верны. Какие источники я бы посоветовал вам в краткосрочной перспективе прочитать, когда вы будете мозговым штурмом отвечать своему менеджеру? Посмотрите блоги известных экспертов по гибким технологиям, таких как Майк Кон , Мартин Фаулер , Элизабет Хендриксон , Юрген Аппело , Эстер Дерби и некоторые другие, и найдите статьи об организации гибкой команды.

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

Мы всегда ищем вклад, который программист вносит в команду и бизнес.

Это на уровне измерения строк кода или количества ошибок - но немного сложнее.

На первый взгляд, нет ничего плохого в измерении, но когда вы думаете об этом, вы начинаете выдвигать возражения:

• как насчет более сложных историй?

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

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

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

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

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

1. Ведущие знают и понимают способности людей в своей команде.
2. Менеджеры прислушиваются к рекомендациям лидеров для членов команды, которые не набирают вес.
3. Команду в целом хвалят за успешные спринты.

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

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

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

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

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