Los Bugs en Scrum

¿Cómo se priorizan los Bugs en el product backlog? ¿El Product Owner debe hacerlo? ¿Interesa discriminarlos de los Requerimientos? ¿Cómo se estima el esfuerzo de corregirlos? ¿Es un Bug o una Mejora?

Si alguna vez te encontraste envuelto en una discusión similar en un Equipo ágil, no dejes de leer este artículo.

Advertencia:

Se trata de un artículo algo extenso, ya que intento cubrir todos los aspectos importantes. Se divide en las siguiente partes:

1) Definición: ¿Qué es y que no es un Bug?
2) Cómo se priorizan
3) Los costos escondidos
4) La estimación de esfuerzo
5) Cómo se gestiona la calidad en Scrum
6) Etimología de la palabra
7) Lectura Recomendada

¿Es un Bug?

Hablamos de un Bug cuando nos referimos a un comportamiento del software que cumple con tres características básicas: es defectuoso, es indeseado y es inesperado.

Pero… ¿inesperado por quién? Inesperado para el Product Owner que solicitó la funcionalidad (O cliente en su defecto), para el Analista que escribió la especificación del requerimiento, para quien diseño la solución o para el Desarrollador que la programó. Como veremos más adelante, no siempre para el usuario final.

¿Y para el Tester que se encontró con el comportamiento inesperado? Para el Tester también, pero ojo, el Tester encontrará muchos puntos donde la experiencia de usuario podría y/o debería ser mejor. Pero no todos los casos serán Bugs. El Tester deberá contar con un criterio muy refinado, conocer bien el sistema, los requerimientos, las reglas de negocio, el nivel de calidad acordado y validar con el Product Owner en caso de dudas. El nivel de calidad debe estar acordado entre el Product Owner y el Equipo. (Ver caso 4 más adelante).

Es un Bug, aunque la funcionalidad haya sido programada tal como se especificó en el requerimiento. No importa de quien es la «culpa», puede ser un error de codificación, un error de diseño de la solución, una inconsistencia en la especificación de requerimientos. Sigue siendo un Bug.

¿Cuando NO es un Bug?

No toda mala experiencia de usuario representa un Bug en el sistema. Veamos los casos más relevantes:

Caso 1: Incidentes. El sistema no funciona como corresponde por condiciones externas al software. Se cayó un servidor o se saturó su capacidad, un ataque de DoS de un hacker, un Servicio externo requerido que no está disponible, etc. En este caso hablamos de Incidentes.

Caso 2: Carencia de funcionalidades básicas que todavía no se implementaron. Cuando es intencional, por lo tanto no es inesperado. Ej. Puedo registrarme, pero no encuentro cómo recuperar la contraseña o editar mis datos personales.

Caso 3: Regla de negocio que perjudica el usuario. Ejemplo: El sistema no permite efectuar una transferencia bancaria luego del horario normal de operación del banco. El sistema no permite al usuario copiar, extraer, descargar o compartir la información. Este es el caso decimos que es una funcionalidad. Una regla de negocio diseñada para el beneficio de otro que no es el usuario final. El usuario se puede ver frustrado y quejarse, pero no será tratará de un Bug.

Caso 4: Mejora. Cuando el sistema funciona, pero podría ofrecer una mejor experiencia de usuario, ser más amigable, más lindo, más cómodo, con accesible. Aquí la distinción no es objetiva. Dependerá del nivel de calidad acordado en el Equipo para el sistema y de los criterios de aceptación. Cuando no hay un acuerdo formal, habrá que discutir cada caso particular, teniendo en cuenta la subjetividad de cada una de los involucrados.

Caso 5: Estándar de Calidad. Cuando el Bug es tan pequeño e insignificante que invertir tiempo en solucionarlo sería pecar de perfeccionistas. Este punto, al lugar que el anterior también es subjetivo y debe ser un acuerdo del Equipo entender cual es el nivel de calidad esperado.

La Priorización de Bugs

La importancia es discriminarlos radica en darles el tratamiento adecuado. Los Bugs no se gestionan como los requerimientos: tienen un ciclo de vida distinto, la estimación de esfuerzo es distinta, los datos requeridos son distintos. Pero lo más importante aquí son los criterios a emplear para la priorización y planificación.

