TI2023

LEAN SOFTWARE DEVELOPMENT

(LSD)
 LSD
¿Qué es?
Enfoque
Fortalezas y Debilidades
 ¿Qué es LSD?
Lean Software Development (LSD) es una adaptación del “Lean
Manufacturing” de Toyota al desarrollo software ágil. Mary y
Tom Poppendieck llevaron Lean al mundo del desarrollo de
software. Convirtieron todos los valores, prácticas y principios de
acuerdo con la industria del software, los documentaron todos
en un libro y los pusieron en práctica.

El Lean Software Development (LSD) es un marco ágil basado en

optimizar el tiempo y los recursos de desarrollo, eliminar el
desperdicio y, en última instancia, entregar solo lo que el
producto necesita.
 Enfoque Lean
El enfoque Lean también se conoce como la estrategia de
Producto Mínimo Viable (MVP), en la que un equipo lanza una
versión mínima de su producto al mercado, aprende de los
usuarios lo que les gusta, lo que no les gusta y lo que quieren
agregar, y luego itera en base a esta retroalimentación.
 Fortalezas y Debilidades
Las fortalezas del LSD incluyen:
 El enfoque simplificado permite ofrecer más funciones en menos
tiempo.
 Elimina la actividad innecesaria y, como resultado, puede reducir los
costos.
 Empodera al equipo de desarrollo para tomar decisiones, lo que
también puede elevar la moral.

Las debilidades del LSD incluyen:

o Depende en gran medida del equipo involucrado, por lo que no es
tan escalable como otros marcos.
o Depende de documentación sólida, y no hacerlo puede resultar en
errores de desarrollo.
 LSD
Principios
Principios
 Principios
El desarrollo de software bajo la filosofía Lean se puede resumir
en siete principios:
1. Eliminar desperdicios/restos.
2. Amplificar el aprendizaje.
3. Tomar decisiones lo más tarde posible.
4. Entregar lo antes posible.
5. Potenciar el equipo.
6. Construir en Calidad (crear la integridad ).
7. Visualizar todo el conjunto.
 Eliminar desperdicios / restos
Por desperdicio o basura consideramos todo aquello que no aporta
valor al cliente. En Lean y en su nombre original en japonés se conoce
como Muda 無駄.

Dentro del desarrollo de software podríamos incluir los siguientes

elementos:
• Código generado que ofrece funcionalidades no deseadas o
necesarias.
• Retrasos en el proceso de desarrollo de software.
• Mala toma de requisitos.
• Problemas con la comunicación interna.
• Documentación excesiva o mal procedimentada.
 Amplificar el aprendizaje
Es de vital importancia que todos los miembros del equipo de
desarrollo trabajen con una mentalidad de aprendizaje continuo. El
hecho de que un desarrollador trabaje con una tecnología o lenguaje
concreto (JavaScript, .NET, J2EE, Angular, NodeJS, etc.) no quiere decir
que no pueda aprender de otros compañeros o proyectos.

Estamos en una era en la que la tecnología que hoy es noticia en unos

días puede haber cambiado radicalmente. Por este motivo los
principales implicados tienen que estar al día tanto por su bien como
profesionales como por el bien de las empresas de desarrollo de
software.
 Tomar decisiones lo más tarde
posible
Este principio que a priori puede parecer malo desde un punto de vista
tradicional en la filosofía Lean es primordial.

En un modo tradicional (sin aplicar Lean) el proyecto parte de unos

requisitos iniciales que condicionan todo el ciclo de desarrollo de
software y cualquier cambio plantea replanificación y adición de Muda
al proyecto.

En una filosofía Lean, Agile generalmente, los requisitos suelen ser

sustituidos por user stories que están más cerca de la necesidad real.
Por este motivo podemos esperar a construir el software hasta que la
user story esté definida claramente y sin ambigüedades.
 Entregar lo antes posible
En un modelo Lean, las entregas de software son más frecuentes
incluyendo features alineadas con las user stories.

