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.
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
