Desarrollo esbelto de software(DES)

Desarrollo esbelto de software(DES)

Muchas de las técnicas del área de producción de la Ingeniería Industrial se han migrado al desarrollo de software, en muchos casos con buen éxito. 

Recientemente los conceptos de manufactura esbelta se han empezado a utilizar en el área del desarrollo de software.

Los orígenes de la manufactura esbelta se remontan a la década de 1960 con el sistema de producción de Toyota denominado Kanban, cuyas características principales eran la autonomía total, el realizar los procesos justo a tiempo, lo cual implica no manejar almacén y no realizar inspecciones. Este esquema hizo que rápidamente Toyota se ubicará como la primera armadora de carros en los Estados Unidos.

Todos estos conceptos se migraron al área de producción para crear el concepto de manufactura esbelta. Los principios esbeltos aplicados más importantes son los siguientes: 

1. Los que hacen las cosas son los que saben.

2. Se manejan lotes chicos (privilegia los desarrollos personalizados a los de masa).

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 de software esbelto está muy casado con el concepto de desarrollo ágil, aunque son conceptos totalmente distintos. El desarrollo esbelto implica agilidad, aunque la agilidad no necesariamente implica ser esbelto. Por ejemplo, una persona que es esbelta generalmente es ágil, una persona que es ágil no necesariamente es esbelta (hay muchas personas que aun siendo obesas desarrollan agilidad). En cuestión de desarrollo de software la agilidad implica desarrollar cosas con destreza (no necesariamente rápido), mientras que el desarrollo de software esbelto de manera esencial consiste en eliminar procesos innecesarios. 

En una era donde ser esbelto está de moda, ¿se pueden poner a dieta los procesos de desarrollo de software?

Por raro que parezca, no existe una definición formal de metodologías esbeltas simplemente se usan los principios del pensamiento ágil. Cada autor varía los principios manejados. A continuación, se muestran algunos principios básicos y su explicación.[pic 1]

PRINCIPIO 1: 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.

Se tiene el mito que la especificación temprana del producto de software reduce el desperdicio. En la práctica se ha comprobado que influye más la forma de desarrollar que en sí el mismo producto debido a la complejidad del software. Por ejemplo: el desarrollar un software a través del modelo de cascada en teoría debería evitar problemas en el desarrollo. En la práctica siempre se dan problemas dado que el software es un producto no tangible cuyas especificaciones van cambiando frecuentemente.

PRINCIPIO 2: GENERAR 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 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. En este tenor, se debe seguir el principio de mantener lo más simple el diseño del software, así como utilizar técnicas más avanzadas como la refactorización de código.

PRINCIPIO 3: 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 socio tecnológico que al verse involucrado por el capital intelectual no es predecible.

PRINCIPIO 4: APLAZAR EL COMPROMISO

En este apartado 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. En este punto el mito más generalizado en el desarrollo de software es la idea de que la planificación crea compromiso. En el desarrollo de software no se cumple tal cual porque los requerimientos cambian.

PRINCIPIO 5: ENTREGAR RAPIDO

...