Turpial Development Turpial Development
EN
Metodología Turpial · MTIS

Software que no puede fallar empieza por entender tu negocio.

El Método Turpial de Ingeniería de Software (MTIS) parte de Scrum y suma lo mejor del desarrollo guiado por pruebas (TDD), el diseño guiado por el dominio (DDD), el diseño de experiencia y la gestión del cambio. Con inteligencia artificial en todo el proceso y la calidad como condición, no como fase final.

Por qué un método propio

«Usamos Scrum» no es suficiente

Scrum organiza el trabajo, no garantiza el resultado

Scrum define cómo iterar. No dice qué construir ni con qué calidad. Por eso empezamos por el negocio y cerramos cada sprint con una definición de terminado exigente.

La IA acelera, y también amplifica

La investigación DORA de Google describe la IA como un amplificador: potencia las fortalezas de un equipo y también sus debilidades, y asocia su adopción con menor estabilidad en la entrega. Por eso la usamos dentro de un sistema de calidad.

Leer el informe DORA 2025 ↗

El software que no se adopta no sirve

Un sistema impecable que nadie usa es un proyecto fallido. La gestión del cambio empieza en la primera fase, no el día del lanzamiento.

Las 6 E

Seis fases, de entender a evolucionar

Las dos primeras son las que más nos definen: entender el negocio y planificar el trabajo es lo que hace que el desarrollo salga bien.

Entender el negocio

Qué hacemos
Inmersión en el modelo de negocio, sus actores, procesos y restricciones. Talleres para descubrir el dominio antes de hablar de tecnología.
Qué recibes
Un mapa del dominio y el problema priorizado.

Estructurar el plan

Qué hacemos
Objetivo del producto, backlog priorizado por valor de negocio, arquitectura con decisiones documentadas, riesgos, definición de terminado y plan de calidad.
Qué recibes
Plan, arquitectura y una estimación acotada.

Experimentar la experiencia

Qué hacemos
Prototipos, pruebas con usuarios y sistema de diseño. El diseño no termina cuando empieza el código: acompaña la construcción.
Qué recibes
Flujos y diseño validados con usuarios reales.

Ejecutar con calidad

Qué hacemos
Sprints que terminan en un incremento funcional, desarrollo guiado por pruebas, revisión de código obligatoria e integración continua con compuertas de calidad.
Qué recibes
Un incremento probado al final de cada sprint.

Entregar y lograr adopción

Qué hacemos
Despliegue, pruebas finales, traspaso de código y cuentas, capacitación y un plan de adopción para que el sistema se use de verdad.
Qué recibes
Sistema en producción, documentación y usuarios capacitados.

Evolucionar con datos

Qué hacemos
Medimos la salud de la entrega con las métricas de DORA y planificamos las siguientes iteraciones sobre esa evidencia.
Qué recibes
Un tablero de salud y una hoja de ruta.
Transversal

Lo que atraviesa todo el método

Calidad: MTAC

Nuestro Método de Aseguramiento de Calidad es una compuerta en cada sprint, no una revisión al final. Es el mismo método que usamos para auditar el software de otros.

Conocer MTAC →

IA, con controles

Usamos IA en descubrimiento, requerimientos, diseño, código, pruebas, revisión, documentación y operación. La regla: todo lo que genera la IA pasa por revisión humana y por las mismas compuertas que el código escrito por personas.

Gestión del cambio

Trabajamos la adopción con el modelo ADKAR: conciencia, deseo, conocimiento, habilidad y refuerzo. La conciencia y el deseo se trabajan desde el inicio; el conocimiento y la habilidad, antes de cada entrega.

Definición de terminado

Cuándo decimos que algo está terminado

La publicamos porque se puede verificar. Un incremento no está terminado hasta que cumple todo esto:

  • Pruebas automatizadas para la lógica nueva
  • Revisión de código por al menos otro ingeniero
  • Integración continua en verde
  • Cero hallazgos críticos según MTAC
  • Documentación actualizada
  • Lo generado con IA pasó las mismas compuertas
Siguiente paso

¿Tienes un proyecto que no puede salir mal?

Cuéntanos qué hay que construir. Empezamos por entender tu negocio.