Bugs, cambio de requisitos y el dilema de PO

 
En mi última publicación, no tuve espacio o tiempo para explorar otros problemas de acumulación de pedidos, que se vuelven más importantes una vez que comienza la fase de implementación: bugs (o defectos) y cambio de requisitos (o solicitudes de cambio – Change request o Change Requirements, CR). Los bugs deben incluirse en el backlog, porque tomarán la capacidad para resolverse y traerán insatisfacción al usuario. En esta publicación abordaremos diferentes preguntas: a qué tipo de errores y solicitudes de cambio podemos enfrentarnos, en qué contextos los enfrentaremos, quiénes normalmente los reportarán en el backlog y el dilema del Product Owner entre la ocupación de capacidad  con una nueva función o la solución de bugs o mejora / adaptación de los detalles del producto. 

Que tipo de bugs y solicitudes de cambios que podemos encontrar?

Los mencionados anteriormente, en el post Jerarquía de requisitos, qué debe escribirse por cada nivel y por quién. Aqui se exploró el tema de la transición entre los niveles de detalle de los requisitos, de alto nivel hasta niveles más detallados, quando nos acercamos a la implementación. También comparto mi opinión sobre quien debería escribir requisitos y en cada uno de los diferentes niveles. Ahora iremos a concentrarnos en estos dos tipos de requisitos o problemas que pueden encontrarse en el backlog: bugs and change requirements (CR).
Un bug es un comportamiento del software que no se havia especificado para la función que se intenta executar, o que se realiza con varianza para la especificación inicial. El cambio de requisitos es una adaptación o un cambio en el comportamiento del software que tiene en cuenta una especificación.
Un error normalmente se clasifica según dos criterios: severidad y frecuencia. La gravedad significa cuánto está bloqueando al usuario final el uso del producto como se especificó inicialmente. También puede considerar la importancia de la funcionalidad para el uso final (por ejemplo, ¿es una funcionalidad principal del producto o simplemente una funcionalidad secundaria, que no se usa con tanta frecuencia?). Frecuencia significa con qué a menudo sucede.
Un bug puede ser funcional si la función no se realiza o non funcional si la función se realiza pero los atributos non funcionales  del producto se ven afectados, como: seguridad o rendimiento, por ejemplo. A menudo, los errores funcionales se activan con pruebas de usuario (por ejemplo, pruebas manuales, smoke tests o sanity tests) o pruebas automatizadas (por ejemplo, pruebas de regresión). Los bugs en los parámetros non funcionales del productos exigen métodos de prueba más complejos (por ejemplo, pruebas de seguridad, penetration tests).


(adsbygoogle = window.adsbygoogle || []).push({});

Un cambio de requisito también puede ser funcional o non funcional y esto define normalmente quién lo identifica y lo escribe en el registro. Tenga en cuenta que un cambio de requisito forma parte del ciclo de vida del producto, es natural que ocurra. Lo que se puede ver como ineficiencia es si el cambio de requisito se produce en medio de la release para implementar a un nuevo requisito por primera vez.

El dilema del propietario del producto entre la capacidad a ocupar con una nueva funcionalidad, a corregir bugs o a mejorar / adaptar los detalles del producto (CR)

Los bugs y los cambio de requisito suelen entrar en el backlog después de que la capacidad para el sprint o para la release se haya alcanzado y acordado por completo. Y esto es un gran error. Antes de acordar en los objectivos de la release, debemos considerar cuánto queremos invertir en la calidad y mejora del producto en comparación con lo que queremos invertir con las nuevas características.
Esta competencia por la capacidad del equipo debe resolverse entre el equipo y el Propietario del producto con la moderacion del Scrum Master. Para apoyar esta negociación, le recomiendo que lea: ¡Prepárese para una negociación del release plan!


(adsbygoogle = window.adsbygoogle || []).push({});

Uncategorized

Leave a Reply