Entendemos por priorización a la decisión de qué hacer primero: ¿Resolver un Bug o desarrollar una funcionalidad nueva?

Cuando compiten con los nuevos requerimientos en el Backlog, empleando el mismo criterio de priorización, pueden perder prioridad y comenzar a acumularse. Sobretodo cuando hay mucha presión puesta sobre el Equipo de desarrollo para entregar funcionalidad cuanto antes.

Tanto Product Owners como desarrolladores pueden verse tentados a no solucionar Bugs pendientes. Existen varios motivos por lo que esto puede ocurrir:

• Los Bugs en el backlog de alguna manera molestan, son indeseados y puede resultar incómodo hablar de ellos. Por ejemplo, hacer transparente que una funcionalidad no va ser desarrollada porque en su lugar vamos a estar arreglando Bugs detectados.
• La presión del mercado por reportar nuevas funcionalidades productivas, antes que la competencia, tiende a reducir el estándar de calidad.
• El Product Owner puede desentenderse de los Bugs asumiendo que es un problema del Equipo de desarrollo y no querer invertir tiempo en analizarlos y priorizarlos.
• Para los desarrolladores solucionar Bugs no es tan motivante o interesante como desarrollar nuevas funcionalidades.
• La satisfacción de tener nuevas funcionalidades siempre es mayor que solucionar Bugs.

Un Bug se puede interpretar como un requerimiento con valor de negocio negativo. 

Mientras que un requerimiento agrega valor de negocio o Satisfacción al usuario; un Bug lo resta. Por este motivo, no corresponde emplear el mismo criterio de priorización.

Los requerimientos se priorizan teniendo en cuenta dos variables: Beneficio o Valor de Negocio por un lado y el esfuerzo o costo de implementación. La relación entre ambos nos da el Retorno de la Inversión.

Esta priorización no funciona para los Bugs porque no aportan valor de negocio y tampoco se estima el esfuerzo (veremos por qué más adelante).

Los Bugs se priorizan teniendo el cuenta el Costo de NO solucionarlos. En inglés este criterio de priorización se conoce como Cost of Delay.

Ahora bien, el desafío radica en que los Bugs tienen «costos» escondidos que son difíciles de «ver» para tenerlos en cuenta y ponderarlos apropiadamente.

Te propongo que antes de seguir leyendo este artículo, armes una lista con todas las consecuencias y costos que la organización sufre por tener Bugs sin resolver.

Ahora comparalos con lista a continuación, ¿Estabas considerando todos estos costos? Seguramente también hayas encontrado algunos que no figuran en esta lista. Te invito a aportar dejando tu comentario abajo.

Factores que hacen al Costo de tener Bugs en el Sistema sin resolver

1) Impedir al usuario completar la operación. Todo el desarrollo de la misma es en vano si el usuario no puede completarlo. El usuario se sentirá frustrado y sentirá que le hacen perder el tiempo.

2) Experiencia de usuario negativa. Reduce su nivel de satisfacción con nuestro producto o servicio. Lo contrario de lo que cualquier Organización está buscando cuando diseña un producto.

3) El usuario podría no volver a elegir nuestro producto la próxima vez. En el caso de servicios y aplicaciones pagas, implica anular suscripción, devolución de dinero, etc. Tener usuarios registrados inactivos también es un costo adicional.

4) Reputación e imagen negativa de la organización. El usuario no solamente no vuelve a usar el producto sino que estará menos dispuesto a probar cualquier otro producto de la organización. Se pierde la confianza del usuario.

5) Recomendaciones. Bajo nivel de Net Promoter Score (NPS). Los usuarios sólo recomiendan a los amigos los productos con los que se sienten satisfechos. Con los que tienen buena experiencia de usuario.

6) Calificaciones en el Market Place. El usuario deja bajas calificaciones y comentarios negativos en el App Store, Play Store, etc. Provocando que otros usuarios No descarguen. Las calificaciones y comentarios negativos no pueden ser eliminados.

