¿Utiliza resultados de compilación continuos como parte de las métricas de revisión de rendimiento? [cerrado]

11

Mi jefe planea usar las métricas de nuestra compilación continua (compila y ejecuta pruebas en cada confirmación) como parte de nuestras revisiones de rendimiento (en nuestra métrica de 'calidad'). Esto parece una REALMENTE mala idea para mí, pero me gustaría saber si alguien ha estudiado esto o visto esto probado antes.

Mi opinión es que nuestros desarrolladores no realizarán tantas pruebas como lo harían de otro modo, por temor a que las pruebas fallen. Siento que está convirtiendo una valiosa herramienta de desarrollador en un palo para vencer a los desarrolladores.

El contraargumento obvio es que promoverá que las personas sean más cuidadosas antes de comprometerse y, por lo tanto, conducirán a una mayor calidad.

¿Estoy fuera de la base aquí? Deje a un lado la pregunta de si deberíamos hacer evaluaciones de rendimiento o no, eso se ha respondido en otro lugar.

continuous-integration Michael Kohne
fuente
8
Cualquier sistema que se pueda jugar es una entrada horrible para una evaluación de rendimiento.
Steve Jackson
¿Todos tienen la opción de no probar?
JeffO
1
@Steve, y los "sistemas" que no se pueden jugar te dan una pequeña visión estrecha de la imagen más grande. Para realizar un seguimiento realmente preciso del rendimiento se requeriría trabajo en las piernas.
maple_shaft
2
Tenga en cuenta que algunas cosas funcionan bien en las máquinas de los desarrolladores, pero fallan en el servidor de compilación (una dependencia accidental de un jar externo, forma incorrecta de usar / y \ en cajas de Linux, etc.). La razón principal del servidor de compilación es detectar estas cosas, no hostigar a nadie por no probarlas primero. En otras palabras, esta es una mala idea.
1
Seguimiento: Después de comenzar a hacer esto, descubrí que el mayor problema no tenía nada que ver con los otros ingenieros y la disposición para escribir las pruebas adecuadas, sino con el hecho de que nuestras pruebas existentes eran REALMENTE inestables, por lo que cada compromiso tenía una posibilidad bastante grande de romper sin culpa de la persona que comete. Este factor disminuyó el entusiasmo de todos por probar mucho más que cualquier efecto de la evaluación del desempeño.
Michael Kohne

Respuestas:

7

Las revisiones de rendimiento están bien, pero ¿qué hay de métricas útiles como:

  • Porcentaje de cobertura de prueba unitaria en funciones
  • Capacidad para cumplir plazos
  • Documentación clara y concisa
  • Siga las convenciones de codificación adecuadas
  • Se comunica bien con los demás.
  • Capacidad para convertir requisitos e historias de usuarios en tareas

Todas estas son buenas formas de medir el rendimiento, pero los problemas que la administración parece tener con ellos es que realmente requieren ... ummm ... bueno, ya sabes ... TRABAJO REAL de su parte.

Desafortunadamente, la mayoría de la gerencia tiene la actitud: "Al diablo con eso, quiero juzgar a mis empleados según las métricas que en realidad no requieren que me mantenga al día con lo que están haciendo".

árbol de arce
fuente
1
+1 por proporcionar algunas buenas opciones de qué métricas son útiles.
David Ruttka
3

Jugar el sistema aquí es bastante probable, en mi opinión, y tu jefe tiene que encontrar formas de evitar que eso sea la realidad. El otro caso que no mencionó es cuando los desarrolladores se comprometen toneladas de veces para que haya una avalancha de registros donde el número de modificaciones es relativamente bajo, como si hubiera una parte de la revisión donde se usa el recuento de compilaciones. es donde esto se convierte en una nueva herramienta que podría ser mal utilizada con bastante facilidad. Estoy pensando en los registros en los que se cambia el nombre de algo o se cambia el espacio en blanco es un registro y cuenta como alguna forma de productividad sería la visión pedante.

JB King
fuente