Empieza un producto nuevo en Taiga

Prepara un resultado claro

Este escenario usa un servicio ficticio de solicitudes de equipamiento. Un responsable registra la solicitud de un empleado y la decisión. El autoservicio para empleados queda para una ampliación posterior. Usa registros sintéticos durante el aprendizaje. El escenario no autoriza el uso de datos reales de personal.

Antes de crear el producto, confirma que la organización y el contexto compartido pertinente están configurados. Identifica a la persona responsable del resultado del servicio y al equipo responsable de su entorno operativo.

Escribe un límite inicial: la primera versión registra solicitudes y decisiones. No encarga equipamiento, aprueba gastos automáticamente ni modifica registros de nóminas.

Elige cómo empieza el producto

Elige Start from scratch para este servicio nuevo. Usa Import codebase cuando un repositorio existente deba definir el punto de partida. La importación se elige al crear el producto, así que decide de forma consciente.

La creación también pregunta si Taiga escribe Infrastructure code y CI/CD pipelines. Son responsabilidades separadas. Si tu equipo de plataforma ya aporta una parte, desactiva esa opción de generación y describe cómo se hace el trabajo actualmente.

Por ejemplo: «Nuestra plataforma despliega imágenes de contenedor revisadas mediante el pipeline existente del repositorio. Usa su identidad de carga de trabajo y su configuración de entornos». Confirma que esta descripción sea correcta antes de basarte en ella.

Aporta contexto antes de la conversación

Discovery empieza por Context. Añade material de referencia del producto e instrucciones permanentes antes de la conversación. Sitúa las reglas compartidas por varios productos en el nivel de organización o factory.

Para el servicio de equipamiento, el contexto útil incluye el método de identidad de empleados, los servicios de datos aprobados y la regla de acceso de los responsables. Expón las preguntas sin resolver de forma explícita. No inventes un periodo de conservación para completar un formulario.

Después, describe el servicio en la conversación. Explica los usuarios, el resultado deseado, las restricciones y lo que queda fuera del alcance. La especificación se guarda como borrador mientras trabajas.

Revisa y publica la intención

Lee la especificación para detectar suposiciones que cambiarían la implementación. En este escenario, comprueba si un responsable puede ver todas las solicitudes de empleados o solo las de su equipo. Esa diferencia afecta a permisos, flujos de datos y pruebas.

Publica la especificación cuando su contenido sea adecuado para el trabajo posterior. Los cambios en borrador no sustituyen la versión publicada hasta que vuelvas a publicar. Continúa con los documentos obligatorios y revisa sus suposiciones. La lección de Discovery explica las dependencias y los documentos desactualizados.

Cuando los ocho documentos obligatorios estén publicados, termina Discovery y planifica las iniciativas. La secuencia generada es una propuesta que puedes examinar y modificar.

Conecta el destino real de entrega

Conecta el repositorio antes de planificar las iniciativas en detalle. Define al mismo tiempo los entornos previstos, aunque no haga falta un entorno para empezar a planificar.

La descripción de un entorno no concede acceso cloud. Tu pipeline realiza el despliegue. Comprueba con el equipo responsable la rama del repositorio, la identidad, la responsabilidad de infraestructura y las tareas de configuración necesarias.

El resultado útil de este escenario es un producto definido y trabajo revisable basado en su entorno real de entrega. Practica la secuencia de decisiones en la simulación del flujo de Taiga.