Por este motivo, cada entrega incluirá funcionalidades que necesitan

los usuarios lo antes posible basadas en prioridades, impacto, valor o
cualquier otro motivo.
 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.

Además, los propios desarrolladores saben de primera mano qué

tareas cuestan más, cuales menos y qué implicaciones tienen el ciclo
de vida del proyecto.

Técnicas como el Planning Poker en las que se asignan pesos,

esfuerzos o complejidades a las tareas a realizar caen dentro de este
principio.
 Construir en calidad
En la industria del desarrollo de software, su objetivo debe ser
mantener la calidad desde el principio y no probarla en etapas
posteriores. Los autores de Lean Software Development sugieren que
resuelva el problema de calidad directamente cuando comienza a
aparecer, inicialmente poniendo la calidad en el producto y no dejando
la identificación y corrección de errores para pruebas o producción.
Para esto, vale la pena moverse en pequeños pasos y verificar la
calidad después de cada paso.

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.
 Visualizar todo el conjunto
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.

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.
 LSD
Desperdicios
 Desperdicios
Muda es la palabra con la que se designa desperdicio en el Lean
Manufacturing. Buscando una definición más precisa de lo que
se entiende por desperdicio sería:

Los 7 mudas son:

a. Sobreproducción.
b. Inventarios.
c. Sobreproceso.
d. Esperas.
e. Defectos.
f. Transportes.
g. Movimientos.
Desperdicios
 Desperdicios
Si los proyectos pertenecen al mundo de la manufactura no
habrás tenido problemas en comprender los desperdicios. Pero
en el mundo del software, existe una traslación de los 7
desperdicios Lean del software.

Desperdicio #1 – Trabajo hecho a medias

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.
 Desperdicios
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.

Para combatir este mal debemos buscar un feedback muy rápido del
cliente, tener rápidas subidas a producción, y desechar cualquier cosa
que el cliente no perciba como un valor del producto.
 Desperdicios
Desperdicio #3 – Reaprendizaje
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.
 Desperdicios
Desperdicio #3 – Reaprendizaje
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).
 Desperdicios
Desperdicio #4 – Transferencias de conocimiento
Cuando se produce una comunicación mediante un canal siempre hay
parte de la información que se pierde o se omite, cuantas más
comunicaciones sean necesarias para la realización de una tarea más
pérdidas de información y más ineficiencias se producirán.
Inconscientemente cada agente emisor omitirá una gran parte de
información tácita que sobre todo para los últimos receptores de la
información echarán en falta.

El proceso de desarrollo tradicional secuencial tiene muchas de estas

transferencias: El product manager recoge los requerimientos del
cliente, éste se lo pasa al analista funcional, que a su vez pasa al
arquitecto técnico, éste al programador, después al tester, etc.
 Desperdicios
Desperdicio #5 – Retrasos
Los más importantes son las dependencias con gente de fuera del
equipo en las distintas fases del proyecto: la toma de requerimientos,
desarrollo (validación de la arquitectura), testing (el equipo de QA),
sistemas, UAT, etc. Por cierto lo peor que puedes hacer es intentar
rellenar los espacios con nuevas tareas, recordad la teoría del WIP de
Kanban, incrementar el número de tareas en un proceso ya saturado
de esperas es como intentar arreglar los tacos de una calle muy
transitada y con muchos semáforos metiendo más coches.

Los retrasos normalmente llevarán otros desperdicios asociados, como

por ejemplo el continuo cambio de contexto, el trabajo parcial, el
reaprendizaje, y la funcionalidad extra (consecuencia de aumentar el
ciclo de feedback).
 Desperdicios
Desperdicio #6 – Cambios de contexto
Cuando tenemos varias cosas que se deben hacer de forma inmediata,
tendemos a intentar hacer varias cosas a la vez. Como nuestra mente
no es multitarea, lo que hacemos es continuamente hacer cambios de
contexto y por tanto añadir el overhead por un continuo
reaprendizaje. Además se produce algo curioso, cuando estamos con
varias tareas a la vez como el cambio a la más costosa e importante
cuesta más normalmente, lo dejamos inconscientemente para el final
y acabamos haciendo primero lo más irrelevante (procrastinación).

