Lean de la vida misma de un proyecto: los desperdicios del lean software (1/2)

Cuánto desperdicio de tiempo puede llegar a haber en el día de un proyecto. El desperdicio de tiempo que genera una persona al día, o el trabajo elaborado que no sirve o que entorpece, multiplicado por el de todas las personas de un equipo, y por los meses o años que dura un proyecto, eso es lo que ha acabado matando a miles de proyectos, son los desperdicios del lean software.
El Lean, y el Lean Software Development (te dejo este post sobre qué es Lean Software), se centra en la eliminación continua de desperdicios, los desperdicios del lean software son todo aquello que no aporta valor y que ocurre tanto en todo proyecto.
Aunque el Lean se ha aplicado históricamente a la industria, ha sido en los últimos años cuando se ha adaptado al software, donde las cosas no son exactamente iguales (recuerda aquello de que fabricar software no es lo mismo que fabricar coches o casas). Y en este post vamos a ver los desperdicios del lean software, desperdicios reales de día a día de un proyecto software.
Y, antes de empezar, ojo, que ya veréis que estos los desperdicios del lean software pueden aplicar a tu día a día, a cualquier cosa que hagas en tu vida, desde estudiar para un examen, a mantener un blog, a mejorar tu vida social. De hecho, creo que las personas “súper productivas” vienen “de serie” con el instinto de evitar desperdicios.
Hay 7 típicos desperdicios del lean software (según los clasificaron Mary and Tom Poppendieck en el mejor libro que hay sobre el tema):

Desperdicios del lean software 1: Trabajo realizado parcialmente

Uno de los desperdicios del lean software, y de la vida misma de un proyecto, mas frecuentes. Aquella documentación que tardamos meses en elaborar pero que quedó sin codificar (esto me recuerda a mis tiempos haciendo diseños UML al detalle y que luego al chocar con la realidad no los seguíamos). Los requisitos, y las historias de usuario obsoletas.
Ese código en el PC de un desarrollador durante mucho tiempo, tanto que integrarlo ya es complicadísimo es un desperdicio. O esas ramas de código en la herramienta de control de versiones que viven durante meses antes de “mergearse” con la línea principal, desperdicio.
O el código no probado: sin pruebas, no hay manera de saber que el código funciona (ni con pruebas tenemos seguridad, pues imagínate sin ellas).

Desperdicios del lean software 2:  Características extra

Un clásico: aquello que creemos que el cliente va a necesitar pero que cliente no ha pedido. Cuando un comercial, cliente, etc., insiste en incluir cosas en el producto,que al final no se usan… tenemos un enorme desperdicio. La funcionalidad que ha quedado obsoleta es un desperdicio.
Y no olvidéis que las características introducidas sólo para probar la última moda y esa tecnología moderna… acaban siendo un desperdicio.

Desperdicios del lean software 3: Reaprendizaje

¿Cuántas veces has resuelto un problema y no has implantado inmediatamente la solución? ¿Cuántas veces has tenido que redescubrir semanas después la misma solución? Desperdicio de tiempo, otro de los desperdicios del lean software.
Por otro lado, muchas veces no preguntamos, ni hacemos caso a expertos, y trabajamos en solitario. Cada minuto que pasamos redescubriendo cosas que rápidamente nos podrían haber contado… es tiempo perdido.
Y también está el código mal escrito o indocumentado que conduce a una incalculable cantidad de reaprendizaje, desperdiciando tiempo.
Por último, otro clásico y repetido desperdicio: desarrolladores que están constantemente siendo reasignados a funciones diferentes, dejando sin terminar su trabajo actual.
..
Mañana os dejo la segunda parte sobre desperdicios del lean software: aquello que pasa de mano en mano, las pausas, estar cambiando de tarea constantemente y los defectos.
Lean de la vida misma de un proyecto: los desperdicios del lean software (2/2)

0 comentarios en “Lean de la vida misma de un proyecto: los desperdicios del lean software (1/2)”

  1. Para mí, los desperdicios más destacables de los que comentas son la ausencia total de pruebas (a veces no te dejan ni plantearlo), la inclusión de tendencias de manera arbitraria (‘hazlo en RoR, que mola mucho’) y, como le decía a mi último jefe, «reinventar la rueda… para que encima salga cuadrada».

  2. Pingback: Bitacoras.com

Deja un comentario

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

Share This
Ir arriba