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.

1. ___________
2. ___________
3. ___________
4. ___________
.

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.

19) La motivación de los desarrolladores disminuye cuando deben trabajar con un producto con errores. Peor aún, la motivación del Tester disminuye, porque los Bugs que reporta no se solucionan, entonces ¿Para qué seguir poniendo empeño a encontrar y reportarlos?

20) El Orgullo y motivación de todas las personas detrás del producto decae. No es lo mismo lo que se siente trabajar desarrollar un producto de alta calidad y reputación que para un producto con bajas calificaciones.

21) Se dificulta la planificación a largo plazo (Roadmap) del producto. El Backlog de producto es más difícil de gestionar y menos claro de entender cuando los nuevos requerimientos se encuentran mezclados con Bugs. Para el Product Owner es más trabajoso invertir tiempo en entender los Bugs reportados y priorizarlos.

22) Se forja una cultura organizacional de tolerancia a la mala calidad y donde producir con defectos es aceptado por todos. Es moneda corriente escuchar en las conversaciones que hay un Bug interfiriendo y nadie se alerta demasiado.

Como corolario, podemos inferir que la decisión sistemática de No resolver los Bugs inmediatamente genera un efecto de Bola de Nieve. Se comienzan a acumular a una tasa cada vez mayor. Comiendose la motivación y la productividad hasta que el sistema no podrá responder más a cambios y deberá rehacerse por completo.

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.

Las métricas de esfuerzo en Scrum con Puntos (Story Points) ayudan al equipo a entender cuanta funcionalidad pueden completar en una iteración. En base a una Velocity promedio del Equipo el Product Owner puede planificar varios Sprints y armar un Roadmap de Producto.

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?





Otros Motivos que desalientan estimar el esfuerzo (incluso en estimación con Horas)

1. Motivo de Estimar. Los requerimientos llevan estimación de esfuerzo para planificación y priorización. Sin embargo, en el caso de los Bugs ya hemos visto que esto es distinto.

2. Incertidumbre. En muchos casos, no sabemos por qué ocurre el Bug, con lo cual estimar el esfuerzo requerido para solucionarlo es difícil y tiene un margen de confiabilidad demasiado bajo. 

3. Los Bugs, por su naturaleza tienen un mayor esfuerzo en análisis e investigación para encontrar el origen del error y muchas veces el esfuerzo de solucionarlo puede ser tan pequeño como agregar un punto y coma.

4. Costo y más costo. La existencia de un bug en el sistema representa un costo hundido. Es uno de los desperdicios identificados en Lean Software Development. Emplear tiempo extra en obtener una estimación de esfuerzo para arreglar un Bug implica incrementar el costo el mismo.

Priorización Ágil ¿Cómo se gestionan los bugs en Scrum?

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"


Si todavía estas conmigo, te felicito! este fue uno de los artículos más extensos que escribí. Para terminar voy a hablar un poco del término Bug utilizado como defectos de Software.

La traducción del inglés es "insecto". Irónicamente muy lejos de los defectos, los insectos son tan perfectos como toda obra de la naturaleza... 

También es curioso notar que utilizado como verbo, "bug" se traduce como "molestar". Tanto los insectos como los defectos en el software tienen la capacidad de "molestar" a usuarios y desarrolladores. Muchos insectos tienen una gran capacidad para esconderse, así como los Bugs se esconden en el Software y tienen costos escondidos.

Otra forma de verlo, tener un "Bug" es estar enfermo. Nuestro sistema también está "enfermo" si tiene defectos o bugs.

Pero lo cierto, es que el primer uso del término se remonta a 1946, cuando ingenieros de Harvard encontraron que una polilla atrapada en la Computadora era el origen del mal funcionamiento de la misma. Adosaron la polilla a la planilla de registro. Ese fue el primero registro formal que se conoce del uso de Bug para referirse a los defectos de software.






Lectura recomendada:

Si te resulta interesante el tema te recomiendo leer los siguientes artículos (En inglés)

Twitter: @dbuo
LinkedIn: http://www.linkedin.com/in/buonamico


Entradas populares de este blog

Visual User Story Mapping Aplicado

Historia de las Metodologías Ágiles en Contexto