Corregir bugs de forma rápida y sencilla

La corrección de bugs ya era un desafío en el desarrollo de software antes de Scrum. Las iteraciones cortas en Agile no facilitan necesariamente a los equipos la decisión de qué bugs deben corregirse y cuáles pueden esperar.

La buena noticia es que un Scrum Team normalmente tiene muchos menos bugs que un equipo que trabaja con frameworks de desarrollo más tradicionales. Pero incluso los equipos ágiles encuentran de vez en cuando algún bug, especialmente si parte del desarrollo proviene de la época anterior a que el equipo adoptara un enfoque ágil. Y para priorizar estos defectos, el equipo necesita una solución efectiva.

Priorización de correcciones de bugs: lo que no se debe hacer

Al principio de mi carrera como programador, mi jefe sacó a todo el equipo durante una semana para hablar sobre todos los defectos conocidos. Hablamos sobre posibles causas, sobre la gravedad de cada bug, con qué frecuencia ocurría, si se podía reproducir, dónde en el código podría estar el error y quién de nosotros debería solucionar el problema.

Incluso estimamos cuánto tiempo llevaría para cada bug. Estas estimaciones en la mayoría de los casos no solo fueron bastante inútiles, sino que generalmente tomó más tiempo hacer la estimación que simplemente corregir el bug.

Cuando, después de estas experiencias tempranas, empecé a liderar equipos, comencé a experimentar con otros enfoques más ligeros.

Hoy quiero presentar mi método favorito para la corrección de bugs.

Directrices para la priorización de bugs

En lugar de tomarse el tiempo para pensar en cada bug individual, es mejor crear directrices que determinen qué tan rápido debe corregirse un bug o cuán alto es el impacto del defecto cuando ocurre.

Ejemplo 1: Una de estas directrices podría ser que cualquier bug que afecte dramáticamente a todos los usuarios debe corregirse de inmediato, es decir, que se interrumpan los trabajos en curso del Sprint. Otra directriz podría establecer, por ejemplo, que los bugs que ocurren extremadamente raramente y no impiden al usuario ejecutar las funciones más importantes se documenten y se corrijan sin presión cuando haya tiempo para ello.

Crear y utilizar directrices se conoce también como priorización por políticas (prioritization by policy).

Ejemplo 2: Un ejemplo más concreto sería cuando el Product Owner y su equipo acuerdan que cualquier bug que impida a los usuarios realizar pedidos en su página de comercio electrónico debe corregirse lo antes posible.

Otras directrices podrían referirse a bugs que solo deben corregirse al final del día, al final de la semana o incluso no corregirse en absoluto.

Definir directrices de defectos

Para formular directrices de corrección de bugs son útiles las siguientes consideraciones:

• Probabilidad de un defecto: ¿Con qué frecuencia ocurre el problema?
• Gravedad de un defecto: ¿Qué tan malo es cuando ocurre el problema?

Imagínate que en Amazon hay un bug que provoca que los pedidos con un valor de 1 millón de dólares no se puedan realizar, porque un desarrollador asumió que un pedido nunca superaría un valor de 999.999,99 dólares.

Es malo cuando esto ocurre (alta gravedad), pero creo que Amazon no recibe muchos pedidos que superen 1 millón de dólares (baja probabilidad).

Creación de la matriz de directrices de defectos para priorizar bugs

Las dos dimensiones – gravedad y probabilidad – pueden combinarse para establecer la directriz de priorización de un defecto. Una matriz como esta puede ayudar:

Hay muchas formas de clasificar la probabilidad y la gravedad de los bugs. En el ejemplo de la página de comercio electrónico, la probabilidad se expresa con el porcentaje de transacciones afectadas. Todo lo que afecta al 10% o más de las transacciones es bastante importante, así que he establecido toda la columna en prioridad alta o muy alta.

Para medir la gravedad de un defecto, se puede considerar si existe una solución alternativa y si es obvia o difícil de encontrar. En una página de comercio electrónico, por ejemplo, podría haber dos botones “Comprar ahora”, pero solo uno de ellos funciona.

Las celdas de la matriz muestran qué directriz aplica para defectos con una determinada probabilidad y gravedad. En este ejemplo he elegido cinco niveles de prioridad diferentes: de muy baja a muy alta. En algunos casos, tres niveles pueden ser suficientes. No recomiendo más de cinco, aunque también lo he visto.

Así utilizo los cinco niveles de prioridad:

• Muy alta: Se incorpora inmediatamente a la iteración en curso, aunque eso signifique que otros trabajos queden pendientes. Puede requerir más de un miembro del equipo, posiblemente incluso todo el equipo.

• Alta: Se incorpora inmediatamente a la iteración en curso, aunque eso signifique que otros trabajos queden pendientes. El equipo decide quién puede resolver mejor el problema.

• Media: Puede incorporarse a la iteración en curso a criterio del Product Owner.

• Baja: Se documenta y se discute en la siguiente reunión de planificación a criterio del Product Owner.

• Muy baja: Se documenta en la lista de problemas conocidos. Solo se vuelve a tratar si cambia la probabilidad o la gravedad, o a criterio del Product Owner.

Ventajas de la priorización por directrices

La principal ventaja de este enfoque es que se dedica considerablemente menos tiempo a discutir qué hacer con cada defecto individual. Este tipo de priorización de bugs requiere inicialmente algo de esfuerzo para crear las directrices. Pero una vez que estas directrices están creadas, priorizar nuevos defectos se convierte en algo muy sencillo.

El objetivo de este enfoque es que la priorización de defectos se convierta en un asunto más objetivo que subjetivo. Por supuesto, alguien tendrá que decidir con qué frecuencia es probable que ocurra un problema, pero aparte de eso, la priorización en sí no llevará más tiempo que mirar la matriz de priorización.

Este artículo proviene del blog de Mike Cohn y fue traducido al español.

Formación de Product Owner

=> Convértete en Product Owner certificado y visita una de nuestras formaciones

Requisitos no funcionales

=> Descubre cómo convertir requisitos no funcionales en User Stories.

Product Scorecard

=> Descubre si tu producto contribuye a la estrategia empresarial y utiliza la Product Scorecard.