desperdicios LEAN del software

Los 7 desperdicios LEAN del software (I)


En el post sobre Kanban vimos la importancia de tener un flujo continuo de entrega de valor a la compañía. Todo el proceso de mejora continua se centra al fin y al cabo en optimizar ese flujo, o bien en aumentar el trabajo acabado, en mejorar su calidad o en eliminar los cuellos de botella actuales.

Kanban está muy ligado a los principios de LEAN, que hablan de eliminar cualquier cosa en el proceso o producto que no aporte valor final al cliente. Cualquier cosa que no aporte valor se considera un desperdicio.

Los 7 desperdicios LEAN del software

LEAN define los 7 principales desperdicios en un proceso de manufactura, pero existe una traslación de estos 7 desperdicios LEAN del software. Son los siguientes:

Desperdicio #1 – Trabajo hecho a medias

Y es que las cosas que se quedan en el entorno de desarrollo durante mucho tiempo trae consigo muchos problemas. Es código que hay que compilar y desplegar mientras desarrollamos otras cosas, que va a fallar en cuanto cambie alguna interfaz con la que se comunique, sin tests automáticos para detectar posibles fallos tempranamente, y por supuesto sin documentar. En el momento de retomar ese trozo de código en el futuro seguramente nos dará más problemas que si lo tuviéramos que desarrollar de nuevo.

Desperdicio #2 – Funcionalidad extra

Cualquier cosa que no nos hayan pedido es un desperdicio, ya que si no nos lo han pedido es que probablemente no aporte ningún valor o un valor muy escaso comparado con el esfuerzo de conseguir esa característica. Cualquier funcionalidad en el sistema le añade complejidad, es un nuevo punto de fallo, implica un mayor mantenimiento, sincronizar interfaces que cambian, mantener los tests funcionando, etc. Y no hablemos de la funcionalidad para la galería, que decide incorporar el desarrollador simplemente porque le gusta o le motiva (ver Resume Driven Development). Para combatir este mal debemos buscar un feedback muy rápido del cliente, tener rápidas subidas a producción, y deshechar cualquier cosa que el cliente no perciba como un valor del producto (YAGNI).

Desperdicio #3 – Reaprendizaje

A no ser que seamos Sheldon Cooper, nuestra cabeza está limitada y tendemos a ir olvidando lo que no usamos normalmente, y si tenemos que volver a usar algo tenemos que aprender de nuevo cómo usarlo. Cualquier proceso de reaprendizaje es un desperdicio y debe evitarse siempre que se pueda.

Por ejemplo recoger requerimientos demasiado temprano es un desperdicio ya que tendrás que releer los requerimientos y entenderlos de nuevo si ha pasado mucho tiempo.

Las tareas a medias son un desperdicio en parte también porque tendrás que reaprender lo que hiciste antes de continuar, y esto se acentúa si además el código está mal estructurado y mal comentado. Lo mismo aplica a los bugs, si los detectas más tarde de lo normal, si te das cuenta mientras desarrollas es un momento, si llega a producción un mes después de que lo hayas hecho tardarás mucho más simplemente porque tendrás que reentender lo que hiciste.

Si existe un experto de un tema en la empresa pero nos empeñamos en aprender una cosa por nosotros mismos es también un desperdicio, ya que hemos reaprendido un conocimiento que ya existía en la empresa y que podíamos haber adquirido simplemente preguntando a la persona adecuada.

Formas de combatir todo este desperdicio es tener el conocimiento capturado, por ejemplo con wikis de desarrollo. También ayuda no arrastrar deuda técnica y tener el código documentado mediante tests automáticos (unitarios, de integración y de aceptación).

En el siguiente artículo Los 7 desperdicios del desarrollo de software (y II) veremos los 4 desperdicios restantes: Transferencias de conocimiento, retrasos, paralelismo con tareas y defectos.

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

También te puede interesar...

Resumen Scrum by Jeff Sutherland Tenía muchas ganas de leer este libro. Ya no solo porque era leer sobre el framework Scrum que utilizo a diario en mi trabajo, sino porque me lo había...
Los 7 desperdicios LEAN del 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...
Resumen Clean Code Este verano he releído uno de los libros de referencia de todo buen programador. Se trata de "Clean Code", de Robert C. Martin (o más conocido como Un...

Dejar un comentario

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