7) Perder la posibilidad de ser figurar entre los productos Destacados y Promocionados y en el Ranking Top 10. Los Market Place destacan las aplicaciones con buenas calificaciones. Esto es publicidad gratuita, reconocimiento, motivación para los empleados, más tráfico y descargas y reputación para la Organización. Todo esto se pierde por un producto con malas calificaciones que los usuarios dejan cuando se sienten frustrados con una producto con Bugs.

8) Costos de personal de atención al cliente. Los defectos en el sistema incrementan los reclamos de los usuarios, la necesidad de soporte técnico. Los costos de servicio de atención al usuario se incrementan.

9) En ciertos rubros, un Bug podría implicar daños y perjuicios al usuario que demanden resarcimiento (por ejemplo, los sistemas que involucran manejo de dinero o en la privacidad de información sensible).

10) Dentro del sistema, buscamos que los usuarios cumplan un determinado objetivo: que compren, que realicen un pago, que conecten con otros usuarios para potenciar la red de contactos, etc. Un Bug puede demorar este proceso hasta que el servicio de atención al usuario resuelva el caso. Demorando ingresos para la Organización. Las demoras uno de los 7 tipos de Desperdicios identificados por Lean Software Development.

11) Desperdicio del dinero invertido en Marketing. El dinero invertido en publicidad y estrategias para atraer a los usuarios a probar el producto se ve desperdiciado cuando el usuario, luego de probar el producto decide no regresar.

12) Métricas Erróneas. Las empresas de tecnología se apoyan mucho en métricas de todo tipo que explican como los usuarios utilizan el sistema. Los Bugs pueden también interferir en los datos y llevar a tomar decisiones incorrectas.

13) Un defecto puede significar una vulnerabilidad de seguridad del sistema. En ocasiones los errores que no son debidamente controlados revelan información sensible acerca del estado interno del sistema, esa información podría ser usada por usuarios mal intencionados para vulnerar la seguridad y causar daños mayores.

14) Los desarrolladores tienen que lidiar con los Bugs existentes para desarrollar nuevas funcionalidades. De la misma manera, se dificulta el refactoring, creando una barrera para que el código evolucione. Como consecuencia, el desarrollo se hace cada más lento y tedioso. Se incrementa la Deuda Técnica. 

15) Los logs o registros de errores del sistema se «ensucian» con datos de Bugs conocidos, haciéndose difícil detectar la presencia de nuevos errores.

16) El testing de nuevas funcionalidades también es más lento y tedioso con la presencia de Bugs pre-existentes. El tester debe lidiar también con ellos y tenerlos en cuenta cuando se prueban nuevas funcionalidades. Algunas funcionalidades no podrán ser verificadas. El Tester deberá discernir si un comportamiento incorrecto se debe a un Bug conocido o la nueva funcionalidad. Lo cierto es que genera confusión y ante un apuro es más fácil culpar a un Bug pre-existente.

17) Cuando hay Bugs conocidos que no se resuelven, los tests automáticos generan alertas que son desestimadas porque son atribuidas a dichos Bugs. Los tests que fallan terminan siendo desactivados reduciendo la cobertura de test.

18) Una porción de código defectuoso es como un ladrillo roto: es más fácil cambiarlo cuando todavía está fresco el cemento que después de que se hayan edificado otros ladrillos arriba. Si los Bugs no se solucionan en el momento y tienen baja prioridad, el día que se decida solucionarlo el costo será mayor. Este costo está asociado como el desperdicio de Re-aprendizaje de Lean Software Development. Si la persona que lo resolverá es otra persona distinta del que desarrollo la funcionalidad, también el costo es mayor.

La Teoría de las Ventanas Rotas describe justamente este patrón de comportamiento, recomendando siempre arreglar los problemas cuando todavía son pequeños. Cuando no hay Bugs, un sólo atrae la atención de todos. Cuando el sistema está lleno de defectos. ¿Qué le hace una mancha más al tigre?

¿Hay más motivos a considerar? Te invito a dejar comentarios al respecto.

Métricas Honestas. Por qué los Bugs no llevan estimación de esfuerzo.

