domingo, 26 de febrero de 2012

Fallos - Defectos - Errores y su gestión en un contexto ágil

La gestión de fallos del software en el contexto de un proceso de desarrollo ágil no ha sido un tema muy tratado, al menos hasta donde llega mi conocimiento. En este post describo cómo lo hemos abordado en la práctica, en el marco de Tune-up.

En una iteración de desarrollo del producto, además de nuevos requisitos o mejoras en los requisitos ya implementados, es normal (aunque no deseado) incluir también cambios que se refieren a la corrección de fallos. Incluso, si el fallo es muy severo puede obligar al equipo de desarrollo a generar de inmediato una nueva versión del producto (actualización/revisión o como se le llame). Aquellos fallos que no son severos pueden ser planificados para ser resueltos, es decir, pueden ser introducidos en el Product Backlog en espera de ser incluidos en una iteración.

Si bien no existe un consenso absoluto en cuanto a la terminología asociada, para nuestros proyectos y en nuestra herramienta usamos las siguientes definiciones:
  • Fallo es el comportamiento no deseado del producto, visible desde el punto de vista externo del producto. Por ejemplo, se presenta un fallo cuando el usuario intenta realizar una acción y aparece un mensaje de excepción no manejada. 
  • Defecto es la imperfección que causa el fallo. El defecto puede ser visible o no en el exterior del producto, es decir, puede tratarse de una anomalía interna del producto. Un defecto puede existir en el producto y no manifestarse como fallo. Por ejemplo, es un defecto tener una variable no inicializada, lo cual puede causar un fallo.
  • Error es lo que causó la introducción del defecto en el producto. El error siempre es cometido directamente o indirectamente por una acción o no acción humana. Por ejemplo, es un error no realizar la inicialización de una variable en el mismo instante de su declaración.
Así, existe una relación de causalidad Error > Defecto > Fallo. Lo que puede resultar un tanto extraño es que podemos decir Detectar un Error, Detectar un Defecto o Detectar un Fallo. La detección de fallos es de esperar que la realice el equipo de desarrollo, es decir, que los fallos no lleguen a una versión en producción. Los defectos están principalmente en el código, sin embargo, también puede tratarse de defectos en la especificación del cambio del producto. La detección del error debería motivar el establecimiento de alguna acción preventiva que evite la repetición de dicho fallo, lo cual usualmente se enmarcaría en la mejora continua del proceso. En las reuniones de retrospectiva o iniciativas similares para mejora del proceso los Errores-Defectos-Fallos deberían ser uno de los temas protagonistas para ser tratados.

Otro concepto interesante asociado a Fallos es el de Workaround, es decir, una solución transitoria para el usuario mientras no disponga de una nueva versión del producto en la cual el fallo esté corregido. Para el personal del Service Desk y para el servicio que ellos ofrecen, es importante conocer los fallos existentes en  el producto, si tienen un workaround  y si están siendo corregidos para una próxima versión. Es importante tener una fluida comunicación entre el equipo de desarrollo y el de Service Desk en cuanto a los fallos. Normalmente el mismo fallo puede ser reportado por diferentes usuarios, es decir, muchos tickets de soporte a usuarios pueden estar relacionados con el mismo fallo. Sin embargo, desde la perspectiva de desarrollo, el cambio para realizar en el producto (en este caso la corrección del fallo) es sólo un ítem de trabajo.

Por otra parte, si bien un fallo es un tipo de cambio en el producto que no suele requerir una especial preparación en cuanto a análisis y estimación, es recomendable que siga un proceso similar (o igual) al de otros tipos de cambios en el producto, asegurando el estudio del impacto de lo que será su corrección y garantizando su correcta solución mediante pruebas.

Para explotar posteriormente la información de fallos es interesante que un fallo se complemente, por ejemplo, con datos tales como, si la detección fue realizada por el cliente o por el equipo de desarrollo, y en esté último caso en qué actividad se detecto.

Finalmente, un atributo imprescindible para apoyar la toma de decisiones respecto de fallos es conocer su Severidad. Reuniendo información extraída desde el contexto de ITIL, de proceso de desarrollo de software y diversas otras fuentes, hemos llegado al establecimiento y utilización de un conjunto de indicadores que ayudan a determinar nuestro nivel de severidad de un fallo.

Severidad del Fallo
Indicadores (puede que NO se presenten todos a la vez)
Crítico
Nivel de detección del fallo por el usuario: Muy Alto
Frecuencia con la que se presenta: Muy Alta
Número de clientes/usuarios afectados: Muy Alto
Requiere soporte en línea: SI
Pérdida de funcionalidad esencial: SI
Pérdida de datos: SI
Problema de seguridad: SI
El fallo tiene workaround aceptable para el usuario: NO
Severo/Importante
Nivel de detección del fallo por el usuario: Alto
Frecuencia con la que se presenta: Alta
Número de clientes/usuarios afectados: Alto
Requiere soporte en línea: Posiblemente SI
Pérdida de funcionalidad: NO
Pérdida de datos: NO
Problema de seguridad: NO
El fallo tiene workaround aceptable para el usuario: SI
Moderado
Nivel de detección del fallo por el usuario: Medio
Frecuencia con la que se presenta: Media
Número de clientes/usuarios afectados: Pocos
Requiere soporte en línea: Posiblemente NO
Pérdida de funcionalidad: NO
Pérdida de datos: NO
Problema de seguridad: NO
El fallo tiene workaround aceptable para el usuario: ---
Leve
Nivel de detección del fallo por el usuario: Bajo
Frecuencia con la que se presenta: Baja
Número de clientes/usuarios afectados: Muy Pocos
Requiere soporte en línea: NO
Pérdida de funcionalidad: NO
Pérdida de datos: NO
Problema de seguridad: NO
El fallo tiene workaround aceptable para el usuario: ---

La gestión de la información comentada antes no tiene por qué implicar un alejamiento del los principios ágiles en cuanto a documentación, pues en la práctica sólo implica que para cada ítem de tipo corrección de fallo en desarrollo debe establecerse su Severidad (para decidir cuándo debe corregirse), indicarse el defecto que lo produjo (y posiblemente el error que hizo posible la introducción del defecto) y registrarse en soporte el workaround que se le hubiese ofrecido al usuario (si había alguno). En el contexto de mejora continua del proceso se explotaría toda esta información.



Patricio Letelier




No hay comentarios:

Publicar un comentario