Los Siete Desperdicios del Desarrollo de Software

En los procesos productivos industriales existen extensos estudios sobre cómo reconocer y eliminar el desperdicio ya que se entiende que traen aparejados costos que afectan a la rentabilidad de la producción. No obstante, en áreas de servicios como el desarrollo de software, pareciera que los desperdicios son intangibles que somos incapaces de reconocer pero que interfieren con entregarles a nuestros clientes un producto valioso y de calidad, el primer paso será entonces reconocerlo para después tomar acciones tendientes a eliminarlos.

Pero antes de poder reconocer el desperdicio necesitamos definir qué es el valor en mi producto. Valor son todos aquellos momentos y acciones en la creación de un producto que el cliente está dispuesto a pagar. Si tuviera al cliente sentado a mi lado, en qué momento sacaría la billetera para darme dinero por el producto que estoy construyendo, es en ese momento que estamos generando valor. Entonces el desperdicio deben ser todos aquellos momentos y acciones que no generan valor pero consumen recursos y que interfieren con darle al cliente lo que ellos consideran valioso. Un ejemplo de desperdicio son las actividades de testing, en sí mismas no generan valor al producto pero consumen tiempo. El testing no es algo que queremos eliminar, es impensable entregar algún producto que no pase por alguna fase de verificación, es un desperdicio temporalmente necesario. Sin embargo, existen otras actividades que son desperdicios pero que no son necesarias, esas actividades son desperdicio puro y deben eliminarse.

En el desarrollo de software se reconocen siete desperdicios puros:

• Trabajo realizado parcialmente
• Características Extra
• Reaprendizaje
• Entregas
• Intercambio de tareas
• Demoras
• Errores

Trabajo realizado parcialmente

Hasta que el trabajo no es entregado al cliente, no es posible estar completamente seguros de que el producto no tenga problemas de calidad. Cualquier trabajo a medio hacer o que no esté implementado en Producción, es una forma latente de desperdicio que debemos intentar reducir al mínimo. Cuanto antes podamos entregar el producto, más fácil será detectar cualquier falla en la comunicación del requerimiento o cualquier inconveniente en la implementación. También puede darse con funcionalidad que fue solicitada en algún momento y que después se decidió eliminar, dejando código comentado que muchas veces genera otros tipos de desperdicios como Reaprendizaje y Demoras.

Características Extra

Este desperdicio se refiere al exceso de funcionalidades que en realidad no son necesarias para el cliente. Se sabe que, estadísticamente, sólo el 20% de las funcionalidades son usadas con regularidad. Son funciones que alguien solicitó, un analista lo escribió, los desarrolladores lo codificaron, los testers lo verificaron y el cliente lo aprobó para que pase a Producción, sin embargo no son usados con regularidad, pero consumen recursos y se encuentran en el repositorio de código agregando complejidad y haciendo a todo el sistema más difícil de mantener. La única forma de prevención es logrando que el cliente priorice las funcionalidades que necesita al inicio de cada sprint a modo de darle mayor importancia durante el proceso de desarrollo.

Reaprendizaje

El reaprendizaje se refiere a reaprender algo que alguna vez se sabía o re trabajar sobre la misma funcionalidad. Cualquier intento de retomar una parte de código que alguna vez escribimos o que otro compañero escribió o intentar recordar cómo debería funcionar, son actividades que toman tiempo y por lo tanto, generan desperdicio. Generalmente está relacionado a una mala planificación, exceso de bugs, recursos sobrecargados, código no documentado y una mala comunicación.

Entregas

Cada vez que se entrega algo a otro equipo (desarrollador le entrega código a otro desarrollador, desarrollador entrega funcionalidad al tester, etc.), siempre hay alguna pérdida en la transferencia del conocimiento. La única prevención es intentar mantener a todos los equipos con la misma información y que las entregas se realicen de la forma más fluida posible. En esto son especialmente útiles las reuniones de planificación y las reuniones diarias con todo el equipo (daily meetings).

Intercambio de tareas

Se sabe que, ante una interrupción por una llamada telefónica, al cerebro le lleva 15 minutos para poder retomar las tareas que estaba realizando antes del llamado. Pasar de una tarea compleja a otra igual de compleja, implica mayor esfuerzo. Algunos managers consideran que, al asignar a un desarrollador a dos proyectos, el desarrollador va a alcanzar un rendimiento del 100%. No obstante, cada vez que tenga que cambiar la atención de un proyecto a otro, va a sufrir una disminución del 20%, registrando sólo un rendimiento del 80%. Así, a medida que se agreguen más proyectos, el rendimiento se decrementa hasta que pase más tiempo intentando enfocarse en el proyecto que efectivamente codificando. Esto se ve reflejado en el siguiente gráfico, el cual muestra el costo del cambio de contexto, ya con tres proyectos, el 40% del tiempo resulta en desperdicio.

Demoras

Las demoras introducen discontinuidad y generan otros desperdicios como el Reaprendizaje. Una forma de prevenirlo es dejar que las necesidades del cliente dirijan la producción (sistemas pull en vez de sistemas push), pero esto por sí mismo no es suficiente. Realizando un gráfico de flujo de valor es posible detectar las demoras que se producen durante el proceso de desarrollo, es un ejercicio sumamente útil y que abre la oportunidad de detectar mejoras, algunas de las demoras más comunes son: esperas por aprobación de cambios, esperas por listas priorizadas, espera por recursos, esperas para obtener el sign-off.

Errores

Todo error es un desperdicio que puede disparar otros como Reaprendizaje y Demoras. El objetivo debe ser realizar software libre de bugs o acercarse lo más posible. Si se detectan bugs, los mismos deben encontrarse lo más pronto posible, un bug en Producción es más costoso y con mayor visibilidad que un bug encontrado en un ambiente de Testing. Algunas acciones que se pueden tomar para prevenirlos son: hacer pruebas de unidad y de integración, programación por pares y revisión de código, Staging lo más parecido a Producción, realizar entregas rápidas, documentar el código.