¿Hay alguna forma elegante de analizar el proceso de un ingeniero?

Existe mucho sentimiento de que medir commits es inapropiado.

¿Se ha realizado algún estudio que intente atraer más fuentes que commits, tales como:

• patrones de navegación
• Trabajo IDE (pre-commit)
• tiempo de inactividad
• multitarea

No puedo pensar en una manera fácil de hacer estas medidas, pero me pregunto si se ha realizado algún estudio.

En una nota personal, creo que la reflexión sobre las propias 'métricas' podría ser valiosa independientemente de (o en ausencia de) usarlas para evaluar el rendimiento. Es decir, una forma imparcial de reflexionar sobre sus hábitos. Pero este es un tema de discusión más allá de las preguntas y respuestas.

No estoy seguro de si lo consideraría elegante, pero Watts Humphrey escribió un libro completo llamado Personal Software Process que trataba de medir su propia productividad. Describió las métricas para entradas como tiempo en su escritorio versus interrupciones, tiempo dedicado a trabajar en varios tipos de actividades del ciclo de vida del software, defectos por cantidad de código. Hay un informe técnico que ofrece la versión corta en:

http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm

Si desea ver algo como la calidad de un código de desarrollador, Chidamber & Kemerer propuso varias métricas para el código orientado a objetos.

Métricas para código orientado a objetos

• profundidad del árbol de herencia,
• número ponderado de métodos,
• cantidad de funciones miembro,
• número de hijos y
• acoplamiento entre objetos.

Usando una base de código, intentaron correlacionar estas métricas con la densidad del defecto y el esfuerzo de mantenimiento mediante el análisis covariante. Estudios posteriores hicieron un análisis similar en cientos de proyectos de Source Forge Java para determinar sus características en relación con CK Metrics y algunas métricas adicionales propuestas más adelante.

Métricas que surgen en el contexto de las Revisiones de Código

Los defectos se pueden clasificar por muchos criterios:

• gravedad: (mayor, menor, cosmética, investigar / desconocida),
• tipo (lógica, error tipográfico, ortografía, infracción estándar de codificación, etc.),
• origen / contención de fase (requisitos, diseño, código, etc.).

También hay tasas de preparación e inspección (tiempo por revisor, tiempo por línea de código) y densidades de defectos (por KLOC (mil líneas de código), por minuto de tiempo de inspector / revisor).

Al trazar estos valores en gráficos de control puede mostrarnos si estamos dentro de los límites del proceso (por ejemplo, un equipo que inspecciona 200 líneas de código que no encuentra defectos en un grupo que promedia veinticinco defectos por KLOC podría estar funcionando mal).

Otras métricas

Otras métricas que podrían ayudar incluyen aquellas para

• valor ganado para ayudar a calibrar la estimación
• velocidad para aquellos que usan Scrum o Kanban .
• El trabajo de Pareto , Juran , Demming , Ishikawa y otros de calidad e ingeniería industrial es algo portátil para el desarrollo de software con un poco de imaginación.

Limitaciones de análisis

Existen enormes límites en el valor de las métricas. Los errores corregidos por desarrollador pueden significar casi cualquier cosa, y cuando comience a castigar o recompensar esa medida, apuesto a que los errores se volverán más numerosos y granulares, y la combinación de errores difíciles y fáciles corregidos también cambiará a medida que el equipo elija correr para tener más.

También hay una cierta distracción y, potencialmente, una pérdida de enfoque y disfrute que puede venir con una medición intrusiva. No puedes ser mucho más elegante (y emocionalmente agobiado) que un poeta del lago como Wordsworth que dijo:

      Sweet is the lore which Nature brings;
      Our meddling intellect
      Mis-shapes the beauteous forms of things:--
      We murder to dissect.

Si bien el software no es exactamente la naturaleza, dame algo de libertad porque pensé que nunca podría usar nada de la clase de literatura inglesa de la escuela secundaria.

Ágil podría considerarse una reacción a un gran proceso centralizado. A veces, ese modo de trabajo podría requerir tanto esfuerzo analítico que la capacidad de alcanzar el flujo mientras se crea software prácticamente desapareció.

Quiero agregar una respuesta alternativa que se aleje de la práctica estándar de ingeniería de software hacia otro campo con el objetivo de robar herramientas básicas que podamos adaptar según sea necesario. La gente de control de calidad se preocupa por la producción, el rendimiento y la detección y prevención de defectos, al igual que los desarrolladores de software.

http://en.wikipedia.org/wiki/Seven_Basic_Tools_of_Quality

Me gusta el cuadro de control.

http://en.wikipedia.org/wiki/Control_chart

Haga una actividad, trace una métrica, haga otra, trace su métrica, etc. Por ejemplo, la trama se compromete por día. El gráfico dispersará los datos que van desde un mínimo hasta un máximo. Quizás más adelante pueda caracterizar los resultados para determinar que cuando el valor es bajo, algo impide el progreso y cuando es demasiado alto, el trabajo comienza de manera rápida pero descuidada. Depende de usted cómo alienta a los trabajadores a acelerar o reducir la velocidad.

Las métricas personales pueden ser algo que puede correlacionarse con una pregunta como "Me siento más productivo cuando ..."

• Escriba un caso de uso completo antes de comenzar a codificar.
• Escriba mis pruebas unitarias antes de mi código.
• Consulte con las partes interesadas con frecuencia para asegurarse de que los requisitos no cambien y cree un trabajo masivo en el trabajo realizado hacia un plan obsoleto.
• Cambia la mayor cantidad de código posible.
• Delegue cambios bien definidos a los miembros del equipo que sean más expertos en las partes que les pedí que cambiaran.
  • Brinde a mi equipo una descripción completa, pero con prioridades podemos terminar en el sprint actual.
  • Comience mi pase de refactorización con una lista jerárquica de directorios, archivos, clases, métodos, ecuaciones, variables, documentación, etc. que cambiaré.
  • Investigue un problema de alto nivel para encontrar soluciones de la técnica anterior, estimando el alcance y las mejoras clave necesarias para hacer una mejor solución.

Lo que vimos anteriormente es que lo que hacemos puede llevarlo a atacar el problema según lo que determine que es el factor limitante

o múltiples factores en orden de prioridad basados ​​en un diagrama de Pareto.

http://en.wikipedia.org/wiki/Pareto_chart