Agencia de software · Entrega
Desarrollo de software y aceptación del cliente
Lleva cada hito de los requisitos acordados a una conformidad del cliente que queda registrada. El cliente confirma los criterios de aceptación y da su conformidad desde un enlace público, y ninguna versión le llega antes de que QA y el líder de ingeniería la aprueben.
- Duración: 4 a 8 semanas
- Frecuencia: Para cada hito
- Pasos: 11 pasos
- Agentes de IA: 2 agentes de IA
- Aprobaciones: 3 aprobaciones
Plan gratuito, sin tarjeta de crédito.
Qué cambia con esta plantilla
Sin la plantilla
El cliente se acuerda de una función imprescindible en la demo del sprint.
Una versión probada a medias llega a staging la noche antes de la demo.
La aceptación es un pulgar arriba en una llamada que un mes después nadie encuentra.
QA escribe cada plan de pruebas desde cero.
Con la plantilla
El cliente confirma los criterios de aceptación antes del desarrollo, y el equipo trabaja con una sola lista.
Las pruebas del cliente siguen bloqueadas hasta que QA y el líder de ingeniería aprueban la versión.
El cliente da su conformidad en la ejecución, con las comprobaciones marcadas, su nombre y la hora.
Un agente de IA redacta el plan a partir de los criterios, y el ingeniero de QA lo revisa.
La plantilla, paso a paso
Cada paso indica quién lo hace: alguien de tu equipo, un agente de IA o el cliente mediante un enlace público. Una aprobación mantiene bloqueados todos los pasos siguientes hasta que se da.
- Lo hace tu equipo
- Lo hace un agente de IA
- Lo hace el cliente, mediante un enlace público
Empieza cuando
Un hito del documento de alcance está listo para empezar. El gerente de producto inicia una ejecución con el nombre del cliente y el hito.
- 1
Redactar el alcance y los criterios de aceptación
Semana 1Gerente de producto · Equipo
Convierte el hito del documento de alcance en historias de usuario con criterios de aceptación comprobables, anota las preguntas que el cliente aún debe responder y envía ambos por correo, con los diseños, al product owner del cliente.
Lista de verificación
- Cada historia tiene criterios de aceptación
- Lo que queda fuera del alcance está anotado
- Criterios y diseños enviados al cliente
Campos que rellenar
- Hito (obligatorio)
- Criterios de aceptación (obligatorio)
- Preguntas para el cliente
- Enlace a los diseños (obligatorio)
- 2
El cliente confirma los requisitos
Semana 1Product owner del cliente · Enlace público
El product owner del cliente lee los criterios de aceptación, los diseños y las preguntas que le envió el gerente de producto, y después responde las preguntas y confirma el alcance en el enlace público. El equipo desarrolla y prueba según lo que se confirma aquí.
Lista de verificación
- Criterios de aceptación leídos
- Diseños revisados
- Preguntas abiertas respondidas
Campos que rellenar
- Respuestas a las preguntas abiertas
- Enlace a reglas de negocio o ejemplos
- Confirmo los criterios de aceptación (obligatorio)
- 3
Redactar el plan de pruebas
Semana 1Redactor de planes de prueba · Agente de IA
El redactor de planes de prueba convierte cada criterio de aceptación confirmado en casos de prueba con pasos y resultados esperados, y añade comprobaciones de regresión para las funciones que toca el hito.
Campos que rellenar
- Borrador del plan de pruebas (obligatorio)
Revisión humana: El ingeniero de QA revisa y completa el plan de pruebas en el paso 4.
- 4
Revisar el plan de pruebas
Oculto en el enlace públicoSemana 2Ingeniero de QA · Equipo
Comprueba que cada criterio de aceptación tiene un caso de prueba, añade los casos límite que faltan en el borrador y enlaza el plan de pruebas definitivo.
Lista de verificación
- Cada criterio tiene un caso de prueba
- Casos límite añadidos
- Datos de prueba listos en staging
Campos que rellenar
- Enlace al plan de pruebas definitivo (obligatorio)
- 5
Desarrollar y revisar por sprints
Semanas 2 a 5Líder de ingeniería · Equipo
Desarrolla las historias por sprints y revisa cada cambio antes de integrarlo. Si el equipo espera una respuesta del cliente, marca la ejecución como bloqueada y anota la pregunta.
Lista de verificación
- Cada cambio revisado antes de integrarlo
- Demos de sprint hechas con el cliente
- Ninguna pregunta abierta al cliente
Campos que rellenar
- Fecha prevista de la versión (obligatorio)
- Notas del sprint (obligatorio)
- Enlace a los cambios integrados (obligatorio)
- Lo que el equipo está esperando
- 6
Probar cada criterio en staging
Oculto en el enlace públicoSemana 6Ingeniero de QA · Equipo
Ejecuta el plan de pruebas en staging, registra los defectos en el gestor de incidencias y vuelve a probar las correcciones hasta que no quede ningún error crítico ni grave abierto.
Lista de verificación
- Cada criterio probado
- Pruebas de regresión hechas
- Ningún error crítico ni grave abierto
- Problemas menores conocidos anotados
Campos que rellenar
- Enlace al informe de pruebas (obligatorio)
- Problemas conocidos
Aprobación: La aprobación de la versión sigue bloqueada hasta que el ingeniero de QA aprueba los resultados de las pruebas.
- 7
Redactar las notas de la versión
Semana 6Redactor de notas de versión · Agente de IA
El redactor de notas de versión redacta para el cliente las notas a partir de los criterios de aceptación, las notas del sprint y los problemas conocidos: qué es nuevo, qué ha cambiado y qué sigue pendiente.
Campos que rellenar
- Borrador de las notas de la versión (obligatorio)
Revisión humana: El líder de ingeniería corrige las notas y aprueba la versión en el paso 8.
- 8
Aprobar la versión para las pruebas del cliente
Semana 6Líder de ingeniería · Equipo
Lee el informe de pruebas, corrige las notas de la versión y comprueba que staging ejecuta la versión probada. Después apruébala y envía por correo al product owner del cliente el enlace a staging y las notas de la versión.
Lista de verificación
- Informe de pruebas leído
- Notas de la versión corregidas
- Staging ejecuta la versión probada
Campos que rellenar
- Enlace a staging enviado al cliente (obligatorio)
Aprobación: Las pruebas del cliente siguen bloqueadas hasta que el líder de ingeniería aprueba la versión.
- 9
El cliente prueba en staging y da su conformidad
Semana 7Product owner del cliente · Enlace público
El product owner del cliente prueba la versión en staging, con el enlace que le envió el equipo, según los criterios de aceptación, y después marca cada comprobación y registra su decisión en el enlace público. Los problemas van en el campo de abajo, con enlaces a capturas de pantalla o grabaciones.
Lista de verificación
- Cada criterio de aceptación probado
- Notas de la versión leídas
Campos que rellenar
- Decisión (obligatorio)
- Problemas encontrados
- Enlaces a capturas de pantalla o grabaciones
- 10
Decidir sobre los hallazgos del cliente
Semana 7Gerente de producto · Equipo
Repasa la decisión y cada hallazgo con el líder de ingeniería. Si un hallazgo bloquea la aceptación, marca la ejecución como bloqueada con el motivo hasta verificar la corrección y que el cliente esté de acuerdo, y después aprueba el paso a producción.
Lista de verificación
- Cada hallazgo marcado como bloqueante o no
- Hallazgos bloqueantes corregidos y verificados
- Resto de hallazgos planificados para un hito posterior
Campos que rellenar
- Hallazgos pasados a un hito posterior
Aprobación: El paso a producción sigue bloqueado hasta que el gerente de producto lo aprueba.
- 11
Publicar en producción y cerrar el hito
Semana 7Ingeniero de DevOps · Equipo
Despliega la versión aceptada con el plan de vuelta atrás preparado, haz las pruebas de humo y registra la versión publicada.
Lista de verificación
- Plan de vuelta atrás preparado
- Pruebas de humo superadas
- Monitorización revisada tras la publicación
Campos que rellenar
- Versión publicada (obligatorio)
- Fecha de publicación (obligatorio)
Termina cuando
El cliente ha dado su conformidad al hito según los criterios acordados, y la versión está en producción con el informe de pruebas, las aprobaciones y la conformidad en la ejecución.
Hazla tuya. Cambia el nombre de los pasos y los responsables, y añade elementos a la lista, campos o aprobaciones. La plantilla es un punto de partida para la forma de trabajar de tu equipo.
Los agentes de IA de esta plantilla
Un agente solo trabaja en sus propios pasos, y una persona de tu equipo revisa lo que hizo. Todo lo que un agente escribe en una app conectada espera aprobación, salvo que lo permitas.
Redactor de planes de prueba
Convierte los criterios de aceptación confirmados en un borrador de plan de pruebas.
Qué hace
- Lee los criterios de aceptación y las respuestas del cliente en la ejecución
- Escribe casos de prueba con pasos y resultados esperados
- Añade comprobaciones de regresión para las funciones que toca el hito
- Completa su paso para que el ingeniero de QA pueda revisarlo
Revisión humana: El ingeniero de QA revisa y completa el plan de pruebas en el paso 4.
Redactor de notas de versión
Redacta para el cliente las notas de la versión que pasa a sus pruebas.
Qué hace
- Lee los criterios de aceptación, las notas del sprint y los problemas conocidos
- Escribe qué es nuevo, qué ha cambiado y qué sigue pendiente
- Usa un lenguaje claro para el cliente
- Completa su paso para que empiece la aprobación de la versión
Revisión humana: El líder de ingeniería corrige las notas y aprueba la versión en el paso 8.
Preguntas que responde esta plantilla
Pide la conformidad según los criterios de aceptación que el cliente confirmó al inicio, no según una demo. En el paso 9 el product owner del cliente prueba en staging y después marca cada comprobación y registra su decisión en el enlace público, con su nombre y la hora en la ejecución.
Acuerda criterios de aceptación comprobables antes de empezar el desarrollo y haz que el cliente los confirme por escrito. En el paso 2 el product owner del cliente responde las preguntas abiertas y confirma los criterios en el enlace público, así el equipo desarrolla y prueba según una única lista acordada.
Haz que las pruebas del cliente dependan de resultados de pruebas aprobados, no de la fecha de la demo. Los pasos 6 y 8 son controles de aprobación: las pruebas del cliente siguen bloqueadas hasta que el ingeniero de QA y el líder de ingeniería aprueban la versión.
Guarda los criterios de aceptación, los resultados de las pruebas y la decisión del cliente en un mismo registro. La ejecución muestra los criterios confirmados en el paso 2, los resultados y aprobaciones de los pasos 6 y 8, y la conformidad del paso 9 con nombre y hora.
Deja que la IA redacte el plan de pruebas y las notas de la versión a partir de lo que tu equipo ya escribió, y que la revisión quede en manos de personas. En el paso 3 el redactor de planes de prueba redacta casos de prueba que el ingeniero de QA revisa en el paso 4, y en el paso 7 el redactor de notas de versión redacta notas que el líder de ingeniería corrige en el paso 8.
Separa los errores que bloquean la aceptación de los que pueden esperar, y deja que una persona tome esa decisión. En el paso 10 el gerente de producto marca cada hallazgo como bloqueante o no, mantiene la ejecución bloqueada hasta verificar las correcciones bloqueantes y solo entonces aprueba la versión.
Ejecuta este flujo en OKiDO
Configura los pasos, los responsables y las aprobaciones una vez, y luego inicia una ejecución para cada caso nuevo.