RobustoConversemos
← Inicio / Método

Un proceso que puedes verificar, no una promesa.

Somos un equipo pequeño que trabaja como uno grande: ciclos semanales, cada cambio revisado y probado, documentación basada en ISO/IEC 29110 e inteligencia artificial con reglas claras. Todo lo que ves en esta página sale del proyecto real del LMS.

Trazabilidad

Elige un criterio y sigue su rastro hasta la aceptación.

Cada cosa que el sistema debe hacer se escribe como un criterio verificable antes de programar. Ese criterio tiene un test con su mismo nombre, un PR que lo entrega, una ejecución del CI y una aceptación del Cliente. Así se ve la cadena con datos reales.

    Datos copiados del repositorio privado del LMS al 2026-10-16.

    Scrum + Kanban

    Ciclos de una semana. Un tablero que muestra todo.

    Tomamos de Scrum el ciclo corto con planificación y demo, y de Kanban el tablero donde cada historia avanza a la vista de todos. Nunca pasa más de una semana sin que veas software funcionando.

    1. Viernes

      Planificación

      Elegimos contigo las historias de la semana y sus criterios de aceptación.

    2. Lunes a jueves

      Construcción

      Cada historia avanza por el tablero: un PR por capa, cada uno con sus pruebas.

    3. Viernes

      Demo y aceptación

      Ves lo nuevo en el ambiente de prueba, aceptas o pides cambios, y queda en el acta.

    El tablero del LMS hoy

    Backlog3
    #32 Ver y editar mi perfil
    #33 Asignar rol en la organización
    #36 Crear curso con fechas
    En progreso0

    Vacía esta semana

    En revisión0

    Vacía esta semana

    Hecho2
    #29 Crear organización con admin inicial
    #31 Iniciar sesión y elegir organización

    GitFlow

    Cada cambio tiene su camino, su revisión y su registro.

    Ramas de GitFlow: las ramas feat salen de develop y vuelven por Pull Request; develop se publica a main. maindevelopfeat/… → PRfix/… → PRrelease
    develop despliega solo al ambiente de prueba; main, a producción.

    Nada directo a producción

    main y develop solo reciben cambios por Pull Request.

    Un PR por capa

    Una historia se entrega en orden: base de datos → backend → frontend.

    Ramas y commits con nombre

    feat/, fix/, docs/… y Conventional Commits: el historial se lee como un registro de cambios.

    Otra persona aprueba

    Quien escribe un cambio no se lo aprueba: lo revisa otro integrante, con el CI en verde.

    ISO/IEC 29110 · perfil Entrada

    Lo que recibes además del software.

    ISO/IEC 29110 es la norma de ciclo de vida de software para organizaciones pequeñas. Adoptamos su perfil Entrada de forma liviana: cada actividad deja un documento concreto y verificable. Estos son los del LMS y su estado real.

    PM.1

    Plan de proyecto

    Alcance, fases, riesgos y calendario acordados al inicio.

    Hecho
    PM.3

    Actas semanales

    Demo, aceptación de cada historia y resultado de cada caso de prueba.

    Primera acta: 16-10-2026
    SI.2

    Especificación de requisitos

    Qué debe hacer el sistema, validado por el Cliente.

    Validada el 12-10-2026
    SI.3

    Arquitectura y decisiones (ADR)

    Por qué el sistema está construido así, decisión por decisión.

    7 ADR
    SI.3

    Casos de prueba

    Criterios "dado… cuando… entonces…" escritos antes de programar.

    En cada historia
    SI.2–5

    Matriz de trazabilidad

    Requisito → historia → PR → casos de prueba → evidencia.

    En uso
    SI.6

    Manual de operación

    Uso, despliegue y respaldo del sistema.

    Borrador
    PM.4

    Acta de aceptación

    Cierre formal: qué se entregó y qué aceptó el Cliente.

    Al lanzar el MVP

    Basado en ISO/IEC 29110, perfil Entrada, en adopción liviana. No es una certificación.

    IA con reglas · Claude Code

    La IA acelera. Las personas deciden.

    Desarrollamos con Claude Code organizado en agentes especializados. Cada uno trabaja en su parte del sistema y tiene prohibido lo demás. Ninguno hace commit, abre un PR ni despliega: eso lo hace siempre una persona.

    1. Persona

      Una persona escribe los criterios con el Cliente

    2. Agente

      El agente escribe primero los tests, con el ID de cada criterio

    3. Agente

      Después, el código que los hace pasar

    4. Agente

      Entrega una tabla criterio → test → resultado

    5. Persona

      Una persona revisa, hace commit y abre el PR

    6. Persona

      Otro integrante y el CI aprueban

    database

    ✓ Modelo de datos y migraciones

    × No toca services, frontend ni CI

    backend

    ✓ API NestJS y sus tests por caso de prueba

    × No toca frontend, docker ni CI

    frontend

    ✓ Angular y tests E2E

    × No toca backend, docker ni CI

    Las personas decidenIA propone → persona revisa → commit → PR → CI

    devops

    ✓ Docker y pipelines de CI/CD

    × No ejecuta comandos: propone y una persona corre

    reviewer

    ✓ Revisa cada PR contra sus casos de prueba

    × Solo lectura: no modifica nada

    server-auditor

    ✓ Diagnostica el servidor

    × Solo lectura: nunca despliega ni instala

    acta

    ✓ Prepara el borrador del acta semanal desde GitHub

    × No cierra issues, no comenta, no commitea

    Lo que todavía no está

    Adoptamos este proceso completo en octubre de 2026. Hasta hoy, 2 de las 35 historias del LMS lo han recorrido de punta a punta, y sus primeros PRs se mergearon sin la revisión de otro integrante. Lo mostramos igual porque el proceso está hecho para detectar justamente eso: quedó registrado en el acta y la revisión es una tarea pendiente.

    Conversemos tu proyecto