Métricas del proceso

Una metodología que promete velocidad necesita poder mostrar que esa velocidad es confiable. Este documento define qué mide Argui sobre el resultado de la entrega y, sobre todo, cómo lo mide sin convertirse en burocracia.

La pregunta que ordena todo: ¿la velocidad sigue siendo confiable? No se mide para probar que se va rápido —ir rápido con IA es fácil—; se mide para detectar cuándo la velocidad empieza a costar calidad, deuda o riesgo.

Qué mide este documento (y qué no)

Argui mide en tres ejes distintos; cada uno vive en su propio documento para no mezclarse:

Eje	Pregunta	Dónde
Costo del proceso	¿cuántos tokens cuesta?	efficiency.md
Salud interna	¿se está degradando? (drift, suite de tests)	operations.md
Resultado de entrega	¿la velocidad es confiable?	este documento

Las métricas de entrega no reemplazan a las otras dos: las complementan. Una entrega rápida con la suite de tests podrida o con el costo de tokens disparado no es una entrega sana.

Principios de medición

Trabajo activo, no calendario. El tiempo se cuenta en días de trabajo, no de calendario. Un prototipo trabajado un día y retomado tres meses después es un día de trabajo, no tres meses. La unidad de la promesa “~5 días” es el día de trabajo; la métrica mide lo mismo para ser comparable.
Captura en el origen. Cada señal se estampa cuando ocurre el evento, no se reconstruye después leyendo todo el proyecto. La mayoría ya vive en artefactos que el proceso genera —el artifact de QA (Quality Assurance), el backlog, el historial de git—; la auditoría periódica solo las agrega e interpreta. Es el mismo principio que la captura de candidatos de la fase 6 (ver workflow.md).
Señal, no KPI (Key Performance Indicator) de vanidad. Las métricas existen para ajustar el proceso, no para presionar velocidad ni para lucirse. No se comparan entre proyectos sin contexto, y con pocos datos (N pequeño) se leen como tendencia, no como verdad exacta.
Una tabla, no un dashboard. Se persisten como una tabla fechada en el log de auditorías (una fila por auditoría = la serie de tiempo). Argui no distribuye generadores de gráficas, JSON ni dashboards: sería tooling frágil con problema de adopción (ver portability.md, “código vs. responsabilidad”) y la burocracia que la metodología evita. Si un proyecto quiere graficar, la tabla ya está lo bastante estructurada para exportarla — pero esa es su decisión, no la de la metodología.

El set mínimo

Siete métricas en tres lentes, adaptadas del marco que la industria empuja para el desarrollo agéntico (medir resultados, no solo output; segmentar por autoría; tratar el riesgo como dimensión de primer nivel, no solo la velocidad). Dos están marcadas como derivadas: ya viven en otra forma y se incluyen solo si aportan.

Lente 1 · Velocidad y flujo

Métrica	De dónde sale	Qué señala
Tiempo a prototipo aprobado	días de trabajo activo (fechas distintas de commit en la fase 3) hasta la aprobación	respalda la promesa; si sube, el alcance creció o hay fricción
Ciclos por item	re-entradas a `apply` antes de `archive` (historial del item)	claridad del spec y calidad del primer intento
Cycle time por item (derivada)	días de trabajo entre el gate y el archive del item (git)	flujo de extremo a extremo

Lente 2 · Calidad y riesgo

Métrica	De dónde sale	Qué señala
Bugs por disposición	resolved / won’t-resolve / skipped del artifact de QA	dónde se concentra el riesgo; los `skipped` que se acumulan son deuda
Deuda de automatización aplazada	skips del gate de costo de QA (anotados como candidato de backlog)	cuánta verificación quedó pendiente “por ahora”
Drift specs↔código (derivada)	hallazgo de la auditoría de specs (operations.md)	cuánto se aleja la documentación de la realidad

Lente 3 · Autoría e intervención

Métrica	De dónde sale	Qué señala
Intervención correctiva	la entrevista de la auditoría + notas del ciclo	cuánto hay que rehacer el trabajo de un agente

La intervención correctiva no cuenta los puntos de aprobación humana (✋ en PRDs —Product Requirements Documents—, prototipo y cierre de QA): esos son calidad por diseño, no ineficiencia. Cuenta solo lo no previsto — rehacer o re-promptear la salida de un agente porque estuvo mal. Es la “tasa de intervención humana” del marco agéntico, ajustada para no penalizar el human-in-the-loop que define a Argui.

Métricas de equipo (cuando hay varios desarrolladores)

Con un solo responsable no existen; con equipo aparecen señales de coordinación, capturadas de git/PR (Pull Request) y leídas en la misma auditoría (ver teams.md). Miden el sistema, no a las personas —el límite de abajo aplica con más fuerza aquí: no son un ranking de devs—.

Métrica	De dónde sale	Qué señala
WIP (Work In Progress) — unidades en paralelo	ramas/PR abiertos a la vez (git/forge)	sobre-paralelización: más conflictos y el dueño saturado
Espera de revisión	días de trabajo de PR abierto → merge	costo de coordinación puro; si sube, el dueño/arquitecto es cuello de botella
Conflictos / disparos de la guarda	conflictos en artefactos compartidos + veces que la guarda de gobernanza frenó un PR	salud de la propiedad compartida; un pico = estándares inestables o gente tocando lo gobernado de pasada

Y una métrica del set gana lectura de equipo: el cycle time por item ahora incluye la espera de revisión, que en solitario es cero. Si el cycle time sube pero los días de trabajo activo no, esa diferencia es la fricción de integración. La pregunta que ordena las tres: ¿la coordinación cuesta más de lo que el paralelismo ahorra?

Cómo se recolectan

Misma cadencia que las auditorías (cada sprint o cada 5 items archivados — ver operations.md) y por el mismo camino: el comando auditoria corre el conteo mecánico (git, artifact de QA, backlog) en un agente económico, hace una entrevista corta por lo que es juicio o no quedó en ningún artefacto (¿hubo ocio o bloqueos que inflen el calendario?, ¿intervención correctiva relevante?), y escribe la fila en el log. La interpretación —qué significa cada movimiento, qué se ajusta— es trabajo humano.

La medición depende de una disciplina que ya existe: un día de trabajo deja al menos un commit (ver disciplina de sesión en operations.md). Sin commit, ese día es invisible para la métrica de tiempo.

Cómo se leen

Importan las tendencias y los cruces, no los valores absolutos:

Ciclos por item subiendo → specs poco claros o gate flojo.
Intervención correctiva subiendo → agentes mal calibrados o contexto insuficiente; revisar sus description/Expertise o el CLAUDE.md.
Bugs skipped acumulándose → deuda de calidad que la fase 6 debería estar drenando.
El cruce que importa: velocidad subiendo mientras calidad o riesgo empeora es exactamente la trampa que la métrica existe para detectar — la velocidad dejó de ser confiable. Ahí se frena y se corrige; no se celebra el número de velocidad.

Límites

Estas métricas son un instrumento de ajuste, no un tablero de control ni un sistema de evaluación de personas. Con proyectos cortos el N es pequeño y el ruido alto: sirven para ver hacia dónde se mueve un proyecto en el tiempo, no para rankear proyectos ni equipos entre sí. El día que una de estas métricas empuje a sacrificar un punto de aprobación humana o a marcar bugs como won't resolve para “mejorar el número”, la métrica está haciendo daño y se ignora.