Engineering Analytics - entrega y desarrolladores

Engineering Analytics convierte los datos que AppArch ya recoge (merge requests, análisis, despliegues, incidencias, incidentes) en métricas de entrega. Una regla recorre todas las pantallas: un número que no puede medirse se muestra como no medido, nunca como cero, y dos series mostradas lado a lado nunca se presentan como causa y efecto.

Tarjeta de salud del proyecto (/reports/health)

Cada puntuación que la plataforma guarda por proyecto en una sola tarjeta: ArchScan, ArchSecurity, Cumplimiento, Git Health y la puntuación derivada de SonarQube (calificaciones de fiabilidad, seguridad y mantenibilidad mapeadas A=100 … E=20), cada una como el último valor 0-100 de esa herramienta o un guion si nunca evaluó el proyecto.

• Consenso - la media de las fuentes existentes, siempre con cuántas fueron (“de 3 fuentes”). No es un índice ponderado y nunca trata una fuente ausente como cero.
• Evaluado por - cuántos proyectos ha mirado realmente cada lente.
• Las herramientas discrepan - proyectos donde ArchScan y la puntuación de Sonar difieren 20 puntos o más, con la dirección (“Sonar más benévolo” / “Sonar más estricto”). No es un veredicto sobre ninguna herramienta; es un lugar donde mirar.
• Todas las lentes en verde - toda fuente evaluadora en 80 o más, con al menos dos fuentes.
• Hallazgos externos - hallazgos de seguridad abiertos de GitLab y SonarQube por proyecto (total, críticos, altos) listados como recuentos bajo la puntuación de ArchSecurity; nunca entran en el consenso. Una tarjeta suma los críticos abiertos de toda la ficha.
• Líneas de tendencia por proyecto para ArchScan y Sonar en el periodo elegido, quality gate de Sonar, cobertura y duplicación, y filtro por grupo de proyectos.

MR Insights (/reports/mr-insights)

Cada merge request de cada proyecto conectado se sincroniza cada 30 minutos: autor, estado, fechas de apertura/merge/cierre, quién hizo el merge, tamaño (adiciones, eliminaciones, archivos cambiados) y hora de la primera revisión.

• Rendimiento semanal - abiertas, fusionadas y cerradas por semana.
• Lista de riesgo - merges puntuados por tamaño, auto-merge, falta de aprobación y falta de comentarios de revisión; los más altos primero.
• Síntomas - MRs grandes, largas esperas de revisión, auto-merges, merges sin revisar, con los números detrás de cada uno.
• Mapa de calor de actividad - “cuándo aterriza el trabajo”: 7 días x 24 horas en la zona horaria del lector, aperturas y merges combinados. Los merges fuera de lunes-viernes 08:00-19:59 hora local se cuentan aparte - no como veredicto, sino como pregunta.
• Cobertura de revisión - proporción de MRs fusionados (con comentarios sincronizados) que recibieron al menos un comentario humano contado de alguien distinto del autor; el resto se fusionó en silencio. Usa los veredictos de comentarios de revisión, así que los acuses no cuentan como revisión.

Las columnas de aprobación solo cubren las MRs que ArchPilot ha visto.

Comentarios de revisión (/reports/review-comments)

Cada comentario humano de un merge request sincronizado se guarda junto a él (GitLab, GitHub, Bitbucket Cloud y Azure DevOps; los eventos de sistema como “añadió 2 commits” y los comentarios propios de ArchPilot nunca se guardan). La pregunta que responde la pantalla es quién revisa de verdad, y un veredicto por comentario mantiene el recuento honesto:

• Sin juzgar - cuenta como trabajo de revisión hasta que alguien diga lo contrario.
• Revisión - sustancial: una pregunta, un problema, una sugerencia, una decisión.
• Excluido - un acuse (“gracias”, “ok, lo hago”, un emoji). Fuera de todo recuento.

Un propietario o administrador del workspace fija los veredictos a mano. Con Ajustes de módulos > ArchPilot > Clasificar comentarios pendientes con IA activado, el proveedor de IA de la instalación juzga cada 10 minutos los comentarios aún sin juzgar; el veredicto de un administrador nunca se sobrescribe. El interruptor solo aparece cuando el administrador de la instancia ha configurado un proveedor de IA y activado al menos una función de IA. La tarjeta de IA de la página muestra lo que ha costado la clasificación hasta ahora (llamadas, comentarios juzgados, tokens de entrada y salida) y qué hizo la última llamada; un administrador puede encolar una pasada de inmediato con Clasificar pendientes ahora (hasta 40 comentarios, dos llamadas al proveedor). La clasificación gasta la clave de IA de la instalación y cuenta contra el cupo del asistente.

Los comentarios contados alimentan la tarjeta Comentarios de revisión y la distribución Quién comenta en MR Insights, y la cifra Comentarios de revisión del perfil del desarrollador. Los comentarios del autor del MR en su propio MR se listan pero nunca cuentan como revisión dada.

AI Impact (/reports/ai-impact)

Lo que el proveedor de IA de la instalación costó a este espacio de trabajo - explicaciones de hallazgos, respuestas del asistente y llamadas de clasificación de comentarios de revisión (tokens de entrada/salida, regeneraciones, por persona y modelo; las dos últimas son a nivel de espacio de trabajo y solo se cuentan en la vista de todos los proyectos) junto a lo que cambió en las mismas semanas: puntuación de ArchScan, densidad de hallazgos de ArchPilot, funcionalidades y correcciones fusionadas. La nota al pie lo dice sin rodeos: las series se muestran juntas, no se afirma causalidad.

DORA (/reports/dora)

