¿Cómo demuestra el rendimiento en entornos de programación emparejada?

Las evaluaciones de rendimiento han surgido recientemente en mi trabajo, y me pusieron en una posición interesante. Nuestro equipo realiza una gran cantidad de programación de pares, lo que tiende a promediar las diferencias de habilidades entre los miembros del equipo (especialmente teniendo en cuenta que rotamos los pares). En general, al hacer evaluaciones de desempeño, usted mira hacia atrás al trabajo que ha realizado y demuestra lo que ha logrado y cómo ha superado las expectativas para tratar de negociar un aumento u otros beneficios.

¿Cómo demuestra (o incluso mide) el desempeño individual en un entorno como este?

incluye el valor que agregaste a la programación de pares en la evaluación de rendimiento: ¿ayudaste al otro programador a aprender cosas útiles? (y viceversa, ¿escuchaste sus sabios consejos y cooperaste bien?)

una evaluación de desempeño no debe ser una competencia, debe ser una evaluación de entrenamiento en relación con sus objetivos personales (que presumiblemente están en línea con los objetivos de la compañía y acordados mutuamente al comienzo del año; de lo contrario, es arbitrario)

Sería difícil demostrar definitivamente un beneficio de rendimiento sobre el otro científicamente.

Su hipótesis es que la programación de pares aumenta el rendimiento del desarrollador y mejora la calidad. Su prueba implicará dar a un par un conjunto de requisitos restringidos a una arquitectura específica y hacer que lo implementen.

Su control en este caso es que le da los mismos requisitos a un único desarrollador de igual posición, habilidad y experiencia (según lo juzguen objetivamente sus pares) y también limitado dentro de la misma arquitectura.

Para verificar su hipótesis de rendimiento en el tiempo, los programadores de pares deben completar su trabajo en menos de la mitad del tiempo que el control. Para verificar su hipótesis sobre la calidad, debe hacer que un tercero objetivo revise el par de experimentos y el código de control, y que un grupo de control de calidad objetivo pruebe los resultados de ambos grupos sin decirles qué equipo produjo qué. El grupo de programación de pares debe tener un mejor código y menos errores.

No es un experimento perfecto, pero me encantaría saber si alguien ha intentado algo similar.

Además de esto, sin embargo, no puedo ver cómo puede demostrar de hecho que la programación de pares es superior a un solo programador en una función determinada.

En sus métricas de rendimiento, llame por separado 1) crecimiento y desarrollo individual, y 2) tutoría y apoyo entre pares. Permita que cada empleado se autoevalúe e incorpore los comentarios de sus líderes. Si tiene sentido en la cultura de su empresa, considere las revisiones o testimonios de colegas.

Si se hace correctamente, el empleado que está obteniendo el mayor valor educativo de un emparejamiento es recompensado por su capacidad a largo plazo de contribuir al equipo, y el empleado que está ayudando a ponerlos al día es recompensado por transferir conocimiento y experiencia. Las personas que están en algún punto intermedio (aprendiendo nuevos dominios en lugar de simplemente pasar de junior a senior) son reconocidas por ambos extremos de la ecuación.

En la práctica, calificar el desempeño individual es complicado en el mejor de los casos. Es bastante difícil hacerlo sin crear algunos sentimientos de resentimiento o competencia. Pero si califica la contribución individual al equipo y valora tanto el aprendizaje como la enseñanza, hay algunas posibilidades de que funcione con algo menos de fricción.

¿Los pares cambian a menudo? Si es así, puede usar revisiones anónimas para obtener un indicador. Por ejemplo, si la persona A dijo que B hizo el 60% del trabajo, la persona C dijo que la persona B hizo el 30% del trabajo, y la persona D dijo que la persona B hizo el 90% del trabajo, puede promediar eso a la persona B haciendo 60% del trabajo. Si el trabajo que la persona B realizó en sus pares tiene un factor relativo de 100 puntos, ¡entonces la persona B hizo 60 puntos de trabajo!

Sin embargo, esto no es (en ningún lugar cercano) perfecto. Es probable que las personas se den más crédito de lo que le dan a la otra persona, por lo que es posible que deba tener esto en cuenta en el cálculo. Esto también podría conducir a un entorno en el que las parejas sospechen unas de otras. El cálculo también puede ser cambiado por alguien que no le gusta la persona con la que está trabajando, etc.

Digo que si dos de nosotros trabajamos juntos para crear X, entonces ambos obtendremos crédito por haberlo terminado y desplegado. Donde podría tener un problema es cuando una parte de un par no funcionó en absoluto. En este caso, el gerente debería haber sido informado sobre esto todo el tiempo y, por lo tanto, debería usar esa retroalimentación al completar su comentario en la evaluación del desempeño.

Estás en la situación exacta en la que mi maestro nos pone a los estudiantes en nuestro plan de estudios de Desarrollo de juegos. Estamos emparejados (2, 3 o 4 personas dependiendo del tamaño de la clase y el tamaño del proyecto) y al final se nos dice que evaluemos a cada miembro del equipo y a nosotros mismos en relación con el proyecto y qué trabajo se realizó, así como los proyectos de los otros equipos en su conjunto. Se formula una calificación basada en estas evaluaciones.

Durante la formulación del equipo, el maestro ubicaría deliberadamente a un programador fuerte y a un programador débil con la esperanza de que trabajarían mutuamente y / o se ayudarían, pero el 99% del tiempo el programador débil patinaría y haría muy poco trabajo para ninguno o no tengo idea de lo que están haciendo (al ser los cursos avanzados, es muy frustrante).

Se supone que las evaluaciones son privadas, pero digamos que hay algunas personas con las que todos se niegan a trabajar.

La programación en pareja significa que una persona piensa qué y cómo se debe hacer algo, y la otra juega un mono codificador. Luego, en algún momento cambian (uno se aburre, se cansa, etc.). Es bueno, porque ambos no son interrumpidos en sus actividades.

Algunas personas también lo consideran como "la revisión del código de los esteroides". Obtiene código revisado, lo que debería significar una mayor calidad.

Buena pregunta. Lo importante no es simplemente lo que contribuyes, sino cómo tus compañeros ven tu contribución. Pídales sus comentarios sinceros, ya que es este comentario el que le ayuda a ser mejor 'lo que sea' . En serio, es importante que su compañero comprenda su contribución y la entienda solo cuando tenga una buena cantidad de conocimientos mientras se empareje con usted. Codificación feliz, intercambio y aprendizaje, lo que resulta en una buena ganancia.

La desventaja de la programación de pares es que la productividad del programador con más experiencia se limita a la productividad del programador con menos experiencia, a corto y mediano plazo. A largo plazo, la experiencia y la productividad aumentan en el desarrollador junior.