En el caso concreto del desarrollador de software lo vemos

constantemente, cambios entre proyectos, cambios entre tareas, y las
más importantes y quizás las que pasan más desapercibidas
interrupciones constantes mientras se está trabajando concentrado.
 Desperdicios
Desperdicio #7 – Defectos
Podemos decir que el costo total de este desperdicio es la
multiplicación del impacto que tiene el defecto en el producto por el
tiempo que está sin detectarse. Por ejemplo un bug en un sistema de
contabilidad que descuadra unos decimales algunos importes si se
detecta en el entorno de desarrollo y se corrige inmediatamente no
tiene casi impacto, mientras que si está en producción durante 3
meses es posible que se pierda mucho dinero.

Puesto que ningún desarrollador decide conscientemente introducir

bugs de mayor o menor impacto en un sistema (en todo caso puede
decidir omitirlos) en lo que nos centraremos es en minimizar el tiempo
de exposición de estos fallos.
 Desperdicios
Desperdicio #7 – Defectos
Los métodos más efectivos a la hora de minimizar el tiempo de vida de
los defectos son:
 Test de regresión automatizados (unitarios, de integración y de
aceptación).
 Tests exploratorios constantes.
 Cuando se detecte un bug, en lugar de arreglarlo directamente,
primero se crea un test que falle ante ese defecto, y después se
hace pasar el test, en lugar de arreglarlo directamente.
 Integración continua.
 Los entornos de integración y de producción deberían ser lo más
parecidos posibles.
 LSD
Modelo del Proceso
Flujo
Modelo del Proceso
 Flujo del proceso
Hemos visto que los principios Lean se pueden aplicar en cada fase de
producción. Veamos cómo encajan durante cada fase del desarrollo de
software:
1: Concepto
Después de obtener información sobre los requisitos y problemas de
software de un cliente, los desarrolladores aplican los principios de
desarrollo de software lean para incorporar todas las características
necesarias y eliminar el desperdicio.

2: Requisitos
Dado que los requisitos siguen cambiando a medida que avanza el
proyecto, entra en juego el principio de compromiso diferido. Permite
a los desarrolladores crear software flexible que se puede modificar
cuando se recopila nueva información.
 Flujo del proceso
3: Diseño de producto
Los requisitos comerciales son dinámicos; por lo tanto, el diseño del
producto debe ser lo suficientemente flexible para adaptarse a futuras
modificaciones.

4: Desarrollo de productos
Dado que el enfoque de desarrollo de software esbelto es repetitivo,
los desarrolladores obtienen más conocimientos durante cada
iteración. Por lo tanto, obtienen y mejoran habilidades a partir de estas
tareas repetitivas, lo que lleva a un mejor producto. Aquí entra en
juego el principio de amplificar el conocimiento.
 Flujo del proceso
5: Prueba de productos
Las pruebas se introducen en las primeras etapas del proceso de
desarrollo de software para eliminar errores. También asegura que se
cumplan las expectativas del cliente. Aquí, aplicará el principio de
eliminación de residuos y mejorará la calidad.

6: Lanzamiento de producto
Cuando el producto se lanza al mercado, los comentarios del cliente se
utilizan para mejorar y corregir los errores del software. Aquí se aplica
el principio de entrega rápida.
LSD
MVP
MVP
 MVP
Hemos visto que Lean utiliza la estrategia de Producto Mínimo Viable
(MVP), en la que se lanza una versión mínima del software al mercado,
se aprende de los usuarios y luego se itera en base a esta
retroalimentación. Revisemos los pasos para lograrlo:

