El Retrabajo Como Desperdicio

Introducción

Qué se entiende por retrabajo?

Se considera retrabajo al trabajo que se hace a causa de no haber realizado el “trabajo” correctamente la primera ve, también se considera retrabajo los cambios continuos que se hacen y el trabajo duplicado entre personas. La causa más frecuente de retrabajo es la necesidad de hacer correcciones para resolver defectos o no cumplimientos de los estándares establecidos. Las métricas de retrabajo puede ayudar al equipo de SQA a demostrar la conveniencia de mejores planes de proyectos teniendo más cuidado y prestando mayor atención a los requerimientos.

Costo de calidad. (COQ)

SQS: Software Quality System, indice que mide la calidad del sistema.

COA: Cost of Quality, costo de recursos asignados para prevenir errores y alcanzar la calidad.

Incluye ítems como entrenamiento, implantación de metodologías, de herramientas automáticas, planificación , desarrollo de estándares entre otros. Estos son los costos en los que se incurre por reducir la probabilidad de que un error se haga por primera vez.

COF: Cost of Failure, Costo de recursos utilizados por que la calidad no fue alcanzada (este es el retrabajo)

 COQ = COA + COF

La estimación de costos se da como resultado de las revisiones y testeos, son los costos en los que incurrimos por mirar errores una vez que el producto ha sido producido.

Se incurren en costos de fallas cuando un producto manifiesta un error. Es importante reconocer que la primera vez que se hace una revisión de un producto, o el primer test que se le hace a una pieza de código cuanta como una estimación de costos.

Cualquier otra revisión o re testeo que se necesite por los defectos que fueron encontrados y corregidos son parte del COF. Este es un costo en el cual no se quiere caer una vez que la tarea se hizo correctamente la primera vez.

En la mayoría de las empresas 3/4 del costo del COQ es invertido en el COF este indicador incluye el retrabajo.

Porque minimizar el retrabajo ?

“Los proyectos de software gastan entre el 40 y 50% de su esfuerzo en retrabajo que podría haberse evitado...” Frase extraída del articulo “Software Defect Reduction top 10 list “ de Boehm y Basili.

Para estos autores el retrabajo consiste en “gastar” esfuerzo en arreglar problemas que podrían haberse detectado previamente haciendo que el “arreglo” del mismo sea menos costoso, o directamente se podrían haber evitado. Reducir el retrabajo evitable traerá una mejora significativa en la productividad del desarrollo de software. Según estos autores la reducción del costo de retrabajo se logra teniendo un proceso de desarrollo maduro, una mejora en las arquitecturas del software y gestión de riesgos

“80% del retrabajo evitable viene del 20% de defectos....”

Este 80% puede ser un valor alto o bajo dependiendo del tamaño del sistema que se esta desarrollando. Uno de los puntos que llevan a este problema es hacer especificaciones de requerimientos a las corridas y un diseño no muy claro hace que la arquitectura no sea bien definida lo que traerá problemas al momento de la codificación.

El tener un sistema que permita hacer el seguimiento de los defectos y los arreglos que se llevan hechos ayudan a hacer un análisis de los problemas y saber el costo del esfuerzo que se ha incurrido en retrabajo.

Actividades de SQA y SCM

Como ya se definió al principio el esfuerzo de retrabajo tiene tres perspectivas:

• Tareas que se ejecutaron incorrectamente

• Tareas nuevas por cambios continuos de un proyecto

• Tareas duplicadas por mala gestión de los documentos/productos compartidos

Vamos ahora a vincular estas visiones del retrabajo con los roles de SQA y SCM en un proyecto de software, los cuales son directamente responsables de minimizar el esfuerzo en retrabajo. A continuación se describirán solo algunas actividades de estas dos disciplinas, mas adelante en este documento se ampliará sobre los factores y las medidas generales a tomar en proyectos de ingeniería de software.

Actividades del SCM: Definición y Seguimiento de la Línea Base + Control de Cambios

El cambio es inevitable cuando se construye software. Los procesos de desarrollo intentan ser cada vez más rápidos. Procesos lentos impactan produciendo perdida de oportunidades de negocio, los mercados cambian, las demandas de los clientes cambian y la competencia cambia rápidamente. Es fundamental la gestión de estos cambios para que se den en forma ordenada y consistente. Una responsabilidad del SCM es administrar un protocolo de aprobación y reporte de cambios a los interesados. Dado un alcance negociado y validado pueden surgir tareas de retrabajo por modificaciones (en requerimientos, diseño,...) durante la implementación. Además, si se introducen defectos al producto por no haber evaluado el impacto de un cambio también estaremos incurriendo en “retrabajo” por corrección de errores.

La Gestión de Configuración permite, entre otras cosas, identificar claramente las versiones “activas” de un producto. Es una práctica común mantener el entorno de desarrollo de la versión actual, mientras se trabaja en una nueva versión. Esto permite planes de contingencia ante eventuales fallas de la versión en uso, corrigiendo el error (parches) y comunicándolo al grupo de desarrollo de la nueva (futura) versión. No prever esta situación es un factor importante de retrabajo que exigiría un gran esfuerzo para el equipo de desarrollo.

En un proyecto de software muchas personas interactúan con elementos comunes, compartidos o muy relacionados. Podemos interpretar que el “retrabajo” es el polo opuesto al “reuso” y en tal sentido si la línea base de un proyecto esta bien definida esto nos da la pauta para poder construir, avanzar sobre esos cimientos, las nuevas funcionalidades de un sistema. Por el contrario, si la línea base es difusa puede ocurrir que algunos integrantes del equipo trabajen sobre diferentes versiones de los documentos o prototipos, siendo esta la tercer perspectiva de desperdicio de recursos en retrabajo.

Actividad

...