UPsobuam

UNIVERSIDAD NACIONAL DE SAN AGUSTÍN DE AREQUIPA
ESCUELA DE POSGRADO
UNIDAD DE POSGRADO DE LA FACULTAD DE INGENIERÍA DE
PRODUCCIÓN Y SERVICIOS
MODERN AGILE COMO PROPUESTA DE MODELO DE DESARROLLO

DE APLICACIONES MÓVILES EMPRESARIALES
Tesis presentada por el bachiller:

Soto Bueno, Alexander Mario
Para optar el Grado Académico de:

Maestro en Ciencias: Ingenierı́a de
Sistemas con mención en Gerencia en
Tecnologı́as de Información
Asesor:
Dr. Beltrán Castañón, César Armando
Arequipa - Perú
2023
Agradecimientos
Agradezco a mis padres de forma muy especial, su sacrificio y dedicación son invalua-
bles.
A mi amada familia que me ha concedido su tiempo y palabras de aliento para poder
cumplir con este objetivo.
De igual forma, agradezco a mi Asesor de Tesis, que gracias a sus consejos y correccio-
nes hoy puedo culminar este trabajo.
A la Universidad Nacional De San Agustı́n De Arequipa, por haberme brindado tantas
oportunidades y enriquecerme en conocimiento.
i
Dedicatoria
Dedico esta tesis en primer lugar a Dios, quien con su gracia me ha permitido dar cada
paso en mi vida, tanto personal y profesional.
A mis padres que siempre me dieron todo su apoyo con el único deseo que cumpla mis
sueños.
En especial a mi esposa, sin su apoyo, inspiración y motivación incondicionales, no
habrı́a sido posible lograr este objetivo.
Y a mis hijos quienes son el motor y la alegrı́a de mi vida.
ii
Resumen
Desarrollar aplicaciones móviles empresariales es un gran desafı́o el cual

no está exento de todos los problemas que conlleva construir software, in-
satisfacción del cliente, errores en las diferentes etapas, incumplimientos,
sobrecostos entre otros. Las metodologı́as ágiles han comprobado ser una
forma efectiva de generar valor ante la incertidumbre de la industria del
software, de ello que se han popularizado, no solamente en el ámbito de
desarrollo de software, sino también para el trabajo en equipo en general.
Pero muchas de las cosas que asumimos de facto, preconceptos, prácticas,

management, certificaciones, coaching, etc. no son realmente ágiles gene-
rando crı́ticas y muchos defensores están buscando mejorar lo propuesto en
el “Manifiesto Ágil”. En ese contexto aparece Modern Agile, propuesta de
Joshua Kerievsky CEO de Industrial Logic, que es una comunidad para per-
sonas interesadas en descubrir formas de obtener mejores resultados. Por tal
motivo en el presente trabajo, utilizaremos el enfoque “Modern Agile” para
proponer un modelo de desarrollo de aplicaciones móviles empresariales.
Nuestros resultados muestran que cada equipo debe libremente encontrar

su propia metodologı́a ágil, que, en lugar de limitarse a rı́gidos marcos de
trabajo, debe operar sobre la base de principios fundamentales que lo guia-
rán a aplicar métodos y prácticas a fin de alcanzar resultados de alto valor
iii
para su negocio.
Donde la agilidad debe ser reconocida, no como la informalidad del software

ni tampoco como una tendencia de moda, sino como un enfoque cientı́fico
que permita guiarnos en la construcción de productos o servicios digitales
orientados a maximizar el valor e impacto en la industria.
Palabras Clave Modern Agile, modelo de desarrollo de aplicaciones móviles,

aplicaciones empresariales, metodologı́as ágiles y lean.
iv Escuela profesional de Ingenierı́a Informática y de Sistemas

Abstract
Developing mobile applications is a great challenge which is not exempt

from all the problems involved in building software, customer dissatisfaction,
errors at different stages, delays, cost overruns and others. Agile methodo-
logies have proven to be an effective way in order to generate value in the
face of the software industry uncertainty, which is why they have become
popular, not only in the software development aspects, but also for team-
work in general.
However, many of the things that we assume de facto, preconceptions, prac-

tices, management, certifications, coaching, etc. They are not really agile,
which generate criticism, on the other hand many defenders are looking
for improving what is proposed in the “Agile Manifesto”. In those contexts,
Modern Agile appears, proposed by Joshua Kerievsky CEO of Industrial
Logic, that is a community for people interested in uncovering better ways
of getting awesome results. For this reason, in this work, we use the “Mo-
dern Agile” approach to propose a model for enterprise mobile applications
developing.
Our results show that each team must find its own agile methodology, which,
instead of limiting itself to rigid frameworks, must operate under fundamen-
tal principles that lead it to apply methods and practices in order to achieve
v
high business value results.
Where agility must be recognized, not as the software informality nor as

a fashion trend, but as a scientific approach that guide us in the digital pro-
ducts or services building for the purpose of maximizing value and impact
in the industry.
Keywords modern agile, mobile application development model, enterprise

applications, agile/lean methodologies.
vi Escuela profesional de Ingenierı́a Informática y de Sistemas

Índice general
Agradecimientos i
Dedicatoria ii
Resumen iii
Abstract v
Lista de tablas xii
Índice de figuras xiv
Lista de Código fuente xviii
Lista de Abreviaturas xix
I. Planteamiento del Problema 1

1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Definición del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2. Objetivos Especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.3. Variables de la Investigación . . . . . . . . . . . . . . . . . . . . 7
1.5. Enfoque de la Investigación . . . . . . . . . . . . . . . . . . . . . . . . 8
vii
ÍNDICE GENERAL
1.6. Población . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7. Tamaño de la Muestra . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.8. Tipo de Muestreo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.9. Técnicas de Investigación . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.10. Instrumentos de Recolección de Datos . . . . . . . . . . . . . . . . . . . 10
1.11. Tipo y Diseño de la Investigación . . . . . . . . . . . . . . . . . . . . . 10
II. Marco Teórico 11

2.1. Definición de Ágil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Desarrollo de Software Ágil . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Metodologı́as Ágiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1. Programación Extrema (Extreme Programming) . . . . . . . . . 13
2.3.2. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3. Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4. Aplicaciones Móviles Empresariales . . . . . . . . . . . . . . . . . . . . 16
2.4.1. Aplicaciones Móviles . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2. Aplicaciones Móviles Empresariales . . . . . . . . . . . . . . . . 16
2.5. Visión Crı́tica de las Metodologı́as Ágiles . . . . . . . . . . . . . . . . . 17
2.5.1. Scrum y Agile no son lo Mismo . . . . . . . . . . . . . . . . . . 17
2.5.2. Inconvenientes con el Enfoque de Sprints . . . . . . . . . . . . . 18
2.5.3. La Velocidad está Matando la Agilidad . . . . . . . . . . . . . . 19
2.5.4. La Obsesión por la Estimación . . . . . . . . . . . . . . . . . . . 20
2.5.5. User Story Points decrecen la Agilidad . . . . . . . . . . . . . . 21
2.6. Modern Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.1. Introducción a Modern Agile . . . . . . . . . . . . . . . . . . . . 24
2.6.2. Principios de Modern Agile . . . . . . . . . . . . . . . . . . . . 25
2.6.3. Modern Agile & El Manifiesto de Desarrollo de Software Ágil . . 32
2.6.4. Métodos y Prácticas de Modern Agile . . . . . . . . . . . . . . . 33
2.6.5. Ejemplos de Modern Agile . . . . . . . . . . . . . . . . . . . . . 42
viii Escuela profesional de Ingenierı́a Informática y de Sistemas

ÍNDICE GENERAL
III.Diagnóstico Situacional 48
3.1. Diagnóstico de Desarrollo de Aplicaciones Móviles en Perú . . . . . . . 48
3.2. Definición de los Problemas a Resolver con la Propuesta . . . . . . . . 52
IV.Propuesta Planteada 54
4.1. Planteamiento de Metodologı́a de Desarrollo de Aplicaciones . . . . . . 54
4.2. Definición del Metaproceso . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.1. Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.2. Despegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.3. Producto Mı́nimo Viable MVP . . . . . . . . . . . . . . . . . . 57
4.2.4. Versiones Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.5. Flujo de Trabajo en Progreso WIP . . . . . . . . . . . . . . . . 60
4.2.6. Priorización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.7. Evaluación de Resultados . . . . . . . . . . . . . . . . . . . . . 64
4.2.8. Retrospectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.9. Definición de Artefactos para Validar Propuesta . . . . . . . . . 65
4.3. Descripción del Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . 67
4.3.1. DondeParqueo App . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.4. Desarrollo del Producto DondeParqueo . . . . . . . . . . . . . . . . . . 68
4.4.1. Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4.2. Despegue o Liftoff . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.4.3. Definición del Flujo de Trabajo . . . . . . . . . . . . . . . . . . 79
4.4.4. Descubrimiento del Producto Mı́nimo Viable – MVP . . . . . . 81
4.4.5. Implementación del MVP . . . . . . . . . . . . . . . . . . . . . 94
4.4.6. Retrospectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.4.7. Comentarios al Terminar Iteración . . . . . . . . . . . . . . . . 126
V. Validación de la Propuesta 127

5.1. Resultados de Medición de Instrumentos de la Propuesta . . . . . . . . 127
Escuela profesional de Ingenierı́a Informática y de Sistemas ix

ÍNDICE GENERAL
5.2. Resultados de Variable Independiente con CVIndepend . . . . . . . . . 127

5.2.1. Errores Durante el Proceso . . . . . . . . . . . . . . . . . . . . . 128
5.2.2. Conocimiento Sobre las Necesidades del Cliente . . . . . . . . . 130
5.2.3. Resultados de Variable Dependiente con CVDepend . . . . . . . 138
VI.Evaluación de la Propuesta 146

6.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
6.2. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.3. Costos e Inversión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
6.4. Beneficios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Conclusiones 153
Recomendaciones 155
Bibliografı́a 157
Glosario de Términos 164
A. Anexos 173
A.1. Historia de la Agilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
A.1.1. Antes de 2001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
A.1.2. Año 2001 - Manifiesto Ágil . . . . . . . . . . . . . . . . . . . . . 174
A.1.3. Después del 2001 . . . . . . . . . . . . . . . . . . . . . . . . . . 176
A.1.4. Agile es Una Mentalidad . . . . . . . . . . . . . . . . . . . . . . 177
A.2. Programación Extrema . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
A.2.1. Reglas de Programación Extrema . . . . . . . . . . . . . . . . . 178
A.2.2. Valores de XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
A.3. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
A.3.1. Pilares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
A.3.2. Valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
x Escuela profesional de Ingenierı́a Informática y de Sistemas

ÍNDICE GENERAL
A.3.3. El Equipo Scrum (Scrum Team) . . . . . . . . . . . . . . . . . . 183

A.3.4. Eventos de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 185
A.3.5. Artefactos de Scrum . . . . . . . . . . . . . . . . . . . . . . . . 189
A.4. Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
A.4.1. ¿Qué es un Sistema Kanban? . . . . . . . . . . . . . . . . . . . 190
A.4.2. Proceso de Adopción . . . . . . . . . . . . . . . . . . . . . . . . 191
A.5. Aplicaciones Móviles Empresariales . . . . . . . . . . . . . . . . . . . . 195
A.5.1. Aplicaciones Móviles . . . . . . . . . . . . . . . . . . . . . . . . 195
A.5.2. Aplicaciones Móviles empresariales . . . . . . . . . . . . . . . . 195
A.5.3. Arquitectura Cliente/Servidor . . . . . . . . . . . . . . . . . . . 197
A.5.4. Alcance del Desarrollo de Aplicaciones Móviles Empresariales . 199
A.5.5. Arquitectura de Software . . . . . . . . . . . . . . . . . . . . . . 200
A.5.6. Arquitectura Frontend . . . . . . . . . . . . . . . . . . . . . . . 207
A.5.7. Arquitectura Backend . . . . . . . . . . . . . . . . . . . . . . . 210
A.5.8. Caracterı́sticas Esenciales de una App Móvil Empresarial . . . . 212
A.5.9. Elección del Stack de Tecnologı́as de Apps Empresariales . . . . 215
A.5.10. Razones Crı́ticas Para Construir Aplicaciones Móviles . . . . . . 222
Escuela profesional de Ingenierı́a Informática y de Sistemas xi

Lista de tablas
2.1. Manifiesto Ágil vs. Principios Modern Agile. . . . . . . . . . . . . . . . 33

2.2. Análisis de la Visión de Jeff Bezos vs. Los Principios Modern Agile . . 43
4.1. Artefactos de Validez para Variables Independientes . . . . . . . . . . . 65

4.2. Artefactos de Validez para Variables Dependientes . . . . . . . . . . . . 66
4.3. Checklist Antes de Planificar Liftoff . . . . . . . . . . . . . . . . . . . . 73
4.4. Historia de Usuario Mostrar Parqueos en Mapa . . . . . . . . . . . . . 86
4.5. Historia de Usuario Mostrar Detalle de Parqueo . . . . . . . . . . . . . 86
4.6. Historia de Usuario Mostrar Ruta a Parqueo . . . . . . . . . . . . . . . 87
4.7. Resumen de Dificultades de los Usuarios al Interactuar con el Mockup . 91
4.8. Resumen de Dificultades de Usuarios al Interactuar con Prototipo Ver-
sión 0.0.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.9. Endpoints de Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.10. Lista de Métodos de la Aplicación . . . . . . . . . . . . . . . . . . . . . 97
4.11. Diccionario de Datos Request Método Parking . . . . . . . . . . . . . . 97
4.12. Diccionario de Datos Response del Método Parking . . . . . . . . . . . 99
4.13. Resumen de Dificultades de Usuarios al Interactuar con App en Produc-
ción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.14. Comparación de IPDD Mockups vs. App en Producción . . . . . . . . . 122
5.1. Recopilación de errores . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
xii
LISTA DE TABLAS
5.2. Preguntas Encuesta CSAT – Conocimiento del Cliente sobre sus Nece-
sidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.3. Resultados CSAT – Conocimiento de las Necesidades del Cliente por Rol 132
5.4. Consolidado de Medición CSAT de Conocimiento de las Necesidades del
Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.5. Resultados de Sobrecostos por Dı́a . . . . . . . . . . . . . . . . . . . . 140
5.6. Resumen de Preguntas CSAT del Producto, CVDepend . . . . . . . . . 142
5.7. Resultados de CSAT CVDepend por Dı́a, Fase y Rol . . . . . . . . . . 142
5.8. Resultados CSAT CVDepend Consolidados por Pregunta y Fase. . . . 144
5.9. Relación Propuesta CSAT de CVIndpend vs. CSAT de CVDepend . . 144
6.1. Costos de Licencias Usadas en Propuesta . . . . . . . . . . . . . . . . . 151
Escuela profesional de Ingenierı́a Informática y de Sistemas xiii

Índice de figuras
2.1. Resumen de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2. Los Cuatro Principios de Modern Agile . . . . . . . . . . . . . . . . . . 25
2.3. Diagrama de Principios, Métodos y Prácticas de modernagile . . . . . . 34
2.4. Modern Agile como Analogı́a con una Función Matemática . . . . . . . 42
3.1. Categorı́as y Pilares del Índice de Competitividad Global . . . . . . . . 50

3.2. Resumen del Desempeño de Competitividad del Perú . . . . . . . . . . 51
4.1. Metaproceso de la Metodologı́a . . . . . . . . . . . . . . . . . . . . . . 55

4.2. Inicio para Establecer el Backbone del User Story Map. . . . . . . . . . 56
4.3. Despegue o Liftoff. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4. Split de Requerimientos de Negocio. . . . . . . . . . . . . . . . . . . . . 58
4.5. Tratamiento Lean de las Tareas. . . . . . . . . . . . . . . . . . . . . . . 59
4.6. Tratamiento Kanban de las Tareas de Desarrollo. . . . . . . . . . . . . 61
4.7. TDD de Aceptación o UI y TDD Unitario. . . . . . . . . . . . . . . . . 62
4.8. Flujo de Desarrollo a través de Pipelines de CI/CD. . . . . . . . . . . . 63
4.9. Backbone o Columna Vertebral del Producto. . . . . . . . . . . . . . . 69
4.10. Fragmento de Mapa Referente a Inscripción de Usuario. . . . . . . . . . 70
4.11. Fragmento de Mapa Referente a Búsqueda de Parqueo. . . . . . . . . . 70
4.12. Fragmento de mapa Referente a Actualización de Espacios. . . . . . . . 71
4.13. Fragmento de Mapa Referente a Empadronamiento de Empresas. . . . 71
4.14. Fragmento de Mapa Referente a la Revisión de Resultados. . . . . . . . 72
xiv
ÍNDICE DE FIGURAS
4.15. Fragmento de Mapa Referente a Facturación. . . . . . . . . . . . . . . . 72

4.16. Diagrama de Lı́mites e Interacciones del Equipo. . . . . . . . . . . . . . 77
4.17. Matriz de Impacto y Probabilidad. . . . . . . . . . . . . . . . . . . . . 78
4.18. Flujo de Trabajo Kanban a Implementar. . . . . . . . . . . . . . . . . . 80
4.19. Clases de Servicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.20. User Story Map para el MVP. . . . . . . . . . . . . . . . . . . . . . . . 82
4.21. Priorización de MVP – Visión Completa. . . . . . . . . . . . . . . . . . 84
4.22. Historias del MVP de Cerca. . . . . . . . . . . . . . . . . . . . . . . . . 85
4.23. Diagrama de Flujo Básico MVP DondeParqueo App. . . . . . . . . . . 88
4.24. Wireframe del MVP para Probar la Hipótesis. . . . . . . . . . . . . . . 89
4.25. Prototipo Mockup del MVP. . . . . . . . . . . . . . . . . . . . . . . . . 90
4.26. Diagrama de Flujo Básico MVP, Versión 0.0.2. . . . . . . . . . . . . . . 92
4.27. Prototipo Wireframe MVP, Versión 0.0.2. . . . . . . . . . . . . . . . . 93
4.28. Tablero Kanban Inicial – Backlog. . . . . . . . . . . . . . . . . . . . . 94
4.29. División de Historias de usuario en Tareas de Implementación. . . . . . 95
4.30. Arquitectura Limpia del App Móvil. . . . . . . . . . . . . . . . . . . . 100
4.31. Capas de Arquitectura del App Móvil Perspectiva Hexagonal . . . . . . 101
4.32. Eje Funcional dentro de Arquitectura Limpia Perspectiva Hexagonal. . 102
4.33. Eje Funcional dentro de Arquitectura Limpia Perspectiva de Dependencia.103
4.34. Esquema de Split de las Funcionalidades. . . . . . . . . . . . . . . . . . 104
4.35. Estructura de Arquitectura en Proyecto Android de App Móvil. . . . . 105
4.36. Dos Ciclos del Desarrollo Iterativo Impulsado por TDD. . . . . . . . . 106
4.37. Pruebas Dentro de Arquitectura de App Móvil. . . . . . . . . . . . . . 107
4.38. Interfaz de Usuario a Probar en ac1.1. . . . . . . . . . . . . . . . . . . 108
4.39. Código Fuente de Test de Aceptación para ac1.1. . . . . . . . . . . . . 109
4.40. Diseño Propuesto durante Implementación bajo TDD, Capa de Presen-
tación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.41. Diseño Propuesto durante Implementación bajo TDD, Capa de Dominio. 112
Escuela profesional de Ingenierı́a Informática y de Sistemas xv

ÍNDICE DE FIGURAS
4.42. Diseño Propuesto durante Implementación Bajo TDD en la Capa de

Datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.43. Diagrama General de Flujos CI/CD de la Aplicación Móvil. . . . . . . 118
4.44. Diagrama de Pasos del Flujo CI de la Aplicación Móvil. . . . . . . . . . 119
4.45. Diagrama de Pasos de CD de la Aplicación Móvil. . . . . . . . . . . . . 120
4.46. Evolución de IPDD para la Funcionalidad de Encontrar Parqueos Cer-
canos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.1. Gráfica de Comportamiento de Errores en el Tiempo. . . . . . . . . . . 129

5.2. Gráfica Comparativa de Errores vs. Tiempo y Fases del Proceso. . . . . 130
5.3. CSAT de Conocimiento de las Necesidades del Cliente por Fase, Rol
Patrocinador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.4. CSAT de Conocimiento de las Necesidades del Cliente por Fase para el
Rol Equipo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.5. CSAT de Conocimiento de las Necesidades del Cliente por Fases, Rol
Empresa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.6. CSAT de Conocimiento de las Necesidades del Cliente por Fases, Rol
Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.7. Evolución de CSAT de Conocimiento de las Necesidades del Cliente por
Fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.8. Evolución de CSAT de Conocimiento de las Necesidades del Cliente por
Dı́a. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.9. Gráfica de Relación Cantidad de Errores y Sobrecostos. . . . . . . . . . 141
5.10. Gráfico de Barras del Comportamiento CSAT CVDepend por Dı́a, Rol
y Fase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.11. Relación Propuesta CVIndepend vs. CVDepend. . . . . . . . . . . . . 145
A.1. Manifiesto por el Desarrollo Ágil de Software 2001. . . . . . . . . . . . 175

A.2. Diagrama de Proyecto de Programación Extrema. . . . . . . . . . . . . 180
xvi Escuela profesional de Ingenierı́a Informática y de Sistemas

ÍNDICE DE FIGURAS
A.3. Diagrama de Construcción de Madurez Kanban. . . . . . . . . . . . . . 194

A.4. Cinco tipos Diferentes de Arquitectura Cliente / Servidor. . . . . . . . 198
A.5. Diagrama Resumen de Clean Architecture. . . . . . . . . . . . . . . . . 202
A.6. Hexagonal Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 208
A.7. Onion Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
A.8. Capas de Tecnologı́a de Aplicaciones Móviles. . . . . . . . . . . . . . . 216
A.9. Diagrama Genérico de Stack de Tecnologı́as de Apps Móviles. . . . . . 219
Escuela profesional de Ingenierı́a Informática y de Sistemas xvii

Lista de Código fuente
4.1. Parking Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

4.2. Parking Response. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3. Una Prueba de Recuperación de Parqueos, GetCloseParkingsTest. . . . 112
4.4. Implementación GetCloseParkings, Capa de Dominio. . . . . . . . . . . 115
xviii
Lista de Abreviaturas
API Application Programming Interface 116, 117
B2C Business to Consumer 68, 75
CD Continuous Deployment xiv, xvi, 40, 63, 118, 120
CDN Content Delivery Network 221, 222
CEO Chief Executive Officer iii, v, 4, 23, 27–30, 38, 43, 45
CI Continuous Integration xiv, xvi, 40, 63, 118, 119
CI/CD Continuous Integration and Continous Deployment xvi, 118, 126, 147, 151
CSAT Customer Satisfaction Score xiii, xvi, 65, 66, 130–138, 141–145, 151, 152
GE General Electric 27
IPDD Índice Promedio de Dolor xii, xvi, 122, 123, 146
ISP Internet Service Provider 39
MVP Minimun Viable Product, se traduce como Producto Mı́nimo Viable. ix, xv, 55,
57, 59, 75, 81–85, 88–90, 92–94, 121, 128, 130, 132, 133, 137, 142, 144, 146, 147,
149
PDD Pain-Driven Design 90, 94
xix
Lista de Abreviaturas
REST Representational State Transfer 210
SDK Software Development Kit 119
TDD Test Driven Development, se traduce como Desarrollo guiado por pruebas. xiv–
xvi, 22, 61, 62, 106, 107, 109–112, 116, 126, 129, 147, 151, 191
UI User Interface xiv, 62, 107, 211, 216
UX User Experience 36, 40, 90, 94, 128, 129, 132, 136, 137, 140, 142, 144, 146
VPN Virtual Private Network 221
WEF El Foro Económico Mundial - The World Economic Forum, por sus siglas en
inglés. 50, 52
WIP Work In Progress ix, 60, 61, 64, 79, 80, 94, 100, 147, 192
XP Extreme Programming x, 177, 180, 181
xx Escuela profesional de Ingenierı́a Informática y de Sistemas

I | Planteamiento del Problema
1.1. Antecedentes
El auge de la transformación digital y la hiperconectividad que vivimos hoy son el

resultado de industrias y disciplinas que hace pocas décadas no existı́an, convirtiendo
a la computación en protagonista y a la vez en herramienta indispensable para el
desarrollo e innovación en todas los mercados y áreas del conocimiento.
Y en especial las aplicaciones móviles han permitido transformar industrias y
modelos de negocio de forma radical como elemento disruptivo. En ese sentido es vital
contar con métodos y herramientas especı́ficas y adecuadas para la gestión y desarrollo
de productos de software de este tipo, que cumplan con las exigencias y desafı́os de la
era del conocimiento.
Del mismo modo, si miramos nuestra realidad en la industria de desarrollo de
aplicaciones móviles empresariales en Perú, nos damos cuenta de que la adopción de
metodologı́as todavı́a es reciente, en muchos casos se adoptan prácticas empı́ricas o
simplemente se siguen las tendencias asumiendo su idoneidad de antemano, sin cuestio-
namientos o mayor estudio, esto sumado a la presión comercial, no permite un análisis
para identificar las oportunidades de mejora.
En este contexto los problemas más frecuentes evidencian una deficiente ingenierı́a
de requerimientos, demoras e insatisfacción del cliente, por ello la importancia que tiene
definir y organizar un marco de trabajo que enfrente estos problemas apoyados en las
mejores prácticas del mercado.
1
1.1. Antecedentes
La ingenierı́a de software se ha ocupado en buena parte de estos problemas con

muchas propuestas metodológicas pasando por el Proceso Unificado de Desarrollo de
Software, las metodologı́as en Cascada, hasta el Manifiesto Ágil como respuesta a las
dificultades de las metodologı́as “formales” para resolver problemas en ambientes cada
vez más cambiantes y dinámicos donde el time to market es crı́tico; en especial métodos
como Scrum, XP, Kanban entre otros han agrupado diversas prácticas valiosas y útiles
para atender la demanda de soluciones que vemos en la actualidad.
A lo largo de los años el movimiento ágil ha crecido desde un pequeño grupo de
pioneros a mediados de la década de 1990 hasta una gran comunidad de expertos y
profesionales en todo el mundo. En el camino algunos fundamentos ágiles se perdieron.
Abrazar el cambio es uno de ellos especialmente cuando se trata de mejorar su proceso
(Kerievsky, 2015a).
Muchos supuestos muy convenientes en su momento requieren una nueva visión
que muchas veces se contradice con su propósito original de ser adaptable, promotor
de cambios y mejoras constantes, esto queda evidenciado en palabras de los propios
autores originales del manifiesto Ágil, Jeffries (2013) dijo, “pude que haya inventado los
puntos, si lo hice, lo siento ahora”, en referencia a los puntos de historia de usuarios de la
metodologı́a Scrum, de la misma manera Highsmith (2011) reconoce que “la velocidad
está matando la agilidad”, cuando aborda el problema de la obsesión por la “velocidad”
sobre la generación real de valor.
Estas crı́ticas han estado presentes desde la popularización de la agilidad, porque
se ha impuesto incluso hasta hoy una falsa agilidad (fake agile). Por ejemplo sobre
la estimación con puntos de usuario tan defendida en ciertas metodologı́as, Ottinger
(2022) resume su artı́culo “Story Points: Why is this so hard?” con la frase “Parece
completamente razonable y, sin embargo, es casi perfectamente incorrecto”. En esa
lı́nea de ideas Holub (2022) explica, en respuesta a adeptos de Scrum, el objetivo
no es “transformarse” o “convertirse en ágil” o “hacer Scrum”, el objetivo es resolver
problemas.
2 Escuela profesional de Ingenierı́a Informática y de Sistemas

CAPÍTULO I. Planteamiento del Problema
Durante la última década, las empresas innovadoras, los lı́deres de opinión de la

industria del software y los pioneros lean/agile han descubierto formas más sencillas,
más sólidas y simplificadas de agilidad. Estos enfoques modernos comparten un foco
en la producción de resultados excepcionales y el crecimiento de una cultura extraor-
dinaria. Hoy en dı́a, tiene mucho más sentido eludir la agilidad anticuada en favor de
los enfoques modernos. (Kerievsky, 2015a)
1.2. Definición del Problema
Existen muchas razones por las cuales fracasan los emprendimientos de aplica-
ciones móviles, como lo resume Azorı́n (2019), la carencia de originalidad en medio de
tantas aplicaciones similares; una segunda causa es la falta de pruebas tanto de códi-
go como de usuario, es muy perjudicial lanzar una aplicación con errores; una tercera
razón es ofrecer una deficiente experiencia de usuario, no es suficiente que la aplica-
ción funcione sino que provea una experiencia agradable al usuario final; la cuarta se
vincula con la poca comprensión del sistema operativo donde se ejecuta la aplicación
que puede provocar pérdida de usuarios; finalmente problemas de comercialización y/o
distribución terminan por limitar de forma importante el éxito de una aplicación.
En consecuencia, es pertinente evaluar la metodologı́a, según el Diccionario de la
Real academia Española and Madrid (2001), metodologı́a es la ciencia del método. Por
tanto, aplicar o diseñar una metodologı́a significa estudiar y definir un modo ordenado
de ejecutar alguna tarea, en este caso desarrollar una aplicación móvil, lo cual conlleva
esencialmente a un autoanálisis, que en experiencia del autor del presente trabajo ocurre
muy pocas veces dentro de los equipos de desarrollo de software.
De otro lado de acuerdo con el Reporte de Competitividad Global elaborado por
Schwab (2019), el Perú descendió del puesto 63 al 65 en 2019, algunos indicadores
como el Pago y Productividad, Crecimiento de Empresas Innovadoras y Empresas que
Adoptan Ideas Disruptivas califican al paı́s en 3.5, 3.6 y 3.3 respectivamente de una
Escuela profesional de Ingenierı́a Informática y de Sistemas 3

1.2. Definición del Problema
puntuación de 1 a 7, evidenciando un largo camino pendiente en la transformación

digital y en consecuencia en la mejora y adopción de mejores metodologı́as en el paı́s.
Si se hace una revisión de los esfuerzos por establecer una metodologı́a de desa-
rrollo de aplicaciones móviles, en su mayorı́a están orientados hacia algún marco de
trabajo ágil en particular, sobre todo los que gozan de una mayor difusión o populari-
dad, partiendo de dogmas o creencias que no necesariamente han demostrado su eficacia
a la hora de construir soluciones digitales con mejores resultados que un enfoque no
ágil.
Esto viene siendo una constante en los esfuerzos por llevar la agilidad a una imple-
mentación concreta porque como lo refiere la Agile Alliance (2015a), una metodologı́a
es un conjunto de convenciones que un equipo se pone de acuerdo con seguir. Por lo
tanto, cada equipo tendrá su propia metodologı́a, sin embargo, muchas “metodologı́as”
buscan imponerse como adecuadas.
La razón de esta situación es una falla de origen cuando se aborda la agilidad al no
entender lo expuesto por Denning (2019), quien explica que la agilidad debe partir de
lo que se denomina Agile Mindset, que se puede traducir como mentalidad ágil, siendo
esta una forma de abordar los problemas desde una perspectiva opuesta por ejemplo
a una mentalidad burocrática, por lo tanto Agile es una mentalidad, descrita por los
cuatro valores del Manifiesto Ágil, definida en sus doce principios y manifestada a
través de un ilimitado número de prácticas. El problema entonces viene cundo se parte
de las prácticas o “metodologı́as” sin pasar por los valores ni principios.
Una vez entendido el problema en la adopción de la agilidad, el presente trabajo
tomará como referencia ModernAgile, propuesta de Joshua Kerievsky (2015b), CEO de
Industrial Logic, que es un esfuerzo por actualizar la agilidad aprovechando la sabidurı́a
de muchas industrias con el interés de descubrir mejores formas de obtener resultados
sobresalientes, está dirigida por principios y es libre de marcos de trabajo.
Con lo anteriormente descrito, y lo que se va a buscar resolver en el presente
trabajo, el problema puede ser descrito de la siguiente forma: ¿Cómo aprovechar Modern

Agile para definir una metodologı́a de desarrollo de aplicaciones móviles empresariales?
1.3. Justificación
El presente trabajo de investigación pretende aportar a aquellas empresas, em-

prendimientos y profesionales que necesitan una referencia metodológica, un marco de
trabajo, que los guie en la difı́cil tarea de desarrollar una aplicación móvil de forma
profesional con el fin de encontrar un mejor equilibrio entre la agilidad comercial y
técnica, en este caso basado en Modern Agile.
Durante su trabajo, el autor como profesional en el desarrollo de aplicaciones
móviles empresariales ha encontrado dificultades y problemas en el proceso, que lo han
llevado a buscar e investigar las mejoras formas de resolverlos y mitigarlas, encontrar
los caminos que mejor funcionen en su práctica real no ha sido una tarea trivial.
El proceso de desarrollo de aplicaciones móviles es especialmente complejo, sobre
todo en ambientes de ambigüedad, presión comercial y de tan diversas aplicaciones
posibles. No es un tema muy abordado de forma profesional ni académica, porque
requiere conocimientos de varias disciplinas y especialidades dentro de la ingenierı́a de
software, se requiere un marco pertinente que aclare el panorama a los profesionales en
este campo.
Una creencia extendida dentro de las empresas y profesionales de software es
que la velocidad es agilidad, lo cual será aclarado en el presente trabajo, donde la
agilidad debe entenderse como generación constante, real y tangible de valor para el
usuario final. El marco propuesto ayuda a guiarnos en ese sentido lo cual deviene en
reducción de costos, mejores retornos de inversión, mayor satisfacción del cliente y más
rentabilidad para todos los involucrados.
Estudios recientes nos ilustran sobre la coyuntura de la gestión de proyectos de
software, el Project Management Institute (2018) concluye que 50 % de los proyectos
no fue terminado a tiempo, 37 % de los proyectos perdieron su presupuesto cuando el

1.3. Justificación
proyecto fracasó, en tanto que una encuesta a cargo de Wellingtone Project Manage-
ment (2017), revela que solo el 37 % de los equipos en el Reino Unido informaron haber
completado los proyectos a tiempo con más frecuencia que los que dijeron que no, esto
sumado a que 46 % de las organizaciones encuestadas a nivel mundial utilizan o han
usado un enfoque ágil o hı́brido en los últimos 12 meses (Project Management Insti-
tute, 2018), y por su parte 85.9 % de 101 592 desarrolladores de software encuestados
en todo el mundo utilizan Agile en su trabajo (Stack Overflow, 2018), muestran una
creciente adopción de enfoques ágiles en el mundo como herramienta para enfrentar
las turbulencias de los mercados de nuestros dı́as y al mismo tiempo un importante
espacio para mejorar y aportar en este campo de estudio, dando relevancia a este tipo
de investigaciones.
El presente trabajo propone un marco de trabajo para desarrollar aplicaciones
móviles empresariales con el fin de enfrentar los principales problemas de su imple-
mentación, deficiencias en la ingenierı́a de requerimientos, demoras e insatisfacción del
cliente. Para la consecución de los objetivos, tomaremos como referencia un caso prácti-
co donde abordar las diferentes etapas y fases de proceso de desarrollo, desde el análisis
y presentación de propuesta técnica hasta el despliegue y distribución del producto fi-
nal, esta última de forma referencial; seguiremos una perspectiva técnica lo cual no
incluirá aspectos comerciales ni contractuales de la problemática.
Por otro lado, contaremos con la guı́a de un asesor de tesis, con amplia experiencia
académica y práctica en investigaciones de post grado, los recursos de cómputo del
tesista, el software empleado será libre en su mayor parte y el tiempo disponible que
permite la finalización de esta investigación.
Para emprender esta tarea, tomamos como referencia la propuesta de Modern
Agile, cuyos principios han demostrado buenos resultados, recoge las mejores expe-
riencias de las empresas más disruptivas de la industria, sobre investigaciones serias y
exitosamente aplicadas en la actualidad.
Vemos que es viable conseguir los objetivos de la propuesta, gracias a toda la

referencia teórica y práctica en la que se sustenta este trabajo, esto sumado a la expe-
riencia del tesista que se aboca a este tipo de proyectos en su labor profesional, permite
contar con casos reales y prácticos para aplicar y recoger el feedback necesario.
1.4. Objetivos
1.4.1. Objetivo General
Definir una modelo de desarrollo de aplicaciones móviles empresariales basado en

Modern Agile.
1.4.2. Objetivos Especı́ficos
Determinar las condiciones para aplicar el modelo de acuerdo con la definición

de los prerrequisitos.
Planificar la estrategia de aplicación del modelo, mediante la definición de las

fases de modelo, determinación de las técnicas de análisis, diseño y propuesta
técnica.
Construir una solución, mediante la propuesta, adoptando las técnicas y métodos

de implementación, despliegue y distribución.
Elaborar lineamientos para afrontar el proceso de evolución del producto
1.4.3. Variables de la Investigación
1.4.3.1. Variable Independiente
Errores durante las diferentes fases del proceso.
Conocimiento del cliente sobre sus necesidades.
Conocimiento del equipo sobre las necesidades del cliente.

1.5. Enfoque de la Investigación
1.4.3.2. Variable Dependiente
Sobre costos y retrasos al finalizar el proyecto.
Indicador 1 : Costo de errores cometidos en cada fase del proceso, a partir de una
lista predefinida.
Satisfacción del cliente con el producto final.
Indicador 2 : Índice de satisfacción del cliente con el producto final.
Satisfacción del cliente con el proceso de desarrollo.
Indicador 3 : Índice de satisfacción del cliente con el proceso de desarrollo.
1.5. Enfoque de la Investigación
De acuerdo con los objetivos trazados, el presente trabajo será elaborado bajo
un planteamiento metodológico cualitativo: El investigador plantea un problema de
estudio delimitado y concreto sobre el fenómeno, aunque en evolución. Sus preguntas
de investigación versan sobre cuestiones especı́ficas (Hernández et al., 2014).
1.6. Población
Proyectos de software sobre aplicaciones móviles empresariales en Perú.
1.7. Tamaño de la Muestra
En mérito a las caracterı́sticas del estudio, tomaremos únicamente un caso como

muestra de estudio, como indican los autores (Hernández et al., 2014, p. 190) “al no
interesar tanto la posibilidad de generalizar los resultados, las muestras no probabilı́s-
ticas o dirigidas son de gran valor, pues logran obtener los casos (personas, objetos,

contextos, situaciones) que interesan al investigador y que llegan a ofrecer una gran
riqueza para la recolección y el análisis de los datos”.
1.8. Tipo de Muestreo
En este caso vendrı́a a ser un muestreo no probabilı́stico, porque “suponen un

procedimiento de selección orientado por las caracterı́sticas de la investigación, más
que por un criterio estadı́stico de generalización” (Hernández et al., 2014, p. 189).
Pasos a seguir en la investigación:
Revisión de marco teórico.
Análisis situación de desarrollo de aplicaciones móviles en Perú.
Delimitación de problemas a resolver con propuesta.
Definición de artefactos para validar propuesta.
Definición del meta proceso de metodologı́a.
Definición preliminar de metodologı́a.
Aplicación iterativa de metodologı́a propuesta sobre un proyecto real.
Revisión de metodologı́a propuesta en cada iteración, con base en artefactos.
Revisión final de resultados.
1.9. Técnicas de Investigación
Sistematizaciones bibliográficas.
Entrevistas.

1.10. Instrumentos de Recolección de Datos
1.10. Instrumentos de Recolección de Datos
Fichas de trabajo bibliográfico.
Cuestionarios.
Cédula de entrevista.
1.11. Tipo y Diseño de la Investigación
Dado que el objetivo del estudio será definir un modelo ágil de desarrollo de
aplicaciones móviles empresariales basado en los principios Modern Agile y su efecto
en la satisfacción del cliente, se recurrirá a un diseño no experimental que se aplicará
de manera transversal descriptiva.
De acuerdo con Hernández et al. (2014, p. 152) la investigación no experimental
“es la que se realiza sin manipular deliberadamente variables. Es decir, se trata de estu-
dios en los que no hacemos variar en forma intencional las variables independientes para
ver su efecto sobre otras variables. Lo que hacemos en la investigación no experimental
es observar fenómenos tal como se dan en su contexto natural, para analizarlos”. Estos
mismos autores señalan que los diseños de investigación transversales “recolectan datos
en un solo momento, en un tiempo único. Su propósito es describir variables y anali-
zar su incidencia e interrelación en un momento dado” (p. 154). y descriptivo porque
tiene “como objetivo indagar la incidencia de las modalidades o niveles de una o más
variables en una población” (p. 155).

II | Marco Teórico
2.1. Definición de Ágil
Ágil del inglés Agile, es la capacidad de crear y responder al cambio. Es una

forma de lidiar con un entorno incierto y turbulento y, en última instancia, tener éxito.
Los autores del Manifiesto Ágil eligieron “Agile” como la etiqueta de toda esta idea
porque esa palabra representaba la adaptabilidad y la respuesta al cambio, que era tan
importante para su enfoque. Se trata realmente de pensar cómo se puede entender lo que
está pasando en el entorno en el que te encuentras hoy, identificar qué incertidumbre
estás enfrentando y descubrir cómo puedes adaptarte a eso a medida que avanzas.
(Agile Alliance, 2015a)
2.2. Desarrollo de Software Ágil
La Agile Alliance define y delimita sobre lo que se considera desarrollo de software

ágil, y lo que no lo es:
El desarrollo ágil de software es más que marcos como Scrum, Programación

Extrema o Desarrollo Dirigido por Funciones (FDD).
El desarrollo ágil de software es más que prácticas, como la programación
en pares, el desarrollo guiado por pruebas, las presentaciones, las sesiones de
planificación y los sprints.
El desarrollo de software ágil es un término general para un conjunto de
11
2.2. Desarrollo de Software Ágil
marcos y prácticas basadas en los valores y principios expresados en el Manifiesto

para el desarrollo de software ágil y los 12 principios que lo respaldan. Cuando
aborda el desarrollo de software de una manera particular, generalmente es
bueno vivir de acuerdo con estos valores y principios y usarlos para ayudar a
determinar las cosas correctas para hacer, dado su contexto particular.
Una cosa que separa a Agile de otros enfoques para el desarrollo de software
es el enfoque en las personas que realizan el trabajo y cómo trabajan juntas. Las
soluciones evolucionan a través de la colaboración entre equipos multifuncionales
autoorganizados que utilizan las prácticas adecuadas para su contexto.
Hay un gran enfoque en la comunidad de desarrollo de software Agile en
la colaboración y el equipo autoorganizado.
Eso no significa que no haya gerentes. Significa que los equipos tienen la
capacidad de descubrir cómo van a abordar las cosas por su cuenta.
Significa que esos equipos son multifuncionales. Esos equipos no tienen
que involucrar roles especı́ficos tanto como cuando reúnes al equipo, te aseguras
de tener todos los conjuntos de habilidades correctos en el equipo.
Todavı́a hay un lugar para los gerentes. Los gerentes se aseguran de que los
miembros del equipo tengan, u obtengan, los conjuntos de habilidades correctos.
Los gerentes proporcionan el entorno que permite que el equipo tenga éxito. La
mayorı́a de los gerentes dan un paso atrás y dejan que su equipo descubra cómo
van a entregar los productos, pero intervienen cuando los equipos lo intentan,
pero no pueden resolver los problemas.
Cuando la mayorı́a de los equipos y organizaciones comienzan a realizar
el desarrollo de software Agile, se centran en las prácticas que ayudan con la
colaboración y la organización del trabajo, lo que es excelente. Sin embargo, otro
conjunto clave de prácticas que no se siguen con tanta frecuencia, pero deben
ser prácticas técnicas especı́ficas que tratan directamente con el desarrollo de
software de una manera que ayude a su equipo a lidiar con la incertidumbre.

CAPÍTULO II. Marco Teórico
Esas prácticas técnicas son esenciales y algo que no debes pasar por alto. (Agile
Alliance, 2015a)
Una reseña histórica de la Agilidad se encuentra en el Anexo A.1.
2.3. Metodologı́as Ágiles
A fin de definir a las metodologı́as ágiles, se toman los conceptos de la Agile

Alliance.
Si Agile es una mentalidad, ¿qué dice eso sobre la idea de las metodologı́as ágiles?
Para responder a esta pregunta, puede resultarle útil tener una definición clara
de la metodologı́a.
Alistair Cockburn sugirió que una metodologı́a es el conjunto de conven-
ciones que un equipo acuerda seguir. Eso significa que cada equipo tendrá su
propia metodologı́a. Que será diferente, ya sea en forma pequeña o grande, de
la metodologı́a de cualquier otro equipo.
Ası́ que las metodologı́as ágiles son las convenciones que un equipo elige
seguir de una manera que sigue los valores y principios ágiles.
Probablemente se piensa que Scrum y XP eran metodologı́as ágiles, sin
embargo, Alistair aplicó el término marco a esos conceptos. Ciertamente, nacie-
ron de la metodologı́a de un solo equipo, pero se convirtieron en marcos cuando
se generalizaron para ser utilizados por otros equipos. Esos marcos ayudan a
informar dónde comienza un equipo con su metodologı́a, pero no deben ser
la metodologı́a del equipo. El equipo siempre necesitará adaptar su uso de un
marco para que se ajuste adecuadamente a su contexto. (Agile Alliance, 2015a)
2.3.1. Programación Extrema (Extreme Programming)
De acuerdo con el autor, Wells (2013). El primer proyecto de Programación Ex-

trema se inició el 6 de marzo de 1996. La Programación Extrema es uno de varios

2.3. Metodologı́as Ágiles
procesos Agile populares. Ha demostrado ser muy exitoso en muchas compañı́as de

todos los tamaños e industrias en todo el mundo.
La programación extrema mejora un proyecto de software de cinco formas esen-
ciales; Comunicación, sencillez, feedback, respeto y coraje. Los programadores extremos
se comunican constantemente con sus clientes y compañeros programadores. Mantienen
su diseño simple y limpio. Reciben comentarios al probar su software desde el primer
dı́a. Entregan el sistema a los clientes lo antes posible e implementan los cambios como
se sugiere, tal como explica Wells (2013).
Un estudio más profundo de la programación extrema se puede encontrar en el
Anexo A.2.
2.3.2. Scrum
Es simple. Es lo opuesto a una gran colección de componentes obligatorios en-

trelazados. Scrum no es una metodologı́a. Scrum implementa el método cientı́fico del
empirismo. Scrum reemplaza un enfoque algorı́tmico programado con uno heurı́stico,
con respeto por las personas y la autoorganización para enfrentar la imprevisibilidad
y resolver problemas complejos. El siguiente gráfico representa a Scrum en acción, tal
como lo describen Ken Schwaber y Jeff Sutherland en su libro Software in 30 Days,
que nos lleva desde la planificación hasta la entrega del software. (Scrum.org., sf)

Figura 2.1
Resumen de Scrum
Nota. Muestra los elementos y artefactos más importantes de Scrum, el Pro-

duct backlog, Sprint planning, el Sprint Backlog, el Scrum Team, Sprint Re-
view y finalmente el incremento. Reproducido de Scrum Framework, de Schwaber
K., 2021, scrum.org (https://scrumorg-website-prod.s3.amazonaws.com/drupal/
inline-images/2021-01/screen_shot_2021-01-10_at_9.14.17_am.png). CC BY-
SA 4.0
Una mayor explicación de Scrum está disponible en el Anexo A.3.
2.3.3. Kanban
Método propuesto por David J. Anderson, como resultado de sus trabajos en

Corbis 2004, basado en un enfoque de teorı́a restricciones e incorporando un Drum-
Buffer-Rope (comparable a un sistema pull kanban).
¿Qué es un Sistema Kanban? Anderson (2010), expone la definición, dado un
número de kanban (o tarjetas) equivalente a la capacidad (acordada) de un sistema
son puestas en circulación. Una tarjeta se asigna a una pieza de trabajo. Cada tarjeta
actúa como un mecanismo de señal. Una nueva pieza de trabajo puede ser iniciada
solo cuando una tarjeta está disponible. Esta nueva tarjeta es adjuntada a una pieza
de trabajo y la sigue a través de flujo del sistema. Cuando no hay más tarjetas libres,

2.4. Aplicaciones Móviles Empresariales
ningún trabajo adicional puede ser iniciado. Cualquier nuevo trabajo debe esperar en
una cola hasta que una tarjeta esté disponible. Cuando algo de trabajo es completado,
una tarjeta es liberada y reciclada. Con una tarjeta ahora libre, una nueva pieza de
trabajo en la cola puede ser iniciada.
Si no hay un lı́mite explı́cito del trabajo en progreso y no hay señalización para
jalar nuevo trabajo a través del sistema, no es un sistema kanban.
La razón para usar un sistema kanban, es limitar el trabajo en progreso de un
equipo a una capacidad establecida y balancear la demanda sobre del equipo contra el
rendimiento de su trabajo liberado, haciendo que pueda alcanzar una paz sostenible.
Más detalles sobre Kanban se pueden revisar en el Anexo A.4.
2.4. Aplicaciones Móviles Empresariales
2.4.1. Aplicaciones Móviles
Una aplicación móvil, más comúnmente conocida como app, es un tipo de soft-
ware de aplicación diseñado para ejecutarse en un dispositivo móvil, como un teléfono
inteligente o una tableta. Las Apps con frecuencia sirven para proporcionar a los usua-
rios servicios similares a los que se accede en las PC. Las aplicaciones son generalmente
pequeñas unidades de software individuales con funciones limitadas. Este uso del soft-
ware de la aplicación fue originalmente popularizado por Apple Inc. y su App Store,
que ofrece miles de aplicaciones para iPhone, iPad e iPod Touch.
Una aplicación móvil también puede conocerse como app, web app, app en lı́nea,
app para iPhone o app para teléfonos inteligentes. (techopedia, 2020)
2.4.2. Aplicaciones Móviles Empresariales
Kony (sf) una compañı́a global especializada en desarrollo de aplicaciones móviles

empresariales las define como, una aplicación móvil que se utiliza en el mundo empresa-

rial para resolver los problemas de una empresa. En general, una aplicación empresarial
es una plataforma de software que es muy grande y compleja. Las aplicaciones móviles
empresariales se crean para combinarse o interactuar con otras aplicaciones móviles em-
presariales que utiliza la empresa. Además, las aplicaciones móviles empresariales están
diseñadas con la intención de implementarse en muchas redes, dispositivos y sistemas
operativos diferentes; sin embargo, aún se desarrollan con capacidades administrativas
de gestión y seguridad.
El Anexo A.5 es un estudio detallado de las aplicaciones móviles, las considera-
ciones y recomendaciones técnicas aplicadas en el presente trabajo.
2.5. Visión Crı́tica de las Metodologı́as Ágiles
La agilidad genuina es enormemente efectiva en la consecución de resultados, el

problema es que, Agile se ha convertido en una compleja maraña de roles y rituales,
marcos de trabajo y herramientas, procesos y certificaciones. Es necesario volver a la
simplicidad (Kerievsky, 2018).
En ese sentido para tener una mejor comprensión y limitar el alcance del análisis
se dará una visión crı́tica a partir de los propios fundamentos y valores de la agili-
dad definidos en el propio manifiesto ágil (Beck et al., 2001), y veremos que muchas
prácticas, prejuicios y presuposiciones contradicen su razón original de ser.
2.5.1. Scrum y Agile no son lo Mismo
Dentro de la industria de desarrollo de software se asocia frecuentemente a Scrum

como la más conocida metodologı́a ágil y esto hace ver a Scrum como si fuera la única
propuesta Ágil.
Una metodologı́a Ágil son las convenciones que un equipo escoge para seguir de
tal forma que estén acorde a los valores y principios Ágiles (Agile Alliance, 2015a).
Por tanto, ni XP ni Scrum son metodologı́as Ágiles, se deben considerar marcos de

trabajo (frameworks) adaptables a cada realidad. En ese orden de ideas, por ejemplo,
luego de revisar la Guı́a de Scrum de sus autores Schwaber and Sutherland (2017) en su
nota final “Los roles, eventos, artefactos y reglas de Scrum son inmutables y, aunque es
posible implementar solo partes de Scrum, el resultado no es Scrum. Scrum solo existe
como un todo y funciona bien como contenedor para otras técnicas, metodologı́as y
prácticas”. Denota un aspecto ciertamente contradictorio la “inmutabilidad” que no
está acorde con los valores Ágiles.
2.5.2. Inconvenientes con el Enfoque de Sprints
Cuando se divide el trabajo en unidades de tiempo fijas timebox, el equipo inicia

su trabajo de forma optimista comprometiéndose a terminar todo el trabajo dentro
del plazo. A medida que el Sprint avanza no está claro si realmente se terminará todo,
es donde comienzan los imprevistos, tareas que por ejemplo deberı́an tomar tres dı́as,
toman seis o siete, ocurren incidentes en producción que golpean el desempeño del
equipo y hacen que sea muy difı́cil alcanzar el compromiso asumido. Lo cual genera
molestias y obliga a los miembros del equipo a “terminar” de la peor forma, ya que están
presionados por completar todas las tareas individuales, esto genera un entregable que
no tiene el valor esperado, este aspecto se agrava aún más a lo largo de muchos Sprints.
(Kerievsky, 2018)
El enfoque basado en Sprints también conlleva otra consecuencia que es forzar al
equipo a encajar cualquier cosa dentro un Sprint, muchas veces el alcance excede la
duración del tiempo y sumando a otros incidentes que puedan ocurrir, evidencia que
dicho enfoque no funciona eficientemente. Es más cuando una historia de usuario no
puede ser terminada en un Sprint, pasa al siguiente y ası́ sucesivamente. Este efecto
atenta contra el objetivo de la Agilidad que es la entrega continua de valor y se asemeja
más un proyecto en Cascada (Kerievsky, 2018).

2.5.3. La Velocidad está Matando la Agilidad
La Agile Alliance (2015b) refiere que al final de cada iteración, el equipo suma
estimaciones de esfuerzo asociadas con historias de usuarios que se completaron durante
esa iteración. Este total se llama velocidad.
Highsmith, Jim consultor ejecutivo de ThoughtWorks y autor de varios libros so-
bre desarrollo de software ágil en un extracto de su artı́culo ¡La Velocidad está matando
la Agilidad! (“Velocity is killing agility!”) explica:
El énfasis excesivo en la velocidad causa problemas debido a su amplio uso como
medida de productividad. El uso adecuado de la velocidad es como una herra-
mienta de calibración, una forma de ayudar a hacer una planificación basada en
la capacidad, como lo describe Kent Beck en “Programación extrema: Abrazar
el cambio”. Las medidas de productividad en general tienen poco sentido en el
trabajo de conocimiento. La velocidad también es una medida seductora porque
es fácil de calcular. Aunque los puntos de la historia por iteración se calculan
sobre la base de caracterı́sticas liberables, la velocidad en su núcleo se trata de
esfuerzo.
Si bien los equipos ágiles intentan centrarse en ofrecer caracterı́sticas de
alto valor, se desvı́an al informar sobre la productividad. Una y otra vez escucho
sobre comentarios de gerentes o propietarios de productos: “Su velocidad cayó
de 24 la última iteración a 21 esta vez, ¿qué pasa? Volvamos a subirlo o subamos
aún más”. En este escenario, la velocidad se ha movido de una herramienta de
calibración útil (¿cuál es nuestra capacidad para la próxima iteración?) A una
herramienta de medición de rendimiento (productividad). Esto significa que dos
cosas se modifican brevemente: la calidad de la experiencia del cliente (cantidad
de caracterı́sticas sobre la experiencia del cliente) y la mejora del motor de
entrega (calidad técnica). (Highsmith, 2011)

2.5.4. La Obsesión por la Estimación
Abordar este tema es crucial en todo proyecto de software, Jeffries, Ron, uno de
los autores del Manifiesto Ágil, detalla conclusiones sobre su experiencia en un artı́culo
algunas ideas importantes fueron:
Los equipos que aplican ideas ágiles casi siempre obtienen alguna mejora. En
relación con Scrum, el enfoque ágil más popular, es aproximadamente un veinte
por ciento mejor que lo que estaban haciendo antes.
A algunos equipos les va mucho mejor, los equipos que están obteniendo
buenos resultados, pero no excelentes comparten algunos elementos comunes en
lo que hacen, que los están frenando.
Estos equipos están demasiado preocupados en:
Completar una cartera de trabajo predefinida.
Entregar todo lo que solicitan en una fecha fija.
Estimar lo que pueden hacer cada dos semanas y cumplir sus promesas.
Mejorar la calidad de sus estimaciones.
Explicar las discrepancias entre estimaciones y reales.
Mejorar su velocidad, su tasa de producción de caracterı́sticas.
En resumen, están frecuentemente preocupados por la estimación y estar a la

altura de sus estimaciones, lo cual es totalmente comprensible.
Entonces pareciera razonable exigirles que los desarrolladores aprendan a
estimar mejor y aprendan a alcanzar sus estimaciones. Serı́a un buen negocio
exigir que vayan más rápido. El único problema es: que está mal. Estas son las
cosas que hacen que un proyecto Agile sea solo un veinte por ciento mejor de lo
que estaba sucediendo antes.
En la mayorı́a de los casos se escriben todos los requisitos al comienzo del
proyecto. Solo hay tres cosas incorrectas en esto: “requisitos”, “el comienzo” y

“todos”. Al principio, se sabe menos sobre el proyecto de lo que se sabrá. Este

es el peor momento posible para tomar decisiones firmes sobre lo se “requiere”.
Cualquiera que haya visto alguna vez una lista de “requisitos” ha visto
algunos elementos que eran muy importantes, y algunos que eran, bueno, no tan
importantes. No es tan importante como 1/100 como las cosas más importantes.
No es tan importante como las malas ideas. Hay una regla muy estricta “80-20”
en el trabajo de listas de requisitos. La mayor parte del valor proviene de un
subconjunto muy pequeño de los llamados requisitos. Ası́ que estas otras cosas
no son “requisitos” en absoluto. Son ideas, y algunas de ellas no son muy buenas.
¿Cómo podrı́an ser todas buenas? Se inventan antes de comenzar el proyecto,
cuando menos se sabe.
Peor aún, cuando se anota “requisitos”, se actúa como si fuera la última
oportunidad de pedir algo. Por lo tanto, pedimos todo lo que podamos pensar,
todo lo que podamos necesitar. Estando bastante seguros de que no se conseguirá
de todos modos, ası́ que se pide mucho y se espera obtener algo aceptable.
Y no obstante se exige a los desarrolladores estimar y comprometer sus
tiempos pese a su poco conocimiento inicial del proyecto finalmente el equipo
establece una fecha, pero ¿Los responsables del negocio aceptan esto?, ¡Por su
puesto que no!, primero porque es solo una “estimación”, segundo se prejuzga que
el equipo sobre estima dejando holguras y tercero no es cuando los responsables
del negocio lo quieren ellos lo quieren antes. (Jeffries, 2013)
2.5.5. User Story Points decrecen la Agilidad
Los puntos de historia o Story Points y los cálculos de velocidad ahora se con-
sideran partes de facto de la Agilidad, legitimadas por libros populares, integradas en
herramientas de planificación, verificadas en certificaciones y ampliamente practicadas
en la industria (Kerievsky, 2012).
No obstante, en propias palabras de Jeffries (2013), quien se atribuye la autorı́a

de la estimación usando puntos de historia de usuario, “Lo sé: Estuve allı́ cuando fueron
inventados. Pude que haya inventado Puntos, si lo hice lo siento ahora”.
Esta práctica pretende oscurecer el aspecto temporal de la estimación para que
de forma comparativa se pueda medir el esfuerzo y la cantidad de trabajo a completar
en cada iteración, sin embargo, ha venido en detrimento de la propia agilidad, como
veremos de acuerdo con las experiencias de Kerievsky (2012) tras varios años entrenan-
do equipos y dirigiendo proyectos de software ha experimentado y profundizado este
aspecto.
Cuando se tiene una velocidad promedio de Puntos por iteración se presenta una
tendencia por parte de los administradores de equipos y responsables de negocio a pedir
que los desarrolladores incrementen la velocidad con la errónea idea de que ası́ elevarán
la productividad del equipo, la consecuencia de ello es que los desarrolladores inflan sus
estimaciones para que aparenten ser más rápidos en términos de cantidad de Puntos
por iteración, esto se ha visto en equipos con amplia experiencia y bien entrenados en
estas técnicas.
Las técnicas como el desarrollo basado en pruebas (TDD por sus siglas en inglés)
y la refactorización son a menudo lo primero que se debe descartar cuando alguien
intenta “hacer su estimación”. Demasiados equipos sacrifican la calidad y enfrentan
una deuda técnica únicamente para hacer o superar sus estimaciones y mantener sus
gráficos de consumo aparentemente en orden.
Kerievsky (2012) también relata problemas de comparación entre equipos por
su velocidad en Puntos, como tendencia errónea porque la velocidad promedio de un
equipo es una medida relativa basada en la propia experiencia del equipo y es incorrecto
usarla como forma de comparar la “productividad” de equipos distintos.
Muchos justifican el uso de puntos de la historia porque dicen que los humanos
no son buenos para estimar usando el tiempo real, porque se está estimando el
tamaño del trabajo, en lugar del tiempo que lleva completarlo. De hecho, los
humanos no son muy buenos para estimar en general, independientemente de

la medida utilizada. Los Puntos simplemente confunden aún más el problema.

Para usarlos, se debe aprender:
Lo que ellos son.
Cómo usarlos.
Las muchas maneras de no usarlos mal.
Una educación tı́pica en Story Points contiene mucha fricción, al principio

confunden e incomodan al usarlos y con frecuencia se compensa traduciendo
constantemente los Puntos a estimaciones de tiempo real.
Los malentendidos y el mal uso de los Puntos generalmente se multipli-
can con el tiempo, especialmente a medida que un proceso escala de equipo a
departamento a empresa, arreglar esos malentendidos y malos usos cuesta tiem-
po y energı́a. Los puntos de historia y los cálculos de velocidad son técnicas
antinaturales que confunden innecesariamente a los equipos al comienzo de su
experiencia ágil. (Kerievsky, 2012)
2.6. Modern Agile
Modern Agile es una comunidad para personas interesadas en descubrir mejores

formas de obtener resultados increı́bles. Aprovecha la sabidurı́a de muchas industrias,
está dirigida por principios y libre de framework. Es la definición de Joshua Kerievsky
(2015b), CEO de Industrial Logic, quien es el principal impulsor de esta comunidad,
un consultor pionero que moderniza el desarrollo de productos para organizaciones de
todo el mundo. A mediados de la década de 1990, estuvo involucrado en una peque-
ña comunidad de practicantes de “métodos ligeros” que experimentaban con mejores
formas de desarrollar software.
Hoy, lidera un esfuerzo por modernizar Agile eliminando prácticas obsoletas y
aprovechando lo mejor de lo que la comunidad de software y otras industrias han
aprendido para lograr resultados asombrosos (Kerievsky, 2016).

2.6. Modern Agile
2.6.1. Introducción a Modern Agile
Kerievsky escribió el artı́culo “An Introduction to Modern Agile” que constituye

una de las definiciones más detalladas de los conceptos de Modern Agile, en ese sentido
el autor incluye su traducción de dicho material en el resto de la introducción:
Agile se está modernizando. Gracias a los pioneros y profesionales de Lean y
Agile, ahora se tienen formas más simples, seguras y rápidas de lograr resulta-
dos asombrosos. Se llama a estos nuevos enfoques “Modern Agile” porque han
evolucionado mucho más allá de los primeros métodos ágiles.
Modern Agile es ultraligero, lo opuesto a la corriente principal de Agile,
que se está ahogando en una maraña hinchada de herramientas empresaria-
les, frameworks de escalamiento y certificados cuestionables que producen más
burocracia que resultados.
Modern Agile no tiene roles, responsabilidades o prácticas ungidas. En
cambio, se define por cuatro principios rectores:

Figura 2.2
Los Cuatro Principios de Modern Agile
Nota. Pretende ser un enfoque de agilidad que parte de principios y está libre de todo
marco de trabajo. Reproducido de Modern Agile, de Kerievsky J., 2015, moderna-
gile.org (https://modernagile.org/img/modernAgileWheel/modern_agile_wheel_
english.svg). CC BY-SA 4.0
Estos cuatro principios aclaran el propósito y guı́an hacia una mejor gestión de
riesgos, una mayor eficiencia de capital, una mayor empatı́a y una reducción del
trabajo pesado.
Luego de estudiar a chefs de tres estrellas Michelin como Massimo Bottura,
empresarios multimillonarios como Gary Vaynerchuk y organizaciones de clase
mundial como Alcoa, Amazon, Google y Etsy, se encuentran estos principios
operando.
Los principios de Modern Agile se establecen como imperativos porque son
vitales para el éxito a largo plazo. (Kerievsky, 2016)
2.6.2. Principios de Modern Agile
Siendo sus cuatro principios el fundamento de Modern Agile sus definiciones se

incluyen como fragmentos de la traducción de “An Introduction to Modern Agile”

2.6. Modern Agile
elaborada por el autor.
2.6.2.1. Hacer que la Gente sea Impresionante (Make People Awesome)
Si bien Modern Agile no dice qué crear, sı́ establece que su propósito es hacer
que la gente sea impresionante. Esta idea está inspirada en los blogs, charlas y
libros de Kathy Sierra.
Sierra (2015) dice que no estamos aquı́ para hacer un gran producto o
una gran compañı́a, sino para hacer que nuestros clientes sean increı́bles en lo
que hacen con nuestros productos o servicios. Eso significa descubrir qué los
está frenando y hacer cambios esenciales para ayudarlos a lograr resultados
increı́bles.
Este consejo puede llevarnos lejos. Amazon ha hecho de “Customer Ob-
session” un principio rector desde 1997. Si se hace que los clientes sean geniales,
tienden a ser promotores naturales de sus productos o servicios. El trabajo o
negocio prosperará si sigue los consejos de Sierra.
Pero ¿qué pasa si usted está empeñado en hacer que los clientes sean increı́-
bles y su personal tenga condiciones de trabajo o relaciones laborales miserables?
Esa no es una receta para el éxito a largo plazo. Para hacer su mejor trabajo
y hacer que los clientes sean geniales, el personal también debe ser increı́ble.
Modern Agile sugiere que nos esforcemos por hacer que todos en nuestro ecosis-
tema sean increı́bles, incluidos aquellos que usan, fabrican, compran, venden o
financian nuestros productos y servicios.
Esa es una tarea difı́cil. De hecho, puede requerir luchar por innovaciones
disruptivas o grandes objetivos peliagudos y audaces. Reunir un equipo y definir
un futuro que tal vez no tenga idea de cómo lograr. Nicholas Negroponte dijo una
vez: “El incrementalismo es el peor enemigo de la innovación”. Hacer mejoras
incrementales es bueno (especialmente si se pueden ofrecer continuamente), pero
las grandes innovaciones a menudo requieren una forma diferente de pensar.

En el libro Smarter, Faster, Better, de Charles Duhigg (2016) describe la

creación de los trenes bala de Japón, que viajaron 120 MPH en 1964. Cuando
Jack Welch (ex CEO de General Electric) escuchó la historia de estos trenes
a principios de la década de 1990, pidió a cada división dentro GE adoptar el
“pensamiento del tren bala” estableciendo objetivos ambiciosos que no tenı́an
idea de cómo lograr. (Kerievsky, 2016)
2.6.2.2. Haga de la seguridad un requisito previo (Make Safety a Prerequisite)
Hacer que la gente sea increı́ble no es posible si la gente no está segura. La

seguridad es una necesidad humana básica y una clave para desbloquear el
alto rendimiento. Modern Agile lo eleva a un requisito previo, un ingrediente
fundamental para el éxito.
El miedo es rampante en muchos equipos. La gente tiene miedo de hacer
cambios, miedo de expresar sus opiniones y miedo de cometer errores. El pro-
blema es que el miedo mata el rendimiento. Si tienes una cultura del miedo,
ninguno de tus procesos o prácticas sofisticadas te ayudará.
Seth Godin dijo: “La gente no teme al fracaso, tiene miedo de la culpa”.
Culpar aumenta la negatividad y no ayuda a nadie. Es por eso por lo que Etsy
tiene una “cultura irreprochable”. Entienden que, en lugar de ser culpa de un
solo individuo o grupo, los errores son generalmente el resultado de problemas
invisibles en el entorno que pueden haber existido durante algún tiempo, pero
sucedieron desencadenados un dı́a por alguien. Su preocupación es aprender sin
culpa de los fracasos y mejorar rápidamente.
Lo mismo es cierto en Google. Una vez, un ingeniero de Google confesó:
“Arruiné una lı́nea de código y nos costó un millón de dólares en ingresos”.
El código en cuestión era parte del software AdWords altamente rentable de
Google. En muchas organizaciones, un error como ese podrı́a conducir a pérdidas
adicionales, como la pérdida del trabajo de uno, una pérdida de confianza o

2.6. Modern Agile
respeto. No en Google.
Como describe Laszlo Bock en su libro Work Rules, el ingeniero que co-
metió el error trabajó para Jeff Huber, vicepresidente sénior de anuncios y apli-
caciones. Jeff crea una cultura que permite a las personas admitir errores de
forma segura y aprender de ellos. Él convoca una sesión de “¿Qué aprendimos?”
En la que el equipo discute errores notables, corrige esos errores y discute qué
aprender de los errores.
Después de llevar a cabo una sesión de este tipo sobre el error de un
millón de dólares del ingeniero, Jeff le preguntó al equipo: “¿Obtuvimos más de
un millón de dólares en aprender de esto?” Cuando el equipo respondió que sı́, la
reunión concluyó y todos volvieron a trabajar con conocimientos más cruciales
que antes. De hecho, esa reunión ahorró más de un millón porque la toma de
riesgos y los nuevos descubrimientos que permiten las culturas seguras para
fracasar no tienen precio.
Otro ejemplo surge en 2012, cuando Charles Duhigg publicó su fantástico
libro The Power of Habit. Duhigg cuenta la historia de Paul O’Neill y el gigante
de aluminio, Alcoa. El Sr. O’Neill se convirtió en CEO de Alcoa en 1986, en un
momento en que la empresa de 100 años estaba en problemas. Los trabajadores
estaban descontentos, la calidad del aluminio era pobre, los sindicatos lucharon
ferozmente con la gestión de Alcoa y la innovación se estancó. El Sr. O’Neill
tuvo una idea inusual para solucionar todos estos problemas: centrarse en la
seguridad de los trabajadores.
El Sr. O’Neill no hizo de la seguridad una prioridad, ya que las prioridades
cambian con frecuencia. En cambio, autorizó a los trabajadores a hacer de la
seguridad un requisito previo. Los cambios fueron inmediatos y asombrosos. A
medida que los trabajadores hicieron cambios, el trabajo se volvió más seguro y
eficiente. La solución de los problemas llevó a los trabajadores a sugerir nuevas
ideas innovadoras y mejorar la calidad. Al hacer que la seguridad de los tra-

bajadores sea un requisito previo, Paul O’Neill habı́a abierto una puerta a la
excelencia.
En los 13 años durante los cuales el Sr. O’Neill fue CEO y mucho después
de su partida en 2000, las acciones de Alcoa tuvieron un desempeño espectacular,
las lesiones en el lugar de trabajo y los dı́as de trabajo perdidos se desplomaron
y los trabajadores y clientes de Alcoa estuvieron mucho más felices que antes.
Hacer que la seguridad sea un requisito previo significa establecer la segu-
ridad antes de realizar un trabajo potencialmente peligroso. Si no se mejora la
seguridad después de cada accidente o uno que casi ocurre, la excelencia será
elusiva. Por lo tanto, después de una falla o un fallo cercano, tomar medidas
para evitar que el problema vuelva a ocurrir.
Hacer que la seguridad sea un requisito previo requiere que las colabora-
ciones, productos y servicios sean seguros. Esforzarse por proteger el tiempo, el
dinero, la salud, la información, la reputación y las relaciones de las personas.
En lugar de decir tópicos corporativos vacı́os, como “Tomamos su seguridad en
serio”, tratar la seguridad como la puerta a la excelencia, una clave esencial para
hacer que la gente sea impresionante. (Kerievsky, 2016)
2.6.2.3. Experimentar y Aprender Rápidamente (Experiment & learn rapidly)
El vuelo propulsado por humanos fue una vez un problema sin resolver. En 1959,
un hombre de negocios rico ofreció una gran recompensa en efectivo a cualquiera
que pudiera pilotar un avión propulsado por humanos alrededor de un recorrido
de ocho kilómetros en una milla. Durante 18 años, nadie lo hizo. Entonces Paul
MacCready entró en el desafı́o. Consideró lo que se habı́a intentado y declaró:
“El problema es que no sabemos cuál es el problema”.
MacCready luego diseñó un proceso mediante el cual podrı́a iterar de ma-
nera segura y rápida sobre el problema del vuelo propulsado por humanos. Él y
su equipo utilizaron tubos de aluminio, Mylar (poliéster) y alambre para produ-

2.6. Modern Agile
cir rápidamente aviones experimentales. Los aviones volaban tan lentamente y

tan cerca del suelo que chocar era seguro y arreglar los aviones era fácil. Mien-
tras que sus competidores tardaron semanas o meses entre vuelos de prueba,
MacCready y el equipo intentaron vuelos, fallaron, aprendieron, se adaptaron y
experimentaron nuevamente en cuestión de horas. Al año de intentar el primer
vuelo propulsado por humanos, él y su equipo tuvieron éxito con el Cóndor
Gossamer.
Paul MacCready es ampliamente considerado como uno de los mejores
ingenieros del siglo XX. Fracasar de forma rápida y segura fue parte integral
de su éxito. Experimentar y aprender rápidamente es un principio rector de
Modern Agile porque nos protege de perder el tiempo y nos ayuda a descubrir
el éxito más rápido.
Hacemos que nuestros experimentos sean “seguros para fallar”, de modo
que no tengamos miedo de realizar más. Un periodista le preguntó una vez a
Jeff Bezos, CEO de Amazon, sobre el Amazon FirePhone, un fracaso total. Sin
perder el ritmo, el Sr. Bezos respondió: “Estamos trabajando en fallas mucho
más grandes en este momento”. El Sr. Bezos dirige Amazon como un fondo de
capital de riesgo, que solo necesita tener éxito en algunas apuestas en su cartera
para pagar fácilmente todos sus fracasos Bezos está orgulloso de que Amazon
sea un lugar seguro para fallar.
Cuando se presentan obstrucciones o no se aprende lo suficiente, se debe
tomar como una señal de que se necesita realizar más experimentos. La velocidad
es clave con este principio. No se espera largos perı́odos de tiempo antes de
saber que algo no está funcionando. Fallar rápido y pasar rápidamente a nuevos
experimentos. Experimentar y aprender rápidamente ayuda a lograr una mejora
continua. (Kerievsky, 2016)

2.6.2.4. Entregar Valor Continuamente (Deliver Value Continously)
¿Cuánto tiempo tarda un nuevo ingeniero en AirBnB para enviar el código de

manera segura a producción? En muchas tiendas, la respuesta serı́a semanas o
meses. La idea general es que los novatos no son seguros para enviar a producción
y necesitan mucha capacitación y tutorı́a antes de realizar su primer despliegue
de producción.
Pero en AirBnB, las nuevas contrataciones envı́an código después de solo
2 dı́as en el trabajo. ¿Cómo es eso posible?
AirBnB valora tanto el despliegue continuo que la integra directamente en
su programa de incorporación. Un mentor asignado a una nueva contratación y
el mentor encuentra un defecto que corregir o una pequeña caracterı́stica que
implementar. En el primer dı́a de trabajo del nuevo empleado, el mentor lo
ayuda a configurar su máquina de trabajo (esto es automático, por lo que no
toma mucho tiempo). Luego, el mentor ayuda al nuevo empleado a comprender
su tarea y luego se sale de su camino.
Esta experiencia le da a cada nuevo empleado la oportunidad de compren-
der el proceso de implementación de AirBnB y los pasos necesarios para obtener
una idea desde la punta de sus dedos hasta la puesta en producción. Si tienen
algún problema, su mentor está allı́ para ayudar.
Esto es posible porque AirBnB realmente se preocupa por entregar valor
continuamente. Invierten en hacer que su canalización de despliegue sea segura
para que a los desarrolladores les resulte fácil entregar valor en manos de los
clientes.
Si no realiza entregas regularmente, retrasa el aprendizaje sobre lo que
deleita a los clientes. Entregar valor no significa necesariamente lanzar un pro-
ducto o caracterı́stica al público en general. A veces puede ser tan simple como
entregar una idea a medias a alguien y recibir rápidamente comentarios.
Desea trabajar de tal manera que el valor fluya constantemente. Si se tiene

2.6. Modern Agile
la tarea de ahorrar dinero a una empresa al no permitir que se sigan ejecutando

instancias no utilizadas de Amazon Web Services, busque la forma más rápida
posible de comenzar a ahorrar dinero ahora, no con un plan de dos meses.
Cualquier cosa valiosa que no se haya entregado no está ayudando a nadie.
En Modern Agile, se hace la pregunta: “¿Cómo se podrı́a entregar los resultados
correctos más rápido?” Para hacerlo, es necesario descubrir incrementos más
pequeños que se puedan implementar de forma segura ahora en lugar de más
adelante. Brindar valor continuamente ayuda a que los clientes estén felices y
seguros (por ejemplo, al liberar rápidamente una corrección de errores para
ellos).
Entregar valor continuamente nos permite experimentar y aprender rápi-
damente. En el desarrollo de software, un canal de despliegue seguro y continuo
reduce el estrés al hacer que la liberación sea un evento automatizado fácil, ca-
si aburrido. Dicha seguridad se produce cuando puede deshacer o terminar de
manera rápida y sencilla despliegues o lanzamientos. (Kerievsky, 2016)
2.6.3. Modern Agile & El Manifiesto de Desarrollo de Software Ágil
Como parte de sus investigaciones, Kerievsky (2016) elabora un análisis compara-

tivo entre Modern Agile y el Manifiesto de Desarrollo de Software Ágil, a fin de entender
por un lado en que aspectos están alineados y en que otros aporta una perspectiva más
amplia e integradora.
Los cuatro principios de Modern Agile se aplican igualmente a muchos esfuerzos,
como la fabricación, los recursos humanos, las ventas, el marketing, la produc-
ción de un espectáculo o la gestión de un restaurante. Mientras que el Manifiesto
para el desarrollo de software ágil se centra exclusivamente en el desarrollo de
software.
Dada la enorme popularidad de las ideas ágiles, es hora de actualizar
nuestro lenguaje para incluir otras áreas de la actividad humana.

En su comentario sobre Modern Agile, Karl Scotland se preguntó cómo

serı́a si las declaraciones de valor del Manifiesto (“Valoramos x o y”) fueran más
estratégicas, como los cuatro principios de Modern Agile. Esto lo llevó a hacer
la siguiente comparación:
Tabla 2.1
Manifiesto Ágil vs. Principios Modern Agile.
Manifiesto para el Desarrollo de Principios Modern Agile

Software Ágil
valoramos...
Colaboración con el cliente sobre Hacer a la Gente Impresionante
negociación contractual
Individuos e interacciones sobre Hacer de la Seguridad un Prerrequisito
procesos y herramientas
Respuesta ante el cambio sobre seguir Experimentar & Aprender Rápidamente
un plan
Software funcionando sobre Entregar Valor Continuamente
documentación extensiva contractual
Nota. Hace una comparación y paralelo entre los cuatro principios de Modern Agile y los
valores del Manifiesto de Desarrollo de Software Ágil. Traducido de An Introduction to Mo-
dern Agile, de Kerievsky, 2016, An Introduction to Modern Agile (https://www.infoq.com/
articles/modern-agile-intro/). Derechos de autor 2016 Kerievsky, Joshua.
Los principios de Modern Agile orientan hacia la definición de estrategias más

claras para el público en general más allá de los profesionales del software.
2.6.4. Métodos y Prácticas de Modern Agile
Modern Agile consta de cuatro principios superpuestos que incluyen una docena
de métodos / prácticas superpuestas (Kerievsky, 2015a):

2.6. Modern Agile
Figura 2.3
Diagrama de Principios, Métodos y Prácticas de modernagile
Nota. si bien Modern Agile está libre de cualquier marco de trabajo, no se limita
solo a los principios, sino que recomienda ciertas prácticas y métodos alineados a sus
cuatro principios y promueve el descubrimiento, recopilación e invención de otros de
acuerdo a cada situación. Adaptado de Modern Agile overlapping principles/practices,
de Kerievsky J., 2015, industriallogic.com (https://www.industriallogic.com/img/
blog/modernAgile.png). CC BY-SA 4.0.
Muchos de los métodos/prácticas en cada uno de los cuatro cı́rculos se super-

ponen con otros cı́rculos. En las descripciones a continuación, Kerievsky (2015a) ha
incluido etiquetas para aclarar esas superposiciones. El autor ha optado por elaborar
una traducción del artı́culo “Modern Agile” a fin de incluir los conceptos necesarios.
Las etiquetas en negrita indican el principio primario al que pertenece un elemento:
2.6.4.1. Hacer Charter al Trabajo
Hacer a la Gente Impresionante, Hacer de la Seguridad un Prerrequisito

Si se quiere crear usuarios increı́bles, se debe definir lo que eso significa. El Char-
tering ágil es una práctica ligera para que las comunidades de productos descubran y
se alineen en torno a una visión clara, misión y resultados comprobables. No es algo
que se hace una vez al comienzo de un proyecto: Chartering es un esfuerzo continuo
(de ahı́ el “ing” en Chartering). Un buen Charter es como una barandilla: impide salirse
de la carretera. Ainsley Nies y Diana Larsen, dos expertas en Charter, describen esta
importante práctica en su libro, Liftoff: Launching Agile Teams & Projects. (Kerievsky,
2015a)
2.6.4.2. Apalancar Lean StartUp
Experimentar & Aprender Rápidamente, Hacer a la Gente Impresionante, Ha-

cer de la seguridad un Prerrequisito
Ya sea que se desarrolle software para una organización grande, una startup pe-
queña o algo intermedio, se harı́a bien en aprovechar la sabidurı́a del clásico de Eric
Ries, The Lean StartUp. En nuestra búsqueda para hacer que los usuarios sean genia-
les, Eric nos ayuda a comprender que la mayorı́a de nosotros estamos “operando en
condiciones de incertidumbre” y aclara cuán inseguro es adivinar lo que los usuarios
necesitan. Sugiere una variedad de formas útiles para descubrir qué construir, incluida
la experimentación rápida y fructı́fera y la validación / invalidación rápida de hipótesis
antes de invertir en código finamente elaborado. Si no está aprendiendo si los usuarios
realmente están usando, beneficiándose y siendo rudos con su software, es probable que
se necesite redefinir su Definición de Listo. Y si se tiene dificultades para escalar Lean
en su empresa, se recomienda estudiar Lean Enterprise: cómo las organizaciones de
alto rendimiento innovan a escala por Jez Humble, Joanne Molesky y Barry O’Reilly.
(Kerievsky, 2015a)
2.6.4.3. Aplicar Lean UX
Experimentar & Aprender Rápidamente, Hacer a la Gente Impresionante

2.6. Modern Agile
Estrechamente relacionado con Lean StartUp está Lean UX, un enfoque rápido,
económico y basado en análisis para descubrir y producir una usabilidad sobresaliente.
Por ejemplo, la técnica Feature Fake (una de las muchas técnicas de Lean UX) de
Laura Klein, una figura destacada en la comunidad de Lean UX. Se puede obtener más
información sobre Lean UX de Jeff Gothelf y Josh Seiden en Lean UX: Applying Lean
Principles to Improve User Experience y de Laura Klein, UX for Lean Startups: Faster,
Smarter User Experience Research and Design. (Kerievsky, 2015a)
2.6.4.4. Colabora & Integra con Frecuencia
Experimentar & Aprender Rápidamente, Hacer de la Seguridad un Prerrequi-

sito, Entregar Valor Continuamente
La mala colaboración e integración dentro de un equipo o entre equipos expone a
las organizaciones a riesgos. Esta es la causa raı́z de muchos problemas en el desarrollo
de software. El trabajo en solitario tiende a producir silos de conocimiento (cuando
solo una persona sabe cómo funciona algo), mayores defectos, resolución de problemas
más débil, más distracciones y menos disciplina (especialmente en torno a escribir bue-
nas pruebas y mejorar el diseño mediante refactorización). El emparejamiento es la
práctica de hacer que dos personas completen el trabajo juntas e intercambien pares
regularmente. Mobbing es un enfoque comunitario para el desarrollo, en el que tres o
más personas trabajan juntas, intercambiando regularmente quién “maneja” el teclado
/ mouse. Tanto el emparejamiento como el Mobbing aumentan la tasa de aprendizaje,
aceleran el flujo de resultados valiosos, reducen las dependencias peligrosas de las ha-
bilidades / conocimientos clave, permiten cambios más fáciles en la tecnologı́a y sacan
lo mejor de las personas. Algunos departamentos también son bastante efectivos al
permitir el trabajo en solitario profundo, seguido rápidamente por la colaboración en
la revisión del código y la integración en código base maestro. (Kerievsky, 2015a)

2.6.4.5. Hacerlo Seguro a Fallos
Hacer de la Seguridad un Prerrequisito, Experimentar & Aprender Rápida-

mente
Si se tiene una cultura del miedo, ninguna de sus prácticas o procesos sofisticados
le ayudarán. Las mejores empresas fomentan una cultura en la que las personas se
sienten seguras para experimentar, fracasar, estar en desacuerdo y ser ellas mismas.
Dave Snowden habla sobre el uso de sondas a prueba de fallas, experimentos a pequeña
escala que lo ayudan a aprender lecciones valiosas en el contexto de un sistema complejo.
Las empresas que aseguran el fracaso son las organizaciones de aprendizaje. Etsy es un
ejemplo brillante. Una de sus nuevas contrataciones hizo caer su sitio web al eliminar
accidentalmente un archivo CSS crı́tico. ¿Qué hicieron? Le dieron al ingeniero su premio
de suéter de tres brazos por descubrir una falla significativa y arreglaron el diseño para
que fuera más resistente. (Kerievsky, 2015a)
2.6.4.6. Probar y Refactorizar
Hacer de la Seguridad un Prerrequisito, Entregar Valor Continuamente

Las pruebas y el diseño son esenciales para la agilidad. Los practicantes de Modern
Agile realizan pruebas exploratorias, pruebas automatizadas, desarrollo dirigido por
pruebas (que es principalmente una actividad de diseño y, en segundo lugar, una acti-
vidad de prueba) y algunas pruebas manuales. Un estudio cuantitativo de comunidades
de Modern Agile capacitadas y entrenadas en pruebas y refactorización por Industrial
Logic encontró que los defectos cayeron en más del 80 %. Al producir comprobacio-
nes confiables, automatizadas y de alta velocidad del comportamiento del software, los
programadores tienen una red de seguridad que les permite trabajar más rápido, con
menos temor de cambiar el código o producir defectos. La refactorización (mejorar el
diseño del código existente sin cambiar el comportamiento) es una práctica crı́tica para
mantener a raya la complejidad del diseño y hacer que el código sea simple y compren-
sible (y, por lo tanto, más fácil de cambiar). La refactorización es la revisión, que en

2.6. Modern Agile
latı́n significa volver a ver (re-videre). Revisamos las cosas a medida que aprendemos
más, descubrimos defectos en nuestro trabajo anterior y nos esforzamos por mejorar el
diseño / legibilidad / simplicidad de nuestro código. Tanto las pruebas como la refac-
torización son esenciales para la velocidad de un equipo y, por lo tanto, son una parte
crı́tica de Modern Agile. Kerievsky (2015a)
2.6.4.7. Respetar & Apreciar a la Gente
Hacer de la Seguridad un Prerrequisito

El respeto sincero (independientemente del rol, la antigüedad, la educación, la
raza o el género) y la apreciación son fundamentales para establecer una cultura de
seguridad. Los Anzeneers respetan a las personas protegiendo su tiempo, dinero, in-
formación, reputación, relaciones y salud. Cuando la aplicación de colaboración, Slack,
envı́a un correo electrónico para decir que le han reembolsado un monto de su cuenta
porque un usuario no accedió a su servicio en todo el mes, demuestra respeto y cuidado.
Paul O’Neill, ex CEO de Alcoa y secretario del Tesoro de los EE. UU., Dijo que para
que las organizaciones alcancen la excelencia habitual, deben tener una cultura en la
que todos respeten y aprecien a las personas todos los dı́as. En Industrial Logic, se
utiliza DueProps para apreciar regularmente a las personas. (Kerievsky, 2015a)
2.6.4.8. Conducir Retrospectivas sin Culpa
Hacer de la Seguridad un Prerrequisito, Experimentar & Aprender Rápida-

mente
Seth Godin dijo una vez: ”La gente no tiene miedo al fracaso, tiene miedo de la
culpa”. En el libro clásico de 2001 de Norm Kerth, Project Retrospectives: A Handbook
for Team Reviews, observó que Üno de los temores más obvios que la gente tiene al
intentar una retrospectiva es que el ritual se convertirá en una sesión de queja negativa,
intercalada con la culpa y la contra-culpa”. Por lo tanto, Norm definió su ahora famosa
Directiva principal de retrospectiva, que habitualmente se lee antes de una retrospecti-

va: “independientemente de lo que descubramos, entendemos y realmente creemos que

todos hicieron el mejor trabajo que pudieron, dado lo que sabı́an en ese momento, sus
habilidades y habilidades, los recursos disponibles y la situación actual”. Esta directi-
va establece retrospectivas para ser lugares seguros enfocados en el aprendizaje. John
Allspaw de Etsy escribe sobre esto en Blameless Postmortems and a Just Culture. Y
Esther Derby y Diana Larsen tienen un excelente libro llamado Agile Retrospectives:
Making Good Teams Great. (Kerievsky, 2015a)
2.6.4.9. Foco en Flujo
Entregar Valor Continuamente

Modern Agile prefiere el flujo continuo sobre el trabajo en cuadros de tiempo (por
ejemplo, sprints o iteraciones). Kanban permite un flujo continuo. Usando un tablero
kanban, los equipos visualizan su trabajo en un tablero, realizan trabajos importantes
a través de columnas, limitan el trabajo en proceso, soportan clases de servicio (por
ejemplo, trabajo urgente o normal), visualizan y eliminan cuellos de botella y hacen
fluir valor para los usuarios en producción. No pasan tiempo tratando de predecir
cuánto trabajo se puede hacer durante un perı́odo de tiempo, contabilizando el número
exacto de historias o tratando de verse bien publicando un atractivo burn-down chart o
burn-up chart. Esta es una planificación ágil simplificada. David J Anderson lo describe
maravillosamente en su libro fundamental, Kanban: Successful Evolutionary Change for
Your Technology Business. (Kerievsky, 2015a)
2.6.4.10. Desplegar & Liberar Continuamente
Entregar Valor Continuamente, Hacer de la Seguridad un Prerrequisito

Kent Beck publicó un impresionante video de Timothy Fitz titulado “Haciendo
lo imposible 50 veces al dı́a”. (Por desgracia, un ISP desafortunado perdió el increı́ble
video de Timothy, pero escribió un blog al respecto). Timothy describió cómo IMVU
(el lugar de nacimiento de Lean StartUp) llevó la práctica de Integración Continua

2.6. Modern Agile
(CI por sus siglas en inglés) mucho más allá de lo que los primeros agilistas habı́an
concebido al desplegarse de manera segura en producción muchas veces al dı́a. El dial
de CI habı́a sido girado a 11 (expresa que excede lo conseguido hasta el momento en
CI). El Despliegue Continuo (CD) potencia la experimentación temprana y rápida en
producción (por ejemplo, A/B testing) y le permite entregar de manera rápida y segura
lo que más necesitan los usuarios lo más rápido posible. Es una de las prácticas preferi-
das de influencia lean porque reduce drásticamente el ciclo “Concept to Cash”. Timothy
Fitz fue autor de un curso de eLearning en CD con Industrial Logic y actualmente está
escribiendo un libro sobre esta práctica Modern Agile. Jez Humble y David Farley son
expertos profundos en la práctica y autores de Continuous Delivery: Reliable Software
Releases through Build, Test, and Deployment Automation. (Kerievsky, 2015a)
2.6.4.11. Formar Comunidades de Producto
Entregar Valor Continuamente, Hacer de la Seguridad un Prerrequisito

Sin las personas adecuadas, no se podrá crear software que haga que los usuarios
sean increı́bles. Las personas adecuadas forman su comunidad de productos. En pala-
bras de David Schmaltz, una comunidad de productos es “una población de personas
que afectan un producto o pueden verse afectadas por un producto”. Schmaltz observa
que esa comunidad SIEMPRE es más grande de lo que se piensa y que el problema
principal que enfrenta la mayorı́a de los esfuerzos de productos es la “falta de concien-
cia de su propia comunidad” (se tradujo de community-ness que da una la idea del
hecho mismo de ser una comunidad). Una comunidad de productos no está separada
en equipos frontend, backend, middleware y UX, cada uno con su propio backlog. Una
comunidad de productos es completa (full stack ), lista para evolucionar una solución
primitiva en una oferta sofisticada que hace que los usuarios sean increı́bles y ayuda a la
organización a tener éxito. Formar una comunidad de productos ayuda a las personas a
tomar conciencia de quién hace qué y cómo son vitales para ayudar a lograr resultados
clave. La definición y el refinamiento de su comunidad de productos a menudo ocurre

durante el Chartering. (Kerievsky, 2015a)
2.6.4.12. Evolucionar Soluciones
Entregar Valor Continuamente, Hacer de la Seguridad un Prerrequisito, Expe-

rimentar & Aprender Rápidamente
Para desarrollar soluciones rápidamente, debemos organizar a las personas y los
equipos, planificar qué construir, colaborar, integrar, desarrollar y lanzar. Los departa-
mentos Modern Agile ponen productos o caracterı́sticas delante de los usuarios pronta-
mente para aprender rápidamente de los comentarios. El diseño evolutivo es clave para
dicho aprendizaje, ası́ como una de las mejores formas de hacer fluir valor rápidamen-
te a los usuarios. También es una forma extremadamente útil de descubrir y corregir
los riesgos de colaboración e integración dentro o entre comunidades de productos.
(Kerievsky, 2015a)
2.6.4.13. Reflexión sobre el Futuro de la Agilidad
De acuerdo a la perspectiva de Kerievsky, es importante entender la necesidad

de evolucionar los conceptos de Agilidad, en ese orden de ideas explica.
Mientras que Agile se está Modernizando, los principales usuarios de Agile en
la industria del software todavı́a están siendo alimentados por un proceso lento,
estrangulado por herramientas, marcos y certificaciones excesivamente burocrá-
ticas.
Los jóvenes ahora piensan que Agile es para personas mayores. La gente
de productos piensa que Agile tiene que ver con puntos de historia y velocidad,
no con las necesidades del usuario final. Los programadores que alguna vez les
gustaron Agile lo han abandonado por Software Craftsmanship. Los diseñadores
prefieren Design Thinking. Los emprendedores e intraemprendedores prefieren
Lean StartUp.
Mientras tanto, la Compleja Industria Ágil (que incluye vendedores de he-

2.6. Modern Agile
rramientas, personal de ventas y marketing, consultores, grupos de certificación,

entrenadores certificados, etc.) se ven desafiados por los cambios en Agile, ya que
esos cambios requieren la actualización de objetivos de aprendizaje, materiales
de capacitación, exámenes, herramientas, web sitios y más. Si bien podemos en-
tender su enfoque en la monetización, no tenemos que dejar que se interponga
en el camino de la modernización.
Es hora de enviar nuestros procesos y prácticas distinguidas, históricamen-
te importantes, pero ahora anticuadas a una jubilación honorable. Es hora de
devolver a Agile una forma ligera y alegre de ayudar a las personas a lograr
resultados increı́bles. Es hora de Modern Agile. (Kerievsky, 2016)
2.6.5. Ejemplos de Modern Agile
Los principios de Modern Agile surgen como una “factorización” de las empresas
y organizaciones más exitosas de diversas industrias, busca explicar aquellos principios
comunes que hacen la diferencia en la gestión y logro de resultados.
Figura 2.4
Modern Agile como Analogı́a con una Función Matemática
Nota. De acuerdo a las observaciones de Joshua Kerievsky los resultados de clase mun-
dial en diferentes campos e industrias tienen en común la presencia de los principios
Modern Agile junto a sus propias particularidades. Adaptado de Media Kit, Kerievsky
J., 2015, modernagile.org (https://modernagile.org/img/mediaKit.svg). CC BY-
SA 4.0.
En ese orden de ideas el presente trabajo recopila algunos ejemplos de aplicación

cuyas organizaciones no necesariamente se denominan Modern Agile.
2.6.5.1. Caso: Amazon
Es una de las empresas de comercio electrónico más exitosas, al realizar un análisis

de sus fortalezas y valores encontramos los cuatro principios de Modern Agile, por
ejemplo, al revisar la carta que envió su CEO Jeff Bezos (2016) a todas las partes
interesadas de su compañı́a, podemos resaltar: ver Tabla 2.2
Tabla 2.2
Análisis de la Visión de Jeff Bezos vs. Los Principios Modern Agile
Declaración de Jeff Bezos Principio Modern Agile

Obsesión por el cliente en lugar de Hacer a la Gente Impresionante
obsesión por la competencia
Usa la frase “No estoy de acuerdo y me Hacer de la Seguridad un Prerrequisito
comprometo” (apoyar a colaboradores)
Experimente con paciencia, acepte los Experimentar & Aprender Rápidamente
fracasos, siembre semillas, proteja los
retoños y duplique cuando vea al cliente
deleitarse
Tienes que de alguna manera tomar Entregar Valor Continuamente
decisiones de alta calidad y velocidad
Nota. Inspirada en un análisis similar de una recopilación de las afirmaciones de Jeff Bezos,
que evidencian la presencia de los cuatro principios Modern Agile en Amazon, como parte
de su cultura y visión estratégica. Recuperado de Smart organizations scale principles, de
Kerievsky, 2017, Agile Prague Conference: Agile Prague Conference (https://agileprague.
com/slides/ap2017/modernAgilePrague2017.pdf). derechos de autor 2016 por Kerievsky,
Joshua
Todos los productos y servicios de Amazon son encaminados por esta visión que
los ha llevado a conseguir resultados extraordinarios.
Es la compañı́a que alcanzó $ 100 mil millones de ventas anuales más rápido, y
su servicio de software en la nube Amazon Web Services, alcanzó los $ 10 mil millones
en ventas anuales más rápido que amazon.com (Bezos, 2016).

2.6. Modern Agile
2.6.5.2. Caso: Industrial Logic
Empresa especializada en consultorı́a en metodologı́as Ágiles y creadores de Mo-

dern Agile (Industrial Logic, 2022), podemos analizar su caso bajos dos perspectivas:
a Software Desarrollado por Industrial Logic. Uno de sus servicios es su platafor-

ma de eLearning “Agile eLearning”, fue desarrollada por su equipo de software
bajo los principios de Modern Agile y ha tenido gran éxito como herramienta
para el entrenamiento de muchas empresas en todo el mundo con resultados so-
bresalientes (Industrial Logic, sf).
b Éxito de sus clientes. Industrial Logic ha documentado sus casos de éxito más
representativos citamos algunos de sus clientes:
Ford
Google
Cisco
Nokia
American Airlines
Nielsen
HP
Sciex
GE
Roche
Todos ellos vienen operando a la fecha del estudio y refieren resultados exitosos
de los servicios y herrameientas de Industrial Logic (2022).
Ası́ mismo cabe destacar que las empresas que son entrenadas por Industrial
Logic, también se benefician de practicar los cuatro principios y los métodos propuestos
en sus propios negocios adaptándolos a sus propias realidades.

2.6.5.3. Caso: Microsoft bajo Satya Nadella
En febrero 2014 Microsoft marcó un hito importante en su historia, con la desig-

nación de Satya Nadella como su nuevo CEO (Microsoft, sf), que ha significado una
nueva era para su compañı́a y la ha llevado a recuperarse y consolidar su presencia
como una de las grandes tecnólogicas globales bajo su gestión.
En ese contexto al autor recopila algunas referencias que ayudan a explicar el
impacto de las estrategias y visión que Microsoft ha venido concretando durante la
gestión de Nadella y que se encuentran alineadas con los principios Modern Agile:
(a) Principio: Haz que las Personas sean Geniales. Durante sus primeras comunica-
ciones como CEO de Microsoft, Nadella redactó un correo electrónico dirigido a
todos los empleados de la compañı́a donde comenta sobre su visión, “Microsoft es
la empresa que ofrece la plataforma y las herramientas de productividad para el
mundo, que prioriza la movilidad y la nube. Vamos a reinventar la productividad
para capacitar a todas las personas y organizaciones del planeta para que puedan
hacer más y conseguir más” (Nadella, 2017, p. 84).
Es en esta visión que se expresa que el propósito de la tecnologı́a de Microsoft es

ayudar a las personas y organizaciones a mejorar su productividad más allá del
tipo de interfaz que usen (movilidad) soportado por sus plataformas de nube.
(b) Principio: Haz de la Seguridad un Prerrequisito. “En el mundo digital de hoy la

confianza lo es todo” (Nadella, 2017, p. 196), esta frase condensa la importancia
de la confianza en la construcción de soluciones digitales para Microsoft, es una
conclusión de (Nadella, 2017, p. 195) en referencia a la “ecuación de la confianza”
que propone.
E + V C + SF = C/t
E: Empatı́a

2.6. Modern Agile
VC: Valores compartidos
SF: Seguridad y fiabilidad
C/t: confianza con el tiempo.
Donde la seguridad es un prerrequisito necesario y tal como detalla“La confianza a

su vez permite a la gente y las organizaciones tener la seguridad para experimentar
y expresarse” (Nadella, 2017, p. 196).
(c) Principio: Experimenta y aprende rápido. Que se puede evidenciar en una de

las prácticas introducidas en Microsoft para la construcción de su buscador Bing,
donde el diseño moderno tiene que ver con productos online que se actualizan con
una continua experimentación. Los diseñadores ofrecen páginas web en bandadas,
es decir que se ofrece una antigua versión a un grupo de usuarios mientras que
se ofrece otra nueva a otros que aún no ha sido probada, la puntación define la
más eficiente. (Nadella, 2017, p. 52)
Otra de las medidas que adoptó la gestión de Nadella para estimular un cambio
hacia una cultura de aprendizaje en Microsoft fue crear una hackatón anual con
el fin de establecer conexiones, aprendizaje y colaboración, y se ha convertido en
una tradición para superar limitaciones y resolver problemas difı́ciles o aprovechar
oportunidades de forma creativa (Nadella, 2017, p. 109, 110).
De este tipo de prácticas han surgido importantes aportes introducidos en los

productos de Microsoft (Nadella, 2017, p. 110 - 116) como mejoras en la accesi-
bilidad para personas con dislexia, innovaciones en beneficio de la comprensión
lectora, algoritmos de captura de imágenes en movimiento, etc. Y en definitiva
su gran posicionamiento como uno de los lı́deres de la computación en la nube.
(d) Principio: Entrega valor continuamente. Cuando (Nadella, 2017, p. 54) buscaba
llegar a acuerdos con las principales empresas tecnológicas para promocionar su
emergente motor de búsqueda, querı́a saber más sobre el modo que diseñaban

sus productos para mantener la frescura. Descubrió que la clave era la “agilidad,
agilidad, agilidad”.
Tenia que imprimir velocidad presteza y prontitud para conseguir que la expe-
riencia del consumidor fuera correcta, no solo una vez, sino cada dı́a. Establecer
constantes objetivos a corto plazo cumplirlos, y escribir código con un ritmo más
moderno y rápido (Nadella, 2017, p. 54).
Estrategı́as de este tipo han sido adoptadas ya desde hace varios años en Micro-
soft y le han permitido construir productos y plataformas de alta demanda con
resultados sobresalientes a nivel global, expresan lo importante que entregar valor
continuamente.
Como se ha podido entender, los principos propuestos en Modern Agile se pueden

extraer de muchas de las medidas y estrategias que le han dado resultados importantes
a Microsoft durante la influencia de Nadella.

III | Diagnóstico Situacional
3.1. Diagnóstico de Desarrollo de Aplicaciones Móviles en
Perú
Un análisis de la situación del desarrollo de aplicaciones móviles en el Perú no

puede estar exento de revisar la coyuntura de los últimos años de la industria del
software en el paı́s, dada su relevancia en la actualidad.
La expectativa de ventas del mercado global de software es de $ 500 mil millones
para el 2022, en el caso peruano durante el 2017 el 60 % de la facturación estuvo copada
por sólo cinco empresas que en orden son IBM, Adexus, SAP, Oracle y GMD, enfocadas
principalmente en la demanda local con un nivel muy bajo en exportación de servicios,
según un reporte del diario El Comercio (Lumbreras, 2012).
Respecto a la oferta de profesionales de la ingenierı́a de Software para el 2018
sin contar con las decenas de emprendimientos que se vienen multiplicando, al menos
cinco fábricas grandes de capital peruano y otros cinco jugadores globales (como IMB
o la hindú Tata Consulting), ya contaban con los servicios de más 2,500 ingenieros
(Mendoza, 2018).
El último informe de PageGroup señala que la búsqueda de perfiles tecnológicos
en el Perú se ha incrementado entre un 50 % y 60 % y según un informe de Cisco en
2020, existe un déficit de más de 17 mil profesionales tecnológicos (Redacción Gestión,
2022).
Si revisamos la adopción de nuevas tecnologı́as en el Perú las expectativas son
48
CAPÍTULO III. Diagnóstico Situacional
buenas por ejemplo en el 2017 el mercado de servicios de nube pública en nuestro paı́s
alcanzó US$ 98.7 millones, para el 2020, alcanzará un valor de US$ 273.89 millones,
según International Data Corporation (IDC) (Ochoa, 2019).
Respecto al papel del estado como promotor y facilitador de la innovación y
adopción tecnológica su apoyo es todavı́a incipiente comparado al de la región, donde los
paı́ses vecinos destinan alrededor del 1 % en innovación, el Perú está todavı́a lejos según
refiere el Ministerio de la producción (El Peruano, 2019). Cuyo objetivo es duplicar el
número de proyectos innovación cada año para al 2022 y llegar al 1 % de inversión en
innovación.
En el caso que nos ocupa de las aplicaciones móviles, los sectores que dinami-
zan la demanda por soluciones digitales son principalmente retail, consumo masivo,
finanzas entre otros. El desarrollo de aplicaciones móviles crece a ritmo de 50 % anual
y representará un mercado cercano a los S/ 50 millones el 2019, estimó la consultora
Perú Apps (Cruzado, 2018).
En los dos últimos años el desarrollo de webs y aplicativos en el paı́s ha sido
exponencial, con incrementos entre 200 % y 250 %, estima Diego Dueñas, fundador
de Gózzalo, Pero, la pandemia ha propulsado aún más estos emprendimientos, espe-
cialmente, los vinculados al comercio electrónico como retail, proyectos de tecnologı́a;
servicios logı́sticos (reparto y almacén); asesorı́as contables, consumo masivo, gastrono-
mı́a (delivery), empresas de taxi; marketplaces, pasarelas de pago y al rubro de belleza,
entre los principales. (Salas, 2020)
Para realizar un análisis de la situación del desarrollo y madurez de este sector
podemos hacerlo a través de los resultados del Reporte Global de Competitividad 2019
Schwab (2019), como medición exhaustiva y comparativa de cuán competitiva es una
economı́a de cara a la realidad global, este reporte busca responder a los desafı́os del
cambio tecnológico y la 4o Revolución Industrial, a través de 12 Pilares de la compe-
titividad agrupados en 4 categorı́as: Entorno habilitante, Capital humano, Mercados
y Ecosistema de Innovación. El Centro de Desarrollo Industrial: CDI (2018) hace un

3.1. Diagnóstico de Desarrollo de Aplicaciones Móviles en Perú
resumen del reporte y resalta que el WEF (El Foro Económico Mundial - The World
Economic Forum, por sus siglas en inglés.) define que una economı́a exitosa en la 4a
Revolución Industrial debe ser ágil, resiliente, centrada en el ser humano e innovadora.
Perú ocupa la posición 65 dos por debajo del año anterior, entre 140 economı́as, el 4o
lugar en América de Sur y 6o en Latinoamérica y el Caribe. La principal fortaleza del
Perú es la Estabilidad Macroeconómica, se mantienen las principales debilidades en
indicadores de los pilares: Instituciones, Infraestructura, Adopción de Tecnologı́as de
la Información y Comunicación y Capacidad de innovación.
Para el análisis en este trabajo extraeremos los indicadores de mayor relevancia
para la tecnologı́a, innovación y productividad.
Figura 3.1
Categorı́as y Pilares del Índice de Competitividad Global
Nota. Estas categorı́as han servido de referencia durante el diagnóstico del presente
trabajo, ya que permiten hacer un estudio comparativo de las economı́as de diferentes
paı́ses incluido el Perú, interesan sobre todo en el estudio, los pilares 1, 3, 6, 7, 10,
11 y 12. Reproducido de The Global Competitiveness Index 4.0 2019, Schwab y World
Economic Forum, 2019, The Global Competitiveness Report 2019 (p. 18).

Se consigna también un resumen de los resultados del Perú en el ranking.
Figura 3.2
Resumen del Desempeño de Competitividad del Perú
Nota. El detalle de los pilares y su puntuación para el Perú. Reproducido de The Global
Competitiveness Index 4.0 2019, Schwab y World Economic Forum, 2019, The Global
Competitiveness Report 2019 (p. 474).
Dentro de la categorı́a Capital Humano se tiene el pilar 6: Habilidades donde La

facilidad para encontrar empleados calificados tiene un resultado de 3.6 (ı́ndice de 1
a 7) lo cual expresa que existe gran dificultad en las empresas y organizaciones para
contar con profesionales calificados.
De otro lado la categorı́a Ecosistema de Innovación contempla el pilar 11: Dina-
mismo Empresarial, el cual expresa una alta dificultad para iniciar negocios, a conse-
cuencia de un crecimiento de compañı́as innovadoras de 3.6, ası́ mismo compañı́as que
abrazan ideas innovadoras con un resultado de 3 (de 1 a 7).
A su vez referente a la Capacidad de Innovación el Perú se ubica en el puesto 90
de 140 paı́ses, En aplicación de patentes puesto 85 y en solicitud de marcas puesto 64.
(Schwab, 2019)
Todos estos resultados reflejan la realidad de la industria de tecnologı́a en el Perú

3.2. Definición de los Problemas a Resolver con la Propuesta
que evidentemente influye en el desarrollo de aplicaciones móviles, y demuestran que la

adopción de métodos y técnicas de clase mundial todavı́a están en proceso incipiente,
en lı́nea con lo indicado por el WEF que en próximos años crecerán en importancia el
capital humano, la agilidad, la resiliencia y la innovación como elementos clave para
incrementar la productividad y elevar la competitividad. Finalmente, la existencia de
un nexo causal entre la productividad y el crecimiento a largo plazo.
3.2. Definición de los Problemas a Resolver con la Pro-
puesta
En el Capı́tulo I hemos definido como objetivo encontrar la definición de un

Modelo de Desarrollo de Aplicaciones Móviles Empresariales basada en Modern Agile,
para ello es importante establecer qué aspectos hacen que produzca una metodologı́a
adecuada, se proponen entonces tres aspectos que se deben abordar:
Errores durante las diferentes fases del proceso.
Conocimiento del cliente sobre sus necesidades.
Conocimiento del equipo sobre las necesidades del cliente.
Los mismos que vienen a ser las variables independientes, y al mismo tiempo
constituyen los problemas a enfrentar en el presente trabajo, el grado de efectividad en
resolverlos o mitigar sus riesgos evidenciará la efectividad de la metodologı́a.
En ese sentido el Capı́tulo II, permite tener un contexto y visión más amplia de
dos aspectos fundamentales en esta investigación, primeramente, conocer la Agilidad
como repuesta a los grandes problemas del desarrollo de software, seguidamente aborda
los conceptos más importantes de las Aplicaciones Móviles Empresariales.
En consecuencia, continua con una crı́tica a la Agilidad para entender que la
adopción de metodologı́as ágiles tiene ciertos problemas producto de preconceptos,

prejuicios y errores que deben ser evaluados en virtud de los propios valores originales
de la Agilidad.
No obstante, al principio de este capı́tulo se ha establecido que el desarrollo de
aplicaciones móviles empresariales en el Perú en la mayorı́a de los casos requiere mejores
métodos o por los menos referencias y respuestas a fin de elevar la competitividad y
promover la innovación que demanda esta industria.
En ese orden de ideas es evidente que una metodologı́a de desarrollo de aplicacio-
nes móviles empresariales debe ser en primer lugar ágil fundamentalmente desde una
visión crı́tica, a razón de ello el marco teórico aborda Modern Agile ante la necesidad
de una agilidad genuina y constituye la referencia principal de la presente investigación.

IV | Propuesta Planteada
4.1. Planteamiento de Metodologı́a de Desarrollo de Apli-
caciones
Para el planteamiento de la metodologı́a de desarrollo de aplicaciones móviles

empresariales del presente trabajo, es necesario dirigir todos los esfuerzos a partir de
los cuatro principios Modern Agile a la hora de escoger las prácticas y métodos más
adecuados para el caso de estudio.
4.2. Definición del Metaproceso
Al ser una metodologı́a Ágil, esta ha de ser iterativa e incremental y basada en

los principios Modern Agile, esto significa que a diferencia de métodos tradicionales
no se describe un conjunto definido y estructurado de fases tales como análisis, diseño,
implementación, despliegue con un orden rigido, sino que por el contrario la agilidad nos
lleva a detallar un conjunto de iteraciones incrementales y continuas que van agregando
valor al producto, y que a diferencia de un “proyecto” de software no tiene un término
o final definido. Evoluciona constantemente mientras exista el negocio u organización
a la que sirve.
54
CAPÍTULO IV. Propuesta Planteada
Figura 4.1
Metaproceso de la Metodologı́a
Nota. Propone un marco de referencia para definir una metodologı́a basada en Modern
Agile, con sus respectivas fases en el tiempo, partiendo del Inicio, Despegue, Cons-
trucción del MVP, seguida de incrementos continuos, no define un fin de proceso y
establece dos lı́neas de revisión: las priorizaciones sobre el producto en construcción y
las retrospectivas sobre la propia metodologı́a.
4.2.1. Inicio
Como se puede apreciar en la Figura 4.1, se busca establecer un inicio del producto
que permita tener un entendimiento inicial de los problemas a resolver.
En esta etapa se hace uso de la técnica User Story Map, propuesta por Patton
and Economy (2014), su objetivo es generar una descripción común para todos los
involucrados sobre el problema a abordar y su alcance, permite realizar priorizaciones
y otras funciones de mucha utilidad para la metodologı́a propuesta, donde a partir de
una entrevista con los involucrados, se construye un User Story Map con el próposito
de contar con una primera visión general y el posible alcance del proyecto.

Figura 4.2
Inicio para Establecer el Backbone del User Story Map.
Nota. Técnica recomendada para comprender la problemática a resolver, el alcance de

un esfuerzo, priorizaciones, y otros usos dentro de los principios Modern Agile, en esta
parte de inicio, será suficiente entender un flujo narrativo con ayuda de los usuarios
y clientes, se pretende generar un entendimiento compartido y uniforme del alcance
inicial. Adaptado de [Ejemplo de mapa de historias de usuario (User Story Map)], de
Patton and Economy, 2014, User story mapping: discover the whole story, build the
right product (p.42).
4.2.2. Despegue
Después de iniciar el entendimiento y alcance de la solución, se sigue con la

ejecución del despegue por medio de talleres (workshops) de alineamiento de la visión
del producto y la misión del equipo.
Estas sesiones permiten llevar a cabo un alineamiento efectivo del equipo definien-
do los objetivos de forma medible y concreta a través de Tests de misión, adicionalmente
tener definido el contexto donde se desempeñará el equipo y planificar las estrategias
valiéndose de una matriz de impacto, se hará uso de las prácticas propuestas por Larsen
and Nies (2011) de Liftoff: Launching Agile Teams & Projects.

Figura 4.3
Despegue o Liftoff.
Nota. Consta de talleres que siguen un conjunto de lineamientos, a fin de que el equipo
responsable de la construcción del producto cuente con las herramientas necesarias para
mantenerse enfocado y alineado a sus objetivos durante todo el proceso. Adaptado de
Tree Elements of an Agile Charter, de Larsen and Nies, 2016, Liftoff: Start and Sustain
Successful Agile Teams (p. 42).
4.2.3. Producto Mı́nimo Viable MVP
Una vez alineado el equipo, se inicia propiamente el descubrimiento del producto

digital, concepto opuesto al de definir una aplicación a construir, para ello es indis-
pensable el planteamiento de una hipótesis que se validará con la construcción en un
producto mı́nimo viable ó MVP por sus siglas en inglés, ello se consigue con pequeños
incrementos que se van validando hasta alcanzar la mı́nima versión que los usuarios
y clientes estén dispuestos a usar y les genere valor, en ese sentido se agrega mayor
detalle al User Story Map del Inicio, seguidamente se determina un subconjunto de
historias de usuario a implementar cada una de las cuales será dividida en tareas más
pequeñas aptas para su codificación a través de la técnica de Split explicada por Patton
and Economy (2014) como se aprecia en la Figura 4.4.

Figura 4.4
Split de Requerimientos de Negocio.
Nota. Implica tomar las necesidades del negocio, las que se dividen en historias de
usuario que tengan sentido para los usuarios y les aporten valor, seguidamente estas se
vuelven a dividir en tareas de desarrollo que confirmen unidades mı́nimas fácilmente
implementadas por el equipo de desarrollo que les permitan ser tratadas en un siste-
ma Kanban. Adaptado de A right-sized story from a business perspective is one that
helps a business achieve a business outcome, de Patton and Economy, 2014, User story
mapping: discover the whole story, build the right product (p.139).
Durante todo el proceso se siguen los lineamientos y recomenadaciones de los

métodos de Lean StartUp y Lean UX, acortando los ciclos de Learn – Build - Messure
y Learn – Design - Messure, respectivamente aplicando el método cientı́fico para validar
las hipótesis.
Esto significa que ya sea durante toda la construcción del producto (Lean Star-
tUp) o durante el diseño (Lean UX), como se verá más adelante, se propone una
hipótesis la cual debe ser validada lo antes posible y al menor costo, haciendo uso de
instrumentos de medición concretos.
Para finalmente usar estos resultados de medición y decidir si dicha hipótesis
permite generar valor, lo que significa que se debe persevar, o si por el contrario se
debe abandonar o pivotear dicha propuesta, en razón de buscar otra alternativa o
realizar los ajustes necesarios.
Estos conceptos están ampliamente estudiados y desarrollados por Ries (2011) y

Klein (2013).
Figura 4.5
Tratamiento Lean de las Tareas.
Nota. En la parte inferior se tiene un subconjunto de tareas de desarrollo necesarias

parar construir el MVP o cualquier otra versión futura, las cuales son propuestas y
diseñadas siguiendo Lean StartUp y Lean UX, lo que implica la aplicación del método
cientı́fico tanto en la construcción como en el diseño, con el fin de acortar el tiempo y
recursos de validación de las hipótesis, y determinar si se persiste o se necesita cambiar.
Adaptado de The lean loop y You can’t learn if don’t mesure, de Klein, 2013, UX for
lean startups: Faster, smarter user experience research and design (pos.204, 278).
4.2.4. Versiones Futuras
A partir de la construcción del MVP, se realizan los incrementos continuos que

vienen a ser las diferentes versiones del producto en el tiempo, como se puede apreciar en
la Figura 4.1, no se determina un final del ciclo, partiendo de la idea de que los productos
digitales bajo Modern Agile no se definen, sino se descubren y validan constantemente.
Cabe precisar que el incremento de caracterı́sticas, mejoras y correcciones es continuo e
iterativo, se busca establecer un tiempo de entrega predecible por cada tarea atendida
(Anderson, 2010), que puede ser de 2 a 3 dı́as en promedio, sin embargo, la definición

de versiones obedece a las decisiones de ı́ndole comercial bajo las demandas del negocio.
4.2.5. Flujo de Trabajo en Progreso WIP
La construcción del producto se basa en la culminación de diferentes tareas cada

una de las cuales ingresa en un flujo de trabajo definido bajo los métodos de Kanban,
lo cual implica el diseño de un tablero con sus diferentes colas y lı́mites de trabajo
en progreso (WIP), por lo general involucra las colas de entrada, análisis, desarrollo,
pruebas y despliegue, ası́ mismo la definición de clases de servicio donde cada una tiene
un tratamiento distinto. (Anderson, 2010)
Es importante destacar que la definición del flujo de trabajo permite visibilizar
el trabajo de todas las tareas, ası́ también, limitar la capacidad del equipo, proveerle
predictibilidad y por ende elevar su productividad, ver Figura 4.6.

Figura 4.6
Tratamiento Kanban de las Tareas de Desarrollo.
Nota. Una vez definidas las tareas de desarrollo éstas ingresan al sistema Kanban, de
acuerdo a los lı́mites del WIP para ello cada una es catalogada en un tipo o nivel
de servicio, pasando por el análisis, desarrollo, pruebas y despliegue, este tratamiento
permite aprovechar de forma óptima los esfuerzos del equipo y los recursos disponibles.
Adaptado de What is a WIP limit?, Kissflow, 2021, (https://kissflow.com/hubfs/
WIP-limits.png). Derechos de autor 2022 por Kissflow Inc.
Por otro lado cada tarea de desarrollo se implementa siguiendo la técnica pro-
puesta por Beck (2003), Desarrollo Dirigido por Pruebas, Test Driven Development o
TDD por sus siglas en inglés, la cual implicada desarrollar primero las pruebas antes de
implementar cualquier funcionalidad invirtiendo completamente el ciclo de desarrollo,
a fin de encontrar un mejor diseño de software con la ventaja adicional de crear una
red de seguridad y control de calidad orgánico, tal como se aprecia en la Figura 4.7. Se
recomienda seguir dos niveles de TDD, uno de interfaz de usuario o aceptación y otro
nivel unitario.

Figura 4.7
TDD de Aceptación o UI y TDD Unitario.
Nota. Para la implementación se adopta la técnica TDD a dos niveles, un primer nivel de
aceptación conocido como pruebas de instrumentación o pruebas de UI donde primero
se implementa una prueba de aceptación fallida sobre una historia de usuario o funcio-
nalidad, y se satisface con pruebas unitarias en el segundo nivel TDD. En ambos casos
se siguen las fases de prueba fallida, pruebas satisfecha y refactorización. Adaptado de
fundamentals of testing, Google Developers, sf, Fundamentals of testing Android apps
| Android Developers [Gráfico] (https://clintpauldev.com/wp-content/uploads/
2021/01/tdd_architecture.png. CC BY 2.5.
Ası́ mismo para la implementación del código fuente es necesario seguir una ar-
quitectura de desarrollo de software, y se ha optado por implementar aquellas que han
sido catalogadas por Martin (2012), como una Arquitectura Limpia (Clean Architec-
ture), a fin de facilitar la construcción de una aplicación testeable, independiente de
frameworks, de la interfaz de usuario, de la base de datos, o de cualquier otro agente
externo.
Una vez implementada cada tarea o subtarea de desarrollo se opta por integrar-

la inmediatamente al código en producción en el proceso conocido como Integración

Continua o CI, desencadenando un proceso denominado Pipeline de CI que mezcla el
incremento con el código de la rama en producción en el repositorio de control de versio-
nes remoto, seguidamente se corren automáticamente los test unitarios, de aceptación
y otros, en caso pasen todas las pruebas satisfactoriamente el código estará integrado
y es momento de desencadenar el siguiente Pipeline de Despliegue Continuo o CD, una
vez satisfecho se publica una nueva versión en producción. Revisar la Figura 4.8 para
mayor comprensión.
Figura 4.8
Flujo de Desarrollo a través de Pipelines de CI/CD.
Nota. Cada tarea de desarrollo debe seguir un flujo completo desde su codificación
hasta su puesta en producción, empezando por el ambiente local de los desarrolladores,
sigue hacia un repositorio de control de versiones remoto, y cuando se mezcla con el
código de producción en la rama principal, se dispara automáticamente un pipeline de
Integración Continua o CI que ejecuta compilación, pruebas unitarias y de aceptación,
de ser exitosas desencadena un segundo pipeline de Despliegue Continuo o CD que lleva
el ejecutable de la app hasta la tienda de aplicaciones respectiva. Adaptado de What
do CI and CD mean?, Balajee, 2020, What is CI/CD Pipeline?. Derechos de autor por
Medium.

4.2.6. Priorización
Durante el ciclo de vida del producto digital en construcción, es necesario llevar

a cabo de forma periódica (por ejemplo semanal) la Priorización, durante la cual el
equipo reporta la capacidad de WIP disponible en el sistema Kanban, para que desde
un punto de vista comercial se decida cuáles son las nuevas tareas a atender.
Ası́ mismo, es el momento de revisar los resultados de las hipótesis de negocio
planteadas anteriormente a fin de decidir si se persiste o cambia (pivotea), también
determinar que nuevas hipótesis se pueden proponer con el propósito de elegir las
nuevas tareas. Cabe destacar que la Priorización, esta desacoplada del despliegue el
cual es continuo. (Anderson, 2010)
4.2.7. Evaluación de Resultados
La evaluación de resultados es permanente con el propósito de validar las hipó-

tesis, considerando que se practican Lean StartUp y Lean UX durante todo el proceso
de construcción que están alineados a los principios Modern Agile, se recomienda hacer
uso de técnicas como wireframes, mockups, validación temprana, métricas de uso, A/B
testing entre otras, el objetivo es saber si la hipótesis es capaz de generar valor a los
usuarios y clientes, y con base en ello persistir o descartar la hipótesis en el menor
tiempo posible.
4.2.8. Retrospectiva
Ası́ como se tiene una revisión periódica del producto en la Priorización, es nece-
sario contar con una revisión periódica del proceso que pudiera ser por ejemplo bise-
manal o quizás mensual, que consiste en una sesión donde el equipo en una ambiente
de seguridad psicológica llega a un consenso de tres puntos, que estuvo bien, que se
puede mejorar y los próximos pasos concretos a seguir para perfeccionar la metodolo-
gı́a actual, los beneficios de esta práctica son proveer una herramienta sencilla, pero

altamente efectiva de mejora y autoevaluación continua. (Kerth, 2013)
4.2.9. Definición de Artefactos para Validar Propuesta
Para validar la propuesta, se toman las variables del presente trabajo, se establece
un artefacto para cada una de ellas, las mismas nos servirán de herramientas para
monitorear y gestionar constantemente los resultados y el enfoque de la propuesta, se
elabora la siguiente tabla de resumen:
Tabla 4.1
Artefactos de Validez para Variables Independientes
Variable Independiente Indicador Forma de medición

Errores durante proceso Cantidad de errores Herramienta Issue
Tracker: Gitlab y Trello
Conocimiento del cliente Índice de satisfacción del Encuestas digitales a
sobre sus necesidades cliente respecto al través de Survey Monkey
conocimiento de sus
necesidades (CSAT)
Conocimiento del equipo Índice de satisfacción del Encuestas digitales a
sobre las necesidades del equipo (CSAT) sobre el través de Survey Monkey
cliente conocimiento de las
necesidades del cliente
El cuestionario que se aplicará se codifica como CVIndepend (Cuestionario de

variable independiente):
1. ¿Cuál es su participación en el proceso?
a Empresa
b Usuario
c Patrocinador
d Miembro del equipo de desarrollo
2. ¿Actualmente, que tanto comprende el problema a resolver?, siendo 1 el menor

el 5 el mayor grado.

3. ¿Actualmente, que tanto comprende los resultados que dará la solución, a los
usuarios?, siendo 1 el menor y 5 el mayor grado.
4. En caso haya participado en procesos con otros equipos de desarrollo de software,

¿Qué tanto comprendió el problema a resolver?, siendo 1 el menor y 5 el mayor
grado.
5. En caso haya participado en procesos con otros equipos de desarrollo de software

¿Qué tanto comprendió los resultados que dio la solución, a los usuarios?, siendo
1 el menor y 5 el mayor grado.
Tabla 4.2
Artefactos de Validez para Variables Dependientes
Variable Dependiente Indicador Forma de medición

Sobrecostos Costo de errores Cálculo de costo a partir
de cantidad de errores
Satisfacción del cliente Índice de satisfacción del Encuestas digitales a
respecto al producto cliente (CSAT) respecto través de Survey Monkey
al producto
Satisfacción del cliente Índice de satisfacción del Encuestas digitales a
respecto al proceso de cliente (CSAT) respecto través de Survey Monkey
desarrollo al proceso de desarrollo
En este caso se aplicarán dos cuestionarios codificados como CVDepend, para

medir las variables dependientes de la satisfacción del usuario respecto al producto y
proceso:
1. ¿Cuál es su participación en el proceso?
a Empresa
b Usuario
c Patrocinador

2. ¿Cuál es el grado de satisfacción que tiene del producto desarrollado?, siendo 1

el menor y 5 el mayor grado de satisfacción
3. ¿Cuál es el grado de satisfacción que tiene de los resultados que le permite alcanzar
el producto desarrollado?, siendo 1 el menor y 5 el mayor grado de satisfacción.
4. ¿Cuál es el grado de satisfacción que tiene del proceso de desarrollo del producto?,
siendo 1 el menor y 5 el mayor grado de satisfacción
5. ¿Cuál es el grado de influencia que tiene el proceso de desarrollo sobre el producto

desarrollado?, siendo 1 el menor y 5 el mayor grado de influencia.
De acuerdo con las caracterı́sticas de la presente investigación es importante con-

tar con la medición de todas las variables para observar, describir y analizar su com-
portamiento.
4.3. Descripción del Caso de Estudio
Con el fin de observar los efectos causados por la aplicación de los principios y
métodos Modern Agile en un caso real, el autor ha seleccionado el caso de la aplicación
DondeParqueo que constituye un producto actualmente en desarrollo a cargo de la
empresa SmartWay que es una iniciativa del investigador.
4.3.1. DondeParqueo App
El objetivo principal de este producto es proveer servicios de búsqueda de estacio-

namiento vehicular al público en general, es decir cualquier persona que desee conseguir
estacionamiento para su vehı́culo podrá acceder a la aplicación y buscar parqueo de
acuerdo con su ubicación geográfica actual, es decir ¿Cuál es el estacionamiento con
disponibilidad más cercano?
Por otro lado, también permitirá a las empresas proveedores de servicios de esta-
cionamiento inscribirse y mostrar la disponibilidad de sus espacios de estacionamiento

4.4. Desarrollo del Producto DondeParqueo
a través de la aplicación.
Esta iniciativa B2C (Business to Consumer), se lleva a cabo aplicando los princi-
pios de Modern Agile teniendo la lista de stakeholders.
SmartWay, Promotora y encargada de desarrollar la propuesta.
Empresas de Estacionamientos interesadas en integrar sus servicios a través de

la aplicación.
Usuarios finales interesados en contar una aplicación para buscar estacionamiento.
4.4.1. Inicio
Dentro de las prácticas y métodos de Modern Agile se recomienda construir un

User Story Map, bajo el principio de “Hacer a las personas Impresionantes”, se elabora
el mapa durante las primeras sesiones con los usuarios y promotores del producto.
El objetivo es generar un entendimiento compartido entre los usuarios y el equipo
que construirá la solución, para ello se usarán historias de usuario que se deben en-
focar en relatar o contar como debe funcionar la aplicación y no en cómo escribir los
requerimientos.

Figura 4.9
Backbone o Columna Vertebral del Producto.
Nota. A la derecha se ha rotado el mapa por espacio, a la izquierda se divide para mejor
visualización, es un conjunto de tareas que describen el flujo narrativo de un User Story
Map, cuyo objetivo es entender el problema y establecer un alcance deseado por los
usuarios o clientes, esto genera un entendimiento compartido de todos los involucrados
sobre la problemática.
En ese sentido definir la columna vertebral del producto es un punto de inicio

para entender los resultados que deseamos que los usuarios y clientes alcancen a través
del producto, entonces se procede a definir de forma general los principales objetivos y
sus respectivas tareas.
Inscripción de Usuario. Resultado que requiere la creación, eliminación y actua-
lización de los datos de cualquier persona que desee acceder a la aplicación.
Figura 4.10
Fragmento de Mapa Referente a Inscripción de Usuario.
Nota. La inscripción de usuarios como se aprecia requiere de tres tareas en el flujo

narrativo, primeramente crear una cuenta de usuario, ası́ como su eliminación y también
la actualización de sus datos.
Búsqueda de parqueo. Para ello inicialmente se espera buscar un parqueo por su

dirección (Nombre) o por la cercanı́a geográfica con el usuario.
Figura 4.11
Fragmento de Mapa Referente a Búsqueda de Parqueo.
Nota. El proceso de búsqueda consta de dos tareas, la búsqueda de parqueos por nombre
en caso de que el usuario conozca la dirección o nombre del establecimiento y también
la posibilidad de encontrar un parqueo por la cercanı́a a su ubicación actual.
Actualización de espacios. Se desea que las empresas que ofrecen sus estaciona-
mientos actualicen constantemente la disponibilidad de parqueos. Ya sea liberando u
ocupando espacios.

Figura 4.12
Fragmento de mapa Referente a Actualización de Espacios.
Nota. Constará de dos tareas el primer lugar ser capaz de liberar un espacio disponible
de estacionamiento para nuevos vehı́culos y de otro lado registrar su ocupación.
Empadronamiento de empresas. Con la finalidad de incorporar nuevas empresas

que ofrezcan sus servicios de parqueo, se necesita agregar, eliminar y actualizar la
información de cada empresa.
Figura 4.13
Fragmento de Mapa Referente a Empadronamiento de Empresas.
Nota. Las empresas se deben inscribir para ser parte del proceso del app, tomando en
cuenta las tareas de agregación, eliminación y también actualización.
Revisión de resultados. Toda la información generada por las búsquedas de par-

queo debe ser registrada para análisis posteriores y seguimiento de las empresas, en
ese sentido se deben construir reportes para revisar los resultados de interacción que
produce el uso de la aplicación por el público usuario.

Figura 4.14
Fragmento de Mapa Referente a la Revisión de Resultados.
Nota. Constará de un conjunto de reportes que los responsables de las empresas podrán
visualizar.
Facturación. El modelo de negocio que se plantea inicialmente consiste en que las

empresas que ofrezcan sus servicios de parqueo a través del producto paguen por las
búsquedas en las que aparecen y por la visualización de la información de sus estacio-
namientos, por lo tanto, es necesario generar reportes de facturación y funcionalidades
de emisión de dicha facturación.
Figura 4.15
Fragmento de Mapa Referente a Facturación.
Nota. Historias de usuario necesarias para la generación de reportes de facturación y

la emisión propiamente de comprobantes de pago por el uso de la plataforma.
El inicio de la construcción de un producto digital bajo los principios de Modern

Agile, define que más importante que generar extensos documentos de requerimientos,
es explorar de forma colaborativa los resultados que los usuarios finales deben alcanzar.
En ese orden de ideas no se puede pretender que estos lineamientos sean definiti-
vos, no se busca crear una lista de “requerimientos” rı́gidos para luego implementarlos,
sino por el contrario descubrir el mejor producto posible aplicando el método cientı́fico
a partir de la comprobación constante de hipótesis.

Esta primera aproximación al problema fue elaborada luego de una reunión con
los promotores del producto, donde en forma colaborativa se construyó el mapa de las
imágenes anteriores, y seguidamente como se hará durante todo el proceso se aplican
encuestas de verificación, en esta primera parte el cuestionario CVIndepend.
4.4.2. Despegue o Liftoff
Una vez que se tiene un entendimiento inicial, es importante llevar a cabo el

proceso de despegue del equipo de desarrollo para alinear todos los esfuerzos y preparar
a sus miembros para la construcción del producto.
Se llevan a cabo en sesiones o talleres Liftoff explicados en el marco teórico, se
muestran los puntos más destacables de su ejecución para el caso de estudio.
4.4.2.1. Validación
De prerrequisitos, la Tabla 4.3 muestra el checklist necesario antes de planificar

el Liftoff, con ello validamos si es el momento oportuno para iniciar el proceso (Larsen
and Nies, 2016).
Tabla 4.3
Checklist Antes de Planificar Liftoff
Pregunta Respuesta
¿El producto tiene un patrocinador Si
comprometido y un gerente de producto
identificado?
¿Puede articular el caso de negocio? Si
¿Alguien ha asignado los fondos y Si
presupuestado para comenzar el
esfuerzo?
¿Tiene una intención clara de lo que Si
quiere que logre el equipo?
Nota. Adaptado de Are You Ready to Plan A Liftoff?, de Larsen and Nies, 2016, Liftoff: Start
and Sustain Successful Agile Teams (pos.183).
Dadas las condiciones se planifican las sesiones y elaboran los artefactos de esta

etapa.
4.4.2.2. Planificación del Liftoff
Es importante planificar los detalles de estas sesiones para alcanzar los resultados
esperados y alinear al equipo lo mejor posible, en la planificación se define:
Grupo a cargo, Product Manager, Patrocinador y Lider de Equipo de desarrollo
Agenda, Constará de una sesión para elaborar el Chartering como se explica en

el marco teórico.
Duración. Las sesiones se llevarán a cabo en un único dı́a
Participantes. Product Manager, Patrocinador y equipo de desarrollo
Logı́stica. Se llevará a cabo en las oficinas de SmartWay
4.4.2.3. Diseño del Liftoff
Durante el diseño explicado por Larsen and Nies (2016) se tomaron en cuenta
ciertos puntos, detallados a continuación:
Inicio. Se inicia con una dinámica donde los participantes se presentan en caso
de no conocerse.
Introducción del Patrocinador. Una breve reseña que exprese el apoyo a esta
sesión.
Presentación de un experto. Una breve exposición para repasar conceptos Lean

StartUp.
Retrospectiva, se toma una hora para reflexionar sobre experiencias de proyectos

anteriores.
Agile Chartering. El corazón del workshop.

Reporte breve de resultados y conclusiones.
Agradecimientos.
Feedback, para futuras mejoras.
A continuación, se presentan los artefactos resultantes del Agile Chartering, con-

siderando que son la parte más importante de ésta etapa.
4.4.2.4. Ejecución: Agile Chartering
Se deben construir los tres elementos de Agile Chartering, que son propósito,
alineamiento y contexto.
a Propósito
Visión del Producto. Los conductores experimentarán su búsqueda de un espacio

de estacionamiento de forma rápida casi imperceptible aliviando la incertidumbre
y el estrés de desplazarse en la ciudad.
Misión del Equipo. Construiremos una solución digital de búsqueda de espacios

de estacionamiento para cualquier conductor. Una herramienta que reducirá el
tiempo de búsqueda y llegada a un estacionamiento. Esta nueva app permitirá
a los conductores enfocarse en desplazarse a su destino con la tranquilidad de
estacionar lo más cerca posible.
Test de Misión.
Tiempo de búsqueda de un estacionamiento en el orden de 30 segundos.
MVP listo en 3 semanas.
Antes del segundo mes probar en campo con una empresa de estacionamien-
to.
Antes del primer semestre contar una solución que conste de un flujo mı́nimo
B2C.

b Alineamiento
Reglas Simples.
Sé humilde y valiente para hacer lo que dices.
Lleva a cabo la estética y la calidad en absolutamente todos los aspectos del

producto, Dormirás mejor (Steve Jobs).
Aprende a fallar bien, aprende de tus errores para innovar (Eric Schmidt).
Ponte en los zapatos del otro.
Crea el mejor usuario del mundo de nuestro producto, no el mejor producto.
Equipo central (Core Team).
Contamos con un equipo de 2 personas, desarrolladores fullstack con experiencia

en construir aplicaciones de extremo a extremo, frontend, backend y lógica de
negocio. Estaremos abiertos a apoyarnos mutuamente para maximizar nuestros
resultados.
Acuerdos de Trabajo.
Nos enfocamos en un objetivo concreto y decimos “no” a todo lo demás.
Iniciamos cada dı́a con una reunión para sincronizar al equipo.
Escuchamos atentamente las opiniones de los demás.
Respetamos a cada miembro del equipo, su tiempo y aportes.
Solucionamos los problemas de raı́z, entendiendo sus causas, si es posible de

forma definitiva.
Sabemos que terminado es testeado y desplegado en producción.
c Contexto
Lı́mites e interacciones del equipo

Figura 4.16
Diagrama de Lı́mites e Interacciones del Equipo.
Nota. Desde la perspectiva del Equipo (al centro), se muestra la relación con su entorno,
arriba el patrocinador de quien reciben fondos y actualizaciones del caso de negocio
y le entregan reportes de progreso, abajo los grupos de usuarios de quienes reciben
feedback y les entregan demos, versiones del producto y les toman encuestas para medir
resultados.
Recursos no humanos comprometidos para el trabajo.
Se define una lista de recursos necesarios para conseguir los objetivos
Equipos de cómputo para los desarrolladores,
Acceso a usuarios para probar las hipótesis,
Financiamiento de licencias de software para garantizar el diseño, el desa-

rrollo, la integración y el despliegue continuo.
Acceso a internet,
Financiamiento de infraestructura en la nube para desplegar la solución.
Previsión con un análisis prospectivo
Se elaboró la siguiente matriz.

Figura 4.17
Matriz de Impacto y Probabilidad.
MVP EXITOSO Entregas

+3 a tiempo
Usuario
muestra
acojoda del
producto
+2
+1
Demoras por Usuario

-1 Curva de insatisfecho
Aprendizaje
Poca colaboración
de empresas de
Cambios estacionamientos
drasticos de
-2 alcance Rotación de
Personal
Perdida de
-3 financiamiento
50% de
No pasará Improbable Probable Ocurrirá
posiblidad
Nota. Donde el eje vertical representa el impacto positivo o negativo, el eje horizontal la
probabilidad de ocurrencia, y en naranja los eventos ubicados en la matriz que permiten
visibilizar el impacto y establecer estrategias adecuadas.

Una vez definidos los eventos, su impacto y probabilidad se discute y establece

medidas para mitigar y potenciar los eventos más perjudiciales y beneficiosos
respectivamente:
El equipo mitigará los riesgos con incrementos continuos y predecibles,
Aplicará el método cientı́fico para descubrir el producto validando nuevas

hipótesis,
Evaluará cada iteración con los usuarios y el equipo.
Al final de esta etapa se aplicó el cuestionario CVIndepend a nivel interno.
4.4.3. Definición del Flujo de Trabajo
Antes de comenzar propiamente con la construcción del producto se establecerá

una forma de trabajo que permitirá mantener el foco en el flujo y promover la predic-
tibilidad y efectividad con el fin de alcanzar la visión del producto y cumplir con la
misión del equipo.
El flujo de trabajo se implementa sobre la metodológica Kanban recomendada
por Modern Agile, donde definimos los estados de cada trabajo (historias de usuario,
tickets o issues), los lı́mites del WIP y las clases de servicio necesarias:

Figura 4.18
Flujo de Trabajo Kanban a Implementar.
Nota. Se establecen los parámetros y recomendaciones Kanban como las colas de pro-
ceso con sus respectivos lı́mites las cuales definen que la capacidad total del sistema en
11 tareas, toda tarea pasa de izquierda a derecha por la cola de entrada, seguidamente
el análisis, desarrollo, compilación, Pruebas y finalmente es liberada en producción.
Los lı́mites del WIP están definidos de acuerdo con la capacidad del equipo de
desarrollo que será de dos desarrolladores por lo tanto formarán un equipo que puede
atender 11 ı́tems teniendo cada etapa del proceso su propia capacidad, del mismo modo
se establecen las clases de servicio:
Figura 4.19
Clases de Servicio.
Nota. En rojo servicios expeditos se puede atender una tarea urgente como máximo,
en morado servicios de fecha de entrega fija con un lı́mite de una tarea, en amarillo
un máximo de 7 tareas estándar, y finalmente en verde se tiene hasta 3 tareas como
servicios intangibles.

Donde se distribuye la capacidad del equipo de acuerdo a las clases de servicio,

aceptándose un incremento de hasta 9 % o lo que es lo mismo 1 ı́tem “expedito” en
todo el flujo. En ese orden de ideas se reserva una capacidad máxima de 1, 7 y 3 ı́tems
como máximo para los ı́tems de clase “fecha de entrega fija”, “estándar” e “intangibles”
respectivamente.
4.4.4. Descubrimiento del Producto Mı́nimo Viable – MVP
Se Toma como artefacto de entrada el primer User Story Map, y en colaboración

con el cliente se va agregando las historias de usuario que se necesitan para conseguir
los resultados esperados.
Se realiza en dos partes, la primera está dirigida a las historias de usuario del
conductor elaboradas directamente por SmartWay y la otra dirigida a las empresas de
estacionamiento las cuales se elaboran con el apoyo de representantes de una empresa
interesada (seguidamente se aplicó CVIndepend y CVDepend).
Modern Agile recomienda aplicar las prácticas Lean StartUp donde todas estas
historias de usuario plasmadas en el Mapa de Historias de Usuario constituyen única-
mente una hipótesis que debe ser probada, aplicando los pasos de construir, medir y
aprender, luego de lo cual tendremos un conocimiento validado para ir mejorando nues-
tra solución a un menor costo y con mayor impacto. En ese sentido se debe establecer
un conjunto de caracterı́sticas que formarán parte de nuestro MVP.
Cabe destacar que estas caracterı́sticas iniciales deben ser lo “mı́nimo” posible pa-
ra que los usuarios se vean beneficiados, permitiendo medir y validar nuestra hipótesis,
que viene a ser:
¿Cuáles son las preocupaciones más importantes de los conductores antes de tras-
ladarse en su vehı́culo?
Si existe un lugar seguro, cercano y accesible para estacionar
Durante una segunda reunión con los interesados se añaden más elementos al
Mapa de historias de usuario como se muestra en la figura.

Figura 4.20
User Story Map para el MVP.
Nota. A la derecha el mapa está rotado por espacio, a la izquierda se divide para
mejorar visualización. Se agregan las historias de usuario de arriba hacia abajo, luego
de determinar el backbone inicial a fin de ampliar el entendimiento del problema, estas
historias permiten cumplir cada una de las tareas del flujo narrativo.

El mapa con seguridad no será definitivo, ya que solo es una propuesta y debe
ser validada. Por lo pronto empezaremos priorizando las siguientes historias de usuario
que serán parte del MVP.

Figura 4.21
Priorización de MVP – Visión Completa.
Nota. A la derecha el mapa está rotado por espacio, a la izquierda un fragmento más
cerca para mejorar visualización. Encerrado en rojo el mı́nimo subconjunto de historias
de usuario que son indispensables para validar la hipótesis del producto, que a su vez
generen valor al usuario final y al negocio, todas las demás historias de usuario se
revisarán más adelante y no son necesarias en este momento.

En la figura a continuación se puede observar un acercamiento en el mapa, con

las historias de usuario seleccionadas como parte del MVP.
Figura 4.22
Historias del MVP de Cerca.
Nota. Las actividades seleccionadas para ser parte del MVP son “Búsqueda de par-
queo” en azul, sus tareas de flujo narrativo son “Búsqueda De Parqueo por Cercanı́a”
y “Conocer parqueo”, y abajo sus respectivas historias de usuario “Mostrar Parqueos
Cercanos” ası́ como “Mostrar Detalle de Parqueo” y “Mostrar Ruta a parqueo”.
Las historias de usuario se detallan a continuación:

Tabla 4.4
Historia de Usuario Mostrar Parqueos en Mapa
Mostrar parqueos en mapa (#4)
Como conductor
Quiero Visualizar los estacionamientos más cercanos a una ubicación en el mapa
Para Ver la información de los estacionamientos
Escenario: Buscar a partir de un destino
Dado que ubica en centro del mapa un destino
Cuando el conductor presiona el botón de mostrar estacionamientos
Entonces el sistema agrega marcadores al mapa que representan los
estacionamientos más cercados en un radio de un kilómetro
Escenario: Buscar a partir de su ubicación actual

Dado que Dio permisos de obtener ubicación del dispositivo y acaba de abrir la
aplicación o ha presionado el botón de centrar en ubicación actual.
Cuando el conductor presiona el botón de mostrar estacionamientos
Entonces el sistema agrega marcadores al mapa que representan los
estacionamientos más cercados en un radio de un kilómetro
Tabla 4.5
Historia de Usuario Mostrar Detalle de Parqueo
Mostrar detalle de parqueo (#5)
Como conductor
Quiero Ver información adicional del estacionamiento
Para tener más información en la decisión de qué estacionamiento usar
Escenario: Seleccionar estacionamiento desde el mapa
Dado que el usuario visualiza los estacionamientos en el mapa
Cuando el usuario presiona un marcador de estacionamiento del mapa
Entonces muestra la pantalla con información adicional como la dirección, precio,
horario y el botón de mostrar ruta.

Tabla 4.6
Historia de Usuario Mostrar Ruta a Parqueo
Mostrar ruta a parqueo (#6)
Como conductor
Quiero Ver la ruta óptima para llegar al estacionamiento
Para tener una idea de cómo llegar al estacionamiento
Escenario: Mostrar ruta
Dado que está visualizando el detalle de un estacionamiento
Cuando presiona el botón de mostrar ruta
Entonces el sistema muestra en el mapa la ruta más cercana y óptima desde su
ubicación actual hasta el estacionamiento.
Estas historias de usuario y sus criterios de aceptación son aprobados por los
clientes para iniciar su construcción en el presente trabajo se presentan como tablas
para mejor entendimiento, dado que se hace uso de una herramienta de administración
de proyectos, para su registro y seguimiento.
Ası́ mismo se elabora un flujo básico y un wireframe que permiten mostrar cuál
será la funcionalidad por construir.

Figura 4.23
Diagrama de Flujo Básico MVP DondeParqueo App.
Nota. De izquierda a derecha el flujo de interfaces de usuario inicia con un Splash

(0), luego se muestra el Mapa (1), para seguidamente mostrar la ubicación del usuario
(2), añadir al mapa los parqueos cercanos (4), se puede también ver su detalle (5) e
inclusive la ruta para llegar al mismo (6). Abajo del mismo modo se aprecia otro flujo
de búsqueda por dirección de parqueo (3), el cual puede mostrar su detalle (7) y ruta
(6) respectivos.
El flujo permite tener una idea de la secuencia de interfaces propuesta en esta

iteración inicial, esto ayuda a fomentar las conversaciones dentro del equipo. Segui-
damente se diseña un wireframe para ser evaluado por ciertos usuarios clave con el
objetivo de ir afinando la hipótesis del MVP.

Figura 4.24
Wireframe del MVP para Probar la Hipótesis.
Nota. Se propone un borrador con las pantallas de la aplicación móvil de acuerdo al

flujo anterior. De izquierda a derecha se pueden apreciar “Splash”, “mapa”, seguido de
la “búsqueda de parqueos”, el “detalle” y la “ruta”. Ya sea por cercanı́a en la parte
superior o por dirección en la parte inferior.
Una vez evaluado el wireframe y considerando los conceptos Lean StartUp se

busca probar la hipótesis de la forma más rápida y con el menor costo posible, en ese
sentido se construye un mockup para ir analizando la reacción de ciertos usuarios a
una mayor fidelidad lo más parecido a una app implementada.

Figura 4.25
Prototipo Mockup del MVP.
Nota. Muestra a mayor fidelidad un prototipo de las pantallas de acuerdo al flujo

propuesto, que sea lo más cercano posible a la implementación final, haciendo uso de
herramientas de simulación en dispositivos y con usuarios reales. El objetivo es validar
la hipótesis y reducir las dificultades de UX.
A su vez los métodos Lean UX recomiendan aplicar Pain-Driven Design (PDD)

a fin de averiguar las dificultades (dolores) a nivel de experiencia de usuario e iterar
hasta reducirlas (Klein, 2013), el resumen de las dificultades encontradas serı́a:

Tabla 4.7
Resumen de Dificultades de los Usuarios al Interactuar con el Mockup
Usuario Dificultad Observaciones

Usuario 1 No tuvo problemas en su Ninguna
interacción con la
aplicación móvil
Usuario 2 Tuvo dificultades para No entendió la
encontrar funcionalidad de
estacionamientos cercanos ubicaciones cercanas
a su ubicación
Usuario 3 Tuvo dificultades para No encontró los botones
encontrar de ubicación actual
estacionamientos cercanos
a su ubicación
a su ubicación
a su ubicación
Se hacen evidentes los hallazgos respecto a dificultades para encontrar la fun-

cionalidad de estacionamientos cercanos (ver Tabla 4.7), en consecuencia con un bajo
costo se puede iterar rápidamente el diseño de interfaces y elaborar una propuesta con
mejores resultados.

Figura 4.26
Diagrama de Flujo Básico MVP, Versión 0.0.2.
Nota. Revisado en segunda iteración para reducir las dificultades de los usuarios durante
la validación temprana, ahora desde el splash (0) se muestran directamente los parqueos
más cercanos (1), para ver su detalle (2) y ruta (3), más abajo desde la pantalla (1) se
puede buscar por dirección (4), ver el detalle (5) y la ruta (3).
Una vez conseguidos los ajustes que se puede apreciar en la Figura 4.26, el flujo
básico se ha simplificado a fin de mostrar directamente los estacionamientos más cer-
canos reduciendo la dificultad de esta funcionalidad. Con ello se actualiza el wireframe
respectivo a continuación.

Figura 4.27
Prototipo Wireframe MVP, Versión 0.0.2.
Nota. En la segunda iteración el flujo se ha simplificado, después del Splash va di-

rectamente a la búsqueda de parqueos, ya sea por cercanı́a o por dirección, arriba y
abajo respectivamente; presenta una reducción de las dificultades de usuarios durante
la validación temprana.
Una vez disponible el wireframe se inicia una nueva etapa de pruebas con usuarios,
teniéndose el siguiente resultado al aplicar la validación temprana:

Tabla 4.8
Resumen de Dificultades de Usuarios al Interactuar con Prototipo Versión 0.0.2

Usuario 1 No tuvo problemas Ninguna
Ahora que se dispone de una mejor experiencia de usuario UX, se tiene un mayor
conocimiento de sus necesidades, esto ha sido posible gracias a la aplicación de PDD en
favor de la eliminación de desperdicio, reducción de riesgos y costos; en consecuencia
mayor seguridad para el equipo de desarrollo.
4.4.5. Implementación del MVP
Después de contar con el feedback de los usuarios durante la etapa anterior, ahora
se inicia la implementación, esto implica la planificación del WIP en el tablero Kanban.
Figura 4.28
Tablero Kanban Inicial – Backlog.
Nota. Lista de tareas pendientes de implementación a nivel de historias de usuario.
Tenemos las 3 historias de usuario (Figura 4.28), sin embargo, la forma más efi-
ciente de abordar esta implementación requiere dividir cada historia de usuario en

tareas más pequeñas y predecibles, proceso conocido como split y será a nivel de desa-
rrollo tomándose por ejemplo para la historia de usuario “Mostrar parqueos cercanos”
la opción de dividirls en dos actividades:
Mostrar parqueos desde mi ubicación
API de parqueos cercanos.
Figura 4.29
División de Historias de usuario en Tareas de Implementación.
Nota. A consecuencia del Split se divide la historia de usuario “Mostrar Parqueos” (us1)
en dos tareas de desarrollo “Mostrar parqueos desde mi ubicación” (ac.1.1) y “API de
parqueos cercanos” (ac1.2) para que sean factibles de procesar en la cola de entrada e
ingresar al sistema Kanban.
Estas actividades ingresan en la cola de análisis y siguen el flujo del tablero

Kanban que definimos anteriormente, se espera tener un tiempo de entrega de 1 a 2
dı́as, es deseable mantener este tiempo en todas las demás tareas lo cual se traduce en
predictibilidad de entrega y será el criterio de división de las historias de usuario en
adelante, como recomienda Anderson (2010).
4.4.5.1. Desarrollo de Tareas Luego de Split
Con la intención de ilustrar un ejemplo del abordaje de estas tareas tomaremos las
dos primeras que se encuentran pendientes en la cola de entrada, “Mostrar parqueos

cercanos desde mi ubicación” y “API de parqueos cercanos”, de acuerdo al proceso

que se ha establecido en Subsección 4.4.3 (Definición de flujo de trabajo), tenemos
disponibilidad para pasar a la cola de Análisis que tiene un lı́mite de 2 tareas, por
lo tanto ambas tareas pasan a análisis para que dos desarrolladores procedan con su
implementación, en consecuencia también queda espacio en la cola de entrada para un
máximo de 3 tareas.
Dado que ya contamos con un mockup definido, el análisis tendrá como objetivo
establecer dos aspectos:
Interfaces de integración en caso se tengan componentes dependientes,
Definición de pruebas de aceptación u otras necesarias.
Interfaces de integración, En tal sentido las interfaces que serán implementadas

requieren la cooperación entre los miembros del equipo de se encarguen de las 2 tareas
en análisis, ya que la API que se implementará se consumirá desde la aplicación móvil,
para mostrar los paqueos cercanos en un mapa.
URL Base
Tabla 4.9
Endpoints de Backend
URL Ambiente
https://dondeparqueo-mock-api- Testing
26aec.web.app
https://dondeparqueo-dondeparqueo- Producción
backend.34.72.54.109.nip.io
endpoint Parking

Tabla 4.10
Lista de Métodos de la Aplicación
Método Tipo
parking Post
Request de método parking
Código fuente 4.1 Parking Request
1 {
2 " locationQuery " : {
3 " lat " : " - 1 2 . 0 5 5 2 8 " ,
4 " lon " : " - 7 6 . 9 8 1 6 1 3 3 "
5 },
6 " parkings " : [ ]
7 }
Tabla 4.11
Diccionario de Datos Request Método Parking
Atributo Descripción Tipo de datos

locationQuery Coordenadas de origen de Objeto
consulta de parqueos
lat Latitud de origen de Texto en formato decimal
consulta
lon Longitud origen de Texto en formato decimal
consulta
parkings Lista de paqueos Lista
obtenidos desde otra
fuente como puede ser
Google Cloud Platform,
para retroalimentar los
parqueos registrados en el
sistema.

Response del método parking
Código fuente 4.2 Parking Response.
1 {
2 " content " : [
3 {
4 " id " : 1 ,
5 " code " : " ChIJo_CowR 7 HBZERBibmeGO - DJo " ,
6 " description " : " Cochera Guadalupe " ,
7 " lat " : " - 1 2 . 0 5 5 2 6 6 6 " ,
8 " lon " : " - 7 6 . 9 8 3 8 4 7 2 " ,
9 " type " : 1 ,
10 " address " : null ,
11 " reference " : " Jiron virgen de Guadalupe Mz . M 2 ,
Cercado de Lima " ,
12 " price " : "" ,
13 " unit " : null ,
14 " phoneNumber " : null
15 }
16 ],
17 " message " : null ,
18 " code " : 0
19 }

Tabla 4.12
Diccionario de Datos Response del Método Parking
Atributo Descripción Tipo de datos

content Contenido de los parqueos Lista
id Identificador de parqueo Entero
code Código único de parqueo Texto
lat Latitud de parqueo Decimal como texto
lon Longitud de parqueo Decimal como texto
type Tipo de parqueo Entero
address Dirección de parqueo Texto
reference Referencia de parqueo Texto
price Precio de paqueo Texto
unit Unidad de cálculo de Texto
precio de parqueo
phoneNumber Teléfono de parqueo Texto
message Mensaje de error si Texto
existiera
code Código de resultado, 0: Entero
Éxito, 1: Error
La definición de interfaces es esencial para construir el sistema de forma cohe-

rente, sin embargo, es importante no perder de vista que al integrar constantemente
los cambios y mejoras, estas interfaces pueden ser revisadas y refinadas a partir del
conocimiento y la validación de las hipótesis durante el proceso de desarrollo.
Definición de pruebas de aceptación y otras necesarias
Antes de iniciar con la implementación propiamente de las tareas se revisa o de-
finen las pruebas sobre todo las de aceptación (en caso sean necesarias), es recomenda-
ble que cada historia de usuario pueda ser validada de forma objetiva con una prueba
automatizada, lo que permite probar constantemente el sistema en cada iteración e
integración a nivel funcional.
La prueba para esta tarea está definida en la historia de usuario #4 en la Ta-
bla 4.4, en el apartado “Entonces el sistema agrega marcadores al mapa que representan
los estacionamientos más cercados en el radio de un kilómetro”, esto significa que se
implementará una prueba de aceptación automatizada que cumpla objetivamente esta

validación y se correrá en cada integración y despliegue.

Desarrollo de código fuente de las tareas del WIP
En esta sección será necesario hacer una breve explicación de la arquitectura de
software adoptada en el trabajo, con el fin de tener una mejor comprensión del proceso
que se sigue durante el desarrollo del código fuente.
Arquitectura Aplicación Móvil
Como se menciona en la Subsección A.5.5 y a partir de los aportes de Cejas (sf),
se adoptó una Arquitectura Limpia hexagonal con la estructura que se muestra en las
figuras:
Figura 4.30
Arquitectura Limpia del App Móvil.
Nota. Perspectiva de dependencias, Cejas (sf), el sentido de la fecha indica que las
dependencias van desde las capas externas a las internas, las capas más externas en
celeste representan frameworks o bibliotecas especı́ficas, por ejemplo interfaces de
usuario o base de datos, seguidamente en amarillo, adaptadores de interfaz viewModels
en Android, en verde se tiene las reglas de negocio representadas en casos de uso y en
naranja la lógica de dominio que consta de clases de entidades al centro. Reproducido de
Clean Architecture, de Cejas, sf, Android-CleanArchitecture-Kotlin (https://github.
com/android10/Sample-Data/raw/master/Android-CleanArchitecture-Kotlin/
architecture/clean_architecture_reloaded_main.png). derechos de autor 2022
por Cejas, Fernando.

Figura 4.31
Capas de Arquitectura del App Móvil Perspectiva Hexagonal
Nota. En azul la capa de Presentación que gestiona la lógica de interfaz de usua-

rio es decir Activities, Fragments, ViewModels y LiveData. En naranja la capa
de Dominio, encargada de la lógica de negocio de la aplicación consta de Ca-
sos de Uso, Entidades e interfaces de Repositorios. Y abajo en amarillo la capa
de Datos, responsable de la persistencia y recuperación de datos desde servi-
cios externos, almacenamiento local o de memoria, es decir Newtork, Database
o Memory respectivamente. Reproducido de Android 3 Layers Architecture, de
Cejas, sf, Android-CleanArchitecture-Kotlin (https://github.com/android10/
Sample-Data/raw/master/Android-CleanArchitecture-Kotlin/architecture/
clean_architecture_reloaded_layers.png). derechos de autor 2022 por Cejas,
Fernando.
Es fudamental cumplir las reglas de dependencia para garantizar que nuestros

componentes estén desacoplados, sean testeables e independientes de frameworks y
bibliotecas externas, también es importante destacar que podemos añadir un eje para
dar mayor delimitación a la arquitectura, se trata de eje funcional:

Figura 4.32
Eje Funcional dentro de Arquitectura Limpia Perspectiva Hexagonal.
Nota. Donde adicionalmente a la división por capas de presentación, dominio y datos,

también se segmenta la implementación por funcionalidades es decir cada funciona-
lidad es un fragmento independiente de la aplicación que cuenta con su ámbito de
presentación, dominio y datos.
Al segmentar las funcionalidades dentro de la arquitectura se consigue mayor

legibilidad al desacoplar todavı́a más nuestros componentes, si lo vemos desde una
perspectiva de dependencias seria:

Figura 4.33
Eje Funcional dentro de Arquitectura Limpia Perspectiva de Dependencia.
Nota. Donde las funcionalidades son transversales a las dependencias y cum-

plen sus reglas independientemente, facilitando la legibilidad, testeabilidad
y reutilización. Adaptado de Clean Architecture, de Cejas, sf, Android-
CleanArchitecture-Kotlin (https://github.com/android10/Sample-Data/
raw/master/Android-CleanArchitecture-Kotlin/architecture/clean_
architecture_reloaded_main.png). derechos de autor 2022 por Cejas, Fernan-
do.
La consecuencia de este tipo de arquitectura y delimitaciones es contar con la

capacidad de realizar segmentaciones o splits del menor tamaño posible que mantengan
todas las cualidades que deseamos y permitan añadir valor de forma constante a trav´es
de los procesos de integración y despliegue continuo, se puede graficar con el esquema
que sigue.

Figura 4.34
Esquema de Split de las Funcionalidades.
Nota. Inclusive cada funcionalidad se divide en splits más pequeños transversales a

todas las capas de la arquitectura, estos segmentos son partes factibles de implementar
que se van agregando continuamente al código fuente en producción no necesariamente
son visibles al usuario, lo que implica una diferencia entre los conceptos de despliegue
continuo y entrega continua.

Figura 4.35
Estructura de Arquitectura en Proyecto Android de App Móvil.
Nota. Desde un punto de vista del IDE Android Studio se aprecian los paquetes que
son parte del split “Funcionalidad Core”, con las clases y utilidades necesarias para
construir las demás, por ejemplo la gestión de datos (data), inyección de dependen-
cias (di), excepciones, programación funcional, clases base de casos de uso (interac-
tor.implementation), navegación y extensiones de plataforma (platform); a continua-
ción las demás funcionalidades especı́ficas como la “Funcionalidad Búsqueda” con sus
respectivas capas independientes de datos, dominio y presentación, y más abajo la
sección de pruebas, primero las pruebas de aceptación o instrumentación y abajo las
pruebas unitarias.
Por tanto, el equipo de desarrollo debe enfocarse en segmentar las caracterı́sticas

requeridas en pequeños incrementos funcionales no necesariamente visibles al usuario,
pero que se integren inmediatamente al sistema en producción, cada uno de estos incre-
mentos se integra pasando por un flujo completo que incluye el control automatizado
de calidad a través de las pruebas unitarias y de integración de todo el sistema.
Una vez abordada esta definición de arquitectura se retomará la descripción es-
pecı́fica del caso de estudio.

Descripción de Implementación bajo TDD

En este punto contamos con la información mı́nima necesaria para iniciar la co-
dificación de las tareas que se encuentran en progreso, y las tareas pasarı́an de la cola
de Análisis a la cola de Análisis terminado, y de allı́ a la cola de Desarrollo. Para su
atención el equipo de desarrolladores sigue ciertas recomendaciones que le permitan
alinearse a los principios Modern Agile estos están enmarcados en las prácticas TDD
enfocándose en un pensamiento Lean eliminando cualquier desperdicio en el proceso.
Aclarado ello se explica el flujo TDD en dos ciclos Google Developers (sf).
Figura 4.36
Dos Ciclos del Desarrollo Iterativo Impulsado por TDD.
Nota. TDD se aplica a dos niveles en la implementación, el primer nivel de interfaz de

usuario o aceptación cuyas pruebas fallidas (Failling UI Test) se satisfacen (Passing
UI Test) con ciclos de TDD en el segundo nivel a través de pruebas unitarias (cı́rcu-
lo amarillo) para su posterior refactorización en el primer nivel de interfaz de usuario
(Refactor). Reproducido de testing fundamentals, de Google Developers, sf, Fundamen-
tals of testing Android apps | Android Developers [Gráfico] (https://s7280.pcdn.co/
wp-content/uploads/2018/08/Testing-Frameworks-01.jpg.optimal.jpg. CC BY
2.5).
Si contextualizamos los ciclos TDD a la estructura del código fuente de la aplica-

ción móvil del presente trabajo ilustrados desde la Figura 4.31 a la Figura 4.7, tomando
como referencia las recomendaciones de Beck (2003) y DevTernity (Productor) (2017),
se establece que las pruebas deben incorporarse solo en las interfaces de las capas del
proyecto de software, en ese sentido tendrı́amos el siguiente gráfico para explicarlo:
Figura 4.37
Pruebas Dentro de Arquitectura de App Móvil.
Nota. Las pruebas de aceptación están ubicadas en la capa de presentación en la parte

superior, ya que requieren la inicialización de la aplicación en dispositivos reales o
virtuales, de otro lado las pruebas unitarias se encuentran en la interfaz de cada capa
de la arquitectura como se lee de arriba hacia abajo existen pruebas unitarias en la capa
de presentación, dominio y datos cada una en su ámbito especı́fico; al mismo tiempo
en azul están las lı́neas divisorias de los splits internos de cada funcionalidad las cuales
se construyen a partir de pruebas de acuerdo a TDD.
Por tanto, el primer ciclo de UI (Interfaz de usuario) que normalmente se conoce

como pruebas de aceptación, desde una implementación Android la prueba serı́a de la
siguiente forma:

Figura 4.38
Interfaz de Usuario a Probar en ac1.1.
Nota. Muestra la búsqueda de parqueos por cercanı́a, en naranja los marcadores que
representan parqueos y al medio en celeste y negro la ubicación actual del usuario, abajo
a la derecha los botones “E” para mostrar los paqueos cercanos y el botón inferior de
ubicación en el mapa para actualizar la posición del usuario en el mapa.

Figura 4.39
Código Fuente de Test de Aceptación para ac1.1.
Nota. Se puede apreciar dos secciones la primera “Esperar carga de Mapa”, en la cual
se espera que aparezcan en pantalla los botones de búsqueda y ubicación, durante
3000 milisegundos, para seguidamente presionar el botón de búsqueda y esperar los
resultados durante 3000 milisegundos. Finalmente abajo la sección “Mostrar resultados”
donde se verifica que la barra de proceso ya no sea visible lo que implica que los
resultados ya están disponibles en el mapa.
Como quedó explicado en las figuras anteriores, la validación de la funcionalidad

que muestra los parqueos, requiere codificar una prueba que inicialmente no compila
y es fallida (estado Rojo) dado que todavı́a no se han implementado los componentes
necesarios, por ende, se debe continuar con el siguiente ciclo TDD de pruebas unitarias
hasta que esta prueba pase satisfactoriamente, y ası́ pasar al estado “verde”.
En este punto es necesario diseñar las clases que se necesitan para cumplir esta
prueba, allı́ radica una de las diferencias de la adopción de TDD, el construir únicamente
los componentes que requieren las pruebas para ser satisfechas y nada más que eso, la
figura a continuación detalla el diseño propuesto.

Figura 4.40
Diseño Propuesto durante Implementación bajo TDD, Capa de Presentación.
Nota. A la izquierda la interfaz de usuario de búsqueda de parqueos por cercanı́a

etiquetada como RootActivity, la cual es producto de un ciclo TDD a través de Roo-
tActivityTest (arriba a la derecha), dicho ciclo se satisfizo en colaboración con dos ciclos
TDD el primero SearchMapFragmentTest y ParkingsViewModelTest para implementar
el fragment SearchMapFragment y el viewModel ParkingsViewModel respectivamen-
te juntos permiten manejar la funcionalidad del botón “E” y la visualización de los
marcadores en naranja a la izquierda.
Se ha colocado un cı́rculo rojo en cada clase que se considera durante el ejemplo

ilustrado en este apartado, la clase RootActivity representa la interfaz de usuario de
la izquierda, esta clase se implementó como consecuencia de un ciclo TDD (Rojo,
Verde, Azul), lo que significa que primero se escribieron sus pruebas unitarias en la
clase RootActivityTest, y se fue implementando la clase RootActivity hasta satisfacer
y refinar sus pruebas unitarias para finalmente refactorizar el código eliminando la
duplicidad.
Seguidamente se necesita implementar componentes de interfaz de usuario más
pequeñas conocidas en Android como Fragments, que en este caso contendrán el mapa
y permitirán visualizar los marcadores y elementos necesarios tal como se aprecia en el
lado izquierdo de la Figura 4.40, la cual tendrá el nombre de SearchMapFragment, su

implementación requiere también un ciclo TDD, y nuevamente sus pruebas unitarias se

escriben en la clase respectiva SearchMapFragmentTest, y como resultado se completa
el Fragment y este satisface sus pruebas.
Aquı́ es importante señalar que las dependencias externas de cada clase imple-
mentada en los flujos TDD de pruebas unitarias son suplantados usando bibliotecas
especializadas, porque la intención de las pruebas unitarias es diseñar, implementar y
probar solamente la funcionalidad en cuestión, y dejar para más adelante otras imple-
mentaciones.
Dicho esto, mencionar que hasta este punto no se han abordado temas de conec-
tividad con servicios externos ni de persistencia los cuales están en otras capas de la
arquitectura de la aplicación y que todavı́a no se han implementado, y solamente se está
resolviendo la problemática de la interfaz de usuario lo cual reduce significativamente
la complejidad del código que se está construyendo.
De la misma manera la responsabilidad de recuperar los datos de los parqueos
cercanos de este ejemplo se ha delegado a la clase ParkingViewModel que es responsable
de actualizar de forma automática los datos de los parqueos para su visualización en
el mapa lo que significa que los desarrolladores solo se han preocupado por cómo se
muestran estos datos con sus respectivos iconos y colores en el mapa, y no ası́ en la
forma en que estos son recuperados de alguna fuente de datos, de lo cual se encargará la
clase ParkingViewModel que de acuerdo al diseño solicitará de alguna lógica de negocio
(capa de dominio), los parqueos cercanos y los entregará para su visualización.
En consecuencia se implementa un nuevo ciclo TDD de pruebas unitarias definidas
en la clase ParkingViewModelTest, ası́ mismo los flujos de trabajo TDD recomiendan
correr todas las pruebas constantemente para tener la seguridad de que el código nuevo
no ha afectado la funcionalidad de todo el sistema.
Hasta este punto se ha completado la implementación de la funcionalidad de
parqueos cercanos en la primera capa de presentación. A continuación se describirá
lo concerniente a las dos capas pendientes de dominio y datos, cuya ausencia no ha

impedido tener una base de código funcional y completamente testeada y que mantiene
las cualidades que esperamos en una arquitectura limpia.
Continuando con las capas pendientes, se abordará la capa de dominio que es
responsable de la lógica de negocio del sistema, es ası́, que mostramos una imagen para
describir su construcción.
Figura 4.41
Diseño Propuesto durante Implementación bajo TDD, Capa de Dominio.
Nota. La funcionalidad de búsqueda del botón “E” consta de un caso de uso para su
implementación en la capa de dominio, se construye siguiendo TDD a partir de GetClo-
seParkingTest a la derecha cuyo ciclo permite añadir el caso de uso GetCloseParkings
que hace uso de dos interfaces de repositorios LocationRepository y ParkingRepository.
En la capa de presentación tenı́amos ParkingViewModel, como responsable de

solicitar a la capa de dominio los parqueos cercanos, de ello es necesario que en la capa
de dominio se implemente un caso de uso o lógica de negocio que resuelva el problema
de recuperar estos parqueos desde alguna fuente de datos.
Eso lo conseguimos primeramente como ya explicamos iniciando un nuevo ciclo
TDD en la clase de pruebas GetCloseParkingsTest, a fin de agregar la clase GetClose-
Parkings que tiene la responsabilidad de recuperar la posición actual desde la interfaz
LocationRepository y con ella pedir los parqueos cercanos a la interfaz ParkingReposi-
tory, seguidamente se muestran como referencia las clases de pruebas e implementación.
Código fuente 4.3 Una Prueba de Recuperación de Parqueos, GetCloseParkingsTest.
1 @Test

2 fun ‘ Should g et P a r k i n g s c l o s e l o c a t i o n a v a l i a b l e ‘ ( ) {
3 val p a r k i n g s = l i s t O f <Parking >(
4 Parking (
5 1,
6 "c1" ,
7 "Parqueo␣1" ,
8 "1" ,
9 "2" ,
10 "di" , "re" , "1" , "un" , " 45435435 "
11
12 ),
13 Parking (
14 2,
15 "code2" ,
16 "Parqueo␣2" ,
17 "2" ,
18 "2" ,
19 "di" , "re" , "1" , "un" , " 45435435 "
20 )
21 )
22 val locationQuery =
23 LocationQuery (
24 " -12" ,
25 " -77"
26 )
27
28 every {
29 l o c a t i o n R e p o s i t o r y . g et ( )

30 } returns ( locationQuery )
31
32 every {
33 p a r k i n g R e p o s i t o r y . p a r k i n g s ( eq ( l o c a t i o n Q u e r y ) )
34 } r e t u r n s ( E i t h e r . Right ( p a r k i n g s ) )
35
36 runBlockingTest {
37 g e t C l o s e P a r k i n g s . run ( UseCase . None ( ) ) . f o l d (
38
39 fnL = {
40 i t shouldBe n u l l
41 },
42 fnR = {
43 i t ‘ s h o u l d not be ‘ n u l l
44 i t . g et ( 0 ) . i d shouldBe 1
45 i t . g et ( 1 ) . i d shouldBe 2
46 i t . g et ( 0 ) . d e s c r i p t i o n shouldBe "Parqueo␣1"
47 i t . g et ( 1 ) . d e s c r i p t i o n shouldBe "Parqueo␣2"
48 })
49 }
50
51 v e r i f y ( e x a c t l y = 1){
52 p a r k i n g R e p o s i t o r y . p a r k i n g s ( eq ( l o c a t i o n Q u e r y ) )
53 }
54 v e r i f y ( e x a c t l y = 1){
55 l o c a t i o n R e p o s i t o r y . g et ( )
56 }
57 }

Nota. Ubicado en la capa de dominio, el código fuente representa la prueba unitaria para
recuperar parqueos cercanos a una ubicación, como indica el nombre de la función. Primera-
mente se instancia una lista de objetos de la clase Parking que representarán los resultados
esperados, seguidamente con la función “every” se simula el comportamiento de los reposi-
torios LocationRepository y ParkingRepository que están instanciados en forma de mock, ya
que son elementos externos que consume el caso de uso, seguidamente se invoca el método
“run” del caso de uso en GetCloseParkings que se esta probando, cuyo resultado se valida a
través de assets de tal forma que contenga los valores esperados inicialmente, finalmente más
abajo se verifica la correcta invocación de los repositorios.
Código fuente 4.4 Implementación GetCloseParkings, Capa de Dominio.
1 c l a s s GetCloseParkings
2
3 @Inject constructor (
4 dispatcherProvider : DispatcherProvider ,
5 private val parkingRepository : ParkingRepository ,
6 private val locationRepository : LocationRepository )
7 : UseCase<L i s t <Parking >, UseCase . None>
8 ( dispatcherProvider ) {
9
10 o v e r r i d e suspend fun run ( params : None ) :
11 E i t h e r <F a i l u r e , L i s t <Parking>> {
12 v a l l o c a t i o n Q u e r y = l o c a t i o n R e p o s i t o r y . g et ( )
13 ? : return E i t h e r . L e f t ( F a i l u r e . L o c a t i o n E r r o r )
14 return p a r k i n g R e p o s i t o r y . p a r k i n g s ( l o c a t i o n Q u e r y )
15 }
16 }
Nota. Representación del código fuente del caso de uso que permite recuperar los parqueos

cercanos a una ubicación, consta de un constructor a inyectar que recibe el dispatcherProvider
para la gestión ası́ncrona de datos, los repositorios ParkingRepository y LocationRepository;
implementa el método “run”, donde primero recupera la ubicación actual desde locationRe-
pository y a partir de esta busca los parqueos cercanos gracias a la función “parkings” de
parkingRepository. La función “run” devuelve un objeto Either que envuelve dos posibles va-
lores Right (derecho) que serı́a una lista de parqueos o Left (izquierdo) Failure que representa
un error que se retransmitirı́a a todas las capas siguientes.
Una vez concluida la capa de dominio, estarı́a pendiente concluir con la capa de
datos, hasta este punto en la capa de dominio se ha establecido la necesidad de contar
con dos interfaces de acceso a datos LocationRepository y ParkingRepository; para
el ejemplo se mostrará la implementación de se segunda interfaz, tal como se puede
observar en gráfico que sigue.
Figura 4.42
Diseño Propuesto durante Implementación Bajo TDD en la Capa de Datos.
Nota. Detalla el proceso de implementación de la interfaz ParkingRepository arriba

a la izquierda, en la clase ParkingDataRepository partiendo de un primer ciclo TDD
en ParkingDataRepositoryTest que necesita tres fuentes de datos que son: la base de
datos local, el backend de la aplicación y la API de Google Places, las cuales se consi-
guen desde tres ciclos TDD en: ParkingDatabaseSourceTest, ParkingNeworkSourceTest
y GooglePlacesDataSourceTest (a la derecha). esto permite en consecuencia construir
las fuentes de datos ParkingDatabaseSource, ParingNetworkSource y GooglePlacesDa-
taSource respectivamente.

En la capa de Datos se aborda el tema de la obtención de datos propiamente, es

decir para el caso de estudio la recuperación de los parqueos de las diferentes fuentes
disponibles ya sea de la base de datos local del dispositivo, servicios en la nube del
backend de la aplicación o de alguna API externa.
Luego de iterar la implementación de ParkingDataRepository a través de prue-
bas unitarias en ParkingDataRepositoryTest se realiza una refactorización para separar
la obtención de los datos en tres clases de acuerdo con su origen de datos, Parking-
DatabaseSource de la base de datos local, ParkingNetworkSource del backend de la
aplicación y GooglePlacesDataSource del API de Google Places, cada una de los cuales
fue construida a partir de sus respectivas pruebas unitarias.
Una vez que el equipo ha implementado el split de funcionalidad pendiente, esta
en la capacidad de integrarlo inmediatamente a la aplicación, puesto que tiene todo
el conjunto de pruebas que permiten validar permanentemente que el nuevo código es
consistente y no provoca errores ni afecta cualquier funcionalidad previamente imple-
mentada.
No dejando de mencionar que ha ocurrido un proceso similar en el lado de los
servicios del backend de esta aplicación, donde se han seguido los mismos lineamientos
de Modern Agile con la diferencia de tratarse de otro lenguaje de programación y con
otro propósito que es proveer datos a la aplicación móvil.
La práctica de estos métodos y técnicas aporta ciertas ventajas al desarrollo de
software, de las más importantes que atañen al caso de estudio podemos mencionar
que:
Se implementa solamente el código necesario para satisfacer las pruebas, no más

que eso.
El código que se agrega al sistema es cohesionado y desacoplado
Dirige el diseño de forma orgánica.
Permite tender una red de pruebas que validan constantemente todo el código

que es integrado al sistema, teniendo a disposición un control de calidad durante

todo al proceso de desarrollo.
Integración y Despliegue continuos (CI/CD) del Split

Como se vio en el apartado anterior ya se cuenta con el código fuente necesario
para su integración y despliegue en producción, para tal efecto se procede a iniciar
con el flujo de CI/CD a partir del envı́o de código recientemente implementado al
repositorio remoto.
El equipo optó por usar Gitlab desde el cual se definió una rama para incluir estos
cambios, seguidamente el responsable del equipo procede con la integración o merge de
la rama nueva con la rama main que representa el código en ambiente de producción.
El ambiente de CI/CD ha sido configurado para que una vez se realice un merge
en la rama main, inicie lo que se conoce como pipeline de CI y posteriormente el pipeline
de CD, que se explica con el grafico a continuación.
Figura 4.43
Diagrama General de Flujos CI/CD de la Aplicación Móvil.
Nota. De izquierda a derecha el código implementado hecho el commit respectivo en

su rama local (feature branch) se mezcla con la rama main de producción y se inicia
de forma automática un primer flujo o pipeline de CI en verde que corre un conjunto
de pruebas, de ser exitosas se inicia un segundo pipeline de CD que lleva el ejecutable
de la aplicación a un ambiente de producción.
Lo que significa que, si el pipeline de CI es exitoso se continua con el pipeline de

CD, luego de lo cual los cambios ya están disponibles en producción.

En tanto que si se presenta algún problema o error en cualquier paso del pipeline,
se detiene el proceso y dicho problema debe ser resuelto a la brevedad.
Ahora revisaremos los pasos o steps que están contenidos en cada pipeline, co-
menzando por el de CI.
Figura 4.44
Diagrama de Pasos del Flujo CI de la Aplicación Móvil.
Nota. De izquierda a derecha los pasos del flujo de CI de la aplicación móvil, primero se
prepara o actualiza el ambiente virtual para compilar apps Android (ensureContainer
o updateContainer ), para luego proceder con la compilación (Build ) sea en modo de-
puración (buildDebug) o modo productivo (buildRelease), pasando luego a las pruebas
unitarias (Test - testDebug) y finalmente las pruebas de aceptación (AcceptanceTest)
en dispositivos virtuales.
El gráfico nos muestra una serie de pasos de color verde lo cual indica que fueron
exitosos mientras que si estuvieran de color rojo presentarı́an algún fallo deteniendo
todo el flujo.
El pipeline consta de cuatro pasos, primero Environment para preparar el am-
biente donde se ejecutarán todos los trabajos, Build, en el cual se compila la aplicación,
seguido de Test donde se corren todas las pruebas unitarias y finalmente Acceptancetest,
que corre pruebas de aceptación en dispositivos virtuales o reales en la nube.
En los siguientes puntos se describen con mayor detalle los trabajos que se ejecu-
tan en cada paso:
ensureContainer , se encarga de preparar un contenedor Docker compatible con

el SDK de Android para poder compilar y probar la aplicación.
updateContainer , se encarga de realizar actualizaciones al contenedor en caso sea

necesario.
buildDebug, compila el código fuente en modo de depuración.

buildRelease, compila el código fuente en modo de release para producción.
testDebug, corre todas las pruebas unitarias en modo depuración.
Acceptancetest, corre las pruebas de aceptación y/o integración en un dispositivo

en nube, como si se tratara de un usuario real.
En seguida se analiza el pipeline de CD.
Figura 4.45
Diagrama de Pasos de CD de la Aplicación Móvil.
Nota. Se muestran los ambientes por los cuales pasa la aplicación móvil dentro del flujo
de CD, empezando por Internal donde un grupo de usuarios prueba la nueva versión de
la aplicación móvil, seguidamente Alpha donde el grupo de usuarios crece, pasando a
las pruebas Beta donde usuarios invitados pueden ver la última versión y si las pruebas
son exitosas se promueve al ambiente de producción para su disponibilidad al público
en general a través la tienda de aplicaciones Google Play.
En este caso se puede notar que existen cuatro pasos para el despliegue continuo,
luego de los cuales la aplicación móvil es desplegada en la tienda de aplicaciones Google
Play:
Internal , publica la aplicación en un ambiente de pruebas interno para que un

grupo controlado de usuarios pruebe los cambios de la aplicación.
Alpha, publica la aplicación en un siguiente ambiente de pruebas para que un

grupo mayor de usuarios validen los cambios de la aplicación.
Beta, publica la aplicación y la hace visible en la tienda de Google Play solo para
cierto grupo de usuarios.
Production, libera la aplicación para el publico en general en la tienda de aplica-

ciones Google Play.

Al finalizar la atención de las tareas que se han explicado, bajo el flujo de trabajo
Kanban, estas han pasado por las colas de Build Ready, Test, Release Ready y ahora se
encuentran consideradas como Done o terminadas, lo que significa que estan disponibles
para los usuarios finales.
Ası́ mismo se procede a aplicar los instrumentos de medición CVIndepend y
CVDepend a nivel interno.
Cabe mencionar que durante el presente trabajo se han implementado otras tareas
para conseguir la construcción del MVP, en ese sentido lo que se ha buscado es explicar
a forma de ejemplo la aplicación de los métodos y técnicas más importantes de Modern
Agile con el objetivo de completar una tarea especifica.
Es importante destacar que la metodologı́a propuesta busca un enfoque integral
no solamente en la gestión y análisis, sino también detallar aspectos más técnicos,
porque la construcción de productos digitales es un proceso en el que cada etapa tiene
una repercusión en los resultados que se pretenden conseguir.
4.4.5.2. Validación del Incremento
Como se ha venido explicando una de las caracterı́sticas de la metodologı́a es

ser iterativa e incremental, y en el punto anterior se explicó cómo conseguir que un
pequeño incremento pase de la ideación y llegue hasta las manos de los usuarios donde
finalmente pretende añadir valor real.
Eso no se puede considerar como alcanzado si no se valida el impacto real del
incremento sobre los resultados que consiguen los usuarios con la solución, por tal
motivo, en este apartado se darán ciertos ejemplos de la evaluación de los resultados.
Primeramente, se aplicarán los instrumentos CVIndepend y CVDepend a los
usurarios y stakeholders con la finalidad de dar seguimiento al impacto sobre el producto
en construcción y sobre la metodologı́a misma.
En ese orden de ideas, siguiendo las prácticas de Lean UX se aplica uno de sus ins-
trumentos denominados “validación temprana” (Klein, 2013) (explicada anteriormente)

sobre el entregable funcional en producción y lo compararemos con los resultados de

los mockups en las etapas anteriores.
Para tal propósito se establece un indicador que se denominará Índice Promedio
de Dolor con las siglas IPDD que es el promedio de la valoración de dificultad que
experimentaron los usuarios, se califica desde 0 hasta 5, donde 0 significa que no tuvo
ninguna dificultar para conseguir usar cierta funcionalidad satisfactoriamente y 5 re-
presenta el mayor grado de dificultad interpretándose que el usuario no fue capaz de
interactuar con la aplicación.
Se aplica la medición sobre las funcionalidades de encontrar parqueos cercanos a
su ubicación y ver el detalle del mismo, la Tabla 4.7 muestra el resultado de aplicar
“validación temprana” en la aplicación móvil desplegada en producción a 5 usuarios.
Tabla 4.13
Resumen de Dificultades de Usuarios al Interactuar con App en Producción.

Usuario 1 No tuvo problemas (0) Ninguna
Usuario 2 No pudo visualizar (0) Mensajes de errores o
parqueos cercanos por indicaciones de flujos
conectividad (1) alternos no se visualizan
correctamente
Estos resultados nos permiten hacer una comparación objetiva, entre el IPDD
durante la validación temprana es decir los dos primeros mockups y el IPDD de la
aplicación en producción, ver Tabla 4.14 a continuación.
Tabla 4.14
Comparación de IPDD Mockups vs. App en Producción
IPDD Mockup 1 IPDD Mockup 2 IPDD App Version 1.0.0

3.4 0 0.2

Inclusive es posible graficar estos resultados y analizar la evolución del IPDD en

el tiempo, tal como se evidencia en la figura.
Figura 4.46
Evolución de IPDD para la Funcionalidad de Encontrar Parqueos Cercanos.
Nota. El IPDD comienza con un valor de 4.3 al inicio (1), se reduce a 0 al final de la
“validación temprana” (2) y se confirma dicha reducción cuando se vuelve a medir en
producción (3).
El eje horizontal representa las etapas o iteraciones en el tiempo, el eje vertical

representa el IPDD, como se vio en la primera iteración se observa un valor de 3.4, en
la segunda iteración al simplificar el diseño del flujo de Interfaces de Usuario se reduce
a 0, y en la tercera medición ya en producción es 0.2, evidenciando una correlación
positiva entre la validación temprana del diseño y la aplicación en producción.
La interpretación objetiva de estos resultados permite entender que la “validación
temprana” ha permitido prevenir fallos de diseño consiguiendo reducir el grado de
dificultad antes de la primera versión de la aplicación.
En ese entender los resultados son consistentes entre la última versión del mockup
con la versión de la app en producción, con una variación de solo 4 % lo que significa
que existen algunos detalles a mejorar en la aplicación, como son la elección de ciertos
colores y la redacción del texto mostrado bajo flujos alternos, estos se atenderán en las

siguientes iteraciones a fin de seguir mejorando la experiencia de usuario.

Es posible aplicar otros métodos Lean UX de medición de resultados, no obstante,
se ha consignado uno de los más sencillos y básicos, pero no menos efectivo que puede
ser aplicado de forma sistemática para recopilar feedback que es esencial en el proceso,
siendo a su vez parte del insumo para las próximas iteraciones.
Es ası́ como, en este punto de la descripción y dados los resultados del incremento,
se dan las condiciones para validar la hipótesis, tomando la decisión de persistir y
continuar el proceso de descubrimiento del producto que maximice la generación de
valor a los usuarios.
4.4.6. Retrospectiva
Tal como se definió en la Sección 4.2 al establecer el metaproceso de la metodologı́a

es necesario llevar a cabo revisiones del proceso conocidas como retrospectivas, las
cuales se implementan con una regularidad de dos semanas, dado que la frecuencia de
iteraciones que se ha venido dando es de pocos dı́as.
Para conseguir el objetivo de esta parte que es mejorar el proceso propiamente,
se reúne al equipo durante tiempos establecidos, por el ejemplo en sesiones con una
duración entre 30 a 60 minutos. Una de las recomendaciones más importantes de Kerth
(2013), referente a las retrospectivas es promover un ambiente de seguridad psicológica
alineado a los principios Modern Agile.
Donde cada integrante del equipo tenga la libertad de expresar sus puntos de
vista sin temor de ser juzgado o censurado de alguna manera, sin lo cual no es posible
detectar las oportunidades que son la materia prima para la mejora continua de los
métodos que se vienen aplicando y estudiando.
Las retrospectivas se realizan siguiendo una agenda de referencia para hacer de
ellas sesiones productivas sin desperdiciar tiempo ni desenfocarse durante su desarrollo.
Preparar para contar con los implementos necesarios como una pizarra (puede
ser virtual en caso de realizarse de forma remota), post-its y cronómetro.

Predisponer el escenario, de tal forma que todos tengan una actitud abierta y en
confianza para aportar, se ha optado por recordar una frase de Kerth (2013) que
resume lo que se espera promover en los miembros del equipo aquı́ se consigna
una traducción del autor: “Sin importar lo que descubramos, entendemos y verda-
deramente creemos que todos hicieron el mejor trabajo que pudieron, dado lo que
conocı́an en ese momento, sus destrezas y habilidades, los recursos disponibles y
la situación actual”. Ası́ mismo se pide total atención durante la sesión dejando
los equipos computo o teléfonos móviles para evitar distracciones.
¿Qué fue bien?, se hace esta pregunta para que cada miembro en un tiempo de 5
minutos apunte su respuesta de forma puntual, seguidamente mostrar a todos las
notas, durante 5 minutos compartir lo más destacado y 10 minutos para entender
algunos puntos por explicar.
¿Qué se necesita mejorar?, similar al punto anterior, con la diferencia de respon-

der aquello que se puede mejorar en el proceso y recalcando que no se debe
proponer soluciones en este punto, ni tampoco buscar culpables o responsables,
debe enfocarse en una búsqueda objetiva de oportunidades de mejora.
Próximos pasos, finalmente durante los próximos 10 minutos determinar las ac-
ciones, responsables y plazos para concretar lo que se necesita mejorar.
De la aplicación de retrospectivas en el proyecto se puede ejemplificar los siguien-

tes aportes:
¿Qué fue bien?
Se han prevenido bugs en código de forma temprana
Claridad en la implementación esperada
Comunicación cercana con usuarios y stackeholders
¿Qué se necesita mejorar?

Retrasos en ciertas tareas por falta conocimiento de ciertas herramientas
Resistencia a integrar cambios frecuentemente
Resistencia por solicitar feedback continuo
Próximos pasos
Capacitaciones de reforzamiento en temas como TDD, CI/CD, User Story Map-

ping, spliting, una vez por semana de 10:00 a 11:00 a cargo de un miembro del
equipo,
Reunión diaria de 5 a 10 minutos de revisión a las 9:00 AM, para absolver dudas
sobre las prácticas y comentarios sobre los cambios a integrar,
Resumen de los resultados obtenidos hasta el momento para mantener el enfoque

en las nuevas prácticas adoptadas, se enviará por correo electrónico dentro de 2
dı́as, por el responsable de la retrospectiva.
4.4.7. Comentarios al Terminar Iteración
Hasta el momento se ha venido explicando la aplicación de la metodologı́a pro-

puesta a modo de ejemplo y es importante hacer notar que se ha explicado como
entregar un pequeño incremento de la aplicación móvil a los usuarios finales totalmen-
te validado, y que este flujo en esencia se debe repetir dirigido por los valores Modern
Agile en pro de descubrir el producto que aporte el mayor valor posible.

V | Validación de la Propuesta
5.1. Resultados de Medición de Instrumentos de la Pro-
puesta
De acuerdo con la definición de los instrumentos CVIndepend y CVDepend,

se recopilan las mediciones mencionadas durante el desarrollo de presente trabajo,
el objetivo es evaluar si existe alguna relación entre las variables propuestas como
independientes y dependientes.
Con el objetivo de determinar, si influir en las variables independientes a través
de la aplicación de la metodologı́a propuesta tendrá influencia en las variables depen-
dientes, es decir si la aplicación de la metodologı́a puede reducir los errores y generar
una mayor comprensión y conocimiento de las necesidades de los involucrados, y por lo
tanto reducir sobrecostos y mejorar la satisfacción de los involucrados con el producto
final.
5.2. Resultados de Variable Independiente con CVInde-
pend
El instrumento CVIndepend, mide tres variables:
1. Errores durante el proceso,
2. Conocimiento del cliente sobre sus necesidades,
127
5.2. Resultados de Variable Independiente con CVIndepend
3. Conocimiento del equipo sobre las necesidades del cliente.
Las formas de medición han sido primeramente el registro de errores durante el

proceso, y la aplicación de encuestas a 5 personas involucradas.
El patrocinador de la aplicación,
Dos desarrolladores de software responsables de la construcción del proyecto,
Un cliente responsable de una empresa involucrada en el proyecto,
Un usuario final de referencia.
5.2.1. Errores Durante el Proceso
Para medir los errores, se contabilizaron durante la implementación de la pro-

puesta en momentos especı́ficos para su análisis.
Tabla 5.1
Recopilación de errores
Etapa dı́a Cantidad de errores

Inicio 1 0
2 0
Despegue 3 0
4 0
Split funcional 5 0
Validación UX 6 5
7 0
Implementación de MVP 8 0
9 4
10 0
11 3
12 0
Validación de Iteración 13 1
Los errores son defectos encontrados en las diferentes etapas del proceso, consi-
derando que el presente trabajo abarca hasta la primera iteración del MVP.

CAPÍTULO V. Validación de la Propuesta
La adopción de la metodologı́a propuesta ha permitido detectar problemas desde

etapas tempranas inclusive antes de la implementación del código fuente durante la
validación de UX gracias a técnicas como la “validación temprana” de Lean UX y
seguidamente haciendo uso de TDD.
Es ası́ que se detectaron errores en la programación del código fuente consiguiendo
que la primera iteración tenga únicamente 1 error en producción, en consecuencia es
posible incidir positivamente en la ocurrencia y detección de errores de forma temprana
y efectiva siguiendo los principios y métodos Modern Agile.
La gráfica que sigue muestra el comportamiento de la cantidad de errores en
función del tiempo.
Figura 5.1
Gráfica de Comportamiento de Errores en el Tiempo.
Nota. El eje horizontal representa el tiempo en dı́as, el eje vertical representa la cantidad
de errores, como se aprecia los métodos y prácticas aplicados permiten una reducción
temprana de la cantidad de errores desde 5 a los 6 dı́as, a 4 a los 9 dı́as hasta 1 a los
13 dı́as ya en producción.
Del mismo modo se puede ver el comportamiento de la cantidad de errores en

contraste con el tiempo transcurrido en dı́as y las fases correspondientes del proceso,
con ello se puede tener una mejor idea del impacto de la metodologı́a.

Figura 5.2
Gráfica Comparativa de Errores vs. Tiempo y Fases del Proceso.
Nota. El eje horizontal representa el tiempo donde se delimitan las etapas desde inicio a
la izquierda hasta validación de iteración a la derecha, el eje vertical indica la cantidad
de errores, las barras en azul son los dı́as transcurridos hasta conseguir el MVP, la lı́nea
en naranja muestra la cantidad de errores. El gráfico expresa el resultado conseguido
al guiarse por los principios Modern Agile que son reducir la cantidad de errores de
forma temprana a media que se construye y validar la aplicación móvil.
De esta manera es posible incluir el control de calidad de forma iterativa, incre-

mental e integral a lo largo del proceso.
5.2.2. Conocimiento Sobre las Necesidades del Cliente
En el caso del conocimiento de las necesidades del cliente por parte del propio
cliente y del equipo, se aplicó una encuesta detallada en la Subsección 4.2.9 donde se
mide el ı́ndice de satisfacción de cliente CSAT aplicado a los cinco involucrados en
diferentes momentos del proceso, consta de cinco preguntas, a ser valoradas de 1 a 5:

Tabla 5.2
Preguntas Encuesta CSAT – Conocimiento del Cliente sobre sus Necesidades
Pregunta Ámbito Relacionado con

¿Cuál es su participación Interno y Externo App y Otros
en el proceso?
¿Actualmente, que tanto Externo App
comprende el problema a
resolver?
¿Actualmente, que tanto Interno App
comprende los resultados
que dará la solución, a los
usuarios?
En caso haya participado Externo Otros
en procesos con otros
equipos de desarrollo de
software, ¿Qué tanto
comprendió el problema a
resolver?
En caso haya participado Interno Otros
en procesos con otros
equipos de desarrollo de
software ¿Qué tanto
comprendió los resultados
que dio la solución, a los
usuarios?
Los resultados se muestran en la tabla que sigue:

Tabla 5.3
Resultados CSAT – Conocimiento de las Necesidades del Cliente por Rol
Dı́a Fase a Patrocinador Equipo Empresa Usuario

consi-
derar
App Otros App Otros App Otros App Otros
2 Inicio 2 3 1.5 2 2 3
4 Despegue 3 3 3 3 3 3
5 Split 3 3 4 3 3 2
Fun-
cional
7 Validación 4 3 5 3 4 3 4 3
UX
12 Desarrollo 5 3 5 3 5 3 5 3
MVP
Para hacer un análisis del comportamiento del ı́ndice CSAT se evidencia su ten-
dencia en las figuras 5.3, 5.4, 5.5 y 5.6, que se muestran a continuación.

Figura 5.3
CSAT de Conocimiento de las Necesidades del Cliente por Fase, Rol Patrocinador.
Nota. Abajo se delimitan las fases del proceso desde inicio hasta implementación del
MVP de izquierda a derecha, en naranja el conocimiento de las necesidades del cliente
en otras experiencias y en azul el conocimiento de las necesidades del cliente por parte
del patrocinador en el caso de estudio, se evidencia un incremento temprano positivo
bajo la presente propuesta.

Figura 5.4
CSAT de Conocimiento de las Necesidades del Cliente por Fase para el Rol Equipo.
Abajo las fases y dı́as transcurridos de izquierda a derecha, en amarillo el conocimien-

to de las necesidades del cliente en otras experiencias de forma casi constante, y en
gris para el caso de estudio, se evidencia un incremento positivo temprano, desde la
perspectiva del equipo de desarrollo.

Figura 5.5
CSAT de Conocimiento de las Necesidades del Cliente por Fases, Rol Empresa.
Nota. Abajo delimitadas las fases del proceso y los dı́as transcurridos de izquierda a
derecha, para la empresa cuando se trata de otras experiencias el conocimiento de las
necesidades del cliente se mantiene casi constante (en verde), mientras que crece desde
el inicio de forma temprana desde 2 hasta 5 para el caso de estudio (en azul).

Figura 5.6
CSAT de Conocimiento de las Necesidades del Cliente por Fases, Rol Usuario.
Nota. A partir de la validación de UX, se muestran abajo delimitadas las fases y los dı́as
transcurridos de izquierda a derecha, donde se evidencia un comportamiento constante
cuando se trata de otras experiencias (en marrón) a diferencia del caso de estudio que
expresa un crecimiento temprano de 4 a 5 (en azul).
Se puede apreciar que mientras el conocimiento de las necesidades de los clientes

se mantiene estático, cuando se pregunta a los involucrados por su experiencia en casos
anteriores con otras aplicaciones o proyectos de software.
Mientas que el ı́ndice se incrementa en el caso de estudio mostrando una incidencia
positiva al aplicar la metodologı́a. Se evidencia una mejora en la comprensión de las
necesidades del cliente en etapas tempranas y de forma gradual.
Al consolidar el ı́ndice por fase podemos apreciar la tendencia y su evolución en
cada etapa del proceso, ver la Tabla 5.4 y la Figura 5.7.

Tabla 5.4
Consolidado de Medición CSAT de Conocimiento de las Necesidades del Cliente
Dı́a Fase CAST Conocimiento

2 Inicio 1.83
4 Despegue 3.00
5 Split Funcional 3.33
7 Validación UX 4.25
12 Implementación MVP 5.00
Figura 5.7
Evolución de CSAT de Conocimiento de las Necesidades del Cliente por Fase.
Nota. El eje horizontal representa las fases y dı́as transcurridos desde el inicio hasta
la implementación del MVP, en vertical CSAT del conocimiento de las necesidades del
cliente, la curva en azul hace notar un comportamiento favorable tras la aplicación de
la metodologı́a basada en Modern Agile, partiendo de aproximadamente 2 hasta 5 en
promedio.
Y su tendencia dı́a a dı́a en la Figura 5.8

Figura 5.8
Evolución de CSAT de Conocimiento de las Necesidades del Cliente por Dı́a.
Nota. El eje horizontal representa los dı́as transcurridos y en el eje vertical se mide
el ı́ndice del conocimiento de las necesidades del cliente en promedio, se aprecia una
incidencia positiva, temprana y favorable durante la aplicación de la metodologı́a pro-
puesta.
El resultado es coherente con el objetivo de la adopción de los principios Modern

Agile donde el aprendizaje constante de las necesidades del cliente y su validación es
el foco de las actividades implementadas.
5.2.3. Resultados de Variable Dependiente con CVDepend
Junto con la medición de las variables independientes se realizó también medición

de las variables dependientes, siendo tres:
1. Sobrecostos
2. Satisfacción del cliente respecto al producto
3. Satisfacción del cliente respecto al proceso de desarrollo.

Del mismo modo que con las variables independientes se realizó la medición en
las diferentes etapas del proceso a través de encuestas a los cinco involucrados que son
patrocinador, desarrolladores de software, cliente y usuario.
5.2.3.1. Sobrecostos
Los sobrecostos dependen de la cantidad de errores, para el presente trabajo se

considera una expresión de referencia para su cálculo en función de la cantidad de
errores registrados en un momento dado:
SobreCosto = T pSolucion ∗ CantErrores ∗ CostoXHora
Donde:
TpSolucion, Tiempo promedio de solución de un error, para el presente trabajo

será de 3 horas.
CantErrores, Cantidad de errores en una etapa determinada.
CostoXHora, Costo promedio de desarrollo por hora, para el presente trabajo

será de S. 50.
Una vez recopilados los datos en la Tabla 5.1, y aplicándose la expresión de

sobrecostos la Tabla 5.5 muestra los resultados para el caso de estudio.

Tabla 5.5
Resultados de Sobrecostos por Dı́a
Dı́a Cantidad de errores Sobre Costo en S.

1 0 0
2 0 0
3 0 0
4 0 0
5 0 0
6 5 750
7 0 0
8 0 0
9 4 600
10 0 0
11 3 450
12 0 0
13 1 150
Nota. La relación en entre la cantidad de errores y sobrecostos es conocida, y como se explicó

en el apartado anterior su reducción es muy importante dentro de la aplicación de los métodos
y prácticas Modern Agile, más aún cuando se da en etapas tempranas del ciclo de desarrollo,
tanto dentro del diseño de la UX como durante la implementación del código fuente. Ya que
también previene otros costos como retrabajos a consecuencia de un diseño deficiente.
Estos resultados facilitan adicionalmente elaborar un gráfico de la función de

sobrecostos con los datos recopilados durante el proceso.

Figura 5.9
Gráfica de Relación Cantidad de Errores y Sobrecostos.
Nota. En horizontal la cantidad errores detectados durante el proceso, en vertical el

sobrecosto asociado, la gráfica en azul muestra la relación directamente proporcional
entre la cantidad de errores y los sobrecostos, de allı́ la importancia de su reducción
temprana.
Con la Figura 5.9 se explica la relación directa que existe entre la cantidad de
errores y los sobre costos, por tanto, reducir los errores reduce directamente los sobre-
costos.
5.2.3.2. Satisfacción del Cliente Respecto al Producto y al Proceso de Desarrollo
En este caso se han tomado encuestas a los involucrados en las etapas del pro-
ceso de desarrollo midiendo el CSAT respecto en primer lugar al producto como tal y
también al proceso de desarrollo con una valoración de 1 a 5.

Tabla 5.6
Resumen de Preguntas CSAT del Producto, CVDepend
Pregunta Abreviatura / Palabra Clave

¿Cuál es el grado de satisfacción que Producto
tiene del producto desarrollado?
¿Cuál es el grado de satisfacción que Resultados
tiene de los resultados que le permite
alcanzar el producto desarrollado?
¿Cuál es el grado de satisfacción que Proceso
tiene del proceso de desarrollo del
producto?
¿Cuál es el grado de influencia que tiene Influencia
el proceso de desarrollo sobre el
producto desarrollado?
Por cuestiones de espacio las abreviaturas o palabras clave de la Tabla 5.6 se

usarán para hacer referencia a las preguntas correspondientes en los siguientes gráficos y
tablas, los resultados se consolidan primeramente de acuerdo con la fase y participación.
Tabla 5.7
Resultados de CSAT CVDepend por Dı́a, Fase y Rol
Dı́a Fase Patrocinador Equipo Empresa Usuario

2 Inicio 1.25 1.5 1.25
4 Despegue 2 3 1.5
5 Split 2.5 3.75 2.5
Funcional
7 Validación 2.75 4.5 2.5 3.75
UX
12 Implementación 3.75 4.75 3.25 3.75
MVP
Los cuales se grafican para observar su comportamiento.

Figura 5.10
Gráfico de Barras del Comportamiento CSAT CVDepend por Dı́a, Rol y Fase.
Nota. Abajo las fases delimitadas por dı́as transcurridos, mientras que el eje vertical
representa el CSAT de la variable dependiente, las barras representan los roles involu-
crados, en azul el patrocinador, en gris el equipo de desarrollo en celeste la empresa y en
azul los usuarios de la aplicación. Se expresa una incidencia positiva tras la aplicación
de la metodologı́a propuesta desde las primeras etapas.
Entonces se puede entender que existe un comportamiento positivo respecto a la

satisfacción del producto, tomando en cuenta que se trata de la parte inicial del proceso
de desarrollo de la aplicación.
A continuación, se consolidan los datos con la finalidad de observar el comporta-
miento de toda la variable como se ve en la tabla a continuación.

Tabla 5.8
Resultados CSAT CVDepend Consolidados por Pregunta y Fase.
Pregunta\Fase Inicio Despegue Split Validación Implementación

funcional UX MVP
Producto 1 1.5 2.5 3.2 3.8
Resultados 1 2 2.5 3.2 4
Proceso 2.5 2.75 3.5 4 4.2
Influencia 1 3.25 4 4 4.2
La satisfacción del producto crece con el tiempo incluso al tratarse de fases tem-
pranas del proceso de desarrollo, y del mismo modo los involucrados ya pueden obtener
resultados a través de la solución lo cual permite recopilar el feedback respectivo te-
niendo la capacidad de validar el conocimiento adquirido y saber si se debe mantener
la propuesta o realizar ajustes y/o cambios.
De otro lado el proceso va siendo mejor comprendido en relación con el tiempo
incidiendo en su valoración por parte de los involucrados cuando se evalúa el grado de
influencia de la metodologı́a sobre el producto final.
Con la finalidad de observar y proponer una relación entre las variables indepen-
dientes y dependientes como consecuencia de la aplicación de los métodos y prácticas
guiadas por los principios Modern Agile, se resumen los hallazgos en la Tabla 5.9.
Tabla 5.9
Relación Propuesta CSAT de CVIndpend vs. CSAT de CVDepend
Dı́as Fase CSAT CSAT Producto

Conocimiento
2 Inicio 1.83 1.33
4 Despegue 3.00 2.17
5 Split Funcional 3.33 2.92
7 Validación UX 4.25 3.38
12 Implementación 5.00 3.88
MVP

De estos resultados se desprende la gráfica que sigue para evidenciar la relación

propuesta entre las variables independiente y dependiente.
Figura 5.11
Relación Propuesta CVIndepend vs. CVDepend.
Nota. La gráfica muestra en el eje horizontal el CSAT del conocimiento de las nece-
sidades del cliente y en el eje vertical CSAT del producto, la curva en azul expresa
una relación positiva entre ambas variables como consecuencia de poner en práctica
las recomendaciones de la metodologı́a propuesta, maximizando la satisfacción de los
involucrados durante todo el proceso.
La relación propone en consecuencia, que la adopción de la metodologı́a dirigida

por los principios Modern Agile en el caso de estudio de la aplicación móvil empresarial
DondeParqueo sobre las variables independientes puede influir positivamente en las
variables dependientes de forma iterativa e incremental desde las etapas más tempranas
del proceso de desarrollo de software.

VI | Evaluación de la Propuesta
6.1. Ventajas
Durante la propuesta, adaptación y aplicación de los métodos y prácticas Modern

Agile alineados a sus cuatro principios, se ha evidenciado las ventajas de:
Contar con un proceso enfocado en los resultados de los clientes, es decir en la

generación real de valor para el negocio.
Para sustentar este punto se parte de la definición del MVP en función del negocio
y en colaboración con los involucrados (Subsección 4.4.4 y Figura 4.21).
Del mismo modo se ha conseguido un alineamiento claro con objetivos concretos

y medibles como se muestra durante la implementación del Agile Chartering
(Subsección 4.4.2 y Subsubsección 4.4.2.4).
Sin dejar de mencionar que el despliegue de la primera versión en producción, se

completó en 12 dı́as, como consecuencia de entre otras prácticas el User Story
Map (Figura 4.20), flujo de trabajo Kanban (Subsección 4.4.3), el enfoque Lean
StartUp (Figura 4.5) y la validación temprana de UX (Figura 4.27) que ha influido
positivamente durante la validación de la propuesta cuando se midió el IPDD en
Tabla 4.14 y el incremento sobre el ı́ndice satisfacción del producto expresado en
la Figura 5.11.
Tener herramientas que permitan hacer de la seguridad un prerrequisito, a

partir de la cual se puede formar equipos más predispuestos a innovar y aportar.
146
CAPÍTULO VI. Evaluación de la Propuesta
Durante el trabajo se ha sostenido la importancia de la seguirdad en consecuen-

cia se han adoptado prácticas como TDD, Clean Architecture, Split aplicadas
en la Tabla 4.4.5.1 , Retrospectivas documentadas en Subsección 4.4.6, el pro-
pio Agile Chartering visto en Subsubsección 4.4.2.4 con la matriz de Impacto y
Probabilidad de la Figura 4.17.
Establecer una forma concreta de aprender y experimentar rápidamente, co-

locando al conocimiento de las necesidades del usuario final como el principal
objetivo del proceso.
La experimentación es parte fundamental del modelo propuesto, todo el proceso

está guiado por los conceptos de Lean StartUp (Subsección 4.4.4), que como se
explicó ampliamente en el trabajo está basado en el método cientı́fico, partien-
do de una hipótesis en Subsección 4.4.4, que se ha buscado validar durante el
desarrollo de la propuesta.
Dotar a los equipos de desarrollo de software de lineamientos prácticos con el

objetivo de entregar valor continuamente a los clientes y usuarios, de diversas
formas y durante todo el proceso.
Entre estos lineamientos podemos mencionar:
• Priorización de User Story Map (Subsección 4.4.4)
• Aplicación de Split de Tareas (Tabla 4.4.5.1)
• Adoptar TDD (Tabla 4.4.5.1 y Figura 4.37)
• Implementar CI/CD (Figura 4.4.5.1)
• Limitar el WIP (Subsección 4.4.3)
• Aprovechar Lean UX (Tabla 4.8).
Los resultados conseguidos permitieron por ejemplo contar con el MVP en 12

dı́as con un grado de satisfacción esperado tal como se mostró en el Capı́tulo V.

6.1. Ventajas
Otras ventajas que pueden destacarse en función del impacto en el producto

pueden ser:
La metodologı́a no constituye una norma o conjunto de pasos rı́gidos, sino más

bien una guı́a o ejemplo de como encontrar una propia.
En lı́nea con lo expuesto en el marco teórico al definir el concepto de metodologı́a

ágil en la Sección 2.3 queda aclaro que cada equipo, en cada situación y contexto
particular define su propia metodologı́a. Y más adelante al documentar las crı́ticas
más importantes a los mitos y preconceptos predominantes de la entre comillas
“agilidad” (Sección 2.5), es pertinente liberar a los equipos de imposiciones y
prácticas rı́gidas en busca de enfoques más integrales y flexibles como lo es Modern
Agile detallado a profundidad en la Sección 2.6.
Es ası́ que el presente trabajo versa justamente sobre el proceso del autor para
encontrar una metodologı́a que le sirva en el contexto especı́fico de su caso de
estudio, y esto sea un modelo o referencia para otros esfuerzos similares tal como
se busca en el objetivo general (Subsección 1.4.1).
Disponer de herramientas, que guı́en a los equipos de desarrollo de software

especialmente de aplicaciones móviles empresariales a enfocarse en lo realmente
importante.
Dentro de Modern Agile esta implı́cito considerar en todas las prácticas y méto-
dos un pensamiento lean, donde se busca eliminar todo desperdicio en el diseño
y construcción del producto digital, véase Subsección 4.4.4, Subsección 4.2.3 y
Figura 4.6.
Contempla una forma de evaluar la propia metodologı́a con la finalidad de

mejorar sus prácticas de forma periódica.
Debidamente especificado al proponer el metaproceso (Sección 4.2), con las retros-

pectivas que se implementan en la propuesta en la Subsección 4.4.6 dando como
resultado un conjunto de acciones de mejora al proceso en la Subsección 4.4.6.

Permite adaptarse a equipos pequeños y multifuncionales promoviendo su au-

tonomı́a.
Como se explica en el marco teórico en la Sección 2.6, Modern Agile es libre

de marco de trabajo y no impone ninguna restriccı́ón a nivel humano de como
lograr sus objetivos a diferencia de otros enfoques, y al mismo tiempo el equipo
que trabajó en el caso de estudio es de dos personas que fueron capaces de llevar
el producto desde la ideación hasta las manos de los usuarios en producción
(Elemento b de Subsubsección 4.4.2.4).
Dirige los esfuerzos del equipo para generar el mayor impacto posible con la
menor cantidad de recursos disponibles, maximizando el valor entregado a los
usuarios e involucrados.
Para lograrlo el equipo se ha alineado convenientemente en el Liftoff (Subsec-

ción 4.4.2), definió su MVP (Subsección 4.4.4) acotando el alcance y reduciendo
los sobrecostos en la Subsubsección 5.2.3.1.
6.2. Requisitos
Los requisitos más importantes para la implementación de este tipo de metodo-

logı́as están dados por la adopción de los cuatro principios Modern Agile.
Hacer a la gente impresionante,
Hacer de la seguridad un prerrequisito,
Experimentar y aprender rápidamente,
Entregar valor continuamente.
Como se explicó en el marco teórico las prácticas o métodos a implementar de-

ben ser dirigidos por estos principios. No obstante el requisito inicial está dado por

6.3. Costos e Inversión
hacer un cambio de mentalidad hacia lo que se conoce como Agile Mindset, expuesto
detalladamente por Denning (2019) en su artı́culo publicado en Forbes.
Partiendo de aceptar que la tendencia de los equipos es mantener la forma tradi-
cional, intuitiva o “convencional” de llevar a cabo la construcción de productos digitales.
Ası́ mismo que las opiniones y puntos de vista del equipo o responsables de la implemen-
tación son limitadas y tendrán dificultades para estar en sintonı́a con las necesidades
reales de los usuarios.
Seguidamente llegar a entender que la razón de ser un producto digital debe
ser, mejorar la vida de sus usuarios de forma concreta. Es cuando cobra relevancia la
propuesta de Modern Agile que permite conseguirlo partiendo de un enfoque cientı́fico.
Una vez asumidas estas premisas, es crucial tener conciencia que la disciplina es
indispensable para que los resultados sean sostenibles en el tiempo, los cuales deben
ser medidos, evaluarlos y perfeccionados continuamente.
6.3. Costos e Inversión
Se debe indicar primeramente que al tratarse de una metodologı́a sus costos varı́an
según las herramientas y la forma de aplicación especifica en cada caso, sin embargo,
para el ejemplo del presente trabajo, se especifican las herramientas usadas.

Tabla 6.1
Costos de Licencias Usadas en Propuesta
Herramienta Propósito Costo S. Descripción

Survey Monkey Medición 0 Libre, Encuestas
Trello Planificación 0 Libre, Kanban
Figma Diseño 0 Libre, Mockups y
Wireframes
Miro Planificación 0 User Story
Mapinglés
GitLab Desarrollo de 120 Para repositorio de
Software código y CI/CD
Google Cloud Despliegue 1200 Cluster de
Kubernetes
Total 1320
6.4. Beneficios
Los beneficios más importantes están relacionados con los resultados obtenidos
durante la medición de las variables dependientes e independientes.
Reducción y mitigación de errores tanto de diseño como de codificación.
Se consigue a través de la adopción TDD (Figura 4.4.5.1) y la validacion temprana

(Subsubsección 4.4.5.2 en la Subsubsección 4.4.5.2) de Lean UX cuya reducción
queda especificada en la Subsección 5.2.1 al revisar la Tabla 5.1 y la Figura 5.2.
Mejora en la compresión de las necesidades del cliente, por parte de los invo-
lucrados.
De acuerdo con la definición de las variables independientes de la Subsubsec-

ción 1.4.3.1 se ha medido el CSAT (Customer Satisfaction Score) o, indice de sa-
tisfacción del cliente respecto al conocimiento de sus necesidades y se ha registrado
en momentos especı́ficos del proceso. La recopilación de estos datos expresada en
la Subsección 5.2.2 envidencia resultados a través de la Tabla 5.4, la Figura 5.7 y

6.4. Beneficios
la Figura 5.8, donde es posible indicar que la aplicación de la propuesta mejora

el ı́ndice de satisfacción desde fases tempranas de la metodologı́a.
Reducción de sobrecostos y retrabajos.
En la Subsubsección 5.2.3.1 se explica convenientemente la relación entre sobre-

costos y cantidad de errores y cómo una reducción de errores reduce directamente
los sobrecostos y retrabajos, evidenciado en la Tabla 5.5 y en la Figura 5.9.
Mejorar la satisfacción de los usuarios respecto al producto final.
Como se demostró en los puntos anteriores se ha mejorado la satisfacción del

cliente respecto del conocimiento de sus necesidades, y a partir de ello se ha me-
dido como parte de las variables dependientes (Subsubsección 1.4.3.1) el CSAT
(Customer Satisfaction Score) o indice de satisfacción del cliente respecto al pro-
ducto y al proceso, documentado en la Subsubsección 5.2.3.2 explicado en: la
Tabla 5.6, Tabla 5.7, Figura 5.10, Tabla 5.9 y la Figura 5.11.
En consecuencia existe una incidencia positiva entre el ı́ndice de satisfacción del

cliente respecto del conocimiento de sus necesidades y el ı́ndice de satisfacción del
cliente respecto al producto y al proceso, en otras palabras el haber conseguido
mejorar el conocimiento de las necesidades del cliente ha permitido construir un
producto digital y encontrar un proceso con un mayor grado de satisfacción.

Conclusiones
El objetivo general de esta tesis era definir un modelo de desarrollo de aplicaciones

móviles empresariales basado en Modern Agile, ası́ pues la aportación principal es el
diseño, implementación y evaluación de una metodologı́a guiada por los principios
Modern Agile aplicada al caso de ejemplo de una aplicación móvil empresarial. La
cual constituye una guı́a o referencia desde un enfoque cientı́fico que sin pretender
ser una lista de pasos rı́gida, busca ofrecer un punto de partida para llevar a cabo
la construcción de un producto de software centrado en el cliente, viable y al mismo
tiempo acorde con una mentalidad Agile.
En ese orden de ideas, como objetivo especı́fico se buscó determinar las condicio-
nes para aplicar el modelo de acuerdo con la definición de los prerrequisitos, al tratarse
de una metodologı́a era importante comprender sus fundamentos teóricos y su crı́ti-
ca a muchos conceptos de “agilidad” que se vienen difundiendo actualmente y que de
acuerdo con el análisis de varios autores vienen siendo en realidad perjudiciales en la
industria. También era importante, planificar la estrategia de aplicación del modelo,
mediante la definición de las fases del modelo, determinación de las técnicas de análisis,
diseño y propuesta técnica, la propuesta metodológica tiene todo un apartado especial
para lo que se denomina “metaproceso”, que viene a ser un marco de referencia dentro
del cual incluir las prácticas y métodos a ser adoptados.
A su vez define una ruta desde como empezar y las fases más importantes a consi-
derar, se enfoca en la iteración y entrega constante de resultados, ası́ mismo determina
parámetros de validación y ajustes de acuerdo a cada situación y tiene mecanismos
153
6.4. Beneficios
para la evaluación de la propia metodologı́a promoviendo su mejora continua. Ası́ tam-

bién, se pretendió llevar a cabo la construcción de una solución, mediante la propuesta
de técnicas de implementación y definición de métodos de despliegue y distribución, es
ası́ como la propuesta tomó un caso especı́fico, la aplicación móvil empresarial Don-
deParqueo para la aplicación de la metodologı́a hasta entregar un producto mı́nimo
viable.
Y como cuarto objetivo especı́fico, se tuvieron que elaborar lineamientos para
afrontar el proceso de evolución del producto, siendo estos una consecuencia de contar
con un “metaproceso” y haber implementado un caso concreto de aplicación móvil
empresarial. Se han contemplado los ejemplos y experiencias para afrontar la evolución
del producto, es de notar también que la metodologı́a promueve el descubrimiento del
mejor producto que genere valor real a los usuarios a diferencia de una imposición de
los responsables de su desarrollo, eso significa que los métodos y prácticas en esencia
están enfocados en evolucionar la solución de forma coherente, validando cada paso en
el proceso.

Recomendaciones
De la experiencia recogida en el presente trabajo y en otros relacionados con

metodologı́as ágiles para el desarrollo de aplicaciones móviles o similares, se pone de
manifiesto la amplitud de temas, casos de estudio y enfoques que puede tener, dado
que se tratan de problemas multidisciplinarios que inclusive exceden la Ingeniera de
Software y las Ciencias de la Computación. De otro lado se hace evidente también la
importancia y relevancia de su estudio por las implicaciones que tiene en la innovación
y rigurosidad tan necesarias en al ámbito del desarrollo de software, lo cual no debe
ir en detrimento de la eficiencia y rentabilidad desde un punto de vista comercial,
económico o de competitividad en la industria. Es en ese contexto que se dejan algunas
recomendaciones que pueden servir de punto de partida para otros trabajos relacionados
o afines.
Desde un punto de vista metodológico este trabajo ha sido una descripción y
exploración de la propuesta que ha contado con criterios concretos de validación de un
caso práctico, no obstante es posible realizar estudios cuantitativos con la finalidad de
comparar los resultados de la aplicación de metodologı́as basadas en los principios de
Modern Agile y otras que no usan una metodologı́a ágil, inclusive con otros enfoques
que se denominan “ágiles”, a fin de analizar los resultados en relación con la generación
de valor a los clientes y usuarios finales.
De otro lado en relación con su importancia académica se recomienda continuar
contribuyendo en el estudio metodológico del desarrollo de software no solo desde una
mirada técnica sino multidisciplinar, ya que dentro de cuarta revolución industrial la
155
6.4. Beneficios
construcción de productos digitales hoy conocidas como experiencias digitales se en-

cuentra en la base del desarrollo tecnológico, económico y por qué no cientı́fico actual,
por ende su estudio, diseño y evolución es un aporte que no debe ser dejado de lado por
el ámbito académico, estos estudios pueden estar relacionados con las mejoras de pro-
ductividad, requisitos para su implementación, su impacto en la cultura organizacional
y también en su aplicación en diferentes sectores e industrias.
No se quiere dejar de mencionar ciertas recomendaciones a nivel práctico que
se puedan tomar en cuenta, como es el estudio de estos casos de aplicación en un
mayor periodo de tiempo a fin de tener un seguimiento más amplio de los resultados
obtenidos, en ese sentido también es factible ampliar el estudio de la metodologı́a a toda
la cadena de valor de un producto digital e incluir la parte económica y de rentabilidad
que en opinión del autor también deben alinearse a los principios de Modern Agile, si
consideramos que “ágil” es un adjetivo y un negocio seguramente también lo necesita
ser.

Bibliografı́a
Agile Alliance (2015a). Agile 101. https://www.agilealliance.org/agile101/.
Agile Alliance (2015b). Glosary velocity. https://www.agilealliance.org/

glossary/velocity/#q=~(infinite~false~filters~(postType~(~’page~’
post~’aa_book~’aa_event_session~’aa_experience_report~’aa_glossary~’
aa_research_paper~’aa_video)~tags~(~’velocity))~searchTerm~’
~sort~false~sortDirection~’asc~page~1).
Anderson, D. (2010). Kanban: Successful Evolutionary Change for Your Technology

Business. Blue Hole Press, Sequim, USA.
Azorı́n, P. (2019). 5 reasons apps fail. https://clutch.co/app-developers/

resources/reasons-apps-fail.
Balajee, N. (2020). What is ci/cd pipeline? https://nanduribalajee.medium.com/

what-is-ci-cd-pipeline-e2f25db99bbe.
Beck, K. (2003). Test-driven development: by example. Addison-Wesley Professional.
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,
Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin,
R. C., Mellor, S., Schwaber, K., Sutherland, J., and Thomas, D. (2001). Manifesto
for agile software development.
Bergen, P. (s.f.a). Ports and adapters, hexagonal architecture. http://www.

dossier-andreas.net/software_architecture/ports_and_adapters.html.
157
BIBLIOGRAFÍA
Bergen, P. (s.f.b). Ports and adapters, hexagonal architecture [gráfico]. https://www.

dossier-andreas.net/software_architecture/ports-and-adapters.png.
Bezos, J. (2016). Ex-99.1. https://www.sec.gov/Archives/edgar/data/1018724/

000119312516530910/d168744dex991.htm.
Cejas, F. (s.f.). Android-cleanarchitecture-kotlin. https://github.com/android10/

Android-CleanArchitecture-Kotlin.
Centro de Desarrollo Industrial: CDI (2018). Nota de prensa - wef publi-

ca informe de competitividad global 2018 con nueva estructura. https:
//www.sni.org.pe/wp-content/uploads/2018/10/Nota-de-prensa-%C3%
8Dndice-de-Competitividad-Global-4.0-FINAL.pdf.
Cruzado, D. (2018). Mercado de apps móviles llegará a

s/ 50 millones este año. https://gestion.pe/tecnologia/
mercado-apps-moviles-llegara-s-50-millones-ano-237168#.
Denning, S. (2019). Understanding the agile mindset. https://www.forbes.com/

sites/stevedenning/2019/08/13/understanding-the-agile-mindset/?sh=
e4d53395c17f.
DevTernity (Productor) (2017). Devternity 2017: Ian cooper - TDD, where did it all
go wrong [video]. https://www.youtube.com/watch?v=EZ05e7EMOLM.
Duhigg, C. (2016). Smarter faster better: The secrets of being productive. Random
House.
El Peruano (2019). El Perú proyecta invertir 1% de

PBI en innovación. https://elperuano.pe/noticia/
75857-el-peru-proyecta-invertir-1-del-pbi-en-innovacion.
Española, R. A. and Madrid, E. (2001). metodologı́a, volume 22. Real academia espa-
ñola Madrid.

BIBLIOGRAFÍA
Goedvolk, H. (1995). Section 4.5 (vision) – architectures. https://www.rijsenbrij.

net/archive1/vision/eng/vis450h1.htm.
Google Developers (s.f.). Fundamentals of testing android apps | android developers

[Gráfico]. https://developer.android.com/training/testing/fundamentals.
Grech, S. (2014). Onion architecture, NTier, IOC, blog, incredible web, web develop-
ment. https://www.incredible-web.com/blog/the-onion-architecture/.
Hernández, R., Fernández, C., and Baptista, M. d. P. (2014). Metodologı́a de la inves-

tigación. McGraw-Hill / INTERAMERICANA EDITORES, S.A. DE C.V., México
D.F. México.
Highsmith, J. (2011). Velocity is killing agility! http://jimhighsmith.com/

velocity-is-killing-agility/.
Holub, A. (2022). [@allenholub]. https://twitter.com/allenholub/status/

1590494387347128320?s=20&t=iKBBW6Bj4-VQqFbjzY8wmg.
Industrial Logic (2022). Industrial logic - modern agile consultancy. https://www.

industriallogic.com/.
Industrial Logic (s.f.). eLearning. https://www.industriallogic.com/training/

elearning/.
Jeffries, R. (2013). Estimation is evil: Overcoming the estima-

tion obsession. https://medium.com/pragmatic-programmers/
estimation-is-evil-overcoming-the-estimation-obsession-60ce0544ac1e.
Kerievsky, J. (2012). Stop using story points. https://www.industriallogic.com/

blog/stop-using-story-points/.
Kerievsky, J. (2015a). Modern agile. https://www.industriallogic.com/blog/

modern-agile/.

BIBLIOGRAFÍA
Kerievsky, J. (2015b). modernagile.org. http://modernagile.org/.
Kerievsky, J. (2016). An introduction to modern agile. https://www.infoq.com/

articles/modern-agile-intro/.
Kerievsky, J. (2017). Agile Prague Conference: Agile Prague Conference. https:

//agileprague.com/slides/ap2017/modernAgilePrague2017.pdf.
Kerievsky, J. (2018). YOW! 2017 joshua kerievsky - modern agile #YOW [video].
https://www.youtube.com/watch?v=CKu8vjnlaCk&t=810s.
Kerschberg, B. (2019). 4 critical reasons to build enterprise

apps. https://www.forbes.com/sites/benkerschberg/2019/01/29/
four-critical-reasons-to-build-enterprise-apps/?sh=691693e87d51.
Kerth, N. (2013). Project retrospectives: a handbook for team reviews. Addison-Wesley.
Klein, L. (2013). UX for lean startups: Faster, smarter user experience research and
design. .O’Reilly Media, Inc.”.
Kony (s.f.). Enterprise apps. https://docs.kony.com/konylibrary/management/

emm_simpleauthentication_user_guide/Content/Enterprise_Apps_List.htm.
Larsen, D. and Nies, A. (2011). Liftoff: Launching Agile Teams & Projects. Onyx Neon
Press, Hillsboro, OR.
Larsen, D. and Nies, A. (2016). Liftoff: Start and Sustain Successful Agile Teams.
Pragmatic Bookshelf.
Lumbreras, J. (2012). ¿quién es quién en el mercado de ‘software’ ? El Comercio,

page 18.
Martin, R. C. (2012). The clean architecture. https://blog.cleancoder.com/

uncle-bob/2012/08/13/the-clean-architecture.html.

BIBLIOGRAFÍA
Mendoza, M. (2018). Fábricas de software locales manejan más

de 2.500 ingenieros. https://elcomercio.pe/economia/negocios/
fabricas-software-locales-manejan-2-500-ingenieros-noticia-502415-noticia/.
Microsoft (sf). Satya nadella - stories. https://news.microsoft.com/exec/

satya-nadella/.
Nadella, S. (2017). Oprime Refrescar. HarperCollins Espanol.
Ochoa, V. (2019). Mercado de la informática en Perú crece-

rá 9.7 % este año. https://gestion.pe/economia/empresas/
mercado-informatica-peru-crecera-9-7-ano-260535-noticia/.
Ottinger, T. (2022). [@tottinge]. https://twitter.com/tottinge/status/

1589743506310201345?s=20&t=iKBBW6Bj4-VQqFbjzY8wmg.
Palermo, J. (2008). The onion architecture : part 1. https://jeffreypalermo.com/

2008/07/the-onion-architecture-part-1/.
Patrick, R. (2018). 8 essential features of an enterprise mobility app. https://dzone.

com/articles/8-essential-features-of-an-enterprise-mobility-app.
Patton, J. and Economy, P. (2014). User story mapping: discover the whole story, build
the right product. .O’Reilly Media, Inc.”.
Project Management Institute (2018). Pulse of the Profession 2018: Success in

Disruptive Times. https://www.pmi.org/-/media/pmi/documents/public/pdf/
learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf.
Redacción Gestión (2022). Seis profesiones en tecnologı́a con mayor

demanda y con sueldos que podrı́an superar los s/ 9,000 | econo-
mia | gestiÓn. https://gestion.pe/economia/management-empleo/
seis-profesiones-en-tecnologia-con-mayor-demanda-y-con-sueldos-que-podrian-supera
?ref=gesr.

BIBLIOGRAFÍA
Ries, E. (2011). The lean startup: How today’s entrepreneurs use continuous innovation
to create radically successful businesses. Currency.
Roberts, M. (2018). Serverless architectures. https://martinfowler.com/articles/

serverless.html.
Salas, L. (2020). Mercado de aplicativos en el paı́s moverá alrede-

dor de s/ 100 millones este año. https://peru21.pe/economia/
mercado-de-aplicativos-en-el-pais-movera-alrededor-de-s-100-millones-este-ano-ncze-
Schwab, K. (2019). The global competitiveness report 2019. https://www3.weforum.

org/docs/WEF_TheGlobalCompetitivenessReport2019.pdf.
Schwaber, K. and Sutherland, J. (2017). La guı́a de Scrum TM (Sa-

lazar L.)). https://www.scrumguides.org/docs/scrumguide/v2017/
2017-Scrum-Guide-Spanish-SouthAmerican.pdf.
Scrum.org. (s.f.). What is scrum? https://www.scrum.org/resources/

what-is-scrum.
Sierra, K. (2015). Badass: Making users awesome. O’Reilly Media, Inc.
Slesar, M. (s.f.). How to choose the right tech stack for a mobi-
le application - part i. https://alternative-spaces.com/blog/
how-to-choose-the-right-tech-stack-for-a-mobile-application-part-i/.
Stack Overflow (2018). Stack overflow developer survey 2018. https://insights.

stackoverflow.com/survey/2018#development-practices.
techopedia (2020). What is a mobile application? https://www.techopedia.com/

definition/2953/mobile-application-mobile-app.
Wellingtone Project Management (2017). The state of project management

survey 2016. https://www.wellingtone.co.uk/wp-content/uploads/2017/03/
The-State-of-Project-Management-Survey-2017-1.pdf.

BIBLIOGRAFÍA
Wells, D. (1999a). The rules of extreme programming. http://www.

extremeprogramming.org/rules.html.
Wells, D. (1999b). The values of extreme programming. http://www.

extremeprogramming.org/values.html.
Wells, D. (2013). Extreme programming: A gentle introduction. http://www.

extremeprogramming.org/.

Glosario de Términos
A/B testing También conocido como split testing, se refiere a un proceso de experi-
mentación aleatorio en el que dos o más versiones de una variable (página web,
elemento de página, etc.) se muestran a diferentes segmentos de visitantes del si-
tio web al mismo tiempo para determinar qué versión deja el máximo impacto. e
impulsa las métricas comerciales. Traducido de https://vwo.com/ab-testing/
40, 64
anzeneer Una nueva palabra derivada de anzen (que significa seguridad en japonés) e
ingenierı́a. Traducido de https://www.industriallogic.com/blog/anzeneering/
38
asset Se traduce com aserciones, y son mayormente para la validación de los casos de
pruebas. 115
backbone Dentro de la terminologı́a de Use Story Map, se refiere a la columna vertebral

o también conocidado como flujo narrativo. xiv, 56, 69, 82
backend Parte de un sistema informático, pieza de software, etc., donde los datos se
almacenan o procesan en lugar de las partes que el usuario ve y usa directamen-
te. Traducido de https://dictionary.cambridge.org/dictionary/english/
back-end xi, xii, 40, 76, 96, 116, 117, 199, 200, 210, 215, 218, 220, 221
backlog Gran número de cosas esperando por hacer. Traducido de https://dictionary.

cambridge.org/dictionary/english/backlog xv, 94
164
Build Dentro de terminologı́a Lean, es el proceso de construcción de un prototipo o

versión de un producto 58
burn-down chart Gráfico que muestra la cantidad de trabajo que se ha completado

en un epic o sprint, y el trabajo total restante. Los gráficos Burndown se uti-
lizan para predecir la probabilidad de que su equipo complete su trabajo en el
tiempo disponible. También son excelentes para mantener al equipo al tanto de
cualquier avance del alcance que ocurra. Traducido de https://www.atlassian.
com/agile/tutorials/burndown-charts 39
burn-up chart Gráfico que roporciona una representación visual del trabajo comple-
tado de un sprint en comparación con su alcance total. Ofrece información sobre
el progreso de un proyecto, ası́ como también ofrece advertencias para ayudar a
mantener la salud de un proyecto; puede identificar instantáneamente problemas
como la desviación del alcance o una desviación de la ruta planificada del pro-
yecto. Traducido de https://support.atlassian.com/jira-software-cloud/
docs/view-and-understand-the-burnup-chart/ 39
Business to Consumer Venta de bienes o servicios directamente a los clientes para su

propio uso, en lugar de a las empresas. Fuente https://dictionary.cambridge.
org/es/diccionario/ingles/b2c 68
Chartering Enfoque de documentación ligero para crear entendimiento inicial y acuer-

dos sobre el producto y el trabajo (Larsen and Nies, 2016, pos.582). 35, 41, 74,
75, 146, 147
cluster Un grupo de computadoras o aplicaciones que trabajan juntas hacia un objetivo

común. En el contexto de la computación nativa en la nube, el término se aplica
con mayor frecuencia a Kubernetes. Un clúster de Kubernetes es un conjunto
de servicios (o cargas de trabajo) que se ejecutan en sus propios contenedores,
generalmente en diferentes máquinas. La colección de todos estos servicios en

contenedores, conectados a través de una red, representan un clúster. Traducido

de https://glossary.cncf.io/cluster/ 151
commit Comando git que captura una instantánea de los cambios realizados actual-
mente en el proyecto. Las instantáneas comprometidas se pueden considerar co-
mo versiones “seguras” de un proyecto: Git nunca las cambiará a menos que
se lo solicite explı́citamente. Traducido de https://www.atlassian.com/git/
tutorials/saving-changes/git-commit 118
Design Dentro de terminologı́a Lean, es el proceso de diseño de un prototipo o versión

de un producto 58
Design Thinking Ün enfoque para el desarrollo de software que enfatiza las habilidades
de codificación de los desarrolladores de software. Traducido de https://www.
interaction-design.org/literature/topics/design-thinking 41
Docker Plataforma de software de código abierto para crear, implementar y adminis-

trar contenedores de aplicaciones virtualizadas en un sistema operativo común.
Traducido de https://www.techtarget.com/searchitoperations/definition/
Docker 119
endpoint Extremo de un canal de comunicación. Cuando una API interactúa con otro
sistema, los puntos de contacto de esta comunicación se consideran endpoints
(puntos finales). Para las API, un endpoint puede incluir una URL de un servidor
o servicio. Cada uno es la ubicación desde la cual las API pueden acceder a
los recursos que necesitan para llevar a cabo su función. Traducido de https:
//smartbear.com/learn/performance-monitoring/api-endpoints/ xii, 96
environment ambiente 119
factorización Descomponer un número, un polinomio, una matriz u otros entes mate-

máticos como producto de otros. Fuente https://dle.rae.es/factorizar 42

feature branch flujo de desarrollo en Git donde caracterı́sticas debe tener lugar en
una rama dedicada en lugar de la rama principal. Traducido de https://www.
atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
118
frontend Un sistema de front-end es parte de un sistema de información al que el

usuario accede directamente e interactua para recibir o utilizar las capacidades
de back-end del sistema anfitrión. Permite a los usuarios acceder y solicitar las
prestaciones y servicios del sistema de información subyacente. El sistema de
front-end puede ser una aplicación de software o hardware o su combinación, ası́
como recursos de la red xi, 40, 76, 199, 207, 215, 218
fullstack Un desarrollador web de pila completa es una persona que puede desarrollar
software de cliente y de servidor. Traducido de https://www.w3schools.com/
whatis/whatis_fullstack.asp 76
hackatón Encuentros que reúnen a programadores, desarrolladores y hackers. Fuente

https://www.fundeu.es/consulta/hackathon-y-hackaton 46
historia de usuario Las historias de usuario son fragmentos del comportamiento de-
seado de un sistema de software. Se utilizan ampliamente en enfoques de soft-
ware ágiles para dividir una gran cantidad de funcionalidad en piezas más pe-
queñas con fines de planificación. También escucha el mismo concepto referi-
do a una caracterı́stica, pero el término ”historia” o ”historia de usuario” se ha
vuelto predominante en los cı́rculos ágiles en estos dı́as. Traducido de https:
//martinfowler.com/bliki/UserStory.html xv, 2, 18, 22, 62, 94, 95, 99
intraemprendedor Persona que forma parte de una empresa y cuya función princi-
pal es la generación de ideas, propuestas e iniciativas concretas dentro de es-
ta organización. Fuente https://cincodias.elpais.com/cincodias/2015/04/
25/emprendedores/1429965899_681473.html 41

issue un asunto vital o sin resolver. Traducido de https://www.merriam-webster.

com/dictionary/issue 65, 79
kubernetes Orquestador de contenedores de codigo abierto. Automatiza el ciclo de vida

de las aplicaciones en contenedores en infraestructuras modernas, funcionando
como un “sistema operativo de centro de datos” que administra las aplicaciones en
un sistema distribuido. Traducido de https://glossary.cncf.io/kubernetes/
151
lean (De organizaciones, etc.) fuertes y eficientes porque evitan desperdicios en sus pro-
cesos y no tienen más empleados de los necesarios. Traducido de https://www.
oxfordlearnersdictionaries.com/definition/english/lean_2 xiv, 3, 24, 35,
36, 40, 59, 106, 148
Lean StartUp Método que enseña cómo impulsar una startup: cómo dirigir, cuándo
girar y cuándo perseverar, y hacer crecer un negocio con la máxima aceleración.
Traducido de http://theleanstartup.com/principles 35, 36, 39, 41, 58, 59,
64, 74, 81, 89, 146, 147
Lean UX Proceso de diseño centrado en el usuario que adopta las metodologı́as de

desarrollo Lean y Agile para reducir el desperdicio y crear productos centra-
dos en los usuarios. Se basa en un enfoque colaborativo y una rápida experi-
mentación/prototipado para obtener comentarios de los usuarios exponiendo un
producto mı́nimo viable (MVP) a los usuarios lo antes posible. Traducido de
https://www.hotjar.com/blog/lean-ux/ 35, 36, 58, 59, 64, 90, 121, 124, 129,
147, 151
Learn Dentro de terminologı́a Lean, es el proceso de aprendizaje o revisión de los

resultados de un prototipo o versión anterior. 58
Liftoff Se puede traducir como despuegue ix, xiv, 57, 73, 74

main En Git, es una convención de nomenclatura para una rama. Después de clonar
(descargar) un proyecto desde un servidor remoto, el repositorio local resultante
tiene una única rama local: la llamada rama “master”. Esto significa que “master”
puede verse como la rama “predeterminada” de un repositorio. 118
merge Permite tomar las lı́neas de desarrollo independientes creadas por git branch e
integrarlas en una sola rama. Traducido de https://www.atlassian.com/git/
tutorials/using-branches/git-merge 118
Messure Dentro de terminologı́a Lean, es el proceso recolección de datos o medición

de un prototipo o versión de un producto, que permitan validar la hipótesis. 58
mock Objetos simulados que imitan el comportamiento de objetos reales de manera

controlada, generalmente como parte de una iniciativa de prueba de software.
Un programador normalmente crea un objeto simulado para probar el comporta-
miento de algún otro objeto. Traducido de https://en.wikipedia.org/wiki/
Mock_object 115
mockup Puede traducirse como aqueta, es una representación estática de un produc-

to, que muestra a los usuarios y partes interesadas cómo puede verse y usarse.
Contiene elementos como la tipografı́a, los logotipos, las imágenes, los esquemas
de color y las imágenes de navegación que conformarán el diseño final y la expe-
riencia del usuario, ası́ como la ergonomı́a, cuando sea necesario. Traducido de
https://airfocus.com/glossary/what-is-a-mockup/ xii, xv, 64, 89–91, 96,
122, 123, 151
Pain-Driven Design Metodologı́a que requiere que antes de comenzar a diseñar un

producto o caracterı́stica, averiguar que esta caudando dolor a los usuarios y
potenciales usuarios. El resultado deseado de PDD es el dolor se vaya. Traducido
de Klein (2013) 90

pipeline Una cadena de elementos de procesamiento (procesos, hilos, corrutinas, fun-

ciones, etc.), dispuesta de modo que la salida de cada elemento sea la entrada
del siguiente; el nombre es por analogı́a con una tuberı́a fı́sica. Traducido de
https://en.wikipedia.org/wiki/Pipeline_(software) xiv, 63, 118–120
Product Manager Gerente de Producto 74
refactorización Un cambio realizado en la estructura interna del software para que

sea más fácil de entender y más económico de modificar sin cambiar su compor-
tamiento observable. Es una forma disciplinada de limpiar el código que mini-
miza las posibilidades de introducir errores. Traducido de https://dzone.com/
articles/what-refactoring-and-what-it-0 22, 36–38, 62, 106, 117
release Permitir que algo se muestre en público o esté disponible para su uso. Traducido
de https://dictionary.cambridge.org/dictionary/english/release 120
request En un modelo cliente-servidor, un request es un requerimiento, petición o

solicitud que le hace un cliente a un servidor. Por lo general los request suelen
hacerse a través de una red. Fuente https://www.alegsa.com.ar/Dic/request.
php xii, xviii, 97, 210
response Una vez que el servidor ha recibido y procesado la solicitud, éste debe devolver
un mensaje de respuesta HTTP hacia el cliente. Fuente https://sites.google.
com/site/conceptoprogramacion/request-response xii, xviii, 98, 99
Software Craftsmanship Un enfoque para el desarrollo de software que enfatiza las ha-
bilidades de codificación de los desarrolladores de software. Traducido de https:
//en.wikipedia.org/wiki/Software_craftsmanship 41
splash Pantalla inicial, usada para presentar una app o tambión para ayuda al usuario
a esperar al carga de recursos iniciales de la aplicación. 88, 89, 92, 93

split Dividir en dos o más partes, especialmente a lo largo de una lı́nea en particu-
lar. Traducido de https://dictionary.cambridge.org/dictionary/english/
split xiv, xv, 58, 95, 103–105, 107, 117, 118, 128, 132, 137, 142, 144, 147
stakeholder un empleado, inversionista, cliente, etc. que está involucrado en un negocio

o le compra y tiene interés en su éxito. Traducido de https://dictionary.
cambridge.org/es/diccionario/ingles/stakeholder 68, 121
testeable Que se puede probar con pruebas automatizadas 101
time to market Traducido al español como “plazo de lanzamiento” es el tiempo que

transcurre desde que proyectamos un producto y servicio y el tiempo que tar-
da en estar disponible para el consumidor final (incluidos todos los procesos
que se llevan a cabo). Fuente https://connectingvisionsgroup.com/ideas/
crecer-fidelizar/time-to-market/ 2
User Story Map Ordenación las historias de los usuarios a lo largo de dos dimensiones
independientes. El “mapa” organiza las actividades del usuario a lo largo del eje
horizontal aproximadamente en el orden en que el usuario realizarı́a la tarea.
Abajo en el eje vertical, las historias de usuario están ordenadas por prioridad
y/o sofisticación creciente de la implementación. Dado un mapa de la historia
ası́ dispuesto, la primera fila horizontal representa un “esqueleto andante”, una
versión básica pero utilizable del producto. Trabajar a través de filas sucesivas
desarrolla el producto con funcionalidad adicional. Traducido de https://www.
agilealliance.org/glossary/storymap xiv, xv, 55–57, 68, 69, 81, 82, 146, 147,
151
wireframe Esquema o Representación visual bidimensional básica de una página web,

interfaz de aplicación o diseño de producto. Puede considerarse como un boceto
funcional de baja fidelidad. Los diseñadores de productos y los profesionales de
UX (experiencia del usuario) los elaboren para comunicar cómo planean organizar

y priorizar las funciones, y cómo pretenden que los usuarios interactúen con su
producto o sitio web.Traducido de https://www.productplan.com/glossary/
wireframe/ xv, 64, 87–89, 92, 93, 151

Anexos
A.1. Historia de la Agilidad
Veremos una revisión resumida de los principales acontecimientos que originaron

a la agilidad y a dónde se dirige actualmente, para ello el autor toma la reseña de la
Agile Alliance.
A.1.1. Antes de 2001
Las prácticas y métodos se desarrollan independientemente a través de la ex-

periencia. Mucha gente vincula el inicio del desarrollo de software Ágil y, en
cierta medida, Agile en general, a una reunión que tuvo lugar en 2001, cuando
se acuñó el término desarrollo de software Ágil.
Sin embargo, las personas comenzaron a trabajar de manera ágil antes de
esa reunión de 2001. A partir de mediados de los años noventa, hubo varios
profesionales, ya sea personas que trabajan en organizaciones que desarrollan
productos de software o consultores que ayudan a las organizaciones a crear
software que pensaron: “¿Sabes qué? La forma en que hemos estado creando
software simplemente no nos funciona. Tenemos que llegar a algo diferente”.
Estos desarrolladores de software comenzaron a mezclar ideas antiguas
y nuevas, y cuando encontraron una combinación que funcionó, crearon una
metodologı́a para que su equipo los ayudara a recordar la combinación de ideas
173
que funcionaron en una situación determinada.

Estas metodologı́as enfatizaron la estrecha colaboración entre el equipo de
desarrollo y las partes interesadas del negocio; Entrega frecuente de valor co-
mercial, equipos ajustados y autoorganizados; y formas inteligentes de elaborar,
confirmar y entregar el código.
Las personas que crearon esas metodologı́as pensaron que otras personas
podrı́an estar interesadas en obtener algunos de los mismos beneficios que esta-
ban experimentando, por lo que crearon marcos para difundir las ideas a otros
equipos en otras organizaciones y contextos. Aquı́ es donde los marcos como
Scrum, Programación Extrema, Desarrollo Dirigido por Caracterı́sticas (FDD)
y Método de Desarrollo de Sistemas Dinámicos (DSDM), entre otros, comenza-
ron a aparecer.
La difusión de las ideas en ese momento fue muy orgánica, y todos esos
enfoques diferentes comenzaron a crecer de manera muy popular. Las perso-
nas tomaron prestados los marcos originales y los modificaron con diferentes
prácticas para hacerlos apropiados para sus propios contextos. (Agile Alliance,
2015a)
A.1.2. Año 2001 - Manifiesto Ágil
No habı́a una manera consistente de describir estas diferentes formas de desa-

rrollar software hasta que un grupo de 17 personas pensaron: “Todos estamos
haciendo estos enfoques diferentes para desarrollar software. Deberı́amos reunir-
nos y ver dónde hay puntos en común de lo que estamos pensando”. El resultado
fue una reunión en una estación de esquı́ en Snowbird, Utah, en 2001.
Cuando se juntaron, esquiaron un poco y también discutieron dónde sus
enfoques para el desarrollo de software tenı́an puntos en común y diferencias.
Hubo muchas cosas en las que no estuvieron de acuerdo, pero hubo algunas
cosas en las que pudieron ponerse de acuerdo, y que terminaron convirtiéndose

CAPÍTULO A. Anexos
en el Manifiesto para el desarrollo Ágil de Software. Las dos cosas principales

que hizo el Manifiesto Ágil fue proporcionar un conjunto de declaraciones de
valor que forman la base para el desarrollo de software Ágil y acuñar el término
desarrollo de software Ágil en sı́ mismo.
En los meses posteriores, los autores ampliaron las ideas del Manifiesto
Ágil con los 12 principios detrás del Manifiesto Ágil.
Algunos de los autores, incluidos Martin Fowler, Dave Thomas, Jim Highs-
mith y Bob Martin, escribieron sus recuerdos de cómo escribieron el Manifiesto
Ágil. 16 de los 17 autores se reunieron en Agile2011 y compartieron sus recuer-
dos del evento y sus opiniones sobre el estado de Agile hasta ese momento. (Beck
et al., 2001).
Se deja la cita textual del manifiesto:
Figura A.1
Manifiesto por el Desarrollo Ágil de Software 2001.
Nota. Recuperado de Manifesto for Agile Software Development, de Beck et al., 2001,
Manifesto for Agile Software Development (https://agilemanifesto.org/iso/es/
manifesto.html). derechos de autor 2001 por Ward Cunningham

A.1.3. Después del 2001
La adopción comienza y se convierte en corriente principal. Después de que los

autores regresaron de Snowbird, Ward Cunningham publicó el Manifiesto Ágil y
luego los 12 Principios en lı́nea en AgileManifesto.org. La gente pudo conectarse
y firmar para mostrar su apoyo.
Agile Alliance se formó oficialmente a fines de 2001 como un lugar para
personas que desarrollan software y ayudan a otros a desarrollar software a
explorar y compartir ideas y experiencias.
Los equipos y las organizaciones comenzaron a adoptar Agile, lideradas
principalmente por personas que realizan el trabajo de desarrollo en los equipos.
Gradualmente, los gerentes de esos equipos también comenzaron a introducir
enfoques ágiles en sus organizaciones.
A medida que Agile se hizo más conocido, se formó un ecosistema que
incluı́a a las personas desarrollaban software Agile, las personas y organizaciones
que los ayudaron a través de consultorı́a, capacitación, marcos y herramientas.
Este ecosistema comenzó a crecer y las ideas ágiles comenzaron a difundir-
se, algunos adoptantes perdieron de vista los valores y principios expuestos en
el manifiesto y los principios correspondientes. En lugar de seguir una mentali-
dad ”ágil”, en cambio comenzaron a insistir en que ciertas prácticas se realicen
exactamente de cierta manera.
Las organizaciones que se centran únicamente en las prácticas y los rituales
experimentan dificultades para trabajar de forma ágil. Las organizaciones que
se toman en serio el hecho de estar a la altura de los valores y principios de Agile
tienden a darse cuenta de los beneficios que buscan y encuentran que trabajar de
forma ágil ya no es algo nuevo y diferente. En su lugar, simplemente se convierte
en la forma en que se acercan al trabajo. (Agile Alliance, 2015a)

A.1.4. Agile es Una Mentalidad
En última instancia, Agile es una mentalidad informada por los valores conte-
nidos en el Manifiesto Agile y los 12 principios detrás del Manifiesto Agile. Esos
valores y principios brindan orientación sobre cómo crear, responder al cambio
y cómo lidiar con la incertidumbre. Se podrı́a decir que la primera oración del
Manifiesto Ágil resume toda la idea: “Estamos descubriendo mejores formas de
desarrollar software al hacerlo y ayudar a otros a hacerlo”.
Cuando se enfrenta la incertidumbre, intentar algo que crea que podrı́a
funcionar, obtener retroalimentación y realizar los ajustes necesarios.
Tener en cuenta los valores y principios cuando se haga esto. Dejar que
el contexto guı́e los marcos, prácticas y técnicas para colaborar con el equipo y
ofrecer valor. (Agile Alliance, 2015a)
A.2. Programación Extrema
Para una explicación de los conceptos más importantes de XP, el autor hace una
traducción del contenido del sitio web extremeprogramming.org de Wells.
El aspecto más sorprendente de la Programación Extrema son sus reglas simples.

La programación extrema se parece mucho a un rompecabezas. Hay muchas
piezas pequeñas. Individualmente las piezas no tienen sentido, pero cuando se
combinan juntas se puede ver la imagen completa. Las reglas pueden parecer
torpes e incluso ingenuas al principio, pero se basan en valores y principios
sólidos.
Establecen expectativas entre los miembros del equipo, pero no son la meta
final en sı́ mismas. Hay que considerar que estas reglas definen un entorno que
promueve la colaboración y el empoderamiento del equipo, ese es su objetivo.
Una vez logrado, el trabajo en equipo productivo continuará incluso a medida
que se cambien las reglas para adaptarse a las necesidades especı́ficas de la

organización.
Este diagrama de flujo muestra cómo las reglas de programación extrema
trabajan juntas. Los clientes disfrutan de ser socios en el proceso del software,
los desarrolladores contribuyen activamente sin importar el nivel de experiencia
y los gerentes se concentran en la comunicación y las relaciones. Las actividades
improductivas se han recortado para reducir los costos y la frustración de todos
los involucrados. (Wells, 2013)
A.2.1. Reglas de Programación Extrema
Wells (1999a), las describe
A.2.1.1. Planificación
Historias de usuario. Las historias de usuario están escritas.
Plan de lanzamiento. La planificación de lanzamiento crea el calendario de lan-

zamiento.
Lanzar a menudo. Hacer pequeños lanzamientos frecuentes.
Iterativo. El proyecto se divide en iteraciones.
Planificación de iteraciones. La planificación de iteraciones comienza cada itera-

ción.
A.2.1.2. Gestión
Optimizar al final, darle al equipo un espacio de trabajo dedicado abierto.
Ritmo constante, establecer un ritmo sostenible
Reunión de pie, una reunión de pie comienza cada dı́a.
Velocidad del proyecto, se mide la velocidad del proyecto.

Mover a las personas alrededor
Arreglar XP, cuando se rompe.
A.2.1.3. Codificación
Cliente in situ, El cliente está siempre disponible.
codificación estándar debe escribirse según las normas acordadas.
Desarrollo guiado por pruebas, Codificar primero la prueba unitaria.
Programación en pares, Todo el código de producción.
Integración en serie, Solo un par integra el código a la vez.
Integración continua, integrar a menudo.
Integración continua, configurar una computadora de integración dedicada.
Propiedad colectiva
A.2.1.4. Diseño
Simplicidad
Metáfora del sistema
Tarjetas CRC, Utilice tarjetas CRC (Clase, Responsabilidad, y Colaboración)

para las sesiones de diseño.
Solución Espiga, Programas muy simples para explorar posibles soluciones y re-
ducir el riesgo.
No agregar funcionalidad antes.
Refactorizar siempre que sea posible.

A.2.1.5. Pruebas
Pruebas unitarias Todo código debe tener pruebas unitarias.
Pruebas unitarias Todo el código debe pasar todas las pruebas unitarias antes de
que pueda ser liberado
Pruebas Cuando se encuentra un error, se crean pruebas.
Pruebas de aceptación. Las pruebas de aceptación se realizan con frecuencia y el

puntaje esta publicado.
Esto se resume adecuadamente en el diagrama de un proyecto de Programación

Extrema
Figura A.2
Diagrama de Proyecto de Programación Extrema.
Nota. Resume el proceso desde la Espiga Arquitectural, la Planificación de liberación, la

Iteración, las Pruebas de Aceptación y los pequeños incrementos, incluye tratamiento
de los requerimientos, tipos de estimaciones y evolución. Adaptado de The Rules of
Extreme Programming, de Wells, 1999a, The Rules of Extreme Programming (http:
//www.extremeprogramming.org/map/images/projectsml.gif)
A.2.2. Valores de XP
La programación extrema (XP) se basa en valores. Las reglas que se acaban de

examinar son la extensión natural y la consecuencia de maximizar los valores. XP no

es realmente un conjunto de reglas, sino una forma de trabajar en armonı́a con los
valores personales y corporativos. Comenzar con los valores de XP enumerados aquı́,
luego agregar los propios reflejándose en los cambios que se realice en las reglas, de
acuerdo con lo que postula Wells (1999b).
A.2.2.1. Simplicidad
Hacer lo que sea necesario y pedido, pero no más. Esto maximizará el valor
creado para la inversión realizada hasta la fecha. Dar pequeños pasos simples a la meta
y mitigar las fallas a medida que ocurran. Crear algo de lo que se esté orgulloso y
mantenerlo a largo plazo por costos razonables. (Wells, 1999b)
A.2.2.2. Comunicación
Como explica Wells (1999b), todos son parte del equipo y se comunican cara a
cara todos los dı́as. Trabajar juntos en todo, desde los requisitos hasta el código. Crear
la mejor solución para el problema que se pueda juntos.
A.2.2.3. Retroalimentación
Tomar en serio cada compromiso de iteración al entregar un software que funcione.

Demostrar software temprano y, a menudo, escuchar atentamente y realizar los cambios
necesarios. Hablar sobre el proyecto y adaptar nuestro proceso a él, no al revés. (Wells,
1999b)
A.2.2.4. Respeto
Todos dan y sienten el respeto que merecen como un miembro valioso del equipo.
Todos aportan valor incluso si es simplemente entusiasmo. Los desarrolladores respetan
la experiencia de los clientes y viceversa. La gerencia respeta el derecho de aceptar
responsabilidad del equipo y recibir autoridad sobre el propio trabajo. (Wells, 1999b)

A.3. Scrum
A.2.2.5. Coraje
Decir la verdad sobre el progreso y las estimaciones. No documentar excusas para

el fracaso porque se planea tener éxito. No temer nada porque nadie trabaja solo.
Adaptarse a los cambios cuando ocurran Wells (1999b).
A.3. Scrum
A fin de profundizar en los conceptos de Scrum con mayor detalle y citar fuentes
de primera mano, se incorpora en esta sección fragmentos de la guı́a de Scrum, Schwaber
and Sutherland (2017), es decir los creadores de Scrum.
A.3.1. Pilares
Scrum está soportado por tres pilares (Schwaber and Sutherland, 2017).
A.3.1.1. Transparencia
Los aspectos significativos del proceso deben ser visible por todos los involucrados
de acuerdo a Schwaber and Sutherland (2017).
A.3.1.2. Inspección
Con el fin de evitar variaciones indeseadas los usuarios de Scrum deben inspec-
cionar frecuente y diligentemente los artefactos y el progreso hacia un objetivo, con la
suficiente frecuencia como para no interferir en el trabajo. (Schwaber and Sutherland,
2017)
A.3.1.3. Adaptación
En caso de presentarse una desviación en el proceso o material que se está tra-

bajando un inspector debe realizar los ajustes lo antes posible para evitar mayores
desviaciones, tal como se indica en Schwaber and Sutherland (2017).

A.3.2. Valores
Del tal modo que Scrum promueve para su éxito la adopción de valores que son
compromiso, coraje, foco, apertura y respecto (Schwaber and Sutherland, 2017).
A.3.3. El Equipo Scrum (Scrum Team)
Compuesto por El Equipo Scrum consiste en un Dueño de Producto (Product

Owner), el Equipo de Desarrollo (Development Team) y un Scrum Master. Los Equipos
Scrum son auto organizados y multifuncionales (Schwaber and Sutherland, 2017).
A.3.3.1. Dueño del Producto (Product Owner)
Es la única persona responsable de gestionar la Lista del Producto (Product

Backlog) sus funciones son:
Expresar claramente los elementos de la Lista del Producto;
Ordenar los elementos en la Lista del Producto para alcanzar los objetivos
y misiones de la mejor manera posible;
Optimizar el valor del trabajo que el Equipo de Desarrollo realiza;
Asegurar que la Lista del Producto es visible, transparente y clara para

todos y que muestra aquello en lo que el equipo trabajará a continuación;
y,
Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista

del Producto al nivel necesario.
Es una única persona cuyas decisiones deben ser respetadas, para realizar
cambios se debe hacer a través de su gestión y no puede ser reemplazado por
un comité. (Schwaber and Sutherland, 2017)

A.3. Scrum
A.3.3.2. El Equipo de Desarrollo (Development Team)
Equipo de profesionales encargados de entregar el incremento “Terminado” de

producto en cada iteración (Sprint), tienen las siguientes caracterı́sticas:
Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equi-

po de Desarrollo cómo convertir elementos de la Lista del Producto en
Incrementos de funcionalidad potencialmente desplegables;
Los Equipos de Desarrollo son multifuncionales, esto es, como equipo cuen-
tan con todas las habilidades necesarias para crear un Incremento de pro-
ducto;
Scrum no reconoce tı́tulos para los miembros de un Equipo de Desarrollo

independientemente del trabajo que realice cada persona;
Scrum no reconoce subequipos en los equipos de desarrollo, no importan

los dominios que requieran tenerse en cuenta, como pruebas, arquitectura,
operaciones o análisis de negocio; y,
Los Miembros individuales del Equipo de Desarrollo pueden tener habili-

dades especializadas y áreas en las que estén más enfocados, pero la res-
ponsabilidad recae en el Equipo de Desarrollo como un todo.
En cuanto al tamaño del equipo los autores recomiendan equipos no ma-

yores de nueve miembros ni menores de 3 miembros, para un equilibrio en-
tre agilidad y capacidad para completar trabajo significativo. (Schwaber and
Sutherland, 2017)
A.3.3.3. El Scrum Master
Es responsable de promover y apoyar Scrum ayudando a todos los involucrados

a entender la teorı́a, prácticas, reglas y valores de Scrum.
Es un lı́der que ayuda a todos a interactuar para maximizar el valor creado por
el Equipo Scrum.

Su servicio al Equipo Scrum es:
Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional;
Ayudar al Equipo de Desarrollo a crear productos de alto valor;
Eliminar impedimentos para el progreso del Equipo de Desarrollo;
Facilitar los eventos de Scrum según se requiera o necesite; y,
Guiar al Equipo de Desarrollo en entornos organizacionales en los que Scrum aún

no haya sido adoptado y entendido por completo.
Para la organización:
Liderar y guiar a la organización en la adopción de Scrum;
Planificar las implementaciones de Scrum en la organización;
Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el

desarrollo empı́rico de producto
Motivar cambios que incrementen la productividad del Equipo Scrum; y,
Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación

de Scrum en la organización.
(Schwaber and Sutherland, 2017)
A.3.4. Eventos de Scrum
Todos los eventos son bloques de tiempo (time-boxes), de tal modo que todos
tienen una duración máxima. Una vez que comienza un Sprint, su duración es fija y
no puede acortarse o alargarse. Los demás eventos pueden terminar siempre que se
alcance el objetivo del evento, La falta de alguno de estos eventos da como resultado
una reducción de la transparencia y constituye una oportunidad perdida de inspección
y adaptación. (Schwaber and Sutherland, 2017)

A.3. Scrum
A.3.4.1. Sprint
Es un bloque de tiempo (time-box) de un mes o menos durante el cual se crea

un incremento de producto “Terminado” utilizable y desplegable, consisten y
contienen Planificación del Sprint (Sprint Planning), los Scrums Diarios (Daily
Scrums), el trabajo de desarrollo, la Revisión del Sprint (Sprint Review), y la
Retrospectiva del Sprint (Sprint Retrospective). Durante este:
No se realizan cambios que puedan afectar al Objetivo del Sprint (Sprint

Goal);
Los objetivos de calidad no disminuyen; y,
El alcance puede clarificarse y renegociarse entre el Dueño de Producto y

el Equipo de Desarrollo a medida que se va aprendiendo más.
A.3.4.2. Planificación de Sprint (Sprint Planning)
Reunión para planificar el trabajo a realizar durante el Sprint, tiene una duración
de máximo ocho horas para un Sprint de un mes, responde las preguntas, ¿Qué
puede entregarse en el Incremento resultante del Sprint que comienza? Y ¿Cómo
se conseguirá hacer el trabajo necesario para entregar el Incremento?
La entrada a esta reunión está constituida por la Lista de Producto, el úl-
timo Incremento de producto, la capacidad proyectada del Equipo de Desarrollo
para el Sprint y el rendimiento pasado del Equipo de Desarrollo. El número de
elementos de la Lista de Producto seleccionados para el Sprint depende única-
mente del Equipo de Desarrollo. Solo el Equipo de Desarrollo puede evaluar qué
es capaz de lograr durante el Sprint que comienza.
Durante la Planificación del Sprint, el Equipo Scrum también define un
Objetivo del Sprint (Sprint Goal). El Objetivo del Sprint deberı́a lograrse duran-
te el Sprint a través de la implementación de la Lista de Producto y proporciona

una guı́a al equipo de desarrollo de por qué se está construyendo el incremento.

Al finalizar esta reunión, el Equipo de Desarrollo debe ser capaz de explicar
al Dueño de Producto y al Scrum Master cómo trabajar como un equipo auto-
organizado y lograr el Objetivo del Sprint para crear el Incremento esperado.
A.3.4.3. Scrum Diario (Daily Scrum)
Es una reunión diaria de un máximo de 15 minutos, que es responsabilidad del

Equipo de Desarrollo e interna del mismo, se revisan los avances diarios e inspecciona
cualquier inconveniente que puede afectar la consecución del objetivo del Sprint, per-
mite tomar decisiones de forma rápida y compartir la situación y avance general del
Sprint (Schwaber and Sutherland, 2017).
A.3.4.4. Revisión de Sprint (Sprint Review)
Para inspeccionar el Incremento y adaptar la Lista de Producto si fuese necesa-

rio. Durante la Revisión de Sprint, el Equipo Scrum y los interesados colaboran
acerca de lo que se hizo durante el Sprint, el Scrum Master enseña a todos a
mantener el evento dentro del bloque de tiempo fijado de un máximo de cuatro
horas para Sprints de un mes, incluye:
Los asistentes son el Equipo Scrum y los interesados clave invitados por
el Dueño de Producto;
El Dueño de Producto explica qué elementos de la Lista de Producto se

han “Terminado” y cuáles no se han “Terminado”;
El Equipo de Desarrollo habla acerca de qué estuvo bien durante el Sprint,

qué problemas aparecieron y cómo fueron resueltos esos problemas;
El Equipo de Desarrollo hace una demostración del trabajo que ha “Ter-

minado” y responde preguntas acerca del Incremento;

A.3. Scrum
El Dueño de Producto habla acerca de la Lista de Producto en su esta-

do actual. Proyecta objetivos probables y fechas de entrega en el tiempo
basándose en el progreso obtenido hasta la fecha (si fuera necesario);
El grupo completo colabora acerca de qué hacer a continuación, de modo

que la Revisión del Sprint proporcione información de entrada valiosa para
Reuniones de Planificación de Sprints subsiguientes.
Revisión de cómo el mercado o el uso potencial del producto podrı́a haber

cambiado lo que es de más valor para hacer a continuación; y,
Revisión de la lı́nea de tiempo, presupuesto, capacidades potenciales y

mercado para las próximas entregas de funcionalidad o capacidad prevista
del producto.
El resultado final es la Lista de Producto revisada con los elementos de

la Lista de Producto posibles para el siguiente Sprint. Es posible que la Lista
de Producto reciba un ajuste general para enfocarse en nuevas oportunidades.
A.3.4.5. Retrospectiva del Sprint (Sprint Retrospective)
Es una oportunidad para el Equipo Scrum de inspeccionarse a sı́ mismo y de

crear un plan de mejoras que sean abordadas durante el siguiente Sprint, se lleva
a cabo después de la revisión de cada Sprint y antes de planificar el siguiente.
Es responsabilidad del Scrum Master, asegurar que la reunión sea positiva, pro-
ductiva y dentro de un tiempo no mayor de 3 horas para un Sprint de un mes,
su propósito es:
Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones,

procesos y herramientas;
Identificar y ordenar los elementos más importantes que salieron bien y las
posibles mejoras; y,

Crear un plan para implementar las mejoras a la forma en la que el Equipo

Scrum desempeña su trabajo.
Al final el Equipo Scrum deberı́a haber identificado mejoras que implementará

en el próximo Sprint, aunque las mejoras pueden implementarse en cualquier
momento, la Retrospectiva de Sprint ofrece un evento dedicado para este fin,
enfocado en la inspección y la adaptación. (Schwaber and Sutherland, 2017)
A.3.5. Artefactos de Scrum
Los más importantes son:
A.3.5.1. Lista de Producto (Product Backlog)
Es la única fuente de requisitos para cualquier cambio a realizarse en el produc-

to, la Lista de Producto enumera todas las caracterı́sticas, funcionalidades, requisitos,
mejoras y correcciones que constituyen cambios a realizarse sobre el producto para
entregas futuras. Los elementos de la Lista de Producto tienen como atributos la des-
cripción, el orden, la estimación y el valor. Los elementos de La Lista de Producto
muchas veces incluyen descripciones de las pruebas que demostrarán la completitud de
tales elementos cuando estén “Terminados”. (Schwaber and Sutherland, 2017)
A.3.5.2. Lista de Pendientes del Sprint (Sprint Backlog)
Es el conjunto de elementos de la Lista de Producto seleccionados para el Sprint,

más un plan para entregar el Incremento de producto y conseguir el Objetivo del Sprint.
A.4. Kanban
Método propuesto por David J. Anderson, como resultado de sus trabajos en

Corbis 2004, basado en un enfoque de teorı́a restricciones e incorporando un Drum-

A.4. Kanban
Buffer-Rope (comparable a un sistema pull kanban).

Por tal motivo para la sección sobre los métodos Kanban, el autor cita fragmentos
del libro Kanban: Successful Evolutionary Change for Your Technology Business de
Anderson que el autor ha traducido durante la investigación del presente trabajo.
A.4.1. ¿Qué es un Sistema Kanban?
Anderson (2010), expone la definición, dado un número de kanban (o tarjetas)

equivalente a la capacidad (acordada) de un sistema son puestas en circulación. Una
tarjeta se asigna a una pieza de trabajo. Cada tarjeta actúa como un mecanismo de
señal. Una nueva pieza de trabajo puede ser iniciada solo cuando una tarjeta está
disponible. Esta nueva tarjeta es adjuntada a una pieza de trabajo y la sigue a través
de flujo del sistema. Cuando no hay más tarjetas libres, ningún trabajo adicional puede
ser iniciado. Cualquier nuevo trabajo debe esperar en una cola hasta que una tarjeta esté
disponible. Cuando algo de trabajo es completado, una tarjea es liberada y reciclada.
Con una tarjea ahora libre, una nueva pieza de trabajo en la cola puede ser iniciada.
Este mecanismo es conocido como un pull system porque el nuevo trabajo es
jalado dentro del sistema cuando la capacidad lo permite, como refirere Anderson (2010)
a diferencia de ser empujado dentro del sistema basado en demanda. Un pull system no
puede ser sobrecargado si la capacidad, al ser determinada como el número de señales
de tarjetas en circulación, ha sido establecida apropiadamente.
A.4.1.1. Kanban Aplicado al Desarrollo de Software
En este caso se usa un sistema kanban virtual para limitar el trabajo en progreso.
Aunque “kanban” significa “tarjeta de señal”, y hay tarjetas en la mayorı́a de las im-
plementaciones en desarrollo de software, estas tarjetas no hacen realmente la función
de tarjetas de señal para jalar más trabajo. En lugar de eso, ellas representan ı́tems de
trabajo. Por lo tanto, el término “virtual”, porque no son tarjetas de señales fı́sicas. La
señal para jalar nuevo trabajo es inferida de la cantidad visual de trabajo en progreso

sustraı́da de algún indicador del lı́mite (o capacidad). Algunas personas han imple-
mentado kanban fı́sicos usando técnicas comotarjetasas adhesivas o ranuras fı́sicas en
un tablero. La mayorı́a de las señales es generada por un software de seguimiento de
trabajo. Sin embargo, si no hay un lı́mite explı́cito del trabajo en progreso y no hay
señalización para jalar nuevo trabajo a través del sistema, no es un sistema kanban.
(Anderson, 2010)
La razón para usar un sistema kanban, para Anderson (2010), es limitar el trabajo
en progreso de un equipo a una capacidad establecida y balancear la demanda sobre
del equipo contra el rendimiento de su trabajo liberado, haciendo que puedan alcanzar
una paz sostenible.
A.4.2. Proceso de Adopción
El método Kanban propone una serie de pasos para transformar de forma gradual
a un equipo de desarrollo de software y llevarlo al éxito (Anderson, 2010).
A.4.2.1. (1) Enfoque en la Calidad
A través de:
TDD (Test-Driven Development) desarrollo guiado por pruebas y testers
Inspección de código.
Análisis y diseño colaborativo.
Usar patrones de diseño.
Usa herramientas de desarrollo modernas.
Reducir la cantidad de trabajo en progreso.
(Anderson, 2010)

A.4. Kanban
A.4.2.2. (2) Reducir Trabajo en Progreso (WIP, Work-in progress) y (3) Entregar
frecuentemente
Existe una relación de causalidad entre la cantidad de trabajo en progreso y el

promedio de tiempo de entrega, y la relación es lineal (Ley de los pequeños). Hay
una correlación entre tiempo de entrega incrementado y calidad más pobre. Por
lo tanto, tiempos de iteración más cortos conducen a una mejor calidad, es decir
dos semanas de iteración son mejores que cuatro y una semana es mejor que dos,
y ası́ por el estilo. Entendiendo que la gestión del trabajo en progreso mejora la
calidad, se recomienda introducir polı́ticas explicitas de reducción del trabajo
en progreso. Por otro lado, otro efecto beneficioso es que al hacer posibles más
frecuentes lanzamientos o releases de mejor calidad de código mejora la confianza
de los equipos externos. (Anderson, 2010)
A.4.2.3. (4) Balancear la demanda contra el rendimiento
Implica establecer una tasa en cual no se aceptan nuevos requerimientos en con-

ducto de desarrollo de software que corresponda con la tasa en la cual se entrega
código funcional. Entonces cualquier discusión sobre priorización o compromiso
de un nuevo trabajo puede darse solo en el contexto de entregar algo trabajo
existente. El efecto de este cambo es profundo. El rendimiento del proceso será
limitado por un cuello de botella, cuyo origen desconocido y se presumirá que se
trata de una sobrecarga completa. Sin embargo, una vez balanceada la deman-
da contra el rendimiento y limitado el trabajo en progreso dentro de la cadena
de valor, sólo los recursos del cuello de botella permanecerán completamente
ocupados, mientras los otros miembros del equipo experimentarán holgura pro-
ducto de una reducción de su carga de trabajo considerable, permitiendo tener
un control sobre el tiempo disponible.
La consecuencia de producir holgura en el resto de los miembros del equipo
permite que espontáneamente se experimenten mejoras de forma continua en

el proceso como iniciativa de los propios miembros del equipo, balancear la

caga de los miembros del equipo luego de limitar el trabajo en progreso, es
contraproducente al limitar la holgura que promueve la creación de una cultura
de mejora. (Anderson, 2010)
A.4.2.4. (5) Priorizar
Si los tres primeros pasos fueron implementados, código de alta calidad está
llegando frecuentemente, los tiempos de entrega deben ser relativamente cortos,
a medida que el trabajo en progreso es limitado. Nuevo trabajo debe ser jalado
para su desarrollo a medida que la capacidad es liberada al completarse trabajo
existente. En este punto la atención puede girar optimizar el valor entregado
más que meramente la cantidad de código entregado. Existe un detalle en poner
atención a la priorización cuando no existe predictibilidad en la entrega, ¿Por qué
desperdiciar esfuerzo tratando de ordenar la entrada cuando no hay confiabilidad
en el orden de entrega?, hasta que no se corrija esto, el tiempo de gestión es mejor
usado en enfocarse en mejorar ambos la habilidad de entregar y la predictibilidad
de entrega. Se debe pasar a ordenar la prioridad una vez que se conozca que se
puede en realidad entregar cosas en aproximadamente el orden en que fueron
requeridas.
La priorización no debe ser controlada por la organización de ingenierı́a,
si no por el dueño del producto, patrocinador del negocio, departamento de
marketing o similares, para cambiar su comportamiento, a lo mejor, la adminis-
tración de ingenierı́a solo puede buscar influir en cómo se hace la priorización.
Para ello se requiere un nivel de confianza que solo se puede conseguir con la
aplicación de los pasos anteriores. Considerando que el fin principal es entregar
valor al negocio en lugar de ser veloces en el desarrollo de software, llegar a
ello requiere un grado de madurez y un proceso gradual que parte de ir paso a
paso construyendo primero las habilidades básicas antes de los grandes desafı́os.

A.4. Kanban
(Anderson, 2010)
Figura A.3
Diagrama de Construcción de Madurez Kanban.
Nota. El cual es progresivo su objetivo final es tener la capacidad de mejorar la priori-

zación a partir de tres pasos previos, primero construir código de alta calidad, seguido
de la reducción de trabajo en progreso y en seguida balancear la demanda contra el
rendimiento.
A.4.2.5. (6) Atacar fuentes de variabilidad para mejorar la predictibilidad
Ambos, los efectos de la variabilidad y como reducirla dentro del proceso son
temas avanzados, se requiere que los trabajadores de conocimiento cambien la
forma en que trabajan para aprender nuevas técnicas y cambien su comporta-
miento personal, constituye un nivel de madurez mayor en la organización. La
variabilidad resulta en más trabajo en progreso y alarga los tiempos de entre-
ga, crea una mayor necesidad de holgura en los recursos que no constituyen un
cuello de botella con el fin de hacer frente al reflujo y flujo de trabajo ya que
sus efectos se manifiestan en el flujo de trabajo a través de la cadena de valor.
La variabilidad en el tamaño de los requerimientos y la cantidad de esfuerzo

invertido en análisis, diseño, codificación, pruebas, integración y entrega afectan

adversamente el rendimiento del proceso y el costo del funcionamiento de una
cadena de valor de desarrollo de software.
Sin embargo, algunas fuentes de variabilidad son inadvertidamente diseña-
das dentro del proceso a través de pobres elecciones de polı́ticas, por ejemplo, el
re-planeamiento mensual, acuerdos de nivel de servicio en estimaciones, priori-
dad de cambios de texto en producción, estos son controlados por polı́ticas que
pueden ser cambiadas. Simplemente cambiar una polı́tica de proceso existente
puede reducir dramáticamente fuentes de variabilidad que afecten la predictibi-
lidad. (Anderson, 2010)
A.5. Aplicaciones Móviles Empresariales
A.5.1. Aplicaciones Móviles
Una aplicación móvil, más comúnmente conocida como app, es segun (techopedia,
2020) un tipo de software de aplicación diseñado para ejecutarse en un dispositivo
móvil, como un teléfono inteligente o una tableta. Las Apps con frecuencia sirven
para proporcionar a los usuarios servicios similares a los que se accede en las PC. Las
aplicaciones son generalmente pequeñas unidades de software individuales con funciones
limitadas. Este uso del software de la aplicación fue originalmente popularizado por
Apple Inc. y su App Store, que ofrece miles de aplicaciones para iPhone, iPad y iPod
Touch.
Una aplicación móvil también puede conocerse como app, web app, app en lı́nea,
app para iPhone o app para teléfonos inteligentes (techopedia, 2020).
A.5.2. Aplicaciones Móviles empresariales
Kony (sf) una compañı́a global especializada en desarrollo de aplicaciones móviles

empresariales las define como.

Una aplicación móvil que se utiliza en el mundo empresarial para resolver los
problemas de una empresa. En general, una aplicación empresarial es una pla-
taforma de software que es muy grande y compleja. Las aplicaciones móviles
empresariales se crean para combinarse o interactuar con otras aplicaciones mó-
viles empresariales que utiliza la empresa. Además, las aplicaciones móviles em-
presariales están diseñadas con la intención de implementarse en muchas redes,
dispositivos y sistemas operativos diferentes; sin embargo, aún se desarrollan
con capacidades administrativas de administración y seguridad.
El desarrollo de aplicaciones móviles empresariales existe en conjunto con
el aumento de empleados que usan dispositivos móviles personalizados para apli-
caciones corporativas y acceden a los datos de la compañı́a, lo que se conoce
como traer su propio dispositivo o BYOD. Con las aplicaciones móviles em-
presariales, todos los empleados pueden tener acceso simplificado a las mismas
aplicaciones que todos los demás en la empresa, lo que permite la uniformidad
entre dispositivos y al mismo tiempo permite a los empleados tener la experien-
cia móvil personalizada que se ha convertido en algo común hoy en dı́a. Esto
tiene el beneficio de aumentar la eficiencia en el lugar de trabajo y reducir los
costos en dispositivos de la empresa. Si bien muchos empleados pueden facturar
a su lugar de trabajo por ciertos costos, los dispositivos y planes son manejados
por el individuo.
Existen muchos tipos diferentes de aplicaciones móviles empresariales que
se utilizan en un entorno corporativo. Por ejemplo, estas aplicaciones pueden in-
cluir gestión de contenido, procesamiento de pagos, atención al cliente, sistemas
de marketing por correo electrónico, sistemas de facturación automatizados, sis-
temas de colaboración y mensajerı́a, gestión de relaciones con el cliente (CRM),
integración de aplicaciones empresariales (EAI), inteligencia empresarial y mu-
chos más. Las aplicaciones móviles empresariales también pueden denominarse

apps móviles empresariales, software de aplicaciones móviles empresariales o

simplemente software móvil empresarial.
A.5.3. Arquitectura Cliente/Servidor
Las apps móviles empresariales y en general las apps son desarrolladas bajo una
arquitectura cliente/servidor, porque actualmente es casi imposible concebir una apli-
cación sobre todo de negocio que no requiera interactuar con servicios y/o sistemas
externos, para maximizar sus funcionalidades y aprovechas la capacidad de cómputo y
almacenamiento del lado del servidor, es ası́ como Goedvolk (1995) desarrolla los tipos
de arquitectura de acuerdo con sus capacidades.
En la arquitectura cliente/servidor, una aplicación consiste en al menos un com-

ponente en la estación de trabajo (el cliente), que usa los servicios de compo-
nentes; los servidores, en computadoras de rango medio o en el mainframe.
En la arquitectura cliente/servidor, los clientes y servidores son programas
separados. Para ejecutar una aplicación, el usuario inicia el cliente en su estación
de trabajo. El cliente llama al servidor y lo inicia.
El Grupo Gartner distingue cinco tipos para la división de tareas entre
clientes y servidores. Estos se basan en el hecho de que una aplicación consta
de tres funciones, que son la presentación al usuario, la lógica de la aplicación
y la gestión para la recuperación y edición de datos en la base de datos.

Figura A.4
Cinco tipos Diferentes de Arquitectura Cliente / Servidor.
Nota. A la izquierda las arquitecturas más centralizadas y la derecha las arquitec-

turas más distribuidas. Reproducido de Five different types of client/server archi-
tecture (source: Gartner Group), Goedvolk, 1995, Section 4.5 (Vision) – Architectu-
res (https://www.rijsenbrij.net/archive1/vision/images/vis46f1.gif). Dere-
chos de autor 1995 por Goedvolk, Hans.
A.5.3.1. Presentación Distribuida
En este tipo, casi toda la inteligencia se encuentra en el servidor. La estación de

trabajo solo maneja parte de la presentación Goedvolk (1995).
A.5.3.2. Presentación Remota
Para Goedvolk (1995) en este tipo, el cliente maneja la presentación en la estación

de trabajo, preferiblemente a través de una GUI, mientras que el servidor maneja la
lógica de la aplicación y la gestión de datos.
A.5.3.3. Lógica de Aplicación Distribuida
Este tipo divide la lógica de la aplicación en dos partes. Además de la presentación,

el cliente maneja principalmente la lógica de proceso de la aplicación, como mostrar y
manejar ventanas a través de la GUI. Además de la gestión de datos, el servidor también

maneja la lógica de datos de la aplicación, como leer y editar datos y verificación y

seguridad. Este tipo de cliente/servidor se puede usar muy bien con un cliente en la
computadora personal con una GUI para la presentación y uno o más servidores en una
computadora central o en computadoras de rango medio, en forma de un programa en
lı́nea convencional (sin presentación). (Goedvolk, 1995)
A.5.3.4. DBMS Remoto
En este tipo, toda la inteligencia de la aplicación se coloca en el cliente. El servidor

es de hecho un DBMS. Los clientes en las estaciones de trabajo se comunican con un
DBMS relacional a través de consultas SQL (Goedvolk, 1995).
A.5.3.5. DBMS Distribuido
Para este tipo de cliente/servidor los DBMS deben ser compatibles con una base
de datos distribuida.
De todas estos tipos de arquitecturas explicadas por Goedvolk (1995), la más con-
veniente para las aplicaciones móviles en general es de la Lógica de aplicación distribuida
donde ciertas funcionalidades se distribuyen en la aplicación cliente de forma local y
otras requieren la interacción de un servidor de aplicaciones que hoy en dı́a se conoce
como backend estos conceptos se mantienen vigentes, solamente se han modernizado
los conceptos y tecnologı́as pertinentes tanto el lado cliente y servidor.
A.5.4. Alcance del Desarrollo de Aplicaciones Móviles Empresariales
De acuerdo con la experiencia del autor, cuando se abordan proyectos de apps em-
presariales, se asume que el alcance contiene tanto el frontend y backend entendiéndose
por frontend a la app propiamente como componente que se ejecuta en algún disposi-
tivo móvil (o navegador web en muchos casos) y el backend la toda la infraestructura
remota de servicios en el lado servidor aquı́ podemos hablar a servidores web, servicios
en la nube, servicios serverless, etc., presentándose algunos escenarios:

El alcance del proyecto incluye todo el backend incluso aplicaciones web de gestión
El alcance no incluye el backend se limita a la invocación de servicios que estarán

a cargo de algún equipo de desarrollo diferente al que desarrolla la aplicación.
También existen casos de un enfoque intermedio, donde se construye un backend

que se conecta a una base de datos intermedia que se alimenta con proceso de
importación y exportación periódica de datos.
A.5.5. Arquitectura de Software
El trabajo de Martin, Robert C. en la seria de blogs Clean Architecture, cons-

tituyen la base de autor para el diseño de la arquitectura de software del presente
trabajo. En esa lı́nea el autor incluye en esta sección su traducción de los fragmentos
más importantes de estos articulos.
Martin (2012), propuso los lineamientos generales de una arquitectura limpia
“Clean Architecture”, que servirá de referencia en el desarrollo del presente trabajo, a
continuación, en todo este apartado se desarrollan sus conceptos.
En los últimos años, hemos visto toda una gama de ideas sobre la arquitectura
de los sistemas. Estos incluyen:
Hexagonal Architecture (también conocida como Ports and Adapters) por

Alistair Cockburn y adoptada por Steve Freeman, y Nat Pryce en su ma-
ravillo libro Growing Object Oriented Software.
Onion Architecture por Jeffrey Palermo.
Screaming Architecture proveniente de un blog de Martin.
DCI de James Coplien y Trygve Reenskaug.
BCE por Ivar Jacobson de su libro Object Oriented Software Engineering:

A Use-Case Driven Approach.
Aunque todas estas arquitecturas varı́an algo en sus detalles, son muy

similares. Todas tienen el mismo objetivo, que es la separación de intereses.

Todas logran esta separación dividiendo el software en capas. Cada uno tiene al
menos una capa para las reglas de negocio y otra para las interfaces.
Cada una de estas arquitecturas produce sistemas que son:
1. Independientes de frameworks. La arquitectura no depende de la existencia

de alguna biblioteca de software cargado de funciones. Esto le permite
utilizar dichos frameworks como herramientas, en lugar de tener que meter
su sistema en sus restricciones limitadas.
2. Testable Las reglas de negocio se pueden probar sin la interfaz de usuario,

la base de datos, el servidor web o cualquier otro elemento externo.
3. Independiente de la IU. La interfaz de usuario puede cambiar fácilmente,

sin cambiar el resto del sistema. Una interfaz de usuario web podrı́a reem-
plazarse por una interfaz de usuario de consola, por ejemplo, sin cambiar
las reglas de negocio.
4. Independiente de la base de datos. Puede cambiar Oracle o SQL Server por

Mongo, BigTable, CouchDB u otra cosa. Sus reglas comerciales no están
vinculadas a la base de datos.
5. Independiente de cualquier agente externo. De hecho, las reglas de negocio

simplemente no saben nada sobre el mundo exterior.
El diagrama a continuación es un intento de integrar todas estas arquitec-

turas en una sola idea procesable. (Martin, 2012)

Figura A.5
Diagrama Resumen de Clean Architecture.
Nota. Las flechas a la izquierda indican el sentido de la regla de dependen-

cia, al centro en amarillo las reglas de negocio empresariales la segunda ca-
pa en rojo representa las reglas de negocio de la aplicación, en verde la ca-
pa de adaptadores de interfaces y en celeste la capa externa de frameworks y
drivers; a la derecha se ilustra el flujo de control que debe partir del contro-
lador hacia el presentador. Reproducido de The Clean Architecture, de Martin,
2012, The Clean Architecture (https://blog.cleancoder.com/uncle-bob/images/
2012-08-13-the-clean-architecture/CleanArchitecture.jpg). Derechos de au-
tor 2012 por Martin, Robert C..
A.5.5.1. La Regla de Dependencia
Los cı́rculos concéntricos representan diferentes áreas de software. En general,

cuanto más avanzas, más alto se vuelve el nivel de software. Los cı́rculos exte-
riores son mecanismos. Los cı́rculos internos son polı́ticas.
La regla principal que hace que esta arquitectura funcione es la regla de
dependencia. Esta regla dice que las dependencias del código fuente solo pueden

apuntar hacia adentro. Nada en un cı́rculo interno puede saber nada acerca de
algo en un cı́rculo externo. En particular, el nombre de algo declarado en un
cı́rculo externo no debe mencionarse en el código del cı́rculo interno. Eso incluye,
funciones, clases. Variables, o cualquier otra entidad de software nombrada.
Del mismo modo, los formatos de datos utilizados en un cı́rculo externo
no deberı́an ser utilizados por un cı́rculo interno, especialmente si esos formatos
son generados por un framework en un cı́rculo externo. No queremos que nada
en un cı́rculo externo afecte a los cı́rculos internos. (Martin, 2012)
A.5.5.2. Entidades (Entities)
Las entidades encapsulan las reglas comerciales de toda la empresa. Una entidad
puede ser un objeto con métodos, o puede ser un conjunto de estructuras y
funciones de datos. No importa mientras las entidades puedan ser utilizadas por
muchas aplicaciones diferentes en la empresa.
Si no tiene una empresa y solo está escribiendo una sola aplicación, estas
entidades son los objetos comerciales de la aplicación. Encapsulan las reglas más
generales y de alto nivel. Son los menos propensos a cambiar cuando algo externo
cambia. Por ejemplo, no esperarı́a que estos objetos se vean afectados por un
cambio en la navegación de la página o la seguridad. Ningún cambio operativo
en una aplicación particular deberı́a afectar la capa de entidad. (Martin, 2012)
A.5.5.3. Casos de Uso (Use Cases)
El software en esta capa contiene reglas comerciales especı́ficas de la aplicación.

Encapsula e implementa todos los casos de uso del sistema. Estos casos de uso
organizan el flujo de datos hacia y desde las entidades, y ordenan a esas entidades
que usen sus reglas de negocio para toda la empresa para lograr los objetivos
del caso de uso.
No esperamos que los cambios en esta capa afecten a las entidades. Tam-

poco esperamos que esta capa se vea afectada por cambios en las externalidades,
como la base de datos, la interfaz de usuario o cualquiera de los marcos comunes.
Esta capa está aislada de tales intereses.
Sin embargo, esperamos que los cambios en el funcionamiento de la apli-
cación afecten los casos de uso y, por lo tanto, el software de esta capa. Si los
detalles de un caso de uso cambian, entonces cierto código en esta capa cierta-
mente se verá afectado. (Martin, 2012)
A.5.5.4. Adaptadores de Interfaz (Interface Adapters)
El software en esta capa es un conjunto de adaptadores que convierten los datos

del formato más conveniente para los casos y entidades de uso, al formato más
conveniente para algún agente externo como la Base de Datos o la Web. Es
esta capa, por ejemplo, la que contendrá totalmente la arquitectura MVC de
una GUI. Los presentadores, las vistas y los controladores pertenecen aquı́. Es
probable que los modelos sean solo estructuras de datos que se pasan de los
controladores a los casos de uso, y luego de los casos de uso a los presentadores
y las vistas.
Del mismo modo, los datos se convierten, en esta capa, del formulario más
conveniente para entidades y casos de uso, en el formulario más conveniente
para cualquier framework de persistencia que se esté utilizando. Es decir, la
base de datos. Ningún código interno de este cı́rculo debe saber nada sobre la
base de datos. Si la base de datos es una base de datos SQL, todo el SQL debe
restringirse a esta capa, y en particular a las partes de esta capa que tienen que
ver con la base de datos.
También en esta capa se encuentra cualquier otro adaptador necesario para
convertir datos de alguna forma externa, como un servicio externo, a la forma
interna utilizada por los casos y entidades de uso. (Martin, 2012)

A.5.5.5. Frameworks y Controladores (Drivers)
La capa más externa generalmente se compone de frameworks y herramientas

como la Base de datos, el Framework web, etc. Generalmente no se escribe
mucho código en esta capa que no sea código de pegamento que se comunica
con el siguiente cı́rculo hacia adentro.
Esta capa es donde van todos los detalles. La web es un detalle. La base de
datos es un detalle. Mantenemos estas cosas en el exterior donde pueden hacer
poco daño. (Martin, 2012)
A.5.5.6. ¿Solo Cuatro Cı́rculos?
No, los cı́rculos son esquemáticos. Es posible que necesite más que solo estos
cuatro. No hay una regla que diga que siempre debes tener solo estos cuatro. Sin
embargo, la regla de dependencia siempre se aplica. Las dependencias del código fuente
siempre apuntan hacia adentro. A medida que avanza, aumenta el nivel de abstracción.
El cı́rculo más externo es un detalle concreto de bajo nivel. A medida que avanza, el
software se vuelve más abstracto y encapsula polı́ticas de nivel superior. El cı́rculo más
interno es el más general. (Martin, 2012)
A.5.5.7. Cruzando Fronteras
En la esquina inferior derecha del diagrama de la figura A.5 hay un ejemplo de

cómo cruzamos los lı́mites del cı́rculo. Muestra los controladores y presentadores
que se comunican con los casos de uso en la siguiente capa. Tenga en cuenta el
flujo de control. Comienza en el controlador, se mueve a través del caso de uso
y luego termina ejecutándose en el presentador. Tenga en cuenta también las
dependencias del código fuente. Cada uno de ellos apunta hacia adentro hacia
los casos de uso.
Por lo general, resolvemos esta aparente contradicción utilizando el Prin-
cipio de Inversión de Dependencias (Dependency Inversion Principle). En un

lenguaje como Java, por ejemplo, organizarı́amos interfaces y relaciones de he-

rencia de modo que las dependencias del código fuente se opongan al flujo de
control en los puntos correctos a través del lı́mite.
Por ejemplo, considere que el caso de uso debe llamar al presentador.
Sin embargo, esta llamada no debe ser directa porque eso vioları́a la Regla
de dependencia: ningún cı́rculo interno puede mencionar ningún nombre en un
cı́rculo externo. Entonces, el caso de uso llama a una interfaz (se muestra aquı́
como Puerto de salida de caso de uso) en el cı́rculo interno, y el presentador en
el cı́rculo externo lo implementa.
La misma técnica se utiliza para cruzar todos los lı́mites en las arquitectu-
ras. Aprovechamos el polimorfismo dinámico para crear dependencias del código
fuente que se oponen al flujo de control para que podamos cumplir con la Regla
de dependencia sin importar en qué dirección vaya el flujo de control. (Martin,
2012)
A.5.5.8. ¿Qué Datos Cruzan los Lı́mites?
Tı́picamente, los datos que cruzan los lı́mites son estructuras de datos simples.
Puede usar estructuras básicas u objetos simples de transferencia de datos si lo
desea. O los datos pueden ser simplemente argumentos en llamadas a funciones.
O puede empaquetarlo en un hashmap, o construirlo en un objeto. Lo importante
es que las estructuras de datos simples y aisladas se pasan a través de los lı́mites.
No queremos engañar y pasar Entidades o filas de la Base de datos. No queremos
que las estructuras de datos tengan ningún tipo de dependencia que viole la
Regla de dependencia.
Por ejemplo, muchos frameworks de bases de datos devuelven un formato
de datos conveniente en respuesta a una consulta. Podrı́amos llamar a esto un
RowStructure. No queremos pasar esa estructura de fila hacia adentro a través
de un lı́mite. Eso vioları́a la Regla de dependencia porque forzarı́a a un cı́rculo

interno a saber algo sobre un cı́rculo externo.

Entonces, cuando pasamos datos a través de un lı́mite, siempre es de la
forma más conveniente para el cı́rculo interno. (Martin, 2012)
A.5.5.9. Como Recomendación
Cumplir con estas reglas simples no es difı́cil y le ahorrará muchos dolores de

cabeza en el futuro. Al separar el software en capas y cumplir con la Regla de depen-
dencia, creará un sistema que es intrı́nsecamente comprobable, con todos los beneficios
que eso implica. Cuando cualquiera de las partes externas del sistema se vuelve obso-
leta, como la base de datos o el marco web, puede reemplazar esos elementos obsoletos
con un mı́nimo de alboroto. (Martin, 2012)
A.5.6. Arquitectura Frontend
Se ha elegido la arquitectura Hexagonal por ser más desacoplada facilitando el

desarrollo de la parte móvil.

Figura A.6
Hexagonal Architecture.
Nota. Define claramente un núcleo de lógica de negocio que se debe mantener in-
dependientes de los demás componentes y es accesible a través de puertos en ro-
jo, que puede ser conectados con adaptadores externos en azul. Reproducido de An
overview of Ports-And-Adapters, de Bergen, sfb, Ports and Adapters, Hexagonal Ar-
chitecture [Gráfico] (https://www.dossier-andreas.net/software_architecture/
ports-and-adapters.png). derechos de autor s.f. por Bergen, P.
Donde los colores representan:
Amarillo: lógica de núcleo
Rojo claro: puertos primarios
Azul claro: adaptadores primarios
Rojo oscuro: puertos secundarios
Azul oscuro: adaptadores secundarios
El objetivo principal de esta arquitectura es desacoplar la lógica central de la apli-

cación de los servicios que utiliza. Esto permite que diferentes servicios se “conecten”, y
permite que la aplicación se ejecute sin estos servicios. Y en un sentido estricto de esta

arquitectura, incluso el marco de la aplicación es un conjunto de servicios. La lógica

central de una aplicación no debe depender de estos servicios en esta arquitectura (por
lo que se convierte en “agnóstico de framework ”) (Bergen, sfa).
Bergen (sfa) desarrolla la definición de cada uno de los componentes de la arqui-
tectura a continuación:
A.5.6.1. Los Puertos Principales
Bergen (sfa) propone que son la API principal de la aplicación. Son llamados por
los adaptadores principales que forman el lado del usuario de la aplicación. Ejemplos de
puertos primarios son funciones que le permiten cambiar objetos, atributos y relaciones
en la lógica central.
A.5.6.2. Los Puertos Secundarios
Son las interfaces para los adaptadores secundarios. Son llamados por la lógica
central. Un ejemplo de un puerto secundario es una interfaz para almacenar objetos
individuales. Esta interfaz simplemente especifica que se cree, recupere, actualice y
elimine un objeto. No le dice nada sobre la forma en que se almacena el objeto. (Bergen,
sfa)
Un adaptador es un puente entre la aplicación y el servicio que necesita la apli-
cación. Se adapta a un puerto especı́fico (Bergen, sfa).
A.5.6.3. Un Adaptador Primario
Es una pieza de código entre el usuario y la lógica central, tai como explica
Bergen (sfa). Un adaptador podrı́a ser una función de prueba unitaria para la lógica
central. Otra podrı́a ser una función similar a un controlador que interactúa tanto con
la interfaz gráfica de usuario como con la lógica central. El adaptador primario llama
a las funciones API de la lógica central.

A.5.6.4. Un Adaptador Secundario
Es una implementación del puerto secundario (que es una interfaz). Por ejemplo,
puede ser una clase pequeña que convierte las solicitudes de almacenamiento de aplica-
ciones en una base de datos determinada y devuelve los resultados de la base de datos
en un formato solicitado por el puerto secundario. También puede ser un objeto de base
de datos simulado necesario para las pruebas unitarias de ciertas partes de la lógica
central. La lógica central llama a las funciones del adaptador secundario. De acuerdo
a definción de Bergen (sfa).
Las Ventajas de esta arquitectura son:
La lógica central se puede probar independientemente de los servicios externos.
Es fácil reemplazar los servicios por otros que sean más adecuados en vista de los
requisitos cambiantes.
A.5.7. Arquitectura Backend
Se ha elegido la arquitectura Onion por ser más resumida y propicia para im-
plementar servicios REST que se traducen por lo general en Requests desde la parte
móvil al lado servidor.

Figura A.7
Onion Architecture.
Nota. Delimita claramente la lógica de negocio al centro la que manipula los datos
solo a través de repositorios de interfaz, y es accesible únicamente desde interfaces
de servicios, con el fin de que elementos externos como clientes de UI, pruebas, re-
positorios de infraestructura, otros servicios web, etc.; puedan integrarse. Reprodu-
cido de ONION-IZING YOUR MULTI-TIER ARCHITECTURE, de Grech, 2014,
Onion Architecture, NTier, IOC, Blog, Incredible Web, Web Development (https:
//www.incredible-web.com/media/1047/onion-arch.jpg). Derechos de autor 2014
por Onion Architecture, NTier, IOC, Blog, Incredible Web, Web Development.
Según su autor Palermo (2008), la premisa principal es que controla el acopla-

miento. La regla fundamental es que todo el código puede depender de capas más
centrales, pero el código no puede depender de capas más alejadas del núcleo. En otras
palabras, todo el acoplamiento es hacia el centro. Esta arquitectura está sesgada hacia

la programación orientada a objetos, y pone los objetos por encima de todos los demás.
En el centro mismo vemos el Modelo de dominio, que representa la combinación
de estado y comportamiento que modela la verdad para la organización, según define
Palermo (2008). Alrededor del modelo de dominio hay otras capas con más comporta-
miento.
La externalización de la base de datos puede ser un gran cambio para algunas
personas acostumbradas a pensar en las aplicaciones como “aplicaciones de bases de
datos”. Con Onion Architecture, no hay aplicaciones de bases de datos. Hay aplicaciones
que pueden usar una base de datos como servicio de almacenamiento, pero solo a través
de un código de infraestructura externa que implementa una interfaz que tiene sentido
para el núcleo de la aplicación. Desacoplar la aplicación de la base de datos, sistema de
archivos, etc., reduce el costo de mantenimiento durante la vida útil de la aplicación.
(Palermo, 2008)
A.5.8. Caracterı́sticas Esenciales de una App Móvil Empresarial
Cuando se construyen aplicaciones móviles empresariales existen ciertas caracte-

rı́sticas esenciales a tomar en cuenta para una adecuada planeación, desarrollo y soporte
de la solución, en opinión de Patrick (2018) se tiene:
A.5.8.1. Automatización de Procesos
La automatización es la razón principal por la cual las organizaciones están adop-

tando la movilidad empresarial en sus procesos centrales. Con la ayuda de aplicaciones
de movilidad empresarial, las organizaciones buscan agilizar las operaciones con una
intervención humana mı́nima y ahorrar tiempo/costo. (Patrick, 2018)
A.5.8.2. Enfoque Bimodal de TI
Para Patrick (2018), el enfoque bimodal llegó al panorama de TI en 2014 cuando

Gartner introdujo el modelo innovador para manejar las futuras necesidades de TI y

movilidad de las empresas. El enfoque de TI bimodal define dos caminos paralelos: uno
es el enfoque de TI tradicional y el otro es un enfoque experimental y ágil para crear
aplicaciones que se pueden implementar rápidamente y centrarse más en funcionalida-
des intuitivas.
Las apps empresariales también deberı́an centrarse en el enfoque bimodal. En
un extremo, deben ser inteligentes y estar preparados para el futuro, mientras que en
el otro; deberı́an ser más fáciles de integrar en sistemas heredados. Las aplicaciones
deben consistir en herramientas y caracterı́sticas funcionales ágiles y omnipresentes
que se centren tanto en la previsibilidad futura como en la exploración innovadora para
obtener los mejores resultados. (Patrick, 2018)
A.5.8.3. Experiencia de Usuario Increı́ble
Patrick (2018) explica que no solo deberı́a centrarse en mejorar la funcionalidad,

sino también en ofrecer la mejor experiencia de usuario. Esto mejorará la adopción de
la aplicación dentro de una empresa, cumpliendo el objetivo de automatización para
una organización.
Para poder ofrecer caracterı́sticas como la funcionalidad fuera de lı́nea, notifi-
caciones en la aplicación, etc. Además, proporcionar soporte multiplataforma es una
excelente manera de mejorar la experiencia del usuario, ya que no vincula a un usuario
a una plataforma en particular. (Patrick, 2018)
A.5.8.4. Conectividad y Análisis en Tiempo Real
Las empresas modernas explica Patrick (2018) tienen que tratar con cientos de
partes interesadas, administrar miles de procesos y ocuparse de cientos de ofertas en-
focadas en cualquier momento. En una sobrecarga de información tan masiva, cada
empresa busca análisis de datos en tiempo real para tomar mejores decisiones para el
crecimiento futuro.
A través de la conectividad en tiempo real, una aplicación puede capturar datos

relevantes todo el tiempo a través de una conectividad perfecta. Puede convertirse en

un asesor confiable, ayudando a mejorar los procesos actuales a través del análisis de
datos. (Patrick, 2018)
A.5.8.5. Almacenamiento en la Nube
Las organizaciones están invirtiendo fuertemente en soluciones de almacenamien-

to en la nube. Según las últimas encuestas de la industria, el aumento en el gasto
en servicios en la nube será seis veces mayor que el aumento en el gasto en TI en el
mismo perı́odo. Esto muestra que las empresas se toman en serio el almacenamiento
en la nube, lo que lo convierte en un ingrediente esencial para el éxito de una app
empresarial. Las organizaciones buscan soluciones que ofrezcan datos comerciales crı́-
ticos a sus ejecutivos, tomadores de decisiones y administración, en el camino. Por lo
tanto, una aplicación de movilidad empresarial debe construirse teniendo en cuenta las
capacidades de almacenamiento en la nube. (Patrick, 2018)
A.5.8.6. Infraestructura de Datos Segura y Moderada Centralmente
Se debe construir como refiere Patrick (2018) una infraestructura segura y mode-
rada centralmente para una solución de movilidad empresarial. Esto mejora la confianza
al tiempo que garantiza que los datos comerciales crı́ticos siempre estén seguros. En
la era de la información, los datos son el producto más valioso y la pérdida de datos
comerciales puede ser la mayor pérdida para cualquier empresa comercial.
A.5.8.7. Soporte Inteligente y Robusto
Cada aplicación de movilidad empresarial debe tener un sistema de soporte res-

paldado por AI para que las partes interesadas puedan obtener asistencia las 24 horas.
Esto no solo mejora la experiencia del usuario, sino que también garantiza que una
aplicación móvil empresarial se convierta en una parte integral de una organización a
largo plazo. (Patrick, 2018)

Hay varios ejemplos que destacan la importancia del soporte inteligente para
el éxito de una aplicación móvil de acuerdo a los conceptos de Patrick (2018), los
principales son Google Allo, Ozlo y Sherpa. Todas estas aplicaciones aprovecharon el
potencial de la IA para ayudar a los usuarios a encontrar respuestas relevantes a sus
problemas con la mı́nima molestia.
A.5.8.8. Enfoque Basado en Eventos
Según Gartner, el enfoque y la arquitectura basados en eventos serı́an el principal

diferenciador que impulsarı́a la transformación digital de negocios en el 2018. El enfoque
basado en eventos se enfoca en brindar soluciones para cumplir objetivos al responder
rápidamente a eventos especı́ficos. Con ello los desarrolladores podrı́an proporcionar
soluciones en tiempo real y aprovechar las oportunidades de negocios dinámicas a su
máximo potencial. (Patrick, 2018)
A.5.9. Elección del Stack de Tecnologı́as de Apps Empresariales
Para consolidar las recomendaciones más importantes se ha tomado el análisis de

Mila Slesar en esta sección.
Una pila tecnológica (technology stack ) es la combinación de lenguajes de pro-

gramación y productos de software que se utilizan para crear una aplicación
móvil o web. Se crea una pila cuando una capa de una aplicación se crea encima
de la otra. La mayorı́a de las pilas de tecnologı́a de aplicaciones móviles vienen
con dos componentes de software: el lado del cliente y el lado del frontend y
backend, respectivamente.
Las decisiones relacionadas con la tecnologı́a son el tercer paso en la pla-
nificación del desarrollo de aplicaciones móviles, después de haber establecido la
estructura y la perspectiva comercial del producto. En empresas ya establecidas,
los desarrolladores internos suelen tomar la decisión. Es más complicado si se
trata de una pequeña startup.

La decisión determinará en gran medida si la aplicación móvil será esca-

lable y funcionará bien. También tendrá un impacto directo en su presupuesto.
Una tecnologı́a incorrecta puede retrasar el negocio por meses, mientras que
una pila tecnológica bien elegida dará una ventaja competitiva y ayuda a cre-
cer. (Slesar, sf)
A.5.9.1. Contexto, criterios y consideraciones
Con la ayuda de desarrolladores experimentados deben conocer a fondo las nece-

sidades y restricciones de su negocio para sugerir la mejor pila de tecnologı́a para su
aplicación móvil Slesar (sf).
Figura A.8
Capas de Tecnologı́a de Aplicaciones Móviles.
Nota. Desde tres perspectivas a la izquierda análisis y diseño, las capas de descubri-
miento de Requerimientos, diseño de experiencia de usuario y diseño de interfaces de
usuario; al medio desde la perspectiva del lado del cliente, capas de UI, lógica de nú-
cleo y comunicaciones, y a la derecha desde el lado del servidor, los servicios web,
la lógica de Servidor y los datos. Reproducido de Mobile Application Technology La-
yers, de Slesar, sf, How to Choose the Right Tech Stack for a Mobile Application
- Part I (https://alternative-spaces.com/blog/wp-content/uploads/2018/12/
Stack1a.jpg). Derechos de autor s.f. por Mila Slesar.

Una pila tecnológica deberı́a ser rentable, especialmente con un presupuesto

exacto. También es importante comprender las posibilidades técnicas y las li-
mitaciones de varias pilas de tecnologı́a cuando se trata de implementar sus
ideas.
La elección debe estar determinada por los problemas que la aplicación
está resolviendo. Preguntarse:
¿Qué debemos hacer para crear la mejor experiencia de usuario?
¿Cómo vamos a garantizar la seguridad?
¿Es el rendimiento una prioridad ahora, o podemos tratarlo más adelante?
Se deberı́an elegir una pila tecnológica que pueda acomodar el futuro cre-
cimiento horizontal y vertical de la aplicación. Una vez que se haya identificado
una tecnologı́a prospectiva, revisen juntos una lista de verificación:
¿El lenguaje o framework en cuestión tiene ya implementadas soluciones

requeridas, flexibilidad, opciones de integración con soluciones terceras,
etc.?
¿Está bien documentada?
¿Es el código conciso, pero fácilmente mantenible y usable?
¿Es el lenguaje o framework maduro, pero a prueba de futuro?
¿Tiene un gran ecosistema detrás de él?
¿Es la comunidad a su alrededor activa y amigable con los principiantes?
¿Son los profesionales asequibles?
¿Existen compañı́as grandes detrás de la tecnologı́a?
¿Existen grandes compañı́as patrocinando el desarrollo?
¿La tecnologı́a ofrece versiones con soporte de largo plazo?
¿La actualización o migración es proceso sencillo?

¿Su equipo siempre tendrán acceso a los datos?
¿Es posible exportar los datos si se necesita cambiar de tecnologı́a?
¿La tecnologı́a tiene una API para permitir flexibilidad al otro lado?
¿Soporta procesos de carga pesada?
Es excelente cuando las opciones adecuadas coinciden con la experiencia de

los desarrolladores disponibles o potenciales. Sin embargo, la pila de tecnologı́a
debe satisfacer principalmente las necesidades del negocio. Es probable que las
tecnologı́as elegidas permanezcan durante años, probablemente más tiempo que
los desarrolladores que trabajan en ese momento.
La mayorı́a de los principales marcos y herramientas de desarrollo son de
código abierto y gratuitos, pero el acceso a funciones avanzadas puede requerir
una suscripción paga. Antes de hacerlo, mucho menos obtener la licencia, com-
pare el costo y la usabilidad de las funciones pagas. Las empresas en una etapa
temprana de desarrollo generalmente deberı́an optar por soluciones de código
abierto siempre que sea posible. Puede ahorrar mucho tiempo y dinero. Tales
marcos ayudan a construir nuevas caracterı́sticas rápidamente y tienden a ser
más seguros gracias a las grandes comunidades. Su popularidad también facilita
la contratación de nuevos desarrolladores a medida que la empresa crece.
Sin embargo, los lenguajes y los marcos también evolucionan (o se deterio-
ran) con el tiempo, y los requisitos de su negocio pueden cambiar. Se debe estar
preparado para cambiar las tecnologı́as cuando algo ya no funcione. Adoptar
la práctica de desglosar los servicios, backend y frontend en componentes más
pequeños. Hará que reemplazar las tecnologı́as sea menos doloroso. (Slesar, sf)

Figura A.9
Diagrama Genérico de Stack de Tecnologı́as de Apps Móviles.
Nota. A la izquierda lado del servidor, en la base el servidor fı́sico, encima el sistema
operativo, sobre el cual corren el servidor web, la base de datos y se sirve de algún
lenguaje de programación para implementar web frameworks. A la derecha del lado
cliente pude optarse por un stack web sobre el navegador o uno nativo. Reproducido
de mobile app backend stack, de Slesar, sf, How to Choose the Right Tech Stack for a
Mobile Application - Part I (https://alternative-spaces.com/blog/wp-content/
uploads/2018/12/fullstack.jpg). Derechos de autor s.f. por Mila Slesar.
Si es posible, recomienda Slesar (sf) pruebe las tecnologı́as elegidas en un pequeño

proyecto. Una compilación de producto viable mı́nimo (MVP por sus siglas en inglés)
puede mostrar desde el principio cómo funciona cada componente (o no funciona)
para el caso. Si es una startup, llegar al mercado es más importante que tener una
pila tecnológica perfecta. Agregar funciones debe ser barato y rápido. Puede ajustar y
optimizar las funciones o cambiar las pilas de tecnologı́a más adelante, a medida que
crecen sus necesidades y el presupuesto.

A.5.9.2. Tecnologı́a de Backend de Aplicaciones Móviles
“Lado del servidor” y “backend” son términos generales para la capa donde la
lógica empresarial y los datos se unen para ofrecer la funcionalidad principal de la
aplicación móvil. El servidor responde a las solicitudes de los usuarios, accede a la base
de datos. (Slesar, sf)
La lista de las pilas de tecnologı́a más populares incluye, pero no se limita a:
LAMP. Es la abreviatura de Linux (un sistema operativo del servidor), Apache

(el servidor web), MySQL (la base de datos) y PHP o Python (los lenguajes
de scripting). La pila, por lo tanto, consiste completamente en componentes de
software de código abierto. También se puede combinar con otros paquetes de
software libre y de código abierto. Flexible, personalizable y fácil de usar, LAMP
se considera un conjunto de tecnologı́a de backend de aplicaciones móviles ro-
busto y confiable.
MEAN. Es la abreviatura de MongoDB (una base de datos NoSQL), Ex-
press.js (un marco de aplicación web), AngularJS (marco MVC de JavaScript
que renderiza la interfaz) y Node.js (un dominio de ejecución). También es de
código abierto. Node.js permite a los desarrolladores crear una arquitectura ba-
sada en eventos que mejora la experiencia del usuario y reduce el tiempo de
carga de la aplicación. El acceso a la biblioteca de módulos de JavaScript (JS)
facilita la creación de aplicaciones escalables y ágiles. Debido a que los progra-
mas de soporte están escritos en JS, los desarrolladores pueden escribir código
tanto para el lado del servidor como del cliente, ası́ como comprender el código
de los colegas del otro lado, más fácilmente. AngularJS también es flexible y
permite la incorporación sin esfuerzo de marcos de prueba JS. Todo esto hace
que MEAN stack sea una buena opción para los MVP.
Python-Django. No es una “pila completa” como las dos anteriores, porque
tendrı́a que buscar tecnologı́as de bases de datos y servidores web para completar
el conjunto. Aun ası́, Django se puede utilizar con éxito para crear servicios

backend para una aplicación móvil. El marco multifuncional es de código abierto,

maduro, estable y tiene una excelente documentación. Es adecuado tanto para
crear prototipos de trabajo como para crear aplicaciones bastante complejas
rápidamente.
Ruby on Rails (RoR). Es otro framework de código abierto y gratuito.
Promueve el desarrollo web rápido gracias a un rico repositorio de integraciones
de bibliotecas. Este y otros beneficios de RoR también lo convierten en una
tecnologı́a preferida para crear aplicaciones móviles que son simultáneamente
expandibles y multipropósito. RoR es compatible con MySQL y tiene su propia
base de datos incorporada.
Las aplicaciones móviles de alto rendimiento se crean utilizando MEAN o
LAMP. Aun ası́, LAMP con Python parece ser el favorito de los desarrolladores
de backend. Según el Informe de Pilas de tecnologı́a de hipercrecimiento del
2018 a cargo de Toptal, el 71 % de las empresas que usaban una combinación
de Python y Node.js para su backend pudieron lograr un crecimiento anual de
ingresos del 40 % o más. En general, PHP, Python, Node.js y Ruby on Rails son
tecnologı́as de backend favoritas para compañı́as en hipercrecimiento.
Las aplicaciones móviles son vulnerables a problemas de almacenamiento
de datos en caché. Una red privada virtual (VPN) puede ayudar a mejorar
la seguridad y la administración de una aplicación móvil. Para la seguridad
extendida, las empresas pueden permitir el acceso solo de VPN a sus recursos
empresariales cruciales o deshabilitar el acceso a la aplicación a través de redes
públicas inseguras.
Si se tiene la intención de expandir el negocio desde el espacio local al
global, su infraestructura de backend debe ser escalable cuando aumenta el
tráfico. Es mejor usar CDN para contenido estático. Los servidores locales son
demasiado lentos para responder a las solicitudes globales, pero CDN almacena
recursos estáticos en nodos de servidores distribuidos que están geográficamente

más cerca de los usuarios de aplicaciones móviles. De esta manera, CDN asegura
una respuesta y descargas más rápidas para una mejor experiencia de usuario.
(Slesar, sf)
Arquitecturas Severless. Roberts (2018) desarrolla estos conceptos donde las ar-
quitecturas sin servidor son diseños de aplicaciones que incorporan servicios “Backend
as a Service” (BaaS) de terceros y/o que incluyen código personalizado ejecutado en
contenedores administrados y efı́meros en una plataforma de “Funciones como servicio”
(FaaS). Al utilizar estas ideas y otras relacionadas, como las aplicaciones de una sola
página, tales arquitecturas eliminan gran parte de la necesidad de un componente de
servidor tradicional siempre activo. Las arquitecturas sin servidor pueden beneficiarse
de un costo operativo significativamente reducido, complejidad y tiempo de entrega
de ingenierı́a, a un costo de mayor dependencia del proveedor y servicios de soporte
relativamente inmaduros.
Cuanto más grande y complejo sea el proyecto, mayor será la pila de tecnologı́a
móvil que utiliza. La elección de las tecnologı́as puede depender del tipo de producto,
sus requisitos de carga y seguridad, plazos de mercado, competencia, preocupaciones
regulatorias, accesibilidad y asequibilidad de los desarrolladores, base de conocimiento
del equipo existente, herramientas de desarrollo disponibles, costo de licencias y soporte,
el objetivo las preferencias de la audiencia, el tamaño y la edad de la empresa, etc. El
equipo de desarrollo también debe tener en cuenta si ya construye o mantiene servicios
web, la existencia de bases de datos o datos que deben migrarse, o sistemas heredados
que deben transferirse al nuevo sistema. (Roberts, 2018)
A.5.10. Razones Crı́ticas Para Construir Aplicaciones Móviles
Según el análisis de Kerschberg (2019), las apps empresariales están cambiando

la cara de los negocios. Aumentan la productividad de los trabajadores, aprovechan los
grandes datos y ayudan a optimizar la eficiencia de los procesos comerciales. Hace una
distinción y defino el término “app empresarial” para incluir solo aquellas soluciones

móviles enfocadas hacia adentro dentro de la empresa, incluidos los trabajadores de

campo, en lugar de las aplicaciones enfocadas externamente, como una app minorista.
Seguidamente Kerschberg (2019) establece que existen al menos cuatro razones
principales para que las empresas creen aplicaciones móviles, estos incluyen:
Las apps empresariales aumentan la productividad laboral y corporativa general.
Las apps empresariales empoderan a los trabajadores de campo, que están cam-
biando la naturaleza de los paisajes corporativos con su adopción de dispositivos
inteligentes, especialmente tabletas.
El análisis y el big data empresarial generan aplicaciones más inteligentes que

nunca.
Nunca ha sido tan accesible desarrollar apps empresariales.

UPsobuam

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

UPsobuam

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL DE SAN AGUSTÍN DE AREQUIPA

MODERN AGILE COMO PROPUESTA DE MODELO DE DESARROLLO

Tesis presentada por el bachiller:

Para optar el Grado Académico de:

Desarrollar aplicaciones móviles empresariales es un gran desafı́o el cual

Pero muchas de las cosas que asumimos de facto, preconceptos, prácticas,

Nuestros resultados muestran que cada equipo debe libremente encontrar

Donde la agilidad debe ser reconocida, no como la informalidad del software

Palabras Clave Modern Agile, modelo de desarrollo de aplicaciones móviles,

iv Escuela profesional de Ingenierı́a Informática y de Sistemas

Developing mobile applications is a great challenge which is not exempt

However, many of the things that we assume de facto, preconceptions, prac-

Where agility must be recognized, not as the software informality nor as

Keywords modern agile, mobile application development model, enterprise

vi Escuela profesional de Ingenierı́a Informática y de Sistemas

Lista de tablas xii

Índice de figuras xiv

Lista de Código fuente xviii

Lista de Abreviaturas xix

I. Planteamiento del Problema 1

II. Marco Teórico 11

viii Escuela profesional de Ingenierı́a Informática y de Sistemas

V. Validación de la Propuesta 127

Escuela profesional de Ingenierı́a Informática y de Sistemas ix

5.2. Resultados de Variable Independiente con CVIndepend . . . . . . . . . 127

VI.Evaluación de la Propuesta 146

Glosario de Términos 164

x Escuela profesional de Ingenierı́a Informática y de Sistemas

A.3.3. El Equipo Scrum (Scrum Team) . . . . . . . . . . . . . . . . . . 183

Escuela profesional de Ingenierı́a Informática y de Sistemas xi

2.1. Manifiesto Ágil vs. Principios Modern Agile. . . . . . . . . . . . . . . . 33

4.1. Artefactos de Validez para Variables Independientes . . . . . . . . . . . 65

5.1. Recopilación de errores . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

6.1. Costos de Licencias Usadas en Propuesta . . . . . . . . . . . . . . . . . 151

Escuela profesional de Ingenierı́a Informática y de Sistemas xiii

2.1. Resumen de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1. Categorı́as y Pilares del Índice de Competitividad Global . . . . . . . . 50

4.1. Metaproceso de la Metodologı́a . . . . . . . . . . . . . . . . . . . . . . 55

4.15. Fragmento de Mapa Referente a Facturación. . . . . . . . . . . . . . . . 72

Escuela profesional de Ingenierı́a Informática y de Sistemas xv

4.42. Diseño Propuesto durante Implementación Bajo TDD en la Capa de

5.1. Gráfica de Comportamiento de Errores en el Tiempo. . . . . . . . . . . 129

A.1. Manifiesto por el Desarrollo Ágil de Software 2001. . . . . . . . . . . . 175

xvi Escuela profesional de Ingenierı́a Informática y de Sistemas

A.3. Diagrama de Construcción de Madurez Kanban. . . . . . . . . . . . . . 194

Escuela profesional de Ingenierı́a Informática y de Sistemas xvii

4.1. Parking Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

API Application Programming Interface 116, 117

B2C Business to Consumer 68, 75

CD Continuous Deployment xiv, xvi, 40, 63, 118, 120

CDN Content Delivery Network 221, 222

CEO Chief Executive Officer iii, v, 4, 23, 27–30, 38, 43, 45

CI Continuous Integration xiv, xvi, 40, 63, 118, 119

IPDD Índice Promedio de Dolor xii, xvi, 122, 123, 146

ISP Internet Service Provider 39

PDD Pain-Driven Design 90, 94

REST Representational State Transfer 210

SDK Software Development Kit 119

UI User Interface xiv, 62, 107, 211, 216

VPN Virtual Private Network 221

XP Extreme Programming x, 177, 180, 181

xx Escuela profesional de Ingenierı́a Informática y de Sistemas

El auge de la transformación digital y la hiperconectividad que vivimos hoy son el

La ingenierı́a de software se ha ocupado en buena parte de estos problemas con