Estoy ganando 4-5 veces más puntos de historia que el promedio, pero estoy produciendo errores a la mitad. Los gráficos dicen que es 2x más errores, ¿cómo lidiar con eso?

Creo que estás mezclando tus preocupaciones. Y no hay nada en su lado que deba cambiar.

La productividad es un indicio de la rapidez con que se completará un proyecto. A los gerentes de proyecto ya todos los demás les gusta saber cuándo se entregará el proyecto. Una productividad más alta o más rápida significa que veremos que el proyecto se realice antes.

La tasa de errores no está vinculada a la productividad, sino al tamaño del proyecto. Por ejemplo, puede tener N errores por Y líneas de código. No hay nada dentro de esa métrica que diga (¡o le importe!) Qué tan rápido se escriben esas líneas de código.

Para unir eso, si tienes una mayor productividad, sí, "verás" que los errores se escriben más rápidamente. Pero ibas a tener esa cantidad de errores de todos modos ya que está vinculado al tamaño del proyecto.

En todo caso, mayor productividad significa que tendrás más tiempo al final del proyecto para detectar esos errores o el desarrollador será más rápido en encontrar los errores que crearon. ¹

Para abordar los aspectos más personales de su pregunta.

Si su jefe está observando estrictamente la cantidad de errores que produce en lugar de la tasa de errores que produce, se requiere una sesión educativa. El número de errores creados no tiene sentido sin una tasa de respaldo.

Para llevar ese ejemplo al extremo, dígale a su jefe que quiero duplicar su salario. ¿Por qué? He creado absolutamente ningún error en tu proyecto y, por lo tanto, soy un programador muy superior al tuyo. ¿Qué? ¿Tendrá un problema que no haya generado una sola línea de código para beneficiar su proyecto? Ah Ahora entendemos por qué la tasa es importante.

Parece que su equipo tiene las métricas para evaluar los errores por punto de historia. Si nada más, es mejor que ser medido por la cantidad cruda de errores creados. Sus mejores desarrolladores deberían estar creando más errores porque están escribiendo más código. Pídale a su jefe que saque ese gráfico o al menos que lance otra serie detrás de él que muestre cuántos puntos de la historia (o el valor de negocios que mida) junto con la cantidad de errores. Esa gráfica contará una historia más precisa.

¹ _{Este comentario en particular ha atraído mucha más atención de la que estaba destinada. Así que seamos un poco pedantes (sorpresa, lo sé) y restablecemos nuestro enfoque en esta pregunta.}

_{La raíz de esta pregunta es sobre un gerente que mira las cosas incorrectas. Están observando los totales de errores en bruto cuando deberían ver la tasa de generación en función del número de tareas completadas. No nos obsesionemos con la medición contra "líneas de código" o puntos de historia o complejidad o lo que sea. Esa no es la pregunta en cuestión y esas preocupaciones nos distraen de la pregunta más importante.}

_{Según lo establecido en los enlaces por el OP, puede predecir un cierto número de errores en un proyecto únicamente por el tamaño del proyecto solo. Sí, puede reducir este número de errores a través de diferentes técnicas de desarrollo y pruebas. Una vez más, ese no era el punto de esta pregunta. Para comprender esta pregunta, debemos aceptar que para un proyecto de tamaño y una metodología de desarrollo determinados, veremos un número dado de errores una vez que el desarrollo esté "completo".}

_{Así que finalmente volvamos a este comentario que algunos entendieron completamente mal. Si asigna tareas de tamaño similar a dos desarrolladores, el desarrollador con una mayor tasa de productividad completará su tarea antes que el otro. Por lo tanto, el desarrollador más productivo tendrá más tiempo disponible al final de la ventana de desarrollo. Ese "tiempo extra" (en comparación con el otro desarrollador) puede usarse para otras tareas, como trabajar en los defectos que se filtrarán a través de un proceso de desarrollo estándar.}