1. Eliminar Incertidumbre
Gestionar los riesgos desde el inicio, validar el producto usando
prototipos, gestionar la lista de requerimientos del producto y validarla
frecuentemente. Entender el cambio como una constante de su
proyecto de la cual usted es responsable de gestionar. El costo de
corregir un error incrementa con el tiempo. Detecte errores en etapas
tempranas del proyecto.
 MVP
2. Aprendizaje Validado
No esperar a terminar el producto para recibir un “knock-out”. Recibir
golpes desde el inicio, levantarse rápido y corregir el plan mientras
avanza. Validar el producto con el cliente en iteraciones cortas,
semanales o diarias si fuese necesario. Ajustar los requerimientos y
repetir el proceso. Esto no significa que no se controle el alcance
general del proyecto. Establecer una línea base de alcance y hacerla
respetar.

3. Construir-Medir-Aprender
Controlar y medir el proyecto todo el tiempo. Establecer hitos
logrables, medir el progreso real del trabajo en términos de
entregables, usar una matriz de requerimientos para priorizarlos y
hacerles seguimiento. Asegurarse de desarrollar los requerimientos de
mayor prioridad temprano y rápidamente validarlos con el cliente.
 MVP
4. Asegurar un MVP (Minimum Viable Product)
Desarrollar un producto mínimo viable lo más pronto posible, validarlo
con los usuarios o clientes y luego refinarlo. Asegurarse de que el
inversionista al que quiere convencer vea lo que su producto es capaz
de hacer desde el comienzo. Ajustar los detalles más pequeños con
más tiempo.
LSD
Roles
 Roles LSD
Si queremos implementar Lean en cualquier empresa, entonces
se vuelve imprescindible considerar a las personas como el
principal activo de la empresa.

Cualquier equipo que trabaje en un entorno Lean consta

principalmente de 3 roles, estos roles dentro del proceso de
desarrollo Lean son los siguientes:
• Lean Masters.
• Lean Project Leaders.
• Lean Team Members.
 Roles LSD
Lean Master
El Lean Master tiene experiencia y ha trabajado con el cliente en el
mismo entorno por lo que estará más pendiente del proyecto y del
producto.

El Lean Master ayudará al cliente a:

 Seleccionar personas con las habilidades adecuadas y relevantes
para el proyecto, es decir, asignar recursos .
 Entrenar, capacitar y orientar a las personas en Lean Management.
 Mantener el plan maestro.
 Gestionar cambios.
 Brindarles seguridad laboral al personal por parte de la empresa.
 Comprender las herramientas y técnicas Lean.
 Entender qué esperar durante la transición y después de eso.
 Roles LSD
Lean Project Leader
El rol Lean Project Leader funciona como un canal de comunicación
entre Lean Master y el equipo, pero también funciona como
motivador.

Sus principales responsabilidades incluyen:

 Liderar equipos y proyectos Lean todo el tiempo.
 Informar el progreso y eliminar barreras.
 Comunicar y organizar.
 Responsable de la mejora del equipo.
 Roles LSD
Lean Team Member
En un proyecto de pequeño tamaño, el equipo Lean será un equipo de
6-9 miembros.

Sus roles y responsabilidades son las siguientes:

 Representar todos los pasos del proceso.
 Experto en el proceso y el trabajo que realizan. Como
desarrolladores, testers u otros.
 Trabajan juntos para diseñar e implementar una solución.
 DESARROLLO ÁGIL
Fuentes:
Casanova, S. (s/f). Resumen Lean Software Development.
Demush, R. (s/f). How Your Business Should Benefit of Lean Software Development.
Fedorychack, V. (2018). Minimum Viable Product (MVP): what is it for and how to do it
right?
GbkSoft. (2021). Lean Practices In Software Development Process.
Globalbit. (2019). Desarrollo de software Lean (LSD) y sus beneficios para las empresas.
Gómez, J. (2020). Los 7 Desperdicios (Lean) de tu proyecto.
Malas, F. (2019). The 7 Lean Principles To Help Your Software Development.
Microsoft. (2012). Lean Software Development.