Se muestran las cuatro métricas; las dos que necesitan datos de incidentes quedan vacías hasta que se conecta una fuente de incidentes.

Métrica	Fuente	Notas
Frecuencia de despliegue	Eventos de despliegue del catálogo (Argo CD, Kubernetes, Flux)	La hora de despliegue es una observación con hasta 10 minutos de retraso, no un webhook. Las fuentes solo Kubernetes informan etiquetas de imagen, no commits, y se cuentan como no rastreables.
Lead time	Del merge (hechos de MR) al despliegue que lleva el commit	Por entorno; una revisión sin coincidencia es desconocida, nunca cero. El desglose por etapas muestra espera de revisión, en revisión y espera de salida; las dos etapas no medidas se dibujan en gris.
Tasa de fallo de cambios	Incidentes abiertos en la hora siguiente a un despliegue del mismo servicio	Correlación temporal, no prueba de causa - la página lo dice.
Tiempo de recuperación	De la apertura al cierre del incidente	Misma fuente.

Las bandas elite/alto/medio/bajo son una aproximación de la cadencia semanal y van junto al número real, nunca en su lugar. Las medianas por etapa son independientes; no suman la mediana global.

Flujo de incidencias (/reports/issue-flow)

Con una conexión a Jira, las incidencias se releen cada 30 minutos y el flujo se deriva del changelog de cada una: la primera transición fuera de new arranca el reloj, la última transición a done lo detiene. Se informan rendimiento, tiempo de ciclo, trabajo en curso y envejecimiento con siete alarmas (sobrecarga WIP, en curso estancado, backlog envejecido, en curso sin asignar, reabierto, dominado por bugs, baja cobertura de flujo). Las subtareas se excluyen del rendimiento para que un equipo que divide cada historia en seis no parezca seis veces más rápido.

Fuentes de incidentes

Los incidentes de Dynatrace y New Relic se traen al espacio de trabajo y se emparejan con servicios por nombre. Los incidentes sin coincidencia se cuentan y se muestran; una plataforma conectada que no ha almacenado ningún incidente recibe su propio aviso, porque un token limitado a la cuenta equivocada se valida perfectamente y luego no alimenta nada - lo que DORA leería como una tasa de fallo del 0 %.

Historial de Cumplimiento y Git Health (/reports/score-history)

Ambas puntuaciones a lo largo del tiempo. El valor semanal de un proyecto es su último escaneo correcto de esa semana; la línea global es la media de los proyectos escaneados esa semana e indica cuántos fueron. Las semanas sin escaneo son huecos, nunca se arrastran. Por proyecto: última puntuación, cambio entre el primer y el último escaneo del periodo, número de escaneos y línea de tendencia; las tarjetas muestran la media actual, el cambio medio y cuántos proyectos mejoraron o empeoraron.

Tendencia de hallazgos de seguridad (/reports/security-trend)

Hallazgos de GitLab y SonarQube como ciclo de vida. La fecha de detección es la del proveedor; un hallazgo cuenta como cerrado cuando una sincronización deja de verlo abierto (resuelto o descartado). A partir de esas dos fechas la página reconstruye, por semana y por fuente, los hallazgos nuevos, los cerrados y el pendiente abierto al final de la semana - reconstruido, no muestreado, por lo que existe historial de semanas anteriores a la primera apertura de la página. Tarjetas: abiertos ahora (con críticos), nuevos y cerrados en el periodo, cambio neto, mediana de días hasta el cierre. Tablas por fuente y por proyecto. Los escaneos propios de ArchSecurity son instantáneas por ejecución y quedan fuera de este ciclo.

Ciclo de vida de los ADR (/reports/adrs)

Las decisiones de arquitectura como proceso: recuentos por estado, propuestas abiertas con su antigüedad mediana, decisiones por mes según resultado, días medios desde la creación hasta la decisión, tasa de aceptación, decisiones sustituidas, etiquetas y distribución por proyecto. Las propuestas con más de 30 días se listan de más antigua a más reciente - una propuesta que nadie decide es una decisión por omisión.

Acceso frente a contribución (/reports/developer-access)

Para cada desarrollador sincronizado: los proyectos de los que es miembro (según el proveedor), aquellos en los que estuvo activo en el periodo (abrió un merge request o escribió un comentario de revisión contado) y las membresías inactivas - acceso sin actividad. También lo contrario: contribuciones en proyectos donde el proveedor no lo lista como miembro. La inactividad solo se afirma en proyectos con merge requests sincronizados; la página indica cuántos son. Las cuentas de servicio se listan pero quedan fuera de las tarjetas.

Desarrolladores (/developers)

Toda persona que toca un repositorio conectado (miembros y autores de MR) se sincroniza por proyecto, solo en los proyectos con la sincronización de desarrolladores activada (desactivada por defecto). Cada desarrollador tiene un perfil (/developers/{id}) con los proyectos que toca, las MRs que escribió y una puntuación de revisión basada en ArchPilot. Los bots se detectan a partir de señales del proveedor y se marcan como cuentas de servicio; la marca puede ponerse o quitarse a mano, y una marca manual nunca es sobrescrita por la sincronización.

Qué necesitas

• Una credencial Git con acceso a pull requests para MR Insights, el mapa de calor y desarrolladores.
• Una fuente de despliegue (Argo CD, Kubernetes, Flux) para la frecuencia de despliegue y el lead time.
• Jira para el flujo de incidencias; Dynatrace o New Relic para la tasa de fallo y el tiempo de recuperación.
• AI Impact necesita el proveedor de IA de la instalación, configurado por el operador (IA); no hay clave por espacio de trabajo.