_{Tenemos que aceptar el OP en su palabra de que son más productivos que otros desarrolladores. Nada dentro de esas afirmaciones implica que el OP u otros desarrolladores más productivos están siendo descuidados en su trabajo. Señalando que habría menos errores si pasaran más tiempo en la función o sugiriendo que la depuración no es parte de este tiempo de desarrollo, se pierde lo que se ha pedido. Algunos desarrolladores son más rápidos que otros y producen un trabajo comparable o de mejor calidad. Nuevamente, vea los enlaces que el OP expone en su pregunta.}

Pase parte de ese tiempo adicional limpiando, puliendo y probando su código. Todavía habrá errores, pero habrá menos. Eso lleva tiempo. Su tasa de salida de código bajará, pero su salida de código libre de errores aumentará, y eso resultará en una mejor productividad. Porque los bichos son caros.

¿Puede mantener su código en una rama o en un entorno de prueba hasta que lo saque y atrape más errores? Los errores en una rama generalmente causan menos ondas que los errores en el código de producción.

Pero no estoy exactamente cavando sus afirmaciones que conducen a su pregunta. Y quizás tu jefe tampoco lo sea.

No creo que todos los codificadores produzcan la misma tasa de errores. Tu segundo enlace es en realidad totalmente fuera de tema, ya que está comparando diferentes idiomas, no diferentes niveles de habilidad de codificador. El código completo menciona algunas mediciones de muestras grandes que analizan el proceso en lugar de la habilidad de los codificadores. Y cuando dicen que los codificadores de nivel superior producen más / mejor código, parte de eso significa que tiene menos errores. Depende de la aplicación. Entonces, sí, creo que es una cuestión de perspectiva diferente.

Sin embargo, al final, si el jefe quiere un código más limpio, dale un código más limpio.

Me arriesgaré y seré el abogado del diablo. Eso no quiere decir que no simpatizo con tu situación, pero, bueno, mi simpatía no te ayudará. Así que permítame agregar a perspectiva de Philip :

A su jefe le importa la calidad del producto, en parte porque su nombre y reputación estarán vinculados a él. Parte de la calidad es la cantidad percibida de errores . Si vendes un simulacro impresionante que perfora cuatro veces más rápido que cualquier otro ejercicio de la competencia, pero que también se rompa dos veces más a menudo, tendrás una mala reputación. Incluso si es discutible que el simulacro funcione mejor, la gente se acostumbra a la velocidad, pero recordarán las averías.

En retrospectiva, la mayoría de los errores son, obviamente, prevenibles. Si solo tuvieras un poco más de cuidado, tu jefe se sentirá, podrías evitar estos problemas y cualquier limpieza necesaria. Desde su perspectiva, eso es algo trivial y sensato, y cualquier discusión que hagas al respecto no va a funcionar y te hará quedar mal.

No puede medir su productividad superior. Afirma una productividad más alta basada en una métrica verificable, ¿cómo se sienten sus colegas al respecto? ¿Están de acuerdo, quizás a regañadientes, en que eres un programador más productivo, o estás solo en tu opinión? Hará un punto más fuerte si tiene otras personas para respaldar sus afirmaciones.

Eso es para la perspectiva. Ahora, ¿cómo hace para "arreglar" esta situación frustrante en la que se encuentra?

Reduzca la velocidad un poco. Mencione explícitamente a quienquiera que distribuya las tareas que intentará reducir la tasa de errores (*), para que no se sorprendan por su menor consumo. En todo caso, reducir la velocidad reducirá la cantidad de errores asignados a usted por pura falta de suministro.

_{(*) Hay una diferencia entre, por un lado, reconocer que hay hay errores en su nombre y que intentará disminuir esa cantidad y, por otro lado , admitiendo que tiene demasiados errores en su nombre y debe tomar medidas.}

No intentes convencer a tu jefe, porque no funcionará. De nuevo, eso no significa que tenga que conceder su punto; puede presentar un contrapunto y mantener su opinión sin desestimar sus preocupaciones. Porque si discute el punto y no puede demostrar satisfactoriamente su productividad superior (e incluso si puede), se arriesgará a insultar a sus colegas, o parecerá despectivo. No quieres ser ese chico .

Suponiendo que produciría la misma "cantidad" de código como sus colegas en el 20% de su tiempo, podría gastar 4 veces más en realmente depurar el código y hacerlo perfecto, lo que reduciría aún más la tasa de errores. Entonces podrías llamarte un buen programador.

La pregunta más importante es por qué estás codificando 5 veces más que los demás en lugar de buscar calidad. ¿Es esto algo que tu ego te dicta o te obliga tu jefe?

También debe tener en cuenta los costos para corregir un error. Cuando lo encuentre temprano, es posible que todavía esté "dentro" del código lo suficiente para solucionarlo rápidamente. Si aparece solo después de otro mes de desarrollo, podría ser difícil encontrarlo o incluso forzarlo a cambiar grandes partes del código ya programado.

Parece que tienes la habilidad para producir código, y podrías hacerlo increíble si te concentras en la calidad en lugar de la velocidad. Inténtalo un momento, supongo que te gustará.

El siguiente problema es obtener el acuse de recibo (hablar de dinero) para un mejor desempeño. Hable con su jefe y pregúntele cómo debe proceder, es su compañía y su dinero, después de todo, y si quiere que produzca menos errores, también debe decidir de qué manera sucede.

Los desarrolladores pueden ser brillantes, incluso genios, con una aptitud para la comprensión y la codificación en solitario, sin ser buenos desarrolladores. Un buen desarrollador crea un trabajo de calidad y mejora todo el proyecto.

No estoy diciendo que seas tú, pero uno de los programadores más frustrantes con los que he trabajado escribió más código que nadie en el equipo, y teníamos buenas personas en el equipo. Realizamos un seguimiento de los compromisos con un software de clasificación, por lo que fue casi una competencia para algunas personas. Emitió franjas de código, dejando detrás de él CERO documentación, bosques impenetrables, y realmente hizo que algunos de mis propios códigos me resultaran difíciles de entender (puedo hacerlo por mi cuenta, ¡muchas gracias!). Eventualmente, casi descarriló el proyecto, porque se convirtió en un espectáculo de un solo hombre. La gente no podía seguirlo. No estábamos sincronizados como equipo. En realidad, reescribimos algunas de sus características años más tarde, solo para recuperar la capacidad de mantenimiento.

Lo que quería de él era disminuir la velocidad y pasar más tiempo: 1) Mejorar la calidad del código base. 2) Comunicarse con el equipo. 3) Trabajar en cosas que ayudaron a otros, así como también a ayudarlo a terminar artículos / historias 4) Corrección de errores

No estoy de acuerdo con medir la productividad por líneas de código, pero es una métrica clave. ¿Tu contador de código incluye comentarios? Si es así, hay una manera fácil de mantener su salida de línea mientras reduce su "proporción de errores"; simplemente aumenta la calidad y cantidad de comentarios que escribes. Los comentarios rara vez tienen errores (aunque pueden) y, en general, no tenemos suficientes comentarios de calidad. Estoy no aprobando la inflación del código, pero el acto de comentar es como una mini revisión de código, te obliga a pensar, refactorizar y mejorar.

Intentar iluminar la administración no es un arranque. Hay un viejo cliché: "¿Vas a creerme a mí oa tus ojos mentirosos?" Lo que le preocupa a tus jefes son los errores. Ninguna cantidad de racionalización les dirá que es aceptable. Es más del doble de riesgos. Además, no eres el único afectado por tu cuenta de errores. El control de calidad tiene el doble de trabajo al tratar de identificar sus errores, por lo que la administración querrá que usted haga menos de ellos.

