Documentación

Documentación de DevGob

Descubre cómo DevGob organiza el trabajo, gobierna los cambios en su camino a producción y mantiene separada la información de cada organización. Empieza por lo básico y ve luego al área que necesites.

Empieza aquí

Tres pasos desde no tener cuenta hasta un proyecto en el que planificar trabajo.

  1. 1

    Solicitar un espacio de trabajo

    Cada organización tiene su propio espacio de trabajo en tu-equipo.devgob.com, con sus usuarios, proyectos y datos. Solicítalo desde el formulario público; una persona administradora lo revisa antes de activarlo.

    Solicitar un espacio de trabajo
  2. 2

    Iniciar sesión en tu espacio de trabajo

    Inicia sesión en la dirección propia de tu organización. Si solo sabes el nombre del espacio de trabajo, la página de acceso lo localiza y te lleva al sitio correcto.

    Ir a iniciar sesión
  3. 3

    Configura tu primer proyecto

    Un espacio de trabajo contiene proyectos; un proyecto contiene equipos, un backlog, sprints y despliegues. Los tipos de elemento de trabajo, sus estados y sus transiciones se configuran por espacio de trabajo, de modo que el proceso se ajuste a cómo ya trabaja tu organización.

Explora por área

Cada área de aquí abajo describe lo que el producto hace, no lo que piensa hacer.

Work items

La unidad de trabajo y la jerarquía que la organiza.

  • Jerarquía: Épica → Funcionalidad → Elemento de backlog → Tarea.
  • Además Error, Incidencia, Impedimento, Defecto previo a la release y Soporte para el trabajo que no encaja en la jerarquía.
  • Los tipos, los estados y las transiciones entre ellos se configuran por espacio de trabajo; no los fija el producto.
  • Cada elemento lleva una referencia legible como PAGOS-364 para poder citarla en una conversación.
Leer el artículo

Backlog y tableros

Ordena el trabajo y míralo avanzar.

  • Un backlog de producto por proyecto, con triaje de los elementos entrantes.
  • Prioridad reordenable arrastrando, guardada por equipo.
  • Tableros por estado, con las columnas que define tu proceso.
  • Filtros por tipo, estado, persona asignada, iteración y equipo.
Leer el artículo

Sprints y capacidad

Planifica una iteración con las horas de las que realmente dispones.

  • Iteraciones con fechas de inicio y fin, por equipo.
  • Capacidad por persona, contando festivos y días libres.
  • Un burndown del trabajo pendiente a lo largo de la iteración.
  • Retrospectivas registradas contra el sprint al que pertenecen.
Leer el artículo

Gobierno de despliegues

Lo que hace que esto sea más que un gestor de tareas: un cambio llega a producción por un flujo gobernado y con evidencias.

  • Once fases: New, Development, Code Review, Test, To Committee, Committee Authorized, Installed Pre, To Committee Prod, Committee Prod Authorized, Installed Prod, Done.
  • Cada fase tiene un rol responsable y una condición para salir de ella.
  • Dos puertas de comité, no una: el cambio se autoriza por separado para preproducción y para producción, y cada autorización queda registrada con quién la dio y cuándo.
  • Evidencias de instalación capturadas tanto en preproducción como en producción.
  • Una vuelta atrás en producción abre automáticamente un error vinculado, con la severidad más alta, para que nada se pierda con las prisas.
Leer el artículo

Informes y paneles

Qué está pasando, sin preguntarle a nadie.

  • Un panel por proyecto con el estado de la iteración en curso.
  • Informes generales sobre elementos de trabajo, despliegues y trabajo vencido.
  • Gráficos generados por el servidor: nada que instalar, nada que cargar.
  • Exportación a CSV para todo lo que necesites llevarte a otro sitio.
Leer el artículo

Roles y permisos

Quién puede hacer qué, decidido por rol y no por persona.

  • Los roles de sistema —SuperAdmin y Administrador del espacio de trabajo— los fija el producto y no se pueden editar.
  • Los roles funcionales son plantillas editables: Product Owner, Scrum Master, Tech Lead, Desarrollo, QA, Release Manager, Aprobador del comité, Parte interesada, Auditoría.
  • Los permisos son acciones concretas sobre un recurso, concedidas a un rol y nunca a una persona.
  • Administrar el sistema y gobernar el trabajo están separados a propósito: quien dirige un proyecto no puede concederse permisos a sí mismo.
Leer el artículo

Administración

Todo lo que controla quien administra un espacio de trabajo.

  • Usuarios, direcciones de correo autorizadas y asignación de roles.
  • Inicio de sesión único con Microsoft Entra ID, Google o cualquier proveedor OIDC.
  • Integración con GitHub, enlazando ramas y pull requests con los elementos de trabajo.
  • Calendarios laborales, cuotas de almacenamiento y el plan del propio espacio de trabajo.
Leer el artículo

Seguridad y aislamiento de datos

Cómo la información de un espacio de trabajo sigue siendo solo suya.

  • Cada espacio de trabajo se resuelve desde su propio subdominio antes que cualquier otra cosa, y toda consulta queda acotada a él.
  • Contraseñas protegidas con bcrypt y autenticación en dos pasos opcional.
  • Un registro de auditoría que solo añade, con los cambios de estado, los cambios de permisos y los accesos denegados.
  • Los registros eliminados se marcan, no se borran, para que el histórico siga siendo reconstruible.
Leer el artículo

Idioma y accesibilidad

Usable por todo el equipo, no solo por una parte.

  • Interfaz completa en español e inglés, conmutable en cualquier momento.
  • Temas claro y oscuro, recordados por persona.
  • Construido según WCAG 2.1 AA: navegación por teclado, contraste y lectores de pantalla.
  • Funciona en el móvil: las mismas pantallas, dispuestas para una pantalla pequeña.
Leer el artículo

¿Te queda alguna duda?

Si esto no responde a lo que necesitas, pregúntanos directamente: una persona lee cada mensaje.