Desarrollo ágil de software

HISTORIA
 LA METODOLOGÍA DE DESARROLLO DE SOFTWARE LEAN
(TRADUCCIÓN APROXIMADA DE LEAN: «FINO» O «ESBELTO») 

Lean Software Development es una

adaptación del “Lean Manufacturing”
de Toyota al desarrollo software ágil.
Es una traducción de los principios y
las prácticas de la forma de
producir lean, hacia el área
del desarrollo de software.
 “Lean” es sinónimo de Toyota
Production System una estrategia de
fabricación aplicada con mucho éxito en
Japón y ahora muy famosa en el mundo
del software, muchas veces bajo el
término de Lean Software Development.
El término lean software development se originó en
libro del mismo escrito por Mary y Tom
Poppendieck.

EL libro presenta los tradicionales principios Lean

en forma modificada, así como un conjunto de 22
instrumentos y herramientas y las comparaciones
con otras prácticas ágiles. 

Lean software development es básicamente la

aplicación de la filosofía lean al desarrollo de
software. el libro presenta 7 principios basados en
lean y un set de 22 herramientas.
La metodología tiene como objetivo
eliminar desperdicios, seleccionando
aquellas características que
realmente aportan valor, y da
especial importancia a la velocidad y
la eficiencia.
 Lean Software Development
DESCRIPCIÓN
Mary y Tom Poppendieck, Fueron los autores de aquel libro los usaron el
término “lean” para describir cualquier práctica eficiente de gestión que
minimice el desperdicio , lo que incluía a las técnicas de desarrollo de productos
japonesas, con las que los fabricantes de automóviles japoneses habían logrado
recortar mucho los tiempos y las horas de ingeniería.

en comparación Estados Unidos y Europa, hasta tal punto fue el paralelismo

que hoy lean es sinónimo del método de fabricación de Toyota una estrategia de
fabricación aplicada con mucho éxito en Japón y ahora muy famosa en el
mundo del software .
 LEAN SOFTWARE DEVELOPMENT

siendo métodos idealmente originados por estadounidenses, fueron aplicados

por los japoneses, convirtiendo a Japón líder en la industria automovilística,
pasando por encima de los EEUU.

El artífice del Lean, quien introdujo esta nueva manera de fabricar en Toyota,
fue Taiichi Ohno (1912 – 1990), cuya estrategia se fundamentó en tres bases:

 Construir sólo lo necesario.

   Eliminar todo aquello que no añade valor.
 Parar si algo no va bien (lo que está relacionado con el principio de cero
defectos).
 Lean Software Development
PRINCIPIOS
Además, conviene destacar que el Lean incluye siete importantes principios, los
siguientes:
 
 Eliminar desperdicios
 Amplificar el aprendizaje
 Decidir lo más tarde posible
 Entrega lo más rápido posible
 Capacitar, potenciar, al equipo
 Construir con integridad
 Ver el todo
 Lean Software Development
Y en lo que refiere al primer punto, los desperdicios, el Lean habla de que un
desperdicio es todo aquello innecesario, todo añadido del que se puede
prescindir, donde se destacan los siguientes siete siguientes desperdicios:

 Sobreproducción
 Tiempo de espera
 Transporte
 Inventarios innecesarios
 Transportes innecesarios
 Defectos
 Sobre procesamiento, o procesos inadecuados

Hay quien añade un desperdicio más: el talento humano (desperdiciando la

creatividad).
 Lean Software Development
El Lean, el Lean Software Development
y los métodos ágiles
La conexión de lo ágil con el Lean viene de que muchos creadores de métodos
ágiles estuvieron influenciados por el método Lean, como por ejemplo 
Mary y Tom Poppendieck.
 
Hay incluso quienes afirman que las ideas de Lean y las ideas agiles son tan
similares que se dice que aplicar la filosofía ágil es aplicar la filosofía Lean. Y
un proceso Lean, es un proceso ágil. 

aunque la filosofía ágil rechaza que el proceso de desarrollo software sea un

proceso de fabricación industrial tradicional (como el que sucede al construir un
coche o una casa), los ágilistas han tenido una gran influencia y adopción de
los métodos de fabricación de Toyota.
 Lean Software Development
El lean, y el lean software development, no es una metodología de ingeniería de
software en el sentido convencional. Es más una síntesis de principios y una la
filosofía para construir sistemas de software.

Si lean se considera un conjunto de principios más que prácticas, la aplicación

de conceptos lean al desarrollo software y la ingeniería software tiene más
sentido y puede ayudar a mejorar la calidad.
Princípios/Características de Lean Software
Development (LSD)

