process - usar - Código de Calidad
usar atributo alt en html (19)
Trabajo para una empresa de desarrollo de software y tenemos alrededor de 100 personas trabajando en un producto, y una tercera parte de estas personas es de control de calidad. Últimamente, la administración quiere tener una mejor manera de calificar el desempeño de los programadores individuales, por lo que la sugerencia fue utilizar los informes de errores como medida. Cuantos más informes de errores en un desarrollador, peor es él. Esto parece mal aconsejado por más razones de las que puedo decir, por ejemplo, es una forma subjetiva de medir, los desarrolladores trabajan en diferentes proyectos de diferente complejidad. Además, si el QA se mide por la cantidad de informes de errores que generan, habrá muchas discusiones sobre la validez de los informes de errores.
¿Cuál sería una mejor manera de medir el rendimiento de los desarrolladores en tal entorno?
Una sugerencia sería no utilizar los informes de errores de control de calidad como medida y, en su lugar, utilizar informes de errores externos, como los probadores beta que, cuando se emiten dichos informes de errores públicos, también permiten medir el control de calidad.
EDITAR: # 1 Después de leer algunas de sus excelentes respuestas, pensé que el problema general con la métrica descrita anteriormente es que es un error de informe negativo, no alienta a producir código de buena calidad.
EDIT: # 2 Creo que el problema es que son dos mundos. Por un lado, hay personas que no son programadores que tratan a los programadores como trabajadores, básicamente, quieren métricas loc / minuto de preferencia. Luego tenemos a los programadores, que quieren verse a sí mismos como artistas o artesanos, "por favor, no me molesten, estoy programando" :) No creo que la medición de la calidad pueda realizarse con métricas, sin ser contraproducente. En cambio, las cosas sobre cómo reacciona una persona ante los errores, la voluntad de cambiar, la creatividad y, sobre todo, la calidad del trabajo son importantes y, en su mayoría, no son necesariamente medibles.
Después de leer algunas de sus excelentes respuestas, pensé que el problema general con la métrica descrita anteriormente es que se trata de errores de notificación negativos, no alienta la producción de código de buena calidad.
Eso es verdad. Y tendrá el mismo problema con cualquier otra métrica que aplique. El problema clave es que la calidad no es algo que sepamos medir numéricamente. Además, realmente no debería preocuparse por la cuestión de la calidad del código, principalmente si está haciendo su trabajo correctamente. Su verdadera pregunta debería ser: "¿Cómo nos ayuda esta persona a ganar dinero?"
La evaluación no es algo que puedas hacer con los números, pero es algo que debes tratar de hacer. El mejor consejo que puedo darle es que sus gerentes simplemente tienen que trabajar con los programadores y entender lo que están haciendo. Otra fuente importante de información proviene de los compañeros de un programador que trabajan con ellos día tras día. Ya que no tenemos una forma numérica de medir la calidad, en algún grado u otro tendrá que confiar en la ciencia más suave para obtener una idea de qué tan bien se están desempeñando sus programadores.
Antes de implementar cualquier tipo de métrica, pregúntese ... en última instancia ... ¿qué es lo que desea medir?
-Programador de productividad ¿no estás escuchando? duh
-Sí claro .. pero ¿por qué es esto importante?
Involucrar a los seres humanos en las métricas, inevitablemente, intentará optimizarlos para sus propios objetivos, por lo tanto, sabiendo esto, debería poder utilizar esta optimización en su beneficio.
- Pregúntese, entonces, si alguien optimiza la métrica, ¿en qué se concentrará?
Luego dirija su métrica para medir algo que afectará positivamente el sistema, por lo tanto, en lugar de medir errores por programador que solo le da munición a la administración para disparar si las cosas van mal, intente medir dónde y por qué ocurren los errores, no quién los fabricó.
por lo tanto, los errores por módulos, errores por versiones, errores por corrección de código, errores por características serían métricas mucho más productivas y ayudarán a identificar puntos de acceso. Por supuesto, siempre puede vincularlo a alguien, ya que siempre hay un enlace indirecto a un programador, pero antes de colocar a un programador en la vanguardia de la guerra de la culpa, es mejor que esté seguro de que HE-SHE es la causa.
- Pregúntate a ti mismo qué tipo de entorno quieres crear? ¿Cuál será la reacción del equipo, los gerentes y los directores cuando se enfrente a la publicación de la métrica?
Si usted mide a las personas y las hace lucir mal, entonces está pidiendo un problema. Si le da un poco de satisfacción al producto, entonces no se centrará en hacer que se vean bien, sino en hacer que el producto se vea bien. Esto a su vez será un motivador mucho mejor y fomentará el espíritu de equipo positivo.
- Haga que su métrica sea pública, cualquier tipo de ocultación de información causará reacciones adversas e injusticias. Por lo tanto, si publicas tus métricas, ten cuidado con lo que dicen.
Por último, si realmente se trata de medir personas, mídalos a todos, programadores, arquitectos, gerentes, vendedores, directores, todo el mundo debería tener el mismo escrutinio. Luego esconda los cuchillos y coloque detectores de metal en las puertas. Por lo general, la transparencia con las personas en una empresa solo funciona de una manera, desde arriba mirando hacia abajo.
Bien dicho por Chris.
Tuvimos un problema similar en nuestra oficina. El CEO y otras grandes pelucas no sabían cómo medir la calidad del desarrollador e implementaron sus propias medidas ridículas. Totalizar el número de errores de un desarrollador definitivamente no es la medida a seguir. No sé si hay una respuesta perfecta, pero espero que mi trabajo se mida por el cumplimiento o no de los plazos y los comentarios de los consumidores (si están contentos con el producto).
El gran problema que veo con los informes de errores del campo es que un programador puede haber programado el 100% de acuerdo con las especificaciones que recibió y el problema en el campo se debió a especificaciones deficientes o incompletas.
Permítame darle un ejemplo: usted desarrolla y prueba una aplicación en Windows Vista de 32 bits y luego falla en un sitio del cliente donde están ejecutando Windows XP de 64 bits. ¿Fue eso un fallo de los programadores (especialmente si nunca le dio una máquina con XP de 64 bits para probar)?
Una vez que te das cuenta de que puede surgir un error por muchas razones, solo algunas de las cuales el programador tiene el control, debes tener mucho cuidado de no configurar un entorno que lleve a la detección y la habilidad de los dedos. Todos los miembros del equipo deben trabajar juntos para mejorar el producto, no pasar el día tratando de culpar a los demás por los errores.
Hagas lo que hagas, no crees un sistema de incentivos en el que alguien obtenga puntos de bonificación por demostrar que fue culpa de otra persona. Los errores deben ser vistos como propiedad de toda la organización.
El problema fundamental que tengo con este tipo de sistema de calificación es que terminas con tu equipo compitiendo entre sí, en lugar de cooperar entre sí. ¿Cuál sería el incentivo para trabajar en partes difíciles del código si supiera que podría pagar una multa? Simplemente elija las cosas más fáciles que son menos propensas a errores. ¿Por qué ayudar a su colega a mejorar su código cuando esto lo beneficia y potencialmente lo perjudica con respecto al sistema de calificación?
Creo que es mejor utilizar la presión de grupo para aumentar la calidad del código: nadie quiere escribir basura y nadie quiere ser conocido por escribir basura. Haga un esfuerzo real para reducir los defectos con TDD, o al menos con la prueba de la unidad. Mover a la integración continua y dar a conocer quién rompe la construcción. Asuma la responsabilidad de la persona que rompe la construcción para solucionarlo antes de que pueda crear cualquier código nuevo. Cosas como esta aumentarán la calidad.
Una vez que todos estén de acuerdo con los objetivos de calidad, califique al equipo, no a los individuos. Que sea un verdadero beneficio trabajar cooperativamente. Si tiene vagos que se aprovechan del equipo, y todos sabrán quiénes son, trabaje con ellos para mejorar y, si no lo hacen o no pueden, recorte sus pérdidas y encuentre a alguien que se adapte mejor al equipo. . Si tiene las personas adecuadas, probablemente nunca llegará a este punto. Si son las personas equivocadas, tanto usted como ellos están mejor sabiéndolo y avanzando para un mejor ajuste.
Si alguien en el equipo realmente va más allá, recompénselo con algo adicional, pero asegúrese de que realmente haya sido un esfuerzo extraordinario más allá del resto del equipo. Si ese es el caso, al equipo no le importará (demasiado) porque sabrán que su recompensa compartida fue en gran parte debido al esfuerzo de esa persona.
Obviamente, todo lo anterior debe tomarse como reglas generales. Aunque a ellos les gusta llamarlo ciencia de la administración, en realidad es más un arte. Entender la dinámica de su equipo es un asunto complicado, pero creo que la regla general debería ser alentar y recompensar el trabajo en equipo.
Errores encontrados por QA = bueno. Errores encontrados por los clientes = mal.
Si necesita medir a los desarrolladores, use #bugs encontrados DESPUÉS de las pruebas, es decir, en el código de Producción / Lanzamiento / ''en el disco''.
La misma métrica para el control de calidad ... "un equipo, un sueño".
Miguel
Esa es una métrica horrible, por las razones que mencionaste.
Además, los informes de errores "externos" también son una forma injusta y poco confiable de juzgar a los desarrolladores. ¿Qué sucede si algunos desarrolladores trabajan en un área de código que se usa más que otros? Si se usa mi función, mi 80% de los usuarios y el 1% lo usan, ¿quién crees que va a ver más informes de errores?
Cualquier métrica que se pueda jugar fácilmente, o que ofrezca incentivos a otras personas para que jueguen con ellos, también es horrible.
Esta idea solo me hace querer / facepalm.
Bueno, yo mismo tuve un jefe, hace 10 años que me propuso pagarme por SLOC.
Renuncié el mismo día.
Esta métrica apesta y fomentará las malas prácticas y las luchas internas en cuanto a quién causó qué error. Cualquier métrica de falla debe ser compensada por una medición de éxito. Las personas que escriben más código tendrán, por definición, más oportunidades para cometer errores. Dependiendo de los datos disponibles, es posible que desee normalizar su sistema de calificación. Si un desarrollador implementara una función sin defectos, no lo calificaría de ninguna manera mejor que un desarrollador que implementó 243 funciones con 3 defectos. La calificación de los desarrolladores requiere que la gerencia ponga aparte los números y observe a cada miembro del equipo. Un gerente comprometido comprenderá qué desarrolladores tienen deficiencias y trabajará con ellos para mejorar su rendimiento. En realidad, esto requiere que los gerentes trabajen para ayudar a cada individuo a establecer y cumplir los objetivos.
Informes de errores por desarrollador es una métrica horrible. Como líder de control de calidad, he argumentado en contra una y otra vez. Los errores van a pasar. La forma en que se tratan cuando lo hacen es más significativa.
Una mejor métrica es la tasa de reapertura de errores del desarrollador. En otras palabras, cuando el control de calidad registra un error, que luego se corrige, ¿el error se corrige correctamente o hay algo que se perdió, lo que hace que el control de calidad vuelva a abrir el error?
Cuanto más a menudo sucede esto, es una pista de que el desarrollador puede no estar prestando mucha atención al problema. Esto supone, por supuesto, que el error se registró de manera inteligente en primer lugar, preferiblemente con pasos para reproducir, el resultado real, el resultado esperado y por qué. Las capturas de pantalla también ayudan.
Obviamente, esta es solo una métrica sobre la cual se debe informar. Otras posibilidades son
- ¿El desarrollador cumple con los plazos prometidos?
- La capacidad de respuesta a las preocupaciones del cliente.
- Exactitud de cualquier documentación requerida.
y probablemente otros.
Edit: He realizado el desarrollo y el control de calidad y tuve la suerte de que durante mi tiempo de desarrollo no se utilizaron recuentos de errores en mi contra en las revisiones. Discuto en contra de esto en mi compañía actual en mi rol actual porque es un IMO métrico no confiable. Utilizamos la tasa de reapertura como un compromiso para hacer que la gerencia superior (léase el director de desarrollo "de pelo puntiagudo") esté contento de tener algo sobre lo que informar. No soy gerente y en realidad no genero ningún informe (en caso de que sea la causa de algunos votos negativos).
La única forma real de validar la calidad es revisar el trabajo ... y medir lo que se revisa y la cantidad de trabajo. Los errores están detrás de las maneras de medir esto y solo una métrica, pero las revisiones durante el desarrollo son mejores. Eche un vistazo a algunas de las métricas que utiliza TopCoder .
Los informes de errores no solo son una medida sugerente, sino que no son realmente comparables. ¿Qué tan grande es el error? Un error grande puede ser peor que tener 5 pequeños ... por otro lado puede no serlo. Por lo tanto, deberías entrar en los detalles de cada error individual (que será una pesadilla).
Podría ir con el tiempo necesario para solucionar cada error, pero eso puede ser fácil de jugar: agregue un error simple, corríjalo rápidamente, lo que contrarresta el tiempo que tomó corregir un error honesto a la bondad que era más difícil de solucionar.
Puede usar herramientas de pelusa y pruebas unitarias para mejorar la calidad del código sin ser punitivo. La pelusa es un cambio relativamente simple en el proceso en el que trabaja a lo largo del tiempo (comience con las advertencias de X en una base de código existente y luego recompense a las personas que eliminan la mayoría de las advertencias en un período de tiempo; conviértalo en un positivo en lugar de un negativo).
Las pruebas unitarias son otra cosa, recompense el código con el menor número de errores y la mayoría de las pruebas (si las pruebas están escritas correctamente, entonces las probabilidades son el código mejor probado y tendrán la menor cantidad de errores). De nuevo, esto es una recompensa positiva y una cosa alentadora para los desarrolladores. Las pruebas mejoran el código y las personas no son penalizadas.
Hay muchas otras cosas como esta, pero por encima de mi cabeza, tendrán un impacto notable (y son medibles de manera imparcial) en la calidad del producto, que es el objetivo final.
No estoy de acuerdo con el concepto de "Medida por recuento de errores", incluso si el probador está dentro o fuera.
En lugar de contar directamente el número de errores, puede utilizar algún mecanismo de clasificación en relación con la gravedad, es decir, me refiero a medir el descuido del programador.
Digamos que un programador está escribiendo un código sin manejar las excepciones. Este problema es más grande que un error en lógica compleja en un algoritmo complejo. Por lo tanto, utilizar un mecanismo de calificación para cada error sería mejor para tal escenario. En ese caso, cada error / error / error tendrá un peso razonable y podemos obtener una idea general sobre el rendimiento utilizando la suma de las calificaciones de error.
Por otro lado, este enfoque también puede generar problemas porque la calificación también la realizan los seres humanos. Pero tener un equipo para hacer esta calificación reducirá tales problemas y el mecanismo se podrá utilizar más con el tiempo con las mejoras y las alternaciones necesarias.
Pero es su deber subgrupar las categorías de errores y asignarles los pesos necesarios. Creo que no puede hacer esto de una vez. Esta "Definición" también debería madurar con el tiempo con las modificaciones .. :)
Recomiendo a su gerencia que lea Implementación de Lean Software Development: From Concept to Cash , por Mary Poppendieck y Tom Poppendieck. Desalientan mucho la idea de calificar a los desarrolladores basándose en métricas. Su preferencia es recompensar a los equipos, no a los individuos.
Donde ese método no se considera práctico, recomendaría (y también ellos ... creo ...) las revisiones por pares. Sin embargo, no lo expreses en términos contundentes como "¿Cómo clasificas a tus compañeros de equipo?". En cambio, pregunte: ¿A quién recurre cuando tiene un problema que no puede resolver? ¿Quién ha aportado la mejor aportación creativa al proyecto? etc. Las respuestas a este tipo de preguntas pueden proporcionar una mejor orientación en cuanto a quién está poniendo más en el equipo.
Somos profesionales, como mucha gente. También creemos que somos artistas, y en mi opinión lo somos. Desafortunadamente (la mayoría) los programadores son artistas con un patrón.
Al decir que no hay una métrica viable para medirnos es decir "solo déjenos en paz y haremos nuestro trabajo". Eso puede aplicarse a usted, pero ¿cuántos compañeros de trabajo tuvo usted que deseara tener un número para mostrar cuán estúpidos están? La subjetividad es agradable y nos hace sentir mejor a todos, y crea un buen salario para el gerente, pero necesitamos cierta medida de la competencia del programador.
Si nosotros mismos no conseguimos algo que haga feliz a la gerencia, entonces ellos harán lo mismo que hacen los clientes del arte. "No me gusta, estás despedido".
Mundo> Empresa> Producto> Desarrollador
En cuanto a una métrica particular, estoy tan perdido como todos los demás. Lo mejor que vi fue la métrica de los errores reabiertos.
Tengo tres cosas que decir sobre esto:
1) un gerente que sugiere que "un mayor número de errores == peor desarrollador" o "... == mejor probador" puede ser un problema más grande para su empresa que cualquier desarrollador individual. ¿Cómo esta persona llegó a ser parte de la discusión sobre la evaluación del desempeño del desarrollador? Si están administrando desarrolladores, deberían saberlo mejor.
2) La forma más fácil para que un desarrollador juegue cualquier métrica relacionada con errores (recuento de errores, tasa de reapertura, normalizado o no por función / LOC / lo que sea) es hacer que su implementación sea tan difícil de probar como sea posible. Imposible probar significa cero errores encontrados por QA. También es probable que sea imposible de usar, lo que significa cero informes de errores desde el campo (bueno, tal vez uno). Cualquier métrica de conteo de errores es un incentivo contra la capacidad de prueba. Pregunte a la gerencia si eso es realmente lo que quieren.
3) Si alguna vez implementan esta política, corre como un infierno.
Tratar de medir el rendimiento de los programadores con informes de errores es una mala idea. Sin embargo, también lo es intentar medir el rendimiento con prácticamente cualquier otra métrica . No importa lo que hagas, las personas descubrirán cómo jugarlo y te darán lo que estás midiendo sin darte lo que realmente quieres.
De uno de los otros artículos de Joel:
Robert Austin, en su libro Midiendo y administrando el desempeño en las organizaciones, dice que hay dos fases cuando introduce nuevas métricas de desempeño. Al principio, realmente obtienes lo que querías, porque nadie ha descubierto cómo hacer trampa. En la segunda fase, obtienes algo peor, ya que todos descubren el truco para maximizar lo que estás midiendo, incluso a costa de arruinar a la empresa.
