Agile MVP (самый ценный игрок / программист)

Недавно я принимал участие в гибком проекте (с использованием scrum), где руководству пришла в голову идея, что команда назначит разработчика «MVP», а также QA «MVP» в конце каждого спринта, за который проголосовали команда. MVP затем получает небольшое денежное вознаграждение и бесплатный обед, а также трофей, чтобы выложить на стол. Пока у нас было два спринта с этой системой вознаграждений.

Хорошо, что я вижу из этого следующее:

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

Я заметил несколько вещей, которые я бы посчитал плохими сторонами в подобных вещах (по крайней мере, с точки зрения разработчика):

• Есть несколько разработчиков, которые настолько обеспокоены количеством, что качество исправлений ошибок упало. Исправления в одной области вызывают регрессию в другой.
• Есть несколько разработчиков, которые выбирают ошибки «проще / быстрее», чтобы увеличить количество ошибок. Думаю, здесь может быть хорошо или плохо.
• Дефекты с более высоким приоритетом (которые в большинстве случаев соотносятся с «сложнее / дольше исправить») фактически становятся дефектами с более низким приоритетом.
• Блокирующие дефекты не устраняются своевременно, так как обычно они занимают больше времени и требуют большей координации с QA.
• Командный аспект в команде разработчиков был потерян. Командный аспект совместной работы Dev и QA также не улучшился, но не сильно изменился по сравнению с предыдущим.
• Работа за исправлениями ошибок или работа с номером ТО не так легко распознать / отследить.

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

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

Agile подчеркивает командные усилия , а не усилия отдельных людей. Так что нет, этот подход явно не проворен.

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

Я предлагаю наградить команду в целом, если они хорошо поработали.

Я думаю, что это хороший пример применения «плохой геймификации» . Проблема в том, что у ваших программистов потенциально была мотивация в решении проблем и победе в трудных задачах (поиск и исправление серьезных ошибок) И, так как вы внедрили Scrum, работая в качестве КОМАНДЫ. Другими словами, они потенциально хотели сделать хорошую работу.

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

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

Что бы вы могли сделать, чтобы это исправить, попросить руководство немного изменить правила:

• давать баллы, соответствующие сложности и приоритетности билетов. Сделайте так, чтобы было гораздо интереснее, по точкам, исправить трудно найти / воспроизвести ошибку.
• дают очки для решения проблем кооперативно (опять же , команды). Здесь вы можете заставить больше программистов взаимодействовать с QA. Дайте очки за проблему, решаемую совместно программистом И, например, QA.
• дать разные названия, один для наибольшего количества очков и один для большинства билетов. Это должно удовлетворить конкурентные инстинкты программистов.
• возможно установить дружеское соревнование между разработчиком и QA, суммируя очки каждого члена команды

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

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

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

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

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

Выбирать несложные исправления и делать их поспешно или беспорядочно, не имеет смысла, поэтому разработчики, которые просто делают это, вероятно, не должны квалифицироваться как кандидаты MVP. Выбирая новый MVP, забудьте все о команде и людях в ней и посмотрите на программное обеспечение. Выберите самое важное изменение в этом программном обеспечении с прошлого раза. Я имею в виду холостяк здесь; «не так много крошечных ошибок» не является серьезным изменением. Была ли исправлена ​​особенно вопиющая ошибка? Была ли добавлена ​​отличная новая функция? Как только вы определили, что это за одно большое изменение, спросите, кто за это ответственен. Один из этих людей, вероятно, ваш настоящий MVP. Если «не так много маленьких ошибок» является единственной разницей, то и толькотогда число ошибок является допустимым показателем MVP - и даже тогда я бы посмотрел на соотношение исправленных ошибок и вызванных ошибок регрессии. Каждая ошибка, которую кто-то вызывает, вычитает по крайней мере 1 из их количества. На самом деле, я бы сказал, что больше 1, потому что плохое исправление приведет к неизвестной ошибке, которую вы затем должны найти, что хуже, чем известная ошибка, которая уже была найдена. Известная ошибка требует усилий разработчика для исправления; неизвестная ошибка требует усилий QA, чтобы найти, и разработчика, чтобы исправить, и тогда есть риск, что QA пропустит это.

Теоретически, если разработчики поймут, что путь к победе - это решить все меньше и больше проблем, они будут стремиться к сложным, сложным, блокирующим дефектам. Это потребует, чтобы они иногда объединялись, либо потому, что не хватает мясных проблем, либо потому, что проблема достаточно сложна, чтобы требовать больше наборов глаз . Возможно, предложите, чтобы в подобных случаях награду можно было разделить, если неясно, кто из множества людей больше работал над исправлением ошибки - и помните, работа сделана! = Написано строк кода. Разработчики, вероятно, знают это, но вы сказали, что руководство вовлечено, и руководство не всегда понимает этот момент.

И, эй, если ничего не помогает, забудьте программу MVP. Поговорите со своими коллегами-разработчиками вне суеты и отметьте негативное влияние, которое награды MVP оказывают на программное обеспечение. Посмотрите, сможете ли вы заставить их игнорировать это или не сделать это таким большим делом. Оставьте трофей в ящике, потратьте денежный приз на раунд напитков для команды после работы, используйте бесплатный обед, чтобы получить что-то, чем вы можете поделиться, например, кучу кексов. Agile - это командная система; выделение отдельных рисков производительности, противопоставляющих команду друг другу. Объединенный вы стоите, разделенный вы грузите программное обеспечение, заполненное ошибками, после крайнего срока, сверх бюджета.

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

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

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

Я провел несколько семинаров по этой теме, и этот конкретный вопрос время от времени выступает в качестве примера в группах. Применение теории материальных ценностей к делу, которым вы поделились в своем вопросе, может выглядеть примерно так ...

Предположите, что ваша команда ценит последовательность, предсказуемость и высокое качество кода.

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

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

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

И это только некоторые примеры, демонстрирующие подход и способ начать ...

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

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

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

Вознаграждение командной работы, и команда заметит, что важна КОМАНДА, а не их личный успех.