Convierte un resultado en una iniciativa

Describe el resultado antes que los pasos

El servicio ficticio de equipamiento necesita autoservicio para empleados. Una solicitud útil expresa el resultado: «Un empleado autenticado puede crear una solicitud y ver solo sus propias solicitudes».

Explica por qué importa: actualmente los responsables introducen las solicitudes de los empleados. Define el alcance: creación de solicitudes, visualización de su estado, comprobaciones de acceso y pruebas de esos comportamientos. Excluye las compras automáticas y los cambios en la regla de aprobación del responsable.

No prescribas ediciones de archivos antes de examinar el repositorio. La iniciativa recoge la intención; la planificación detallada la convierte en pasos de implementación.

Revisa lo que produjo la solicitud

Taiga usa la solicitud y el contexto del producto para crear una iniciativa o un conjunto ordenado de iniciativas. El trabajo nuevo llega a Backlog. Una solicitud más amplia puede necesitar varios cambios que se puedan revisar por separado.

Lee el estado final generado, Why y Scope. Comprueba que se conserve el comportamiento requerido y se respeten las exclusiones. Si una iniciativa existente ya cubre la solicitud, Taiga puede indicarla en lugar de crear un duplicado.

Una solicitud bloqueada por una política publicada necesita la vía de decisión que define esa política. Lee la explicación y resuelve el conflicto por esa vía. No reescribas la solicitud solo para ocultar la acción prohibida.

Trata el tablero como una secuencia de ejecución

Taiga trabaja en una iniciativa a la vez por producto, incluida la planificación. Empieza la siguiente iniciativa en cola después del merge de la pull request actual. No mueve automáticamente elementos de Backlog o Todo a Queue.

La colocación en Queue importa. Anula la espera por dependencias sin terminar. Antes de poner en cola el autoservicio para empleados, confirma que exista la base de identidad o que el alcance elegido la establezca correctamente.

Examina el plan detallado

El planificador lee el repositorio, los documentos del producto, las políticas, las instrucciones y el contexto de despliegue. Comprueba el plan frente al resultado real para el usuario y el entorno.

Para el servicio de equipamiento, verifica tres casos de acceso. Un empleado ve su solicitud. Otro empleado no puede verla. Un responsable conserva el acceso de revisión previsto. Incluye la migración de datos y los efectos operativos si la implementación los cambia.

Si Build on its own by default está desactivado, el plan terminado espera tu decisión. Approve inicia la implementación como la persona que aprueba, sujeta a sus permisos. Reject usa tus comentarios para volver a planificar. Una iniciativa puede tener su propio ajuste.

Usa el registro adecuado para la siguiente decisión

Los planes tienen versiones. Una ejecución registra qué plan ejecutó. Si cambia el enfoque previsto, revisa la iniciativa y la acción de nueva planificación adecuada. Usa la ejecución para examinar el intento anterior.

Una implementación, una pull request con el merge completado y una publicación en producción son estados diferentes. Mantén visibles las pruebas de aceptación y la responsabilidad del despliegue a medida que avance el trabajo. Continúa con los ajustes de autonomía.