Советы по работе с программистом-ковбоем в agile-команде

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

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

Ответы (7)

Судя по всему, вы изолировали эту проблему от разработчика, и это (imo) означает, что вам необходимо изменить свой процесс, чтобы такие проблемы не возникали постоянно, или изменить взаимодействие с этим разработчиком.

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

Расползание масштаба происходит из-за плохо понятой пользовательской истории:

Вы ИНВЕСТИРОВАЛИ в написание хороших пользовательских историй?

Есть ли у ваших историй четко определенные критерии приемлемости (критерии приемлемости — это требования, которые должны быть соблюдены, чтобы история считалась завершенной)?

Если вы ответили на эти вопросы «да», то вы можете обсудить с командой изменение процесса, когда член команды берет задачу с доски, чтобы включить обсуждение с владельцем продукта (или кем-либо, кто когда-либо представлял PO). . Это обсуждение просто предназначено для того, чтобы убедиться, что разработчик четко понимает, что означает «Готово».

Расползание масштаба — это симптом разработчика, а не процесса:

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

Если их поведение не изменится после этого обсуждения, я бы удалил их из команды.

Расползание масштаба — это признак того, что команда определяет состояние «готово»:

Как истории принимаются в вашей команде? По звуку этого вы говорите, что когда история перемещается в состояние «готово», к ней добавляется большое количество наворотов, но она все равно перемещается в состояние «готово» и «принято».

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

Ползучесть масштаба — это симптом индивидуального дизайна:

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

+1 за хорошее определение проблемы (расширение масштаба) и источников расширения масштаба в Agile. Также: bair = опечатка
Спасибо, очень хорошо объяснил. Очевидно, что в моем случае расползание области действия исходит от разработчика. Так что я попробую поговорить с ним и, как предложил Клейтон, использовать парное программирование.

Люди и взаимодействия важнее процессов и инструментов

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

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

да, парное программирование - хорошая идея!

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

  1. она должна была интегрировать, развернуть и выпустить его в одиночку
  2. когда кто-то другой не смог протестировать, интегрировать или развернуть ее решение, команда перестала работать, и она тоже, и ей пришлось решать проблему.
  3. когда руководство спросило нас о потраченном времени, ей пришлось объяснить «плюс», включая задержки, о которых я упоминал ранее.

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

При правильном подходе (в виде заданий), а не в виде унижения/наказания перед группой (если только они не достаточно сильная личность), иногда это может сработать. Хотя есть и третья возможность: они принимают это как данность в процессе, а не как исключение, и что они могут внедрить любую функцию в производство, если они достаточно сильно захотят, пока они готовы работать беготней.
Я согласен, это определенно должно быть частью процесса для всех, и это не должно звучать как наказание.

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

Расследовать. Что является источником ковбойского поведения при кодировании?

Как менеджер вы должны знать свою команду (ы) и мотивацию людей. Одну из возможных проблем упомянул @Jeese, и она может быть наиболее вероятной. Но, пожалуйста, помните, что для того, чтобы найти правильное решение, вы должны быть уверены, что хотите вылечить.

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

Сделайте это беспроигрышным

@ Jeese также сказал очень важную вещь: если у них есть «идеи», вы должны поощрять их продвигать их, но не слепо кодировать их в историю.

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

Измерьте и решите

@ Дэвид сказал важную вещь: хорошие вещи могут исходить от мошеннических человеческих ресурсов, но много плохих вещей исходит от него .

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

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

Если бы у вас была полностью автоматизированная задача, которая «занимает много времени, чтобы закончить ее, а в результате получается решение и« нечто большее », вы бы это потерпели? Или вы бы нашли неисправный компонент и исправили/заменили его?

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

Не стоит, на мой взгляд. Найдите неисправный компонент, исправьте или замените.

В этом заключается вызов быть лидером. Принимать непопулярные, неэмоциональные и убедительные решения, в которых задействованы люди, объективно анализировать проблему, помня о том, что люди — это такие же активаторы возможностей, как и молот, но при этом относиться к ним с уважением и достоинством, в отличие от молотка. Если от этого у вас переворачивается живот, значит, эта работа не для вас.
К счастью для меня, за свой более чем 10-летний опыт работы программистом я только однажды встретил PM, который обращался со мной как с молотком, и он продержался очень недолго, выполняя эту работу.
Правильно, yms, талантливые лидеры умеют принимать трудные решения, относясь к своей команде с уважением и достоинством. Те, кто не знает, как это сделать, могут не продержаться так долго. Но не обманывайте себя, анализ, к которому вы, по-видимому, не причастны, холоден и бесстрастен.
На самом деле, yms, каждая отрасль и область требуют инноваций, исследований и разработок для дальнейшего развития. И есть проекты инвестиционного типа именно для такой работы. И в этих проектах эти ученые и практики могут проводить мозговые штурмы, создавать и экспериментировать со всем, что захотят. Из этого появляются новые идеи, которые клиент покупает в рамках проекта разработки, где все, что нужно, это разработать его. НИКАКОЙ клиент никогда не должен платить за то, чтобы какой-то практик преследовал идею, если только клиент не соглашается, и в этом случае он больше не является мошенником.
Что вам нужно сделать, так это устроиться на работу, на которой вы несете ответственность за эффективность своих возможностей в соответствии с миссией, где вы отвечаете за ВСЁ: расходы, доходы, цепочку поставок, людей, инструменты, ВСЁ. Сделайте это в течение пяти лет — нет, сделайте это в течение трех лет — и тогда давайте обсудим это. Кстати, оригинальный OP назвал кодера «ковбоем». Кодировщик заработал прозвище. Я не знаю, как вы можете понять это и решить, что при таком сценарии было бы неплохо оставить его. Вы должны понимать управление объемом и плохие результаты покрытия золотом.

Как насчет использования интегрированной методологии кнута и пряника:

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

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

Будем надеяться, что он получит больше от публикации историй на публичном форуме, чем от реализации их самостоятельно.

Вы только что нашли отличного кандидата и будущего менеджера. У этого человека есть свои идеи. У него есть характер, чтобы шлифовать их. Он не боится делать то, что считает лучшим. Он не боится погорячиться и т. д. Интересно, ему просто скучно и нужны ли ему новые интересные проекты или задачи? Вы должны бросить ему вызов. Дайте ему что-то очень трудное или почти невозможное. Дайте ему короткий срок, чтобы сделать это. Запланируйте честное вознаграждение, если он добьется успеха, и сообщите ему об этом заранее. Я бы поговорил с вашим менеджером об этом человеке и назначил бы его наставником. Если он будет сотрудничать со всем этим и докажет свои способности; он будет большим активом для вашей команды и compagny.

Советы по работе с программистом-ковбоем в agile-команде
СпросиСетьПолитика конфиденциальности1y, 0v