Universidad del Valle de Guatemala

Facultad de Ingeniería
Departamento de Ciencias de la Computación
Ciclo I, 2023
Fecha de entrega: 12 de abril de 2023

Ingeniería de Software I
Principios de Lean Software Development

Herber Sebastián Silva Muñoz

Carné 21764
Conceptos Principales
Lean es una práctica que se utiliza a la hora de producir algún producto o proveer al
usuario de recursos que considere valioso, donde valioso se refiere principalmente a
cualquier cosa por la que el usuario sea capaz de pagar. Lean está orientado a
ofrecer un gran valor con la menor cantidad de trabajo posible, optimizando la
productividad, la eficiencia y eficacia a la hora de ofrecer el producto, así como
también, evitar desperdiciar recursos. Está basado en Lean Manufacturing y la
filosofía de pensamiento Lean en general. Cualquier tipo de proyecto en desarrollo
de software puede implementar Lean, debido a que está destinado a dotar a los
proyectos de agilidad y flexibilidad, en donde los recursos más valiosos (para el
desarrollo) resultan en el tiempo y los recursos.
Se debe usar cuando el equipo de desarrollo busca dar el máximo valor al cliente,
ser eficientes en el desarrollo, aprender al momento de estar desarrollando el
proyecto así como también un trabajo continuo y sencillo con el equipo, este último
con el objetivo de adaptarse a los cambios y nuevos requerimientos del cliente.

Principios
Pensamiento Lean:
● Eliminar desperdicios: El desperdicio es cualquier cosa que no agregue valor
al producto, ya sea del lado del desarrollador o del cliente. Se incluye el
código innecesario, requisitos engorrosos, imprecisión en las ejecuciones,
comunicaciones y procesos innecesarios, etc.
○ Aprender a ver los desperdicios: En el código, puede considerarse
desperdicio el código incompleto (no funcional), un exceso de
documentación, características que se salen de los requisitos
funcionales, comportamientos inesperados, y esperas.
○ Aprender a reducir los desperdicios: En el desarrollo, evitar que un
trabajador dependa del trabajo de otro, esto generará un flujo de
trabajo evitando el contenido innecesario y dando un flujo de trabajo
más suave, pensar bien qué agregamos y qué no al sistema, evaluar
en cada nueva característica a implementar si esto va a cubrir algún
requisito funcional.
● Amplificar el aprendizaje: Es necesario comprender el propósito de las cosas,
el propósito debe de ser crear soluciones únicas para los problemas del
usuario, no utilizar soluciones ya existentes, y si se utilizan, mejorarlas. Se
debe obtener la mayor cantidad de información posible proveniente del
entorno y del usuario en sí mismo tantas veces posibles.
○ Feedback: Para implementar esta herramienta, deben proponerse
varios registros de feedback por parte del usuario y probar nuevas o
las características existentes del programa, ya sea de forma explícita o
implícita. Deben correrse las pruebas al mismo tiempo que se
desarrolla la característica, esto implica no dar por terminada o por
aprobada una característica antes que el mismo usuario la apruebe.
Debe reducirse la documentación como tal, debe hacerse código
 sencillo, y de ser posible, que englobe varias funcionalidades y sea
potente. Deben reducirse las opciones de implementación de las
características, tener demasiadas variantes puede llegar a no decidirse
nunca por ninguna.
○ Iterar: El desarrollo iterativo es incremental, cada poco tiempo se
realizan cambios a las características y se divide el trabajo en
pequeñas partes más simples, de modo que el feedback sea más
directo y se evalúe directamente por parte del usuario si ese fragmento
es útil.
○ Sincronización o trabajo paralelo: Es cuando se trabaja al mismo
tiempo que se recibe el feedback por parte del usuario, esto va
concatenado con las herramientas anteriores.
○ Desarrollo basado en sets: Es cuando se crean sets de desarrollo, en
especial en los equipos de trabajo, en donde se desarrolla totalmente
una opción a utilizar, en donde ya quedó claro la necesidad principal y
los objetivos de la implementación, naturalmente, las soluciones
emergen.
● Decidir tan tarde como sea posible: Existen dos formas de implementar esto,
ya sea de forma concurrente o secuencial. En el lado secuencial, primero se
hacen todos los pequeños detalles, lo que permite que la ejecución de las
implementaciones más grandes sea más rápida, se crea una funcionalidad
por unidad de tiempo. Sin embargo, es costoso, rígido, no provee demasiada
escalación y provee de decisiones de alto riesgo basadas en asunciones
nada más. En el lado de la concurrencia, ve todas las características como un
todo, lo que cuesta tiempo, sin embargo, las especificaciones más valoradas
son desarrolladas antes, es adaptable, posee costo de escalabilidad bajo,
debido a que las fallas pueden encontrarse rápidamente y las decisiones de
alto riesgo pueden ser tomadas con más tiempo. Con lo que tomaremos
decisiones con más información.
○ Pensar las opciones: Principalmente se basa en pensar que se tiene el
derecho de hacer algo en el futuro, más no se tiene la obligación de.
Esto quiere decir que se tiene que pensar en el ahora, y que ahora hay
incertidumbre con respecto a alguna característica, entonces deberá
de mantenerse flexible a cualquier cambio, sin embargo, se debe de
reducir cada vez más estas opciones, debido a que tienen su costo.
○ Responsabilidad de último momento: Cuando se falla en alguna
decisión debe tomarse la responsabilidad de crear una nueva
alternativa. Para esto debe de organizarse el equipo, orientarse al
cambio, utilizar modularidad a la hora de diseñar (POO, CBD, etc) y
determinar qué es más importante cubrir, para cubrir dicha
responsabilidad.
○ Tomar decisiones: Debe retrasarse cualquier compromiso que implique
una decisión. Requiere que el equipo se comprometa a evaluar
cuándo es necesario implementar una característica debido a que ya
 forma parte de una necesidad, donde se debe de recabar toda la
