Как вы демонстрируете производительность в средах парного программирования?

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

Как вы демонстрируете (или даже измеряете) индивидуальные результаты в такой среде?

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

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

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

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

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

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

Это не идеальный эксперимент, но я был бы рад услышать, если бы кто-нибудь пытался сделать что-то подобное.

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

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

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

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

Часто ли пары переключаются? Если это так, вы можете использовать анонимные отзывы, чтобы придумать датчик. Например, если человек A сказал, что B выполнил 60% работы, человек C сказал, что человек B выполнил 30% работы, а человек D сказал, что человек B выполнил 90% работы, вы могли бы усреднить это на человека B, выполняющего работу. 60% работы. Если работа, которую человек B выполнил в своих парах, имеет относительный коэффициент 100 баллов, то человек B выполнил работу на 60 баллов!

Тем не менее, это не (где-то рядом) идеально. Люди могут отдать себе больше кредитов, чем другим, поэтому вам, возможно, придется учесть это при расчете. Это также может привести к обстановке, когда пары с подозрением относятся друг к другу. Расчет также может быть изменен кем-то, кому не нравится человек, с которым они работают, и т. Д.

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

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

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

Оценки должны быть частными, но, скажем так, есть несколько человек, с которыми каждый отказывается работать.

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

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

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

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