Una funcionalidad «Completada» significa que no tiene Bugs pendientes. Si el desarrollo produce Bugs y los estos tienen una estimación aparte, se genera una métrica de Velocity engañosa que los esconde y no permite planificar.

Veamos un ejemplo para comprenderlo mejor: Un equipo tiene una Velocity de 30 puntos por Sprint y planifican los requerimientos Story A, B, C y D según el siguiente cuadro.

La User Story «A» fue desarrollada en una semana, pero se encontró un Bug. El equipo debe seguir trabajando en la misma unos días más. Como resultado, no alcanzó el tiempo para completar la User Story «D». Quedará para el próximo Sprint.

Veamos qué ocurre en la planificación cuando los Bugs no llevan estimación (Caso Correcto) y cuando sí llevan estimación (Caso Incorrecto)

En el caso correcto, no completar la Story D, implica Sprint Velocity menor a la esperada (25 vs 28). Además, la Velocity promedio del equipo se ve un poco reducida para ajustarse más a la realidad.

En el caso incorrecto, se estima y se asigna 3 puntos al Bug detectado. Al finalizar el Sprint, la Velocity del Sprint refleja lo planificado, pero la User Story «D» no está hecha! La Velocity sigue siendo 28, cuando el equipo en realidad no es capaz de completar un Sprint planificado de 28 puntos.

Ahora bien…

Qué sucede si el Bug no fue corregido dentro del mismo Sprint. Ya sea por priorización, porque se encontró a posteriori del Sprint y se agregó al Backlog. ¿Le asignarías Story Points? Por supuesto que NO. El criterio es el mismo.

Si la Story «A» se consideró como terminada y se imputaron los 13 puntos a la Velocity, cuando en realidad tiene un bug pendiente, se está acumulando Deuda Técnica. La deuda técnica debe ser pagada, para lo cual se debe arreglar el Bug sin imputar puntos a la Velocity del Sprint por el esfuerzo invertido en solucionarlo. Incluso, si el Bug es antiguo (Legacy).

Veamos como queda en el ejemplo, la planificación del segundo Sprint. Notemos que la Velocity en el caso incorrecto es mayor, pero no es realista. ¿Podría contar el Product Owner con esa velocity para planificar nuevas funcionalidades en el Sprint 3?

 

Scrum (y las metodologías ágiles en general) valoran y promueven la calidad. La tolerancia a Bugs debe ser muy baja en un ambiente de desarrollo ágil. Los Bugs producidos por el desarrollo de una funcionalidad deben ser resueltos dentro del mismo Sprint o en el próximo momento posible.

Los Bugs tienen prioridad por sobre el desarrollo de nuevas funcionalidades, debido a que resolver un Bug no es un trabajo aparte que deba ser planificado, sino que es una tarea más del trabajo de desarrollo. Es como barrer el aserrín luego de haber estado cortando madera.

Una funcionalidad que se desarrolló y tiene Bugs, no se considera «Terminada» hasta que todos los Bugs sean solucionados, y a su vez, un trabajo que está comenzado y cerca de terminarse siempre mayor prioridad que otro requerimiento que aún no se comenzó.

En Scrum, el objetivo está puesto en prevenir que los Bugs. Esto se logra con atención a la calidad, adoptando las conocidas buenas prácticas de desarrollo, buenas prácticas de diseño, apropiada comunicación y colaboración entre todos los roles involucrados. La adopción de los principios ágiles soportan la Calidad, por ejemplo el principio de simplicidad:

«El código que nunca fue escrito no tiene Bugs y no requiere mantenimiento»

Por último, la Mejora Continua y el aprendizaje. Ante un nuevo Bug, ¿Te preguntás por qué se produjo y cómo se puede evitar que vuelva a ocurrir un Bug similar?

Para finalizar, un poco de etimología del término «Bug»

Lectura recomendada:

• That’s Not a Bug, It’s a Feature Request (CodingHorror.com)
• It’s Not a Bug, It’s a Feature (AgileManiac.com)
• The Bug Myth (Business Craftsmaship)
• The Broken Window Theory (CodingHorror.com)
• One way to handle Bugs and Production Support in Scrum (Scrumcrazy.com)

Damián Buonamico

[mc4wp_form id=»228″]