Métricas, adopción y hoja de ruta

Métricas que importan

Tiempo de ciclo, cobertura, comentarios de review y autonomía

Buenas prácticas

Documento vivo construido durante el programa

Transferencia de autonomía

Verificar que el equipo puede continuar solo

Hoja de ruta

Roadmap propuesto por el equipo, no impuesto

Conceptos clave

Métricas de adopción que no mienten

“¿Cuánto usa Copilot?” o “¿cuántas sugerencias acepta?” no dice nada. Son métricas de vanidad.

Las métricas que importan miden impacto en el trabajo real:

1. Tiempo de ciclo

Cuánto tarda una feature desde que se empieza hasta que se mergea. Comparar el sprint actual con el anterior al inicio del programa. No es solo velocidad — es también predictibilidad.

2. Cobertura de tests

Porcentaje de cobertura al empezar vs ahora. El agente genera tests como parte del flujo — la cobertura debería subir sin esfuerzo adicional. Si no subió, el equipo no está usando el agente para testing.

3. Comentarios de review

Después de instaurar el Reviewer como primer filtro, ¿cuántos comentarios llegan al review humano? Los comentarios cambian de “naming incorrecto” a “¿estamos seguros de esta decisión de diseño?”.

4. Deuda técnica

¿El equipo está creando más deuda o reduciéndola? Métrica real: ¿cuántos ficheros legacy se han mejorado con el proceso tests-primero-refactor-después?

5. Autonomía

La más importante. Proxies: ¿cuántos devs actualizan las instrucciones sin que nadie se lo pida? ¿Cuántos han creado prompt files propios? ¿Alguien ha mejorado un agente?

Cómo medir:

Tiempo de ciclo: GitLab tiene métricas de MR (time to merge)
Cobertura: PHPUnit y Karma reportan cobertura — comparar histórico
Review: contar comentarios en los últimos 10 MRs vs los 10 anteriores al inicio del programa
Deuda técnica: contar ficheros tocados con el proceso refactor+tests
Autonomía: revisar commits en .github/ — ¿quién edita instrucciones, agentes, prompts?

Guía de buenas prácticas del equipo

No se escribe aquí. Se construye durante todo el programa — una entrada por bloque con lo que funcionó, lo que no, y las decisiones tomadas.

Al final es un documento vivo en el site que el equipo puede mantener. Refleja su contexto real, no una plantilla genérica.

Estructura sugerida:

# Buenas prácticas — Equipo [nombre]

## Instrucciones

- El copilot-instructions.md se revisa cada sprint
- Las path-specific instructions cubren: Angular, Laravel, tests
- Qué incluir y qué NO incluir en las instrucciones

## Agentes

- Planner: cuándo usarlo (features > 2h estimadas)
- Coder: qué esperar (implementa bien si las instrucciones son buenas)
- Reviewer: cuándo confiar en su output, cuándo no

## Prompt files

- Los más útiles del equipo: /componente-signals, /controller-rest, /revisar-mr
- Cómo crear uno nuevo para una tarea repetible

## Hooks

- PostToolUse de formato: obligatorio, no se desactiva
- PreToolUse de seguridad: bloquea DROP, pide confirmación de migraciones

## Flujo recomendado

- Features nuevas: Plan mode → Coder → tests → Reviewer → MR
- Refactoring: tests primero → refactor → tests de nuevo → Reviewer
- Bugs: Reviewer analiza → Coder corrige → tests

## Errores comunes

- [listado de errores recopilado durante el programa]
- [con la corrección que funcionó en cada caso]

## Qué NO hacer con el agente

- [listado de situaciones donde es mejor NO usar el agente]

Cada dev ha contribuido anotaciones durante las prácticas. Este bloque es para consolidarlas.

Transferencia de autonomía

El objetivo: que el equipo no dependa del consultor.

Verificación de autonomía — cada dev debe poder:

Configurar su workspace usando el MCP Workspace Configurator
Crear un nuevo prompt file para una tarea repetible
Ajustar las instrucciones cuando el agente se equivoca
Ejecutar el flujo completo Planner → Coder → Reviewer sin ayuda
Mejorar el pipeline CI/CD con el agente
Actualizar la configuración del equipo haciendo push al repo de configuración

Hoja de ruta

El equipo propone su propio roadmap. Algunas ideas según lo que hemos visto:

1–2 sprints:

Completar cobertura de tests de los módulos más críticos
Establecer el Reviewer como paso obligatorio antes de cualquier MR
Iterar las instrucciones con los aprendizajes del sprint

Entregables de cierre

Guía de buenas prácticas — documento vivo en el site, construido durante el programa
Repo de configuración — fuente de verdad para instrucciones, agentes, prompts, skills y hooks
MCP Workspace Configurator — desplegado y funcionando en el VPS
Pipeline CI/CD mejorado — con lint, tests, análisis estático
Métricas de referencia — baseline para medir el progreso futuro
Hoja de ruta — propuesta por el equipo, no impuesta

Después de la consultoría

No hay tarea puntual porque este es el último bloque. Pero sí hay una tarea permanente:

Iterar. Las instrucciones, los agentes, los prompts — todo evoluciona con el proyecto. Si algo deja de funcionar, la primera pregunta es: ¿las instrucciones están actualizadas?

El equipo ya tiene las herramientas, el conocimiento y la configuración. Lo que viene después depende de ellos.