La mejor solución es reducir la cantidad de errores que produce , y punto. No solo la administración será más feliz, sino que usted también lo será. ¿No es así? Porque estoy bastante seguro de que tanto como usted disfruta alardeando de que supera a sus compañeros de trabajo en un factor de cuatro, le encantaría decir que lo hace con el mismo número de errores, o incluso menos, que lo hacen.

Como dijo, "... la tasa de errores cometidos en el código ... tiende a verse afectada por los procesos utilizados al escribir el código y después de escribir el código." Si desea modificar el La velocidad a la que se producen los errores tendrá que cambiar los procesos que utiliza para escribir código.

Los programadores usan métodos de producción para producir código, como una línea de ensamblaje usa métodos para producir un objeto producido en masa. De acuerdo, las prácticas de la industria del software son más bien como adelgazar a las ramas que se encuentran en el bosque. Pero como estamos produciendo máquinas, deberíamos emplear el mismo rigor y disciplina utilizados para las máquinas de alta velocidad de producción en masa.

Esto incluye las mismas técnicas utilizadas en la producción en masa para reducir la tasa de defectos: el análisis de la causa raíz para determinar por qué se cometen los errores y cambiar el proceso para que no lo sean. O al menos que atrapes antes de que el control de calidad lo haga.

1. Confecciona una lista de tus errores. Probablemente ya tienes uno gracias a los chicos de control de calidad. Posiblemente categorizado también. Tipo de error, gravedad, el punto en el que se inyectó el error en el código, etc.

2. Selecciona la categoría más grande de errores. Ya que tu volumen es tan alto, primero debes apuntar a esa categoría. Otras categorías incluyen las más fáciles de encontrar y las más fáciles de hacer.

3. Sabiendo dónde se introducen esos errores en el código, intente realizar cambios en esa fase (y anteriores) que eviten que ocurran y encontrar formas para que sea más fácil detectarlos en esa fase.

4. Asegúrese de ver los elementos incidentales no relacionados con la programación, ya que pueden marcar la diferencia en la calidad de su trabajo. Música de fondo, interrupciones, comidas, trabajo demasiado tiempo sin descanso, hambre, etc.

Lo que encuentres puede llevarte a ir más lento. Por otro lado, puede ayudarlo a producir aún más rápido, ya que tendrá menos necesidad de volver a trabajar las cosas que ya ha dejado atrás. Tal como está, cuatro veces más el código no es un orden de magnitud mejor que el de sus compañeros de trabajo, por lo que definitivamente es el camino a seguir el cambio de proceso.

Cambie su objetivo de producir la mayor cantidad de código para ayudar a la empresa a avanzar más.

Como parece que tiene muchos colegas más tiempo extra disponible, el mayor efecto que puede tener en una entrega más rápida de funciones y correcciones de errores es ayudar a sus colegas.

Ayude a sus colegas por

• usar revisiones de código para mejorar la calidad y la educación del código.
• creando procesos de automatización para hacer su trabajo más rápido y sus vidas más fáciles.
• escribiendo mejores pruebas con ellos
• código técnico de ataque para mejorar la base de código
• ser el chico al que acudir y que siempre está disponible para ayudar a otros.
• herramientas de escritura / mejora que ayudan con la productividad del desarrollador
• haciendo caso con la administración de mejores herramientas / equipo / condiciones de trabajo para sus compañeros de trabajo si tiene más poder.
• preparando y liderando sesiones educativas sobre cómo escribir mejor código.
• practicar la humildad

  

Entonces, ¿cómo lidiar con el hecho de que una mayor productividad conducirá a un mayor número de errores?

Su jefe es la única persona que puede responder esto en su caso. Hable con él, señale su mejor proporción y deje que él decida. Si su decisión no tiene sentido, es hora de buscar una empresa con su forma de pensar.

