Antes de seguir quiero indicar la terminología que usaré en cuanto a defectos, fallos y errores. En el post "Fallos - Defectos - Errores y su gestión en un contexto ágil" se ofrecen unas definiciones al respecto, que resumen en lo siguiente: los errores son cometidos por las personas participantes en el desarrollo de un producto, estos errores generan defectos que quedan incluidos en el producto (especificaciones o código), estos defectos en algún momento se manifestarán, cuando se detecte el fallo provocado por el defecto, y finalmente, la corrección del fallo es la eliminación del defecto. Los defectos pueden generarse en cualquier actividad (por ejemplo, al especificar requisitos, diseñar, programar, probar, etc.). Es muy difícil conseguir productos con cero defectos, pero es posible evitar en gran medida los defectos si se dispone de los mecanismos preventivos adecuados.
El Retrabajo conlleva la repetición parcial o total de algún trabajo que se suponía estaba finalizado. Pero hay que destacar que las mejoras en requisitos ya implementados y/o el desarrollo incremental NO deberían considerarse Retrabajo. Aunque se trata de trabajo asociado a resultados ya obtenidos de un trabajo previo y finalizado, se están añadiendo aspectos no existentes en los requisitos ya implementados. Lectura recomendada: "Flecos" de implementación y gestión ágil de proyectos.
El Refactoring sí que es una forma de Retrabajo, pero ojo!, también es considerada una buena práctica en el enfoque ágil. Hay que aclarar que el Refactoring "bueno", el planteado por Extreme Programming (XP), implica intentar mejorar de la organización del código continuamente. Cada vez que se va a cambiar alguna pieza de código existe la oportunidad para mejorarlo. Sin embargo, muchos equipos interpretan el Refactoring como concentrarse puntualmente en hacer mejoras de arquitectura del código puntualmente, especialmente cuando una parte del código está teniendo serios problemas de mantenimiento. Para este Refactoring "bueno" no deberían crearse ítems específicos, sino que este trabajo debería abordarse como parte del trabajo de programación de cualquier cambio en el producto. En un enfoque ágil el Refactoring es muy importante ya que este enfoque apuesta radicalmente por el desarrollo incremental, es decir, una misma pieza de código tiene alta probabilidad de ser cambiada una y otra vez durante el desarrollo del producto. El Refactoring continuo contribuye a evitar que la arquitectura del código se degrade con los cambios. Así pues, este Refactoring "bueno" y su Retrabajo asociado deberían ser asumibles en un enfoque ágil, pues favorecen la estrategia global de desarrollo de este enfoque.
Por otra parte, hay trabajos que tienden a considerarse como Refactoring, tales como una mejora del rendimiento de la aplicación o una remodelación de la interfaz de usuario. La definición estándar de Rafactoring es "cambiar el código sin que esto conlleve cambios en los requisitos ya implementados", es decir, es un trabajo cuyo resultado no es visible para el usuario. Según esto, los dos ejemplos anteriores (mejora de rendimiento y remodelación de la interfaz) son cambios constatables por el usuario, con lo cual no deberían considerarse Refactoring.
Volviendo al tema del Retrabajo, ¿cuál es el Retrabajo verdaderamente negativo y qué supervisión deberíamos hacer sobre él?. Existen dos situaciones de Retrabajo que deberían ser vigiladas:
- Fallos detectados en el uso del producto (en una versión ya publicada). Se deben crear ítems para corregir estos fallos, y estos ítems competirán con los otros ítems del Backlog hasta que alcancen la prioridad para ser implementados (un fallo podría no ser severo y tener menos prioridad que otros ítems). Además de la imagen negativa para los usuarios en cuanto a calidad del producto y sus consecuencias, el esfuerzo dedicado a estos ítems de corrección de fallo restará capacidad al equipo para desarrollar mejoras o nuevos requisitos.
- Fallos detectados durante el proceso de desarrollo de una entrega. Cada vez que en el flujo de trabajo se debe volver a realizar a una actividad supuestamente finalizada se incurre en Retrabajo. Por ejemplo, cuando el programador demanda una corrección dirigida a la actividad (previa) de "Especificar Requisitos" porque algún ítem tiene defectos en su especificación, o cuando el tester al probar un cambio en el producto detecta algún fallo en la implementación de dicho cambio y solicita a programador que vuelva a programar para corregirlo. Sin embargo, no debería considerarse Retrabajo que el mismo programador detecte algún fallo en su trabajo mientras lo está realizando ya que esa detección ocurre en el ámbito de su actividad no finalizada (además, sería difícil distinguir en una misma actividad cual parte del esfuerzo se refiere a defectos detectados y corregidos dentro de la misma actividad). Así pues, una forma sencilla de identificar Retrabajo dentro del proceso de desarrollo es observando cuándo en un ítem se vuelve a repetir una actividad ya finalizada. Por ejemplo, si un ítem está en la actividad "Pruebas de Aceptación" y debido a fallos detectados vuelve abrirse la actividad "Programar". De esta forma, podemos decir que el esfuerzo invertido en la actividad "Programar", después de la primera vez que se dio por finalizada, es tiempo de Retrabajo en dicha actividad. Pero nuevamente, hay tener en cuenta una situación en la que este Retrabajo no tendría un sentido negativo, es más, podría ser algo positivo. Supongamos que se está implementando un ítem ítem grande, complejo y/o con mucha incertidumbre asociada a su "qué y cómo", y que se descartaron las alternativas asociadas a particionarlo (convertirlo en ítems más pequeños) o desarrollarlo incrementalmente (desarrollar primero una pequeña parte y mantener el resto del ítem pendiente en el Backlog), es decir, el ítem se va a implementar como un todo, y se decide iterar Análisis-Diseño-Implementación-Pruebas para ir intencionalmente desarrollándolo en refinamientos sucesivos y asumiendo posibles "pasos en falso". En este caso es probable que se realicen dichas actividades con bastante paralelismo y/o vuelta atrás, con lo cual no deberíamos penalizar esta estrategia, puntual para un ítem, por el Retrabajo natural que se registrará.
A continuación ilustraré cómo en nuestra metodología y herramienta TUNE-UP Process ofrecemos información para la supervisión del Retrabajo. Comenzaremos con lo relativo a fallos detectados en el uso del producto.
Capacidad invertida por tipo de ítem (Nuevos requisitos, Mejoras en requisitos ya implementados y Correcciones de fallos). Esta información se muestra por cada Sprint.
En la gráfica anterior cada barra representa el esfuerzo invertido en un Sprint. Los colores corresponden a la proporción del esfuerzo del Sprint invertido en cada tipos de ítem (verde: Nuevos requisitos, amarillo; Mejoras y rojo: correcciones de fallos).
Número de ítems por tipo en cada Sprint. En esta gráfica se representa también como una barra cada Sprint, pero los colores ahora corresponden a la proporción del número de ítems de cada tipo respecto del total de ítems en el Sprint (usando el mismo código de colores de la gráfica anterior).
Para apoyar la interpretación de estas gráficas también es conveniente conocer la duración de cada Sprint (si el equipo y su disponibilidad se mantiene, a mayor duración del Sprint, mayor capacidad de trabajo). La siguiente gráfica muestra la duración de los Sprints asociados a las anteriores gráficas. Como se observa, en este caso los Sprints son "flexibles" en cuando a duración (en general, lo recomendable es mantener cierta regularidad en la duración de los Sprints, pero puede que en un contexto determinado sea más conveniente usar Sprints flexibles. Ver "Sprints, "welcome to the real world" ...").
Algunos otros datos que podrían ser interesantes para un estudio más profundo, especialmente desde una perspectiva de calidad son:
- Distinguir los fallos según su severidad.
- Conocer las áreas del producto en las cuáles se están generando más fallos y retrabajo.
- Poder identificar el ítem previo o el Sprint donde se introduce cada defecto.
- Conocer el tiempo transcurrido desde que se detecta un fallo hasta que se publica una versión donde ese fallo está corregido.
Retrabajo registrado en cada ítem de trabajo. En la siguiente gráfica se muestra el tiempo invertido en la actividad "Programar" para cada uno de los ítems de un Sprint. Además, para cada ítem se destaca en color rojo la proporción de esfuerzo que corresponde a Retrabajo.
¿Cuánto debería ser la proporción admisible de Retrabajo en un ítem?. Dependerá del contexto y también como indiqué antes hay que tener cuidado al evaluar el Retrabajo, pues puede ser intencional, es decir, cuando la estrategia que elegimos para abordar un ítem genera de forma natural cierto Retrabajo. Sin embargo, lo importante de la gráfica anterior y de su interpretación es poder identificar comparativamente que ítems han generado más Retrabajo y estudiarlos para concluir si es justificable o si deben/pueden tomarse medidas preventivas para reducirlo.
Seguimiento de un ítem con indicación de vueltas atrás. Si accedemos a cualquiera de los ítems con Retrabajo podremos ver en su seguimiento (la historia del ítem) información adicional asociada a dicho Retrabajo. Por ejemplo, en la siguiente imagen podemos ver que hay dos vueltas atrás (marcadas con la flecha roja), es decir, se repitieron dichas dos actividades y los tiempos invertidos de esas repeticiones has sido contabilizados como tiempo de Retrabajo.
Finalmente, es muy importante tener presente que la interpretación de esta información y las posibles acciones que se puedan derivar deben tomarse con prudencia. No es recomendable correlacionar penalizaciones/premios para el equipo basándose directamente en estadísticas de Retrabajo o Fallos. Como he señalado existen bastantes situaciones particulares en las cuales el Retrabajo no debería considerarse negativo. Además, los fallos exigen mayor discriminación en cuanto a severidad, tiempo que se requiere para corregirlos, etc. Acciones mal orientadas podrían perjudicar el espíritu de equipo cuando conllevan la culpabilización de las personas involucradas. Por contraparte, y como sabemos, las estadísticas se pueden manipular :-), sería fácil mejorar los datos, por ejemplo, no registrando esfuerzo en las actividades que se están supervisando, registrando esfuerzo de forma que no figure como Retrabajo, clasificando incorrectamente los fallos, o no poniendo la severidad que les corresponde.
Patricio Letelier
No hay comentarios:
Publicar un comentario