“METODOLOGIAS DE
DESARROLLO AGIL LEAN
SOFTWARE DEVELOPMENT”
UNIVERSIDAD NACIONAL AMAZÓNICA DE
MADRE DE DIOS
FACULTAD DE INGENIERIA
ESCUELA PROFECIANAL DE INGENIERÍA DE
SISTEMAS E INFORMÁTICA
Estudiantes:
HUARICANCHA ABAD, David Jesus
2
INTRODUCCIÓN
Lo proyectos de software, así como otros tipos de
proyectos, por su dificultad necesitan de un conjunto de
patrones que permitan su gestión y ejecución, esto es
ideal si se desea alcanzar los estándares deseados, por
lo cual, a lo largo de los años, tomando experiencia de
todo eso, las personas han desarrollado metodologías
que nos brindan una guía de paso, sí, por así decirlo, que
nos llevaran al éxito que queremos obtener con el
desarrollo de dicho proyecto.
RESUMEN
Durante gran parte del desarrollo profesional de
cualquier ingeniero software, surgen muchos
interrogantes recurrentes sobre cómo llevar al
máximo estándares requeridos para un proyecto de
software, la manera cotidiana de resolver esas
preguntas es mediante una metodología de
desarrollo de software, pero en este trabajo
hablaremos de una metodología algo inusual a lo que
ya conocemos comúnmente
HISTORIA
“El desarrollo del sistema se atribuye fundamentalmente a tres personas: el
fundador de Toyota, Sakichi Toyoda, su hijo Kiichiro y el ingeniero Taiichi Ohno.” (1)
El ingeniero de calidad de Toyota, John Krafcik, acuñó el término mientras observaba
los procesos y herramientas utilizados para la eliminación de residuos en la
producción de los automóviles. No fue sino hasta 2003 que María y Tom
Poppendieck introdujeron Lean como un proceso de desarrollo de Software en su
libro “Lean Software Development: An Agile Toolkit” (2).
HISTORIA
Lean es una metodología genérica para mejorar la
calidad y productividad. Es usada exitosamente en
industrias de manufactura o logística Tiene su origen en
el Sistema de Producción de Toyota (TPS).
Variaciones del “Lean”
• Lean Manufacturing
• Lean Enterprise
• Lean Software Development (LSD)
• Lean Thinking 4 Lean Intelligence
Las ideas fundamentales de manufactura esbelta son
universales aplicables en cualquier lugar por cualquier
persona y muchas compañías (no japonesas) han
aprendido esto.
Es el caso de la metodología que hablaremos a profundidad
en este texto, ya entendiendo de donde proviene esta
metodología nos podemos dar una idea a hacia dónde va
dirigida.
LeanSoftwareDevelopment
Está enfocado principalmente en las prácticas y herramientas que una organización debe poner en práctica
para gestionar equipos de desarrollo de software (5).
El objetivo de la filosofía Lean es la mejora de la productividad y la construcción de productos de calidad.
Para conseguirlo, se enfocan en el personal como elemento principal de la organización, centro de los
procesos de una empresa, y una fuente de habilidades, conocimientos y nuevas ideas que deben ser
tomados en cuenta (4).
Se utilizó los conceptos de liderazgo y autogestión para mejorar el desempeño y se formularon principios
que debían ser implantados radicalmente en la cultura organizacional de las empresas (4).
Se puede decir que es una metodología que tiene como objetivo eliminar desperdicios, seleccionando las
características que realmente aportan valor, velocidad y eficiencia a un producto software. La metodología
incluye siete principios importantes, que redactaremos a detalle más adelante.
Principios de Lean
1. Eliminate Waste (Eliminar Residuos)
2. Amplify Learning (Amplificar el Aprendizaje)
3. Decide as Late as Possible (Decide lo más Tarde Posible)
4. Deliver as Fast as Possible (Entrega lo más Rápido Posible)
5. Empower the team (Potenciar al Equipo)
6. Build Integrity (Establecer Integridad)
7. See the Whole (Verlo todo)
1. Eliminate Waste (Eliminar Residuos)
Herramienta 1. Identificar los desperdicios
Aprender a reconocer “aquellos pasos que no contribuyen directamente con el producto
final y en vez de ello elevan su costo” (8)
Herramienta 2. Mapeo de la cadena de valor
Analizar valiéndonos de mapas de cadena de valor los tiempos de espera y los tiempos
de valor de un proceso. Aquellas actividades cuyos tiempos de espera sean mayores
deben ser estudiados para hallar las fuentes de demora, planificar cómo reducirlos y
diseñar un nuevo mapa de cadena de valor (8) (10)
10
2. Amplify Learning (Amplificar el Aprendizaje)
Herramienta 3. Retroalimentación
Mantener una constante comunicación entre componentes del equipo, clientes e
interesados. La retroalimentación constante permite reaccionar frente a cambios, detectar
fallas en el avance del sistema, mejoras en la forma de realizar el trabajo y la gestión del
proyecto, y una mejor toma de decisiones (8) (10).
Herramienta 4. Iteraciones
Períodos cortos de tiempo donde se produce incrementos ejecutables del software final.
Estos incrementos son mejorados al avanzar las iteraciones. Cada iteración es
planificada, incluyendo en ellos las funcionalidades requeridas por prioridad, las tareas y
los recursos para lograr las versiones (8).
11
Herramienta 5. Sincronización
Varias personas realizan tareas sobre una misma actividad, lo que hace necesario que
exista sincronización para evitar inconsistencias, incongruencias e incompatibilidades
entre avances, se unifiquen y que al final del día se tenga como avance un todo
integrado. Las pruebas de integración son muy útiles para detectar fallas, corregir y
mejorar la construcción terminada en la jornada (8).
Herramienta 6. Desarrollo concurrente
En desarrollo de software, para tomar una decisión, deben diseñarse una serie de límites
que encaminen los acuerdos, y así, las discusiones no se tornen un círculo sin término.
En la solución de un problema, estos límites se llaman soluciones y en base a como
funcionen, se elegirá la alternativa de manera más ágil (8).
12
3 Amplify Learning (Amplificar el Aprendizaje)
Herramienta 7. Pensamiento de opciones
El tomar una decisión crítica al inicio, tiene mucho riesgo, pues hay incertidumbre sobre
qué sucederá. En cambio, las opciones son experimentos para el aprendizaje.
Necesitamos aprender, para recabar información y así tomar una decisión adecuada (8).
Herramienta 8. Último momento responsable
El último momento responsable según (10), es “el momento en que fallar al tomar una
decisión, se elimina una alternativa importante”.
13
3 Amplify Learning (Amplificar el Aprendizaje)
Herramienta 9. Toma de decisiones
Para un entorno cambiante, se requiere un enfoque principal de amplitud, en la cual la
persona tiene experiencia para enfrentar los cambios e identificar oportunidades para la
toma de decisiones. Un enfoque principal, por el contrario, de profundidad requeriría
alguien que pueda tomar decisiones desde el inicio y la seguridad que el entorno es
estable (8).
4. Deliver as Fast as Possible (Entrega lo más Rápido Posible)
Herramienta 10. Sistemas impulsados
En un sistema impulsados, los clientes entregan sus requerimientos en forma de historias
de usuario, para que el equipo, a través de un grupo de criterios y reuniones definidas,
acuerden una planificación en interacciones (de duración no mayor al mes)
14
4. Deliver as Fast as Possible (Entrega lo más Rápido Posible)
Herramienta 11. Teoría de colas
Los conceptos de teoría de colas y de tiempos de ciclo, son importantes para identificar
los cuellos de botella y las colas de espera en un proceso de desarrollo de software.
Luego, se debe de mejorar la forma de alimentación entre subprocesos y tareas
dependientes, reordenar la organización y frecuencia de paquetes de alimentación y
reducir los tiempos de ciclo, para incrementar la rapidez de las entregas (8) (10).
Herramienta 12. Costo de demora
Construcción de modelos financieros que muestren a los interesados del proyecto el
impacto que produciría agilizar o demorar la introducción del producto de software. Los
beneficios o las pérdidas presentadas, crearán conciencia en la organización de la
importancia de implantar un enfoque ágil al proceso de desarrollo de software (8).
15
5. Empower the team (Potenciar al Equipo)
Herramienta 13. Auto-determinación
Un proyecto debe estar enfocado en las personas que desarrollan el producto. Ellos
deben ser los encargados de gestionar, organizar y distribuir su trabajo, en vez que un
gerente o un administrador les diga qué hacer (8)
Herramienta 14. Motivación
Para formar la motivación en los miembros del equipo de proyecto se necesita (8):
• Dar a conocer el sentido y el propósito del cumplimiento de sus tareas, y que tengan la
autonomía de gestionarlo.
• Cultivar en ellos una sensación de pertenencia, seguridad, competencia y progreso de
su trabajo.
16
5. Empower the team (Potenciar al Equipo)
Herramienta 15. Liderazgo
No es lo mismo administración que liderazgo. Un administrador se encarga de controlar
que el proyecto y sus componentes trabajen dentro de unos estándares o acuerdos. Un
líder, en cambio, ha realizado un trabajo conceptual inicial sobre un proyecto, poseyendo
un sentido de pertenencia sobre el producto, lo que le permite dar a conocer al equipo los
objetivos del proyecto y a la vez maximiza las habilidades de cada miembro
Herramienta 16. Pericia
En un proyecto se debe incluir un grupo de personas especializadas y expertas en
distintas áreas del conocimiento (técnicas y de domino), de modo tal, que se forme una
ventaja competitiva sobre otros competidores. Debe ir acompañada de una estructura
organizacional que favorezca el desarrollo de la experiencia (8).
17
6. Build Integrity (Establecer Integridad)
Herramienta 17. Integridad percibida
• Para sistemas pequeños, equipos simples de desarrollo que mantengan contacto
directo con los clientes, y usen cortos periodos de tiempo en las iteraciones.
• Incluir pruebas de usuario para retroalimentación.
• Lenguaje entendible para los clientes y útil para los desarrolladores en el diseño.
• Para sistemas grandes un desarrollador experto con vasta experiencia en
requerimientos de usuario, que dentro del equipo sea un representante de los
intereses del cliente.
Herramienta 18. Integridad conceptual
• Entender y resolver un requerimiento o problema de software al mismo tiempo (Ej.
desarrollo centrado en pruebas).
• Información previa al inicio y el flujo de información completa en el transcurso del
desarrollo, cuando se haya recabado totalmente.
• Información enviada en pequeños paquetes, en vez de todo a la vez.
• Flujo de información bidireccional.
• Preferencia por la comunicación cara a cara, en vez de documentaria.
18
6. Build Integrity (Establecer Integridad)
Herramienta 19. Integridad percibida
Identificar oportunidades de mejora y simplificación del código escrito para una
funcionalidad.
Herramienta 20. Pruebas
El código escrito para una funcionalidad debe ir acompañado de pruebas de unidad,
funcionales, de integración cuando se unifican sus componentes y de clientes al final del
desarrollo. Éstos asegurarán que el sistema ejecuta las funciones requeridas de forma
esperada, sin errores y como un todo. Las pruebas se diseñan y ejecutan durante todo el
desarrollo, pues son útiles para comunicar que debe hacer una función, recibir
retroalimentación, y como fuente de mejoras y cambios (10).
.
19
7. See the Whole (Verlo todo)
Herramienta 21. Integridad percibida
Enfocarse en medidas que representen logros grupales en lugar de individuales. Si
aplicamos mejoras sólo locales, se afectará la organización del proyecto, y sub optimizará
su desempeño como un todo. Para lograr métricas que evalúen el todo se cuenta con
técnicas como la agregación y las métricas de información (8) .
Herramienta 22. Contratos
Se necesita contratos donde la responsabilidad del riesgo por los cambios sea compartida
por cliente y proveedor, donde ambos se fijen metas de manera unificada y trabajen en
conjunto para conseguir calidad y beneficios según un marco. Los tradicionales contratos
de precio fijo no cumplen con estas características, como si lo hacen sus pares de costo-
objetivo, costo-cronograma y beneficios compartidos (8) (10).
.
20
Conclusiones
Existen muchas metodologías agiles que comparten el
mismo objetivo, pero si solo, lo que usted quiere es
desarrollar sin centrase en la documentación ni en el
análisis, sin obviar el propósito de tener un buen
resultado, la metodología LSD, sería una buena opción.
Siempre a tener en cuenta que al momento de la
elaboración de software es de suma importancia la
satisfacción del usuario final, ya que de eso se trata.
Como hemos podido ver la metodología LSD se centra
en una serie principios que nos ayudaran a tener éxito
en la elaboración de nuestro proyecto de software.
21
Bibliografia
1. LIKER, Jeffrey . The Toyota Way: 14 Management Principles from the World's Greatest
Manufacturer. First edition. s.l. : McGraw-Hill, 2003. 0071392319.
2. CSABA, Patkos. code.tutsplus. From Scrum to Lean. [Online] Enero 23, 2013. [Cited: Octubre 14,
2019.] https://code.tutsplus.com/articles/from-scrum-to-lean--net-29420.
3. Wikipedia, Colaboradores de. Sistema de producción Toyota. [Online] Octubre 10, 2019. [Cited:
Octubre, 16, 2019.]
https://es.wikipedia.org/w/index.php?title=Sistema_de_producci%C3%B3n_Toyota&oldid=120143
500.
4. Mercadotenia, Colaboradores de Tecnologia &. talento2011.weebly. “Lean” – Filosofía esbelta.
[Online] septiembre 29, 2011. [Cited: octubre 15, 2019.]
http://talento2011.weebly.com/uploads/8/3/9/1/8391024/lean_tecmkt.pdf.
5. DIAZ, Jose Ramon. Desarrollo de Software Lean. [Online] febrero 08, 2009. [Cited: octubre 14,
2019.] http://najaraba.blogspot.com/2008/02/desarrollo-software-lean.html.
6. POPPENDIECK , Tom and POPPENDIECK , Mary.
https://leansoftwaredevelopment.wordpress.com. Los 7 principios de Lean. [Online] octubre 31,
2011. [Cited: octubre 15, 2019.]
https://leansoftwaredevelopment.wordpress.com/category/desarrollo-agil/.
7. RODRIGUEZ PEÑA, José Ignacio Gaete. PROPUESTA PARA UN NUEVO ENFOQUE DE APLICACIÓN
ÁGIL CON SCRUM, LSD Y KANBAN . 2016.
8. POPPENDIECK, Tom and POPPENDIECK, Mary. Lean Software: An Agile Toolkit. Primera edición.
s.l. : . Editorial Addison- Wesley, 2003.
9. POPPENDIECK, Tom. documents.scribd. Lean Software Development. [Online] 2003. [Cited:
octubre 15, 2019.] http://documents.scribd.com/docs/1vxr3x2enyvvndb2m4cs.pdf.
10. —. Implementing Lean Software Development From Concept to Cash. Primera edición. s.l. :
Editorial AddisonWesley Professional., 2006.
11. ESPINOZA MESA, Arnaldo. MANUAL PARA ELEGIR UNA METODOLOGÍA DE DESARROLLO DE
SOFTWARE DENTRO DE UN PROYECTO INFORMÁTICO. Piura : s.n., 2013.
22