Como profesional, debería poder trabajar con las condiciones del cliente, solo asegúrese de que entiendan las consecuencias. Una buena tabla de errores / historias puede ayudar a su jefe a comprender cuánto se hundirá su productividad si se toma el tiempo de producir menos errores.

También debe tener en cuenta estos puntos:

• complejidad de las historias, por ejemplo, simples envoltorios de getter / setter versus cálculos estadísticos o programación en tiempo real o incluso estadísticas en tiempo real ...
• gravedad de los errores, ¿son errores tipográficos pequeños en los campos de texto o resultados de cálculos incorrectos, bloqueos del programa
• cuesta arreglar los errores, tanto si lo haces ahora como si lo haces más tarde o si alguien más tiene que entender tu código porque te fuiste

La situación es que trabaja cuatro veces más rápido que el programador promedio, pero comete el doble de errores en un tiempo determinado. En relación con la cantidad de trabajo que haces, realmente cometes la MITAD de tantos errores como "promedio".

Puede intentar señalar su baja proporción de errores en el trabajo, o incluso errores en el producto completado (que puede completar en una cuarta parte del tiempo normal). La mayoría de los jefes aceptarán eso.

Hay algunos jefes que no lo hacen porque trabajan con una mentalidad de "asignación" de errores por tiempo. Luego, puede reducir la velocidad de su trabajo, hacer DOS VECES tanto como el promedio en un tiempo determinado, y cometer los mismos (o menos) errores porque tiene más tiempo para revisar su trabajo.

Si su jefe desea que usted mejore la calidad de su trabajo, entonces mejore la calidad de su trabajo.

Debes apuntar a cero errores, no apuntar a producir solo el doble que el siguiente mejor programador.

Debes decirle a tu jefe que las métricas que está usando son bastante erróneas. Si observas las pérdidas de balón realizadas por los guardias de la NBA, verás que tienden a tener números más altos que los delanteros. Pero, eso es porque están manejando más la pelota. Si un guardia no titular juega 1/5 tanto como un guardia inicial y gira la pelota más de 3 veces en promedio .vs. un guardia inicial que hace girar el balón más de 7 veces por juego; a primera vista, puede parecer que el guardia inicial es peor. Pero, si divides la cantidad de pérdidas de balón por la cantidad de minutos jugados, entonces claramente el guardia titular tiene mejores números en función de los minutos jugados.

Del mismo modo, tiene números mucho mejores si la cantidad de errores se divide por la cantidad de puntos de historia completados. Entonces, eso es lo que le propondría a su gerente. Cambie la métrica para que sea el número de errores divididos por los puntos de la historia completados, o al menos agregue una nueva métrica para esto si se necesita el número total de errores por desarrollador. Pero, dado que algunos puntos de la historia son mucho más difíciles y complejos que otros puntos de la historia, puede haber y habrá un poco de variación, y el gerente también debe tener esto en cuenta.

Lo que no creo que debas hacer es disminuir la velocidad.

Valor agregado de la medida

Argumenta que lo que realmente cuenta es el valor que agregas. Luego vaya e introduzca una medida aproximada (manual) de eso:

• Calcule el valor de la funcionalidad que produce
• Resta tu salario
• Reste el costo estimado de sus errores (al menos el costo para solucionarlos)
• Reste el costo estimado de todas las demás Deudas Técnicas que produzca

El resto es tu valor agregado. Del mismo modo para todos los demás.

Estas estimaciones son difíciles, pero incluso las aproximadas pueden hacer el punto. Y el mero proceso de discutir estas estimaciones es útil para el equipo y el proyecto.

Los programadores principales tienen una tendencia a escribir código muy regular que es fácil de depurar y entender, utilizan las herramientas disponibles (análisis estático, errores del compilador, código de depuración) al máximo. Además, los mejores programadores ya aprendieron el valor de la prueba de unidad a través de su propia experiencia.

Entonces, si bien la cantidad inicial de problemas por línea es la misma, los problemas se eliminan más rápido.