Glosario

Los términos que usamos en este sitio, explicados sin jerga. En las demás páginas, pasa el mouse (o toca) los términos con subrayado punteado para ver su definición.

Agente

Un integrante del equipo sintético: una IA con un rol y una tarea concretos.

Ambiente

Lugar donde vive tu aplicación (por ejemplo Desarrollo, QA o Producción). Cada uno tiene un tipo y puede pedir su propia aprobación.

Arquitecto

El agente que diseña la solución, define cómo se conectan las piezas y reparte el trabajo.

Board

Tablero donde ves el estado de cada solicitud y de cada release, con estimación de tiempo.

Equipo sintético

Grupo de agentes de inteligencia artificial, cada uno con un rol (Product Owner, Arquitecto, desarrolladores, QA…), que trabaja sobre tus proyectos como lo haría un equipo humano.

Excepción

Permiso temporal, aprobado por otra persona y con vencimiento, para no cumplir una norma por un motivo válido.

Hotfix

Corrección urgente de un error en producción: salta la cola, parte de la versión publicada y arregla una sola solicitud.

Intención de proyecto

Lo que quieres lograr al crear un proyecto (crear desde cero, evolucionar un sistema, solo QA, auditoría…). SynTeam adapta el recorrido a ella.

Matriz de cumplimiento

Informe en PDF que indica, por cada norma, si un release cumple, no cumple, tiene una excepción vigente o requiere revisión manual.

Módulo

Capacidad especializada que amplía al equipo (seguridad, pruebas de carga, accesibilidad, costos…). Tu empresa contrata los que necesita y cada proyecto activa los que aplican.

Norma

Regla de tu empresa que el equipo debe respetar. Puede ser obligatoria, recomendada o prohibida, y se verifica de forma automática.

Perfil premium

Rol especializado que se suma al equipo cuando lo necesitas: DBA, SRE, Ciberseguridad o FinOps.

Producción

El ambiente que usan tus clientes reales. Por defecto exige aprobación para publicar.

Product Owner (PO)

El agente que conversa contigo, aclara lo que necesitas y lo convierte en solicitudes de cambio claras.

Prototipo

Versión en vivo y con datos de ejemplo para ver y probar la aplicación antes de construir la definitiva.

Prueba de humo

Comprobación rápida tras publicar: que la aplicación responde, que sus rutas principales funcionan y, si aplica, que el inicio de sesión funciona.

Release

Una entrega con número de versión (por ejemplo 1.2.0) que agrupa las solicitudes aprobadas, se construye, se prueba y se publica.

Separación de funciones

Regla que exige que quien construye un release no sea quien lo despliega a producción.

Solicitud de cambio (CR)

Resumen escrito de un pedido, con criterios de aceptación, que tú revisas y apruebas antes de que se construya.