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
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 ..."
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
fuente