Muchas técnicas de la ingeniería de Industrial se han migrado al desarrollo de software, tal es el caso de la manufactura esbelta, la cual a empezado a utilizarse en el desarrollo de software.
Algunos orígenes de la manufactura esbelta se remonta en la década de los 60's como el sistema de producción de Toyota que se denominó Kanban, la cual manejaba la autonomía total, realizar procesos a tiempo, por lo cual conlleva a no manejar almacén y no realizar inspecciones. Este esquema hizo que Toyota fuera la primera ensambladora de vehículos
En lo referente al desarrollo de software esbelto (Lean Software Development) fueron Mary y Tom Poppendieck los primeros en transferir los principios de la manufactura esbelta al software.
El desarrollo esbelto de software esta muy ligado con el desarrollo ágil, aunque son conceptos diferentes puesto que el desarrollo esbelto implica agilidad pero para ser ágil no necesariamente puede ser esbelto, como por ejemplo: una persona esbelta no necesariamente debe ser ágil, y una persona ágil no necesariamente debe ser esbelta; para el desarrollo de software esbelto en esencia, consiste en eliminar procesos innecesarios.
CONSTRUIR CON CALIDAD
A continuación tenemos algunos principios del Desarrollo de Software Esbelto:
ELIMINAR EL DESPERDICIO
Por desperdicio se entiende todo aquel proceso que no crea valor para los clientes y que en muchas ocasiones retrasa la entrega de proyectos. ¿Qué cosas no crean valor en el desarrollo de software? Lista de requerimientos, diseño de la aplicación, errores y sobre todo funcionalidad no usada.
CONSTRUIR CON CALIDAD
La inspección es un proceso fundamental para lograr el aseguramiento de la calidad del software. Se recomienda guiar nuestro desarrollo a través de pruebas automatizadas sobretodo del tipo unitarias y de aceptación. En este sentido se tiene el mito de que el trabajo del tester es encontrar errores cuando su rol principal es verificar que el producto de software sea de calidad.
Una de las metas fundamental del desarrollo esbelto de software es reducir el tamaño del código de manera considerable tomando en cuenta la premisa que a menor código menor probabilidad de error.
CREAR CONOCIMIENTO
Dada la naturaleza del software no es posible conocer las necesidades de un producto de software desde el inicio y tampoco es posible el diseñar sin implementar dado que en general el diseño se va puliendo poco a poco. Se debe de ver el desarrollo de software como un proceso de aprendizaje y mejora tanto del producto como del negocio en sí. Bajo este contexto, se tiene la creencia que el manejar predicciones crean predictibilidad, este concepto es erróneo dado que el desarrollo de software es un proceso sociotecnológico que al verse involucrado por el capital intelectual no es predecible.
POSTERGAR COMPROMISO
En este punto se deben de tomar decisiones que no sean reversibles y encontrar soluciones que se puedan invertir. En palabras más claras, se debe tratar que el proceso de desarrollo no cambie, se quede estandarizado pero que la solución pueda ser modificada fácilmente.
ENTREGAS RAPIDAS
El entregar versiones del software antes de que esté terminado al 100% hace que se mejore la calidad, que el costo sea más bajo, que haya menos cambios.
RESPETAR A LAS PERSONAS
Se debe fomentar el liderazgo y el emprenderismo a todos los niveles del equipo de desarrollador de software. El control del software debe estar basado en los objetivos.
OPTIMIZAR EL TODO
Se debe tener esta premisa siempre, pero se debe de recordar que el cliente siempre quiere las cosas para ayer y las pruebas siempre están sobrecargadas por falta de tiempo. En este sentido se debe optimizar cuando se pueda y realmente sea necesario.