información necesaria de parte del usuario, desarrollando al mismo
tiempo que recibe el propio feedback.
● Entregar tan pronto como sea posible: Debido a que a los clientes les gusta
obtener un producto fresco, esto simboliza un valor agregado al producto en
sí, sólo porque sea entregado rápido, además, esto genera en los clientes
una escasez de tiempo para analizar algo y les impulsa a adaptarse a nuevos
cambios, etc. Además, esto ayuda al principio anteriormente mencionado.
○ Pull Systems: Esto permite al equipo tener una forma de visualizar qué
es lo que necesita ser hecho aún, dándoles una forma de trabajar y un
flujo de trabajo suave, evitando metodologías de trabajo complejas.
Además de brindar una forma de “deadline” para los usuarios en sí.
○ Queuing Theory: Consiste en establecer alguna forma de informar a
los equipos el ciclo de tiempo que deben de dedicarle a cada tarea,
tomando en cuenta el tiempo que se tarda en realizarla, dando un
márgen de tiempo adecuado a sus capacidades. En donde se definen
diferentes estados para cada implementación, por ejemplo, “en cola”,
“en ejecución” o “finalizado”.
● Involucrar al equipo: Consiste en que todo el equipo se sienta incluído en el
proyecto, además que todos saben el curso del proyecto, lo que permite un
mindset homogéneo entre el equipo. Además de motivar al equipo, y tomar
decisiones en conjunto.
○ Self-Determination: Es una forma de asignar tareas o prácticas de un
entorno a su área, y dejar que los subequipos y equipos manejen sus
propios procedimientos, es decir, ellos saben cómo trabajan, pero
también saben qué deben de entregar algo con ciertos lineamientos.
○ Motivation: Esto consiste más en crear un enfoque y propósito del
equipo y su trabajo que les haga recordar porqué hacen lo que hacen.
○ Liderazgo: Esto consiste en que una persona esté comprometida al
cambio y al manejo de su equipo, que sea capaz de motivarlos,
guiarlos en la dirección correcta y verificar que los lineamientos se
cumplan.
● Construir integridad: Esto refiere a que el usuario y el equipo sientan que el
producto que está entregándose es íntegro, es decir, tiene bases sólidas y
que sus funcionalidades correctas son vehemente ariscas a las fallas, esto
quiere decir que el sistema mantiene flexibilidad al agregar nuevas
funcionalidades, debido a que las funcionalidades “anteriores” no deben
porqué fallar, además que es usable y puede evolucionar.
○ Perceived Integrity: Las funcionalidades más pequeñas, divididas
anteriormente pueden ser ejecutadas por un equipo en específico que
verifique que la funcionalidad sea uniforme y que posea integridad,
utilizando el feedback a su disposición, esto logra que sistemas más
complejos, sean más robustos.
 ○ Conceptual Integrity: En este caso, refiere más a las decisiones y al
diseño, ligado a la herramienta anterior.
○ Refactoring: Refactoring es una técnica que se utiliza para mantener
las cosas simples, y que para hacer un cambio solo deba cambiarse
una sección del programa en específico, y no es necesario cambiar en
todo, aunque este sea usado, para esto el código debe mantener
simplicidad, claridad, usabilidad portable, sin repeticiones y sin
agregados.
○ Testing: Esta técnica se basa exclusivamente en estar probando el
programa cada vez que se da por útil una funcionalidad, se debe de
tener el objetivo de hacerlo fallar, esto para dar solución a cualquier
vulnerabilidad del sistema.
● Identificar todos los puntos de vista posibles: Esto refiere más a un mindset,
por ejemplo, no es justo que un sistema sea una suma de partes, es un
producto hecho de varias funcionalidades. En el caso de los problemas,
refiere a que no debe verse la superficie del problema, debe verse la raíz del
problema. En materia de patrones, debe de quitarse límites de crecimiento,
de optimización, etc. Que los requisitos se cumplan no quiere decir que no
pueda mejorarse.
○ Porqué: Esta técnica consiste en preguntarse siempre el porqué, el
cómo y el para qué de todo, al obtener una respuesta, debe de
hacerse otra vez la pregunta, para ser capaz de ver todo el contexto.
○ Medidas: Para esto, puede medirse cada parte del sistema y como
esta está funcionando, el sistema funciona en conjunto, así que con
esto puede verse de dónde provienen las cosas, ya sea una
oportunidad de crecimiento, error, etc.

Referencia:
Lean Software Development Principles (slideshare.net)