Blog

Considerando al riesgo en marcos de trabajo Scrum

En un marco de trabajo Scrum, el Product Owner (PO) juega un papel crucial en la gestión de riesgos al definir historias de usuario y sus criterios de aceptación. Aquí se presentan las maneras en que el PO debe considerar los riesgos:

1. Identificación de Riesgos en la Definición de la Historia de Usuario

Descripción: El Product Owner debe identificar y considerar los riesgos potenciales al definir las historias de usuario. Esto incluye cualquier factor que pueda impactar el éxito de la historia, como la complejidad técnica, dependencias, o posibles fallos.

Ejemplo: Historia de Usuario: «Como usuario, quiero poder registrar una cuenta para acceder a servicios personalizados.»

Identificación de Riesgos:

• Riesgo Técnico: La integración con el sistema de autenticación puede fallar.
• Riesgo de Dependencias: Dependencia de una API externa que aún no ha sido desarrollada.

2. Inclusión de Riesgos en los Criterios de Aceptación

Descripción: Los criterios de aceptación deben incluir condiciones que aseguren que los riesgos identificados sean manejados adecuadamente durante el desarrollo y las pruebas.

Ejemplo: Historia de Usuario: «Como usuario, quiero poder registrar una cuenta para acceder a servicios personalizados.»

Criterios de Aceptación con Consideración de Riesgos:

1. Validación Técnica: La cuenta debe ser registrada y autenticada correctamente usando el sistema de autenticación.
2. Pruebas de Integración: La funcionalidad debe ser probada con la API externa para asegurar que la integración es exitosa y no presenta errores.
3. Gestión de Errores: Si la API externa no está disponible, el sistema debe manejar el error de manera adecuada y proporcionar un mensaje de error claro al usuario.

3. Priorización de Historias de Usuario Basadas en el Riesgo

Descripción: El Product Owner debe priorizar las historias de usuario teniendo en cuenta los riesgos asociados. Las historias con mayores riesgos o impacto crítico deben ser abordadas primero para mitigar los riesgos tempranamente.

Ejemplo: Si una historia de usuario involucra una nueva funcionalidad crítica que, si falla, podría tener un impacto significativo en el negocio, debe ser priorizada para ser abordada en los primeros sprints.

4. Definición de Historias de Usuario para Mitigación de Riesgos

Descripción: El PO puede definir historias de usuario específicas para abordar y mitigar riesgos identificados. Estas historias pueden enfocarse en pruebas, investigación o creación de prototipos.

Ejemplo: Historia de Usuario: «Como equipo de desarrollo, queremos realizar una prueba de integración con la API externa para identificar posibles problemas.»

Criterios de Aceptación:

1. Prueba Inicial Completa: La API externa debe ser probada y cualquier problema identificado debe ser documentado.
2. Documentación de Riesgos: Los riesgos identificados durante la integración deben ser documentados y discutidos con el equipo.

5. Colaboración con el Equipo de Desarrollo

Descripción: El PO debe colaborar estrechamente con el equipo de desarrollo para asegurarse de que los riesgos se gestionen adecuadamente. Esto incluye discusiones en las reuniones de planificación del sprint y revisiones regulares.

Ejemplo: Durante la planificación del sprint, el PO discute los riesgos asociados con cada historia de usuario y trabaja con el equipo para identificar tareas específicas para mitigar esos riesgos.

6. Actualización Continua del Backlog

Descripción: El Product Owner debe mantener el backlog del producto actualizado con la información más reciente sobre los riesgos y su estado. Esto asegura que el equipo esté siempre al tanto de los riesgos y pueda planificar en consecuencia.

Ejemplo: Después de cada sprint, el PO revisa y actualiza el backlog basado en los riesgos identificados y gestionados durante el sprint, ajustando las prioridades según sea necesario.

Conclusión

La consideración del riesgo en la definición de historias de usuario y criterios de aceptación es esencial para la entrega de proyectos exitosos en Scrum. El Product Owner debe:

• Identificar y documentar riesgos en las historias de usuario.
• Incluir criterios de aceptación que aborden estos riesgos.
• Priorizar historias de usuario basadas en el impacto de los riesgos.
• Definir historias de usuario específicas para mitigar riesgos.
• Colaborar con el equipo de desarrollo para gestionar riesgos continuamente.
• Mantener el backlog del producto actualizado con información de riesgos.

Este enfoque ayuda a asegurar que los riesgos sean gestionados de manera proactiva, minimizando su impacto en el proyecto y mejorando la calidad y previsibilidad de las entregas.

¿Cómo manejamos los casos de prueba en Gherkin?

El formato Gherkin es una herramienta poderosa para escribir casos de prueba en un lenguaje claro y comprensible, que ayuda a alinear a todos los miembros del equipo, incluidos los desarrolladores, testers y Product Owners. Al considerar los riesgos identificados en una historia de usuario, un tester puede elaborar casos de prueba en formato Gherkin que aborden estos riesgos de manera efectiva. Aquí te muestro cómo hacerlo paso a paso.

1. Comprender la Historia de Usuario y los Riesgos Asociados

Ejemplo de Historia de Usuario:

Riesgos Identificados:

• Riesgo Técnico: La integración con el sistema de autenticación puede fallar.
• Riesgo de Dependencias: Dependencia de una API externa que aún no ha sido desarrollada.
• Riesgo de Seguridad: Datos de usuario pueden ser vulnerables si no se manejan correctamente.

2. Definir los Criterios de Aceptación con Riesgos en Mente

Criterios de Aceptación:

1. El registro de la cuenta debe ser exitoso usando el sistema de autenticación.
2. La funcionalidad debe manejar correctamente la API externa.
3. Los datos del usuario deben ser almacenados de manera segura.

3. Elaborar Casos de Prueba en Formato Gherkin

Estructura de un Caso de Prueba en Gherkin:

• Feature: Describe la funcionalidad que se está probando.
• Scenario: Describe una situación específica o camino que se está probando.
• Given: Configura el contexto inicial.
• When: Describe la acción realizada por el usuario.
• Then: Describe el resultado esperado.

Ejemplos de Casos de Prueba en Gherkin

Caso de Prueba 1: Registro Exitoso

Feature: Registro de Cuenta

Caso de Prueba 2: Fallo en la Integración con la API Externa

Feature: Registro de Cuenta

Feature: Registro de Cuenta

Acción: Comparte los casos de prueba con el equipo (desarrolladores, Product Owner, y otros testers) para asegurarte de que todos los riesgos han sido considerados y que los casos de prueba cubren los escenarios relevantes.

Ejemplo: Organiza una revisión conjunta de los casos de prueba, discutiendo si hay algún riesgo adicional que debe ser cubierto o si alguna condición particular ha sido omitida.

5. Ejecutar y Ajustar los Casos de Prueba

Acción: Durante la ejecución de los casos de prueba, toma nota de cualquier nuevo riesgo identificado o de cualquier ajuste necesario en los casos de prueba existentes.

Ejemplo: Si durante las pruebas se descubre que hay un riesgo adicional no identificado previamente, como un problema de rendimiento, crea un nuevo caso de prueba en Gherkin para cubrir este nuevo riesgo.

Conclusión

Elaborar casos de prueba en formato Gherkin considerando los riesgos identificados en una historia de usuario es una práctica esencial para asegurar la calidad y seguridad del software. Al seguir los pasos mencionados, los testers pueden crear casos de prueba claros, comprensibles y efectivos que mitiguen los riesgos potenciales y aseguren que todas las funcionalidades se comporten según lo esperado.

Este enfoque también facilita la colaboración y la comunicación dentro del equipo, asegurando que todos los miembros comprendan los riesgos y las medidas tomadas para mitigarlos.

Considera como referencia

en el Syllabus del ISTQB CTFL v4.0, la sección 5.2. Gestión de Riesgos

• 5.2.1. Definición del Riesgo y Atributos del Riesgo
• 5.2.2. Riesgos de Proyecto y Riesgos de Producto
• 5.2.3. Análisis de Riesgos de Producto
• 5.2.4. Control de Riesgos de Producto