La consigna “Pensar en grande, actuar en pequeño, equivocarse rápido y aprender con rapidez” podrían
resumir los siete principios Lean para el desarrollo de software.
1. ELIMINELIMINAR
DESPERDICIOS:
Uno de los pilares de lean es eliminar el desperdicio que no
entrega valor y que agrega tiempos al flujo del  proceso de
desarrollo.

2.- Amplificar aprendizaje

Es de vital importancia que todos los miembros del equipo de desarrollo
trabajen con una mentalidad de aprendizaje continuo.
3.-Tomar decisiones tardías
Este principio que a priori puede parecer malo desde un punto de vista tradicional
(ciclo de vida en cascada) en la filosofía Lean es primordial. Los requisitos de los
clientes pueden cambiar de un día para otro, bien por cambios en las necesidades
o bien por una mala definición de los mismos.

4.-Entregar lo antes posible

En un modelo Lean, las entregas de software son más frecuentes incluyendo
features alineadas con las user stories.
5.-Potenciar el equipo
Facilitar que los desarrolladores participen en la toma de
decisiones de tiempos asociados a tareas, priorización de las
mismas y demás hacen que los miembros del equipo se
sientan parte importante en él.

6.-Crear la integridad
Contar con un buen sistema de integración continua que
incluya pruebas automatizadas, builds, pruebas de usabilidad
son críticas para que un software sea fácil de mantener, de
mejorar y de reutilizar. Con esto evitaremos añadir Muda a
dicho software e intentar aprovechar lo aprendido de
proyectos anteriores.
7.-Visualizar todo el conjunto

Analizar las interacciones de nuestro software con el resto de

sistemas dentro de la compañía nos permitirán estudiar posibles
mejoras y cambios que redunden en una mejor experiencia de
usuario y aporten un mayor valor para el cliente y para el equipo del
proyecto.
 VENTAJAS Y
DESVENTAJAS
Ventajas

-Rápida respuesta a cambios de requisitos a lo largo del desarrollo.

- Entrega continua y en plazos cortos de software funcional.
- Trabajo conjunto entre el cliente y el equipo de desarrollo.
- Minimiza los costos frente a cambios.
- Importancia de la simplicidad, al eliminar el trabajo innecesario.
- Atención continua a la excelencia técnica y al buen diseño.
- Mejora continua de los procesos y el equipo de desarrollo.
- Evita malentendidos de requerimientos entre el cliente y el equipo.
- El equipo de desarrollo no malgasta el tiempo y dinero del cliente desarrollando soluciones
innecesariamente generales y complejas que en realidad no son un requisito del cliente.
- Cada componente del producto final ha sido probado y satisface los requerimientos.
Desventajas
Como en cualquiera otra metodología, también hay desventajas y
problemas que surgen a la hora de implementarlas:

- Falta de documentación del diseño. El código no puede tomarse

como una documentación. En sistemas de tamaño grande se necesitar leer
los cientos o miles de páginas del listado de código fuente.
- Problemas derivados de la comunicación oral. Este tipo de
comunicación resulta difícil de preservar cuando pasa el tiempo y está
sujeta a muchas ambigüedades.
- Falta de calidad. Probar el código de forma constante no genera
productos de calidad, sólo revela falta de análisis y diseño.
- - Fuerte dependencia de las personas. Como se evita en lo posible la
documentación y los diseños convencionales, los proyectos ágiles
dependen críticamente de las personas.
- Falta de procesos de revisión del código. Con métodos como el
PSP o TSP se han conseguido reducciones de errores que oscilan entre el
60 y el 80%. La programación en parejas tiene resultados del 20 al 40%,
- Falta de reusabilidad. La falta de documentación hacen difícil que pueda
reutilizarse el código ágil.
-
- Sobre costos y retrasos derivados de la refactorización continua.
Para un sistema de ciertas proporciones, los costos y retrasos derivados de
la refactorización no pueden despreciarse.
-
- Restricciones en cuanto a tamaño de los proyectos abordables.
- Rigidez. Algunos métodos ágiles son muy rígidos: deben cumplirse
muchas reglas de una forma estricta para garantizar el éxito del proyecto.
Por ejemplo XP exige en realidad mucho esfuerzo, concentración y orden.
-
- Cambios. Los modelos de datos son “pesados” y no pueden cambiarse
así como así solo porque el cliente que ira incorporar más funciones al
sistema.
-
- Problemas derivados del fracaso de los proyectos ágiles. Si un
proyecto ágil fracasa no hay documentación o hay muy poca; lo mismo
ocurre con el diseño. La comprensión del sistema se queda en las mentes
de los desarrolladores.