En nuestro proceso Agile/Scrum, ¿deberíamos tener una etapa de prueba de aceptación del cliente (CAT) en la que el propietario del producto observa lo que se ha desarrollado y reconoce que cumple con todos los criterios de aceptación?
Las pruebas de aceptación del usuario deben realizarse como un proceso separado fuera del sprint siempre que sea posible. Se puede incorporar dentro del sprint, pero hay una serie de advertencias y un gran potencial para el avance del alcance en el sprint.
Las pruebas de aceptación significan diferentes cosas en diferentes organizaciones. En algunas empresas, significa "asegurarse de que el widget cumpla con las especificaciones originales". En otros, significa que alguien firma que la función funciona para ellos, ya sea que haga lo que quieren o no. Una vez más, a veces las pruebas de aceptación significan que alguien revisa la función para ver si le gusta.
La idea general de Scrum es que los clientes (directamente o a través de su representante, el propietario del producto) permanezcan comprometidos durante todo el proceso. Además, la Revisión de Sprint al final de cada iteración es la oportunidad para que las partes interesadas vean las funciones demostradas y ofrezcan comentarios al respecto.
Tenga en cuenta que los comentarios negativos en una revisión de Sprint no significan que el Sprint falló o que las historias de usuario no se completaron de acuerdo con la "definición de hecho". Simplemente significa que la función, incluso si funciona como se diseñó o se especificó , no cumple con una expectativa no documentada (o modificada recientemente).
Si las Revisiones de Sprint ligeras son insuficientes para sus propósitos, siempre puede incluir una tarea de aceptación del usuario en cada historia como parte de su "definición de hecho". Por ejemplo, después de que una función haya superado el paso de control de calidad del sprint, puede pedirle a Joe de contabilidad que pruebe cada función nueva en un sistema de preparación antes de llamarla "terminada".
Sin embargo, si hace que las pruebas de aceptación del usuario formen parte de su definición de hecho, debe asegurarse de que las estimaciones de su historia también incluyan ese esfuerzo. Además, debe decidir qué deben medir las pruebas de aceptación; por ejemplo, ¿debería medir la satisfacción o simplemente la conformidad tal como se definió al comienzo del sprint?
También debe pensar en cuál debería ser el proceso del equipo si una historia es técnicamente correcta, pero no cumple con una "definición de hecho" que incluye la prueba de aceptación del usuario. Si "deleitar al usuario" es parte de su definición de hecho, una idea impracticable que las personas a veces intentan, entonces la mejor práctica sería tratar las variaciones significativas en la historia como un nuevo alcance que debería volver al propietario del producto para volver. priorizar en el Product Backlog.
Definir los límites de variación aceptable para cualquier historia de usuario es un trabajo que debe explorar todo el equipo de Scrum dentro del marco del proceso. Solo asegúrese de mantener su variación aceptable dentro de límites sensatos, o los requisitos deficientes nunca dejarán de mover su queso.
Cada historia debe tener (una lista de) criterios de aceptación muy claros, como máximo acordados en la planificación del sprint.
Entonces, todos los miembros del equipo saben cómo terminar la historia y un rechazo por parte de PO no debería ser una sorpresa. Si fuera una sorpresa, debería hacer mejores criterios de aceptación y/o hacer más preguntas (también durante el sprint) al equipo y al PO.
NB cuando menciona etapas, eso es muy "cascada". La forma ágil es encontrar reglas simples para que el equipo pueda autoorganizarse sin etapas o controles formales como se describe anteriormente...