desperdicios LEAN del software

Los 7 desperdicios del desarrollo de software (y II)


Este post es la continuación al post anterior Los 7 desperdicios del desarrollo de software donde describía los primeros 3 desperdicios del desarrollo de sofware, trabajo hecho a medias, funcionalidades extra y reaprendizaje. A continuación enumero los otros 4 desperdicios:

Desperdicio #4 – Transferencias de conocimiento

Cuando se produce una comunicación mediante un canal siempre hay parte de la información que se pierde o se omite, cuantas más comunicaciones sean necesarias para la realización de una tarea más pérdidas de información y más ineficiencias se producirán. Inconscientemente cada agente emisor omitirá una gran parte de información tácita que sobre todo para los últimos receptores de la información echarán en falta.

El proceso de desarrollo tradicional secuencial tiene muchas de estas transferencias: El product manager recoge los requerimientos del cliente, éste se lo pasa al analista funcional, que a su vez pasa al arquitecto técnico, éste al programador, después al tester, etc…

Tenemos 2 estrategias básicas para combatir este desperdicio:

  • Reducir el número de transferencias, esto es eliminar el máximo de intermediarios posible. Una estrategia alternativa puede ser documentar debidamente ese conocimiento.
  • Favorecer los canales con más ancho de banda, por este orden el cara a cara, teléfono, chat de voz, mail de voz, mensajería instantánea, mail y por último documentos. Aquí también indirectamente se está buscando un feedback rápido.

Desperdicio #5 – Retrasos

Los más importantes son las dependencias con gente de fuera del equipo en las distintas fases del proyecto: la toma de requerimientos, desarrollo (validación de la arquitectura), testing (el equipo de QA), sistemas, UAT, etc… Por cierto lo peor que puedes hacer es intentar rellenar los huecos con nuevas tareas, recordad la teoría del WIP de Kanban, incrementar el número de tareas en un proceso ya saturado de esperas es como intentar arreglar los atascos de una calle muy transitada y con muchos semáforos metiendo más coches.

Otro motivo frecuente de retrasos son los huecos entre el fin de un proyecto y el inicio del siguiente proyecto para un equipo. De la misma forma, debemos centrar los esfuerzos en minimizar los huecos en lugar de intentar rellenarlos.

Los retrasos normalmente llevarán otros desperdicios asociados, como por ejemplo el contínuo cambio de contexto, el trabajo parcial, el reaprendizaje, y la funcionalidad extra (consecuencia de aumentar el ciclo de feedback).

Desperdicio #6 – Cambios de contexto

Cuando tenemos varias cosas que se deben hacer de forma inmediata, tendemos a intentar hacer varias cosas a la vez. Como nuestra mente no es multitarea, lo que hacemos es continuamente hacer cambios de contexto y por tanto añadir el overhead por un continuo reaprendizaje. Además se produce algo curioso, cuando estamos con varias tareas a la vez como el cambio a la más costosa e importante cuesta más normalmente, lo dejamos inconscientemente para el final y acabamos haciendo primero lo más irrelevante (Procrastinación).

En el caso concreto del desarrollador de software lo vemos constantemente, cambios entre proyectos, cambios entre tareas, y las más importantes y quizás las que pasan más desapercibidas interrupciones constantes mientras se está trabajando concentrado (ver Ladrones del Tiempo).

Desperdicio #7 – Defectos

Podemos decir que el coste total de este desperdicio es la multiplicación del impacto que tiene el defecto en el producto por el tiempo que está sin detectarse. Por ejemplo un bug en un sistema de contabilidad que descuadra unos decimales algunos importes si se detecta en el entorno de desarrollo y se corrige inmediatamente no tiene casi impacto, mientras que si está en producción durante 3 meses es posible que se pierda mucho dinero.

Puesto que ningún desarrollador decide conscientemente introducir bugs de mayor o menor impacto en un sistema (en todo caso puede decidir omitirlos) en lo que nos centraremos es en minimizar el tiempo de exposición de estos fallos.

Los métodos más efectivos a la hora de minimizar el tiempo de vida de los defectos son:

  • Test de regresión automatizados (unitarios, de integración y de aceptación)
  • Tests exploratorios constantes
  • Cuando se detecte un bug, en lugar de arreglarlo directamente, primero se crea un test que falle ante ese defecto, y después se hace pasar el test, en lugar de arreglarlo directamente.
  • Integración continua
  • Los entornos de integración y de producción deberían ser lo más parecidos posibles

Fuente principal: http://agile.dzone.com/articles/seven-wastes-software

También te puede interesar...

Resumen Lean Software Development El libro Lean Software Development de Mary y Tom Poppendieck es una lectura obligatoria para todos aquellos que quieran entender muchos de los princip...
Agile BCN Open Space primavera de 2017 (II) Este pasado sábado se celebró el Barcelona el Open Space de la comunidad Agile BCN. Cerca de 70 personas nos reunimos en las oficinas de Netmind IT co...
Reuniones efectivas y divertidas con Goal To Meeti... En una entrada anterior ya estuve hablando brevemente sobre las reuniones efectivas y productivas. Ya no hay duda, las reuniones son uno de los grande...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *