Universidad Nacional del Centro de la Provincia De Buenos Aires

Facultad de Ciencias Exactas - Departamento de Computación y Sistemas

Ingeniería de Sistemas

Aplicación de Scrum en equipos

unipersonales
por

Enzo Nicolas Horquin

Director: Dr. Guillermo Rodríguez

Co-Director: Prof. Dr. Santiago Vidal

Trabajo Final de la carrera de Ingeniería de Sistemas

Tandil, 9 de Junio de 2020.

Resumen

En este trabajo se presenta la definición de un proceso de desarrollo de

software para un equipo unipersonal, adoptando eventos, artefactos y roles
de la metodología de desarrollo ágil Scrum. Este trabajo surge principal-
mente por la falta de experiencias prácticas de la metodología de desarrollo
Scrum aplicado en un equipo de desarrollo unipersonal. En esta línea, sería
importante poder definir un proceso que permita lograr un desarrollo ágil y
de calidad. Conjuntamente con la definición del proceso, este trabajo realiza
un análisis de las distintas herramientas que podrían utilizarse y cómo deben
integrarse las mismas para dar soporte al proceso de desarrollo.
Primero se realiza un análisis de la metodología ágil Scrum, para poder
definir todos los artefactos, roles y eventos que serán utilizados dentro del
proceso. Luego se define el criterio de done, para asegurar la calidad del
proceso de desarrollo y del producto.
Para validar el enfoque, se realizó un caso de estudio en un caso real de
desarrollo de software, en dónde se presenta el producto a implementar, los
objetivos del mismo, las tecnologías a utilizar y los resultados obtenidos en
cada uno de los Sprints.
Como resultado, se pudo obtener un producto funcional, testeado y trans-
parente debido a las métricas de proceso y código obtenidas con las her-
ramientas. Con la utilización de prácticas cómo la Integración Continua e
Inspección Continua se logró que haya una buena implementación del código
desarrollado y se pudo detectar errores de manera rápida y sencilla.

1
Índice general

1. Introducción 7
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3. Organización del trabajo . . . . . . . . . . . . . . . . . . . . . 9

2. Fundamentos teóricos 11
2.1. Metodologías Ágiles . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1. El Manifiesto Ágil . . . . . . . . . . . . . . . . . . . . . 12
2.2. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2. Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2.1. Product Backlog . . . . . . . . . . . . . . . . 14
2.2.2.2. Spring Backlog . . . . . . . . . . . . . . . . . 14
2.2.2.3. Product Increment . . . . . . . . . . . . . . . 15
2.2.3. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3.1. Sprint . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3.2. Sprint Planning . . . . . . . . . . . . . . . . . 15
2.2.3.3. Daily Meeting . . . . . . . . . . . . . . . . . . 16
2.2.3.4. Sprint Review . . . . . . . . . . . . . . . . . . 16
2.2.3.5. Sprint Retrospective . . . . . . . . . . . . . . 16
2.3. Arquitectura de Aplicaciones Web . . . . . . . . . . . . . . . . 17
2.3.1. Tipos de Arquitecturas de Aplicaciones web . . . . . . 17
2.3.1.1. Model View Controller . . . . . . . . . . . . . 17
2.3.1.2. Single Page Application . . . . . . . . . . . . 18
2.4. Tecnologías para el desarrollo de Interfaces de Usuario . . . . 18
2.4.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.2. Popularidad . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.3. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.4. Soporte de la comunidad . . . . . . . . . . . . . . . . . 20
2.4.5. Curva de aprendizaje . . . . . . . . . . . . . . . . . . . 20
2.5. Tecnologías para el desarrollo de servidores web . . . . . . . . 21

2
ÍNDICE GENERAL 3

2.5.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.2. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.3. Escalabilidad . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.4. Frameworks más populares . . . . . . . . . . . . . . . . 22
2.5.5. Ventajas y desventajas . . . . . . . . . . . . . . . . . . 23
2.6. Sistema de Controlador de Versiones . . . . . . . . . . . . . . 24
2.6.1. Controlador de Versiones Distribuido . . . . . . . . . . 25
2.6.2. Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7. Integración Continua . . . . . . . . . . . . . . . . . . . . . . . 26
2.7.1. Herramientas para la Integración Continua . . . . . . . 27
2.8. Inspección Continua . . . . . . . . . . . . . . . . . . . . . . . 28
2.8.1. Herramientas para la Inspección Continua . . . . . . . 28
2.9. Procesos para equipos pequeños . . . . . . . . . . . . . . . . . 29

3. Adaptación del proceso 31

3.1. Características del proceso de desarrollo . . . . . . . . . . . . 31
3.1.1. Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1.1. Product Backlog . . . . . . . . . . . . . . . . 32
3.1.1.2. Sprint Backlog . . . . . . . . . . . . . . . . . 32
3.1.1.3. Increment . . . . . . . . . . . . . . . . . . . . 33
3.1.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.3. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.3.1. Sprint . . . . . . . . . . . . . . . . . . . . . . 33
3.1.3.2. Sprint Planning . . . . . . . . . . . . . . . . . 34
3.1.3.3. Sprint Review . . . . . . . . . . . . . . . . . . 34
3.1.3.4. Daily Meetings . . . . . . . . . . . . . . . . . 35
3.1.3.5. Sprint Retrospective . . . . . . . . . . . . . . 35
3.1.4. Definición de “Done” . . . . . . . . . . . . . . . . . . . 35
3.2. Integración del proceso con herramientas . . . . . . . . . . . . 36
3.2.1. Jira . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1.1. Product Backlog . . . . . . . . . . . . . . . . 37
3.2.1.2. Sprint Backlog . . . . . . . . . . . . . . . . . 37
3.2.1.3. Sprint . . . . . . . . . . . . . . . . . . . . . . 38
3.2.1.4. Diagramas e Informes . . . . . . . . . . . . . 39
3.2.1.5. Definición de “Done” en Jira . . . . . . . . . . 40
3.2.2. Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.3. Integración Continua . . . . . . . . . . . . . . . . . . . 42
3.2.3.1. Build Server . . . . . . . . . . . . . . . . . . . 43
3.2.3.2. Test . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.3.3. Inspección Continua . . . . . . . . . . . . . . 44
3.2.3.4. Resultados . . . . . . . . . . . . . . . . . . . 44
ÍNDICE GENERAL 4

4. Validación del proceso 45

4.1. Sprint 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.1. Análisis del Producto . . . . . . . . . . . . . . . . . . . 45
4.1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.3. Captura y análisis de requerimientos . . . . . . . . . . 46
4.1.4. Inicio del Proceso de Desarrollo . . . . . . . . . . . . . 51
4.1.4.1. Diseño y Arquitectura de la Aplicación . . . . 51
4.1.4.2. Modelo de Base de Datos . . . . . . . . . . . 52
4.1.4.3. Backend . . . . . . . . . . . . . . . . . . . . . 53
4.1.4.4. Frontend . . . . . . . . . . . . . . . . . . . . 54
4.1.4.5. Integración continua . . . . . . . . . . . . . . 55
4.1.4.6. Inspección Continua . . . . . . . . . . . . . . 55
4.1.4.7. Software de Controlador de Versiones . . . . . 56
4.2. Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.1. Sprint Planning . . . . . . . . . . . . . . . . . . . . . . 56
4.2.2. Desarrollo del Sprint . . . . . . . . . . . . . . . . . . . 58
4.2.3. Sprint Review . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.4. Sprint Retrospective . . . . . . . . . . . . . . . . . . . 64
4.3. Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.1. Sprint Planning . . . . . . . . . . . . . . . . . . . . . . 65
4.3.2. Desarrollo del Sprint . . . . . . . . . . . . . . . . . . . 66
4.3.3. Sprint Review . . . . . . . . . . . . . . . . . . . . . . . 69
4.3.4. Sprint Retrospective . . . . . . . . . . . . . . . . . . . 71
4.4. Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.4.1. Sprint Planning . . . . . . . . . . . . . . . . . . . . . . 72
4.4.2. Desarrollo del Sprint . . . . . . . . . . . . . . . . . . . 72
4.4.3. Sprint Review . . . . . . . . . . . . . . . . . . . . . . . 75
4.4.4. Sprint Retrospective . . . . . . . . . . . . . . . . . . . 77

5. Conclusiones 78
5.1. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . 79
Índice de figuras

1.1. Integración del Proceso . . . . . . . . . . . . . . . . . . . . . . 9

2.1. Resultado General sobre Tecnologías de Frontend. . . . . . . . 21

2.2. Controlador de Versiones Distribuido . . . . . . . . . . . . . . 25

3.1. Primera parte del proceso de desarrollo . . . . . . . . . . . . . 32

3.2. Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3. Creación de las historias de usuario . . . . . . . . . . . . . . . 38
3.4. Sprint Backlog representado mediante Scrum Board . . . . . . 39
3.5. Planificación de historias de usuario dentro del Sprint . . . . . 39
3.6. Edición del Sprint . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7. Diagramas e Informes . . . . . . . . . . . . . . . . . . . . . . . 40
3.8. Historia de Usuario en estado Done . . . . . . . . . . . . . . . 41
3.9. Flujo del uso de la herramienta Git . . . . . . . . . . . . . . . 42
3.10. Proceso de Integración Continua . . . . . . . . . . . . . . . . . 43

4.1. Historias de Usuario. . . . . . . . . . . . . . . . . . . . . . . . 49

4.2. Ranking Historias de Usuario. . . . . . . . . . . . . . . . . . . 50
4.3. Historias de Usuario en Jira. . . . . . . . . . . . . . . . . . . . 50
4.4. Diagrama de Casos de Uso. . . . . . . . . . . . . . . . . . . . 51
4.5. Modelos de la Base de Datos. . . . . . . . . . . . . . . . . . . 53
4.6. Arquitectura de alto nivel y Flujo Redux-Saga . . . . . . . . . 54
4.7. Historias de Usuario Sprint 1 . . . . . . . . . . . . . . . . . . 57
4.8. Sub-tareas Sprint 1. . . . . . . . . . . . . . . . . . . . . . . . . 58
4.9. Registrar Usuario. . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.10. Asignar Propietario. . . . . . . . . . . . . . . . . . . . . . . . 59
4.11. Registrar Unidad. . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.12. Agregar Gasto. . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.13. Liquidación Expensas Edificio. . . . . . . . . . . . . . . . . . . 61
4.14. Liquidación Expensas Edificio. . . . . . . . . . . . . . . . . . . 62
4.15. Resultado general para el código fuente de la API. . . . . . . . 63

5
ÍNDICE DE FIGURAS 6

4.16. Resultado general del código fuente de la vista del cliente. . . 64

4.17. Historias de Usuario Sprint 2. . . . . . . . . . . . . . . . . . . 66
4.18. Login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.19. Diagrama de Secuencia Login. . . . . . . . . . . . . . . . . . . 68
4.20. Calculo de Expensas por Unidad . . . . . . . . . . . . . . . . 69
4.21. Resultado general para el código fuente de la API. . . . . . . . 70
4.22. Resultado general para el código fuente de la vista. . . . . . . 71
4.23. Historias de Usuario Sprint 2. . . . . . . . . . . . . . . . . . . 72
4.24. Estructura proyecto UI . . . . . . . . . . . . . . . . . . . . . . 73
4.25. Estructura API . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.26. Obtener Gastos . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.27. Resultado general para el código fuente de la API. . . . . . . . 76
4.28. Resultado general para el código fuente de la vista. . . . . . . 77
Capítulo 1

Introducción

En la actualidad, los métodos ágiles se han establecido como uno de los

métodos más utilizados en el desarrollo de software (Hye-young Paik, 2009).
Uno de los principales objetivos por el que surgieron, fue para poder desarro-
llar software de una manera rápida y respondiendo a los cambios que puedan
surgir a lo largo del proceso de desarrollo. Los métodos ágiles, lograron ofre-
cer un cambio a las metodologías tradicionales, que eran rígidas y estaban
dirigidas por todos los documentos que se generaban en cada una de las
etapas del proceso de desarrollo (Canós and Letelier, 2012).
La importancia de utilizar metodologías de desarrollo ágil radica en que
éstas permiten obtener un proceso de desarrollo adaptativo y flexible, en
dónde cada iteración resultará en una parte del producto final de software.
Las metodologías ágiles utilizan un conjunto de herramientas y buenas
prácticas que ayudan a manejar la complejidad de los proyectos y poder
obtener una buena calidad durante el proceso de desarrollo. Sin embargo,
en las metodologías ágiles no se encuentra documentado, en general, de una
manera explícita cómo adaptar estas herramientas y practicas según el tipo
de grupo y el número de integrantes para asegurar una buena calidad del
producto. Es por eso que esto requerirá de un análisis e investigación de las
herramientas existentes en el mercado para ver cómo se adaptan al proceso
de desarrollo para así, obtener un producto de software de una manera ágil
y de calidad (Ramos et al., 2015).
Uno de los métodos ágiles con mayor aceptación es Scrum (Cadavid et al.,
2013; Mahalakshmi and Sundararajan, 2013a). Scrum se basa en la creación
de iteraciones (2-4 semanas), llamadas Sprints. Cada sprint comienza con
su planificación y termina con una revisión. La planificación consta de una
reunión en la cuál se acuerdan las actividades que se realizarán en esa ite-
ración (Gallego, 2012). Una vez finalizado el sprint, se realizará una revisión
sobre lo implementado en dicha iteración.

7
CAPÍTULO 1. INTRODUCCIÓN 8

1.1. Motivación
Hoy en día existen pocas experiencias prácticas del uso de la metodología
Scrum, aplicado en un equipo de desarrollo unipersonal con un determina-
do criterio de done para las historias de usuario (Cohn, 2004). Este criterio
consta de definir cuándo una historia de usuario se considera terminada (Kar-
lesky and Vander Voord, 2008). Un ejemplo es que una historia de usuario
se considera terminada, cuando esta fue implementada y testeada.
Las metodologías ágiles recomiendan que los proyectos sean para 7(+-2)
personas, pero sin embargo hay muchos grupos que son pequeños o uniper-
sonales. Es por eso que el problema se centra en cómo adaptar estas me-
todologías a los grupos, dónde el número de personas pasa a ser un factor
importante (Nazareno et al., 2013). En la actualidad hay muchos equipos
unipersonales, por ejemplo desarrolladores que trabajan de manera freelan-
ce, que participan en el proceso de desarrollo de ciertos componentes. Aunque
estos trabajen de forma autónoma es necesario que su proceso de desarollo
sea visible y predecible para su cliente.
De acuerdo con la bibliografía existente (Mahalakshmi and Sundararajan,
2013b), Scrum con todas sus etapas y actividades, no parece ser aplicable a
un equipo de desarrollo de una sola persona, y por lo tanto esa persona,
no estaría en condiciones de poder generar un desarrollo ágil, y a la vez
de calidad como propone Scrum. Por eso es que sería importante definir un
proceso ágil basado en Scrum para equipos unipersonales junto con el criterio
de “done”, haciendo énfasis en la transparencia del proceso y la calidad del
software, y que esta aplicación resultará en un desarrollo ágil y de calidad.

1.2. Objetivos
El objetivo general que se plantea para este trabajo es poder definir un
proceso que le permita a una persona de un grupo unipersonal de desarrollo,
poder seguir un framework de trabajo como Scrum, definiendo un determi-
nado criterio de done. Este proceso se va a basar en definir un criterio para
considerar cuando una historia de usuario se encuentra terminada.
A lo largo de los años surgieron herramientas que fueron creadas para
darle un soporte al desarrollo de software y a las metodologías ágiles. Es por
eso que otro de los principales objetivos para este trabajo, es la investigación,
el análisis e integración de las distintas herramientas. Se buscará lograr que
estas herramientas trabajen en conjunto para así obtener un desarrollo ágil
y eficiente al momento de iniciar el proceso de desarrollo de software.
En la Figura 1.1, se puede ver una aproximación de alto nivel del proceso
CAPÍTULO 1. INTRODUCCIÓN 9

Figura 1.1: Integración del Proceso

de desarrollo.
Como se puede observar, en la primera parte de la Figura 1.1, se encuentra
todo el proceso de desarrollo aplicando algunas prácticas de Scrum. Junto
con los tres primeros artefactos, y junto con el soporte de las herramientas
se van a obtener dos categorías de métricas.
La primera categoría de métrica es la de producto, una vez que finaliza
el sprint, el código desarrollado es actualizado en el repositorio común y este
mismo entrará en un proceso de integración. En este proceso se realizarán
los testeos correspondientes y se hará un análisis del código implementado
durante el sprint. Algunas de las métricas a analizar son: porcentaje de cubri-
miento de los test (test coverage), código duplicado, errores de programación,
malas prácticas, etc.
Mientras que la segunda categoría de métrica es la de proceso, se utilizará
una herramienta que nos permitirá administrar, gestionar y seguir el progreso
del proyecto. Esta categoría nos permitirá observar con que calidad se llevó
a cabo el proceso de desarollo.

1.3. Organización del trabajo

A continuación se presenta una breve descripción de los contenidos de
cada uno de los capítulos.

Capítulo 2 describe aspectos teóricos involucrados en este trabajo, des-

de una mirada conceptual sobre lo que son las metodologías ágiles como
Scrum, las tecnologías web más utilizadas en el desarrollo de softwa-
re, sistemas de controlador de versiones, las prácticas ágiles cómo la
integración continua e inspección continua y las herramientas más uti-
lizadas para llevar a cabo dichas prácticas. Además, se explica sobre
trabajos relacionados que tengan que ver con la adaptación de Scrum
en pequeños equipos de desarrollo.
CAPÍTULO 1. INTRODUCCIÓN 10

Capítulo 3 presenta el proceso de desarrollo de software para equipos

unipersonales definido por este trabajo, que utiliza Scrum, como fra-
mework de trabajo, junto con un criterio de done definido. Este criterio
cuenta con la utilización de prácticas cómo la integración continua e
inspección continua y todas las herramientas que formarán parte del
proceso y cómo es la integración entre sí.

Capítulo 4 se aplica el proceso definido en el Capítulo 3, en un caso

real de desarrollo de un producto de software. Se detalla el software a
desarrollar, su motivación, los objetivos y las tecnologías seleccionadas
para poder realizar dicho proceso. También se describe la planificación,
desarrollo y resultados de los Sprints trabajados.

Capítulo 5 presenta las conclusiones globales de este trabajo, ventajas,

limitaciones y trabajos futuros.
Capítulo 2

Fundamentos teóricos

Este capítulo presenta una visión teórica sobre las áreas qué se abordarán
en el resto del documento: tales como Metodologías Ágiles, Scrum, Arqui-
tectura de Aplicaciones Web, tecnologías más utilizadas en el desarrollo de
estas aplicaciones, controlador de versiones junto con Git, Integración Con-
tinua e Inspección Continua y cómo ambos se relacionan entre sí. También
se presentarán trabajos dónde se adaptó el framework de Scrum, para definir
un proceso que involucra equipos pequeños de desarrollo.

2.1. Metodologías Ágiles

En 2001 (Canós and Letelier, 2012), surge de una reunión realizada en
los Estados Unidos, el término ágil aplicado en el desarrollo de software.
Se describieron los principios que les debería poder permitir a los equipos
desarrollar software de una manera rápida, pudiendo responder a los cambios
que puedan surgir a lo largo del proyecto. De esta manera, esos métodos ágiles
ofrecen una alternativa a las metodologías de software tradicionales que son
caracterizadas por ser rígidas, poco flexibles y dirigidas por la documentación
que se genera en cada una de las actividades.
Las metodologías ágiles se las puede considerar cómo un conjunto de mé-
todos en el desarrollo de software que están basados en el desarrollo iterativo
e incremental. Se pueden destacar las siguientes características: son adapta-
tivas y planificadas; rápidas y de respuesta flexible en base a cambios en los
requerimientos.

11
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 12

2.1.1. El Manifiesto Ágil

Tras esta reunión se creó The Agile Alliance 1 , una organización sin fines
de lucro dedicada a promover los conceptos relacionados con el desarrollo ágil
de software. Para eso, crearon un documento denominado el Manifiesto Ágil.
Acorde al Manifiesto Ágil2 se valora:

Al individuo e interacciones del equipo sobre el proceso y las herra-

mientas. En cualquier proyecto, el equipo de desarrollo es el principal
factor de éxito. Es por eso que es mejor crear el equipo y que éste se
configure su propio entorno de desarollo en base a sus necesidades y
experiencia.

Software que funcione sobre realizar una buena documentación. Si bien

es importante una documentación en cualquier proyecto, se valorará
más un software que cumpla con los requisitos iniciales y sea intuitivo,
debido a que es lo que realmente terminan valorando los usuarios finales.

La colaboración con los clientes más que la negociación del contrato.

Esto se refiere a que haya una comunicación constante con el cliente a
lo largo del proyecto, para que el producto final se corresponda con las
necesidades del mercado al momento del lanzamiento.

La respuesta ante un cambio sobre seguir estrictamente un plan. La ha-

bilidad de responder ante un cambio durante el proyecto, determinará
el éxito o fracaso del mismo. Es por eso, que la planificación del mismo
debe ser flexible y adaptativa.

Estos valores fueron inspirados en los doce principios del manifiesto. Estos
principios son características que hace diferenciar un proceso ágil de uno
tradicional 3 .

2.2. Scrum
Scrum es un framework de desarrollo ágil para el desarrollo de softwa-
re. Provee una forma de trabajo flexible y adaptable para la creación de
productos de forma incremental.
Este framework está basado en un conjunto de valores, principios y prácti-
cas para poder administrar cualquier tipo de proyecto. Scrum se basa en tres
1
https://www.agilealliance.org/
2
https://agilemanifesto.org/
3
https://agilemanifesto.org/principles.html
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 13

pilares: Transparencia, Inspección y Adaptación (Sutherland and Schwaber,

2013).
Provee un conjunto de artefactos, roles y eventos. Mientras que el equipo
es el responsable de la creación del producto y de adaptarse a cualquier
cambio que el proceso requiera (Schwaber and Beedle, 2002).
En Scrum, el software es entregado luego de finalizar iteraciones denomi-
nadas “Sprints“. Cada uno de estos Sprints tiene una duración recomendada
de dos a cuatro semanas.
Este proceso se inicia con la recolección de los requerimientos del pro-
ducto en forma de product backlog ítems creadas por los clientes y equipos.
Cada uno de estos ítems están organizadas mediante una prioridad en el
Product Backlog. Los ítems de mayor prioridad son seleccionadas desde el
Product Backlog para ser implementadas en el próximo Sprint. Durante el
Sprint, ningún ítem debe ser agregado. Al comienzo del mismo, una reunión
de planificación es llevada a cabo dónde los miembros del equipo discuten
cuáles son los ítems que pueden comprometerse a resolver para luego crear
el Sprint Backlog (lista de ítems a implementar durante el Sprint).
Durante todo el Sprint, el equipo de desarrollo trabaja en la implemen-
tación de cada uno de los requerimientos incluyendo el diseño, desarrollo y
testeo(o las tareas que indiquen su criterio de done). Luego de finalizar, cada
uno de estos requerimientos es integrado al producto de una manera incre-
mental. Además, se llevará a cabo una reunión diaria en dónde cada miembro
del equipo informa el progreso actual, si tuvo algún tipo de bloqueo, y su plan
para las próximas 24 horas.
Al finalizar el Sprint, debe haber un incremento del producto listo para
ser entregado con nuevas funcionalidades. Además, al finalizar el Sprint, hay
una reunión con los clientes para mostrarles lo que se estuvo realizando du-
rante el Sprint y una reunión interna del equipo junto con el Scrum Master
para evaluar el desempeño durante el Sprint, y qué se puede mejorar para el
siguiente.
En las siguientes subsecciones se hablará sobre las prácticas, artefactos y
roles que están incluidos dentro de Scrum (Sutherland and Schwaber, 2013).

2.2.1. Roles
Scrum define tres roles que formarán parte del framework que conforman
el Scrum Team: Product owner, Development team y Scrum master.
El Product Owner (P.O) es el responsable del producto por parte del
cliente. En este sentido el P.O es el rol más interesado sobre el producto
debido a que éste es el que decide la aceptación del producto a entregar,
establece los requerimientos del proyecto e indica las prioridades de la lista del
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 14

Product Backlog durante la reunión de planificación (Schwaber and Beedle,

2002).
Dentro del equipo de desarrollo (Development Team), en el caso del desa-
rrollo de software, pueden haber distintas personas con distintos roles y ha-
bilidades cada uno. Por ejemplo puede incluir personas con habilidades en el
análisis, desarrollo, testeo, diseño de interfaz, diseño de base de datos, etc.
El equipo es el encargado de entregar una parte del producto funcional al
finalizar el Sprint. El equipo se debe asegurar que se cumpla la definición de
Done para asegurarse que siempre esté disponible una versión del producto
en funcionamiento.
El equipo también se encarga de elegir la cantidad de ítems a seleccio-
nar del Product Backlog y también se compromete a terminar cada uno de
ellos. Además, se encarga de proveer ideas al Product Owner para mejorar
la productividad (Schwaber and Beedle, 2002).
El Scrum Master es el encargado de aplicar cada una de las prácticas que
posee Scrum. Y además, es el principal encargado de llevar a cabo cada una
de las reuniones, y el responsable de garantizar que cada miembro del equipo
pueda llevar a cabo sus tareas correspondientes(Sutherland and Schwaber,
2013).

2.2.2. Artefactos
En la siguiente Sub-sección, se explicará de una manera breve y concisa
cada uno de los artefactos que forman parte de Scrum.

2.2.2.1. Product Backlog

El Product Backlog es una lista priorizada de requerimientos del proyecto
con tiempos estimados para desarrollar la funcionalidad completa del pro-
ducto. Esta lista se actualiza continuamente para reflejar los cambios en las
necesidades del cliente. El Product Owner es el encargado de priorizar cada
uno de estos ítems para luego poder consultar con el equipo y las partes invo-
lucradas en el producto. Además, cada uno de los ítems debe ser estimado. El
equipo y Product Owner son los que se encargan de decidir dicha estimación
en base a complejidades y riesgos(Sutherland and Schwaber, 2013).

2.2.2.2. Spring Backlog

El Sprint Backlog es una lista de tereas consensuadas por el equipo
de desarrollo para ser completadas durante el próximo Sprint. Durante la
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 15

reunión de planificación, el equipo selecciona los ítems de mayor prioridad

del Product Backlog.
Durante el Sprint, se espera que los miembros del equipo actualicen las
tareas del Sprint Backlog a medida que se van completando(Sutherland and
Schwaber, 2013).

2.2.2.3. Product Increment

El Product Increment es la suma de todos los ítems del Product Backlog
que fueron completados durante el Sprint actual y el valor agregado de los
incrementos de los Sprints anteriores. Al final del Sprint, los ítems del incre-
mento deben haber cumplido con todas las condiciones previamente pactadas
para determinar cuándo un ítem se encuentra terminado.

2.2.3. Eventos
A continuación, se explicará cada uno de los eventos que forman parte
del framework de Scrum.

2.2.3.1. Sprint
El Sprint es uno de los eventos más importantes en Scrum, y es el nombre
que recibe cada iteración dentro del proceso. Tiene una duración recomen-
dada de dos a cuatro semanas y generalmente son de duración constante.
Al final de cada Sprint tiene que haber un incremento que aporte un va-
lor agregado al producto que está en desarrollo (Sutherland and Schwaber,
2013).

2.2.3.2. Sprint Planning

Al comienzo de cada Sprint, es llevada a cabo la Sprint Planning. Esta
reunión es dividida en distintas partes. Durante la primer parte, el Product
Owner presenta los ítems del Product Backlog que tienen mayor prioridad al
equipo. Estos colaboran conjuntamente para estimar cuántos de estos ítems
se pueden llegar a desarrollar en el próximo Sprint. La segunda parte de la
reunión, consiste en cómo debe implementarse cada uno de los elementos
seleccionados. Luego, el equipo de desarrollo, estima cuántos de estos ítems
pueden completar para el final del Sprint. Cada uno de los ítems elegidos en
esta segunda parte, es agregado al Sprint Backlog para luego poder comenzar
a trabajar (Schwaber and Beedle, 2002)(Sutherland and Schwaber, 2013).
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 16

2.2.3.3. Daily Meeting

La Daily Meeting es una reunión diaria que no debería tener más de 15
minutos de duración (depende de la cantidad de personas que formen parte
del equipo). En dicha reunión, cada miembro del equipo debe responder las
siguientes preguntas:

1. ¿Qué realizó luego de haber finalizado la daily del día anterior?

2. ¿Con qué va a trabajar luego de la finalizar la daily?

3. ¿Con qué complicaciones se encontró?

Esta reunión mejora la comunicación, colaboración y conocimiento sobre el

progreso actual. El Scrum Master es el encargado de poder llevar a cabo
dicha reunión(Schwaber and Beedle, 2002)(Sutherland and Schwaber, 2013).

2.2.3.4. Sprint Review

Luego de finalizar el Sprint, hay una reunión para revisar lo que se hizo
durante el mismo. A esta reunión asiste el Product Owner, Scrum Team,
Scrum Master y todas las partes interesadas en el producto. Se discute sobre
lo que se hizo durante el Sprint y todo lo que se logró durante el mismo. En
general, este tipo de reuniones dura no más de cuatro horas para un Sprint
de cuatro semanas. En caso de ser de menor duración el Sprint, también lo
será la reunión (Sutherland and Schwaber, 2013).

2.2.3.5. Sprint Retrospective

Luego de finalizar la reunión de revisión, se realiza la Sprint Retrospective.
En dicha reunión asiste el Scrum Team y Scrum Master y se discute:

1. Cuáles fueron las prácticas que resultaron beneficiosas para el equipo.

2. Cuáles prácticas no resultaron beneficiosas para el equipo.

3. Qué se puede mejorar para el siguiente Sprint.

Este tipo de reuniones suele tener una duración máxima de tres horas para
un Sprint de cuatro semanas. En caso de ser de menor duración el Sprint,
también lo será la reunión(Sutherland and Schwaber, 2013).
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 17

2.3. Arquitectura de Aplicaciones Web

La arquitectura de aplicaciones web describe la interacción entre aplica-
ciones, base de datos y middleware en la web para asegurarse que las múltiples
aplicaciones funcionen de manera simultánea.

2.3.1. Tipos de Arquitecturas de Aplicaciones web

Una arquitectura de aplicaciones web es un patrón de interacción entre
varios componentes web. El tipo de arquitectura depende principalmente de
cómo se distribuya la lógica de la aplicación entre el client-side y server-side
(Conallen, 1999). Hay dos tipos principales de arquitectura de aplicaciones
web:

Model View Controller (MVC)

Single Page Applications (SPAs)

2.3.1.1. Model View Controller

Este patrón se encarga de separar los datos, la lógica y la presentación
de los mismos. En dicha arquitectura, el controlador se encarga de procesar
los datos ingresados por el usuario para que el modelo actualice su estado.
Luego, el modelo se encarga de notificar a la vista, que el estado cambió y
este es quién se encarga de representar los nuevos datos en la interfaz de
usuario de la aplicación (Scott, 2015a).

Modelo: Representa los datos de la aplicación. Estos datos contienen

propiedades y posiblemente lógica para acceder y administrar los datos.

Controlador: Es el punto de entrada para la aplicación, dado que recibe

señales desde la Interfaz de usuario. Contiene lógica que procesa al
usuario. Envía mensajes al modelo para actualizar su estado en función
de las señales recibidas.

Vista: La vista es las interfaz que el usuario ve e interactúa. También

se en carga de procesar la lógica que procesa lo ingresado por el usuario
y envía los comandos al modelo para actualizar el estado en base a las
entradas.

Una de las principales ventajas que ofrece este tipo de arquitectura son:
buen acoplamiento, favorece a la separación de concerns, mantenibilidad y
escalabilidad de la misma (Heidke et al., 2008).
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 18

2.3.1.2. Single Page Application

En este diseño, la aplicación completa corre cómo si fuese una sóla página.
La capa de presentación, es separada del lado del servidor y es gestionado
directamente desde el browser. Este tipo de aplicaciones está compuesto por
tres partes: código funcional del lenguaje JavaScript, el lenguaje de maque-
tado HTML y CSS para los estilos (Scott, 2015a).
Algunas de las ventajas de utilizar este tipo de diseño son:

Renderiza la página sin tener que actualizar el browser: SPA posee la

habilidad de renderizar porciones de la vista dinámicamente, haciendo
que el usuario vea los cambios de manera instantanea. No hay necesidad
de renderizar completamente la página ante un cambio de datos.

Desacoplamiento de la capa presentacional: El código que se encarga

de mostrar la vista de la aplicación se mantiene separado del lado del
servidor, haciendo que quede separados cada uno de estos. Esto permite
que se puedan actualizar y mantener por separado.

Las transacciones son más rápidas y livianas: Debido a que solamente

es datos lo que se envía y recibe del servidor, esto hace que las tran-
sacciones sean mucho más rápidas.

Menor tiempo de espera: Cuánto menos tiempo tenga que esperar un

usuario para que cargue una página, es más probable que la persona
permanezca en el sitio y regrese en un futuro.

2.4. Tecnologías para el desarrollo de Interfaces

de Usuario
A continuación se realizará un análisis comparativo de las tecnologías más
utilizadas en la actualidad para el desarrollo de interfaces de usuario. Entre
las más modernas y utilizadas se encuentran Angular4 , React5 y Vue6 . Los
criterios a comparar respecto a cada una de estas tecnologías serán: perfor-
mance, flexibilidad, popularidad y soporte en la comunidad de desarrollo.
4
https://angular.io/
5
https://reactjs.org/
6
https://vuejs.org/
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 19

2.4.1. Background
React es una biblioteca JavaScript de código abierto desarrollada por
Facebook en 2013 para crear interfaces de usuario. Esta biblioteca es amplia-
mente popular entre las comunidades de desarrolladores debido a la facilidad
para el desarrollo de aplicaciones web.
Angular es un framework de código abierto realizado con TypeScript en el
2010, para el desarrollo de Single Web Applications desarrollado y mantenido
principalmente por Google.
Mientras que Vue, es un framework de código abierto desarrollado en
JavaScript que se encuentra en rápido crecimiento para el desarrollo de apli-
caciones web.

2.4.2. Popularidad
Según la encuesta realizada por Stack Overflow correspondiente al año
2019 7 , React se encuentra posicionado como la segunda biblioteca más utili-
zada en el desarrollo de aplicaciones Web con un 31.3 %. Mientras que Angu-
lar, se encuentra en tercer lugar con un 30.7 % y en séptimo lugar Vue con un
15.2 %. Cabe destacar, que en dicha encuesta, se encuentra junto con otros
frameworks de Backend.
Dentro de la misma encuesta, se realizó una pregunta para saber cuáles
eran los frameworks web más requeridos en la actualidad. En dicha encuesta,
React se posicionó en primer lugar con un 74.5 %, Vue en segundo lugar
con 73.6 % y Angular en noveno lugar con un 57.6 %. Este número, refleja
el procentaje de desarrolladores que están desarrollando con la tecnología y
expresaron interés en seguir trabajando con la misma. En dicha encuesta, se
pudo concluir que React y Vue son las tecnologías más requeridas y buscadas
por los usuarios en el desarrollo de aplicaciones web.

2.4.3. Rendimiento
El rendimiento de las aplicaciones desarrolladas con Angular es peor en
comparación con las aplicaciones realizadas en React y Vue. Esto se debe a
que Angular utiliza el Document Object Model real (Interfaz de usuario) y
este cambia cada vez que se actualizan los datos en la aplicación. El uso del
DOM real afecta el rendimiento (bajo) y la habilidad de crear aplicaciones
de software dinámicas.
Con respecto a React y Vue, éstas utilizan un DOM virtual. El DOM
virtual es una abstracción del DOM real. El DOM virtual, es un objeto liviano
7
https://insights.stackoverflow.com/survey/2019#technology
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 20

y está separado de los detalles de implementación específicos del navegador.

Por cada objeto del DOM real, hay un correspondiente objeto del DOM
virtual, siendo este último, una representación de un objeto del DOM.
Una de las principales razones por las que React y Vue utilizan este tipo
de patrón, es debido a que la manipulación del DOM real es muy lenta. En
cambio, el manejo de un DOM virtual es mucho más rápido, debido a que no
tiene que renderizar nada a través de una pantalla (Thomas, 2018) (Martin,
2019).

2.4.4. Soporte de la comunidad

Tanto Angular como React tienen un fuerte apoyo por parte de la comuni-
dad debido a que fueron desarrolladas por empresas cómo Google y Facebook.
Ambas empresas tienen productos desarrollados en dichas tecnologías cómo
por ejemplo Google Adwords e Instagram. Por lo que, la inversión de tiempo
y desarrollo es fuerte en ambas tecnologías por parte de dichas empresas y
la comunidad.
Al contrario es lo que sucede con Vue, debido a que ésta no posee el
respaldo de una empresa de software cómo puede ser Google o Facebook. A
pesar de tener esta desventaja, Vue ha ganado mucha popularidad en este
último tiempo en la comunidad de código abierto.

2.4.5. Curva de aprendizaje

La habilidad que posee un usuario para desarrollar código en un deter-
minado lenguaje se denomina a la curva de aprendizaje. Cuándo se trata de
la misma, React y Vue parecen estar un paso más adelante con respecto a
Angular, y esto se debe a que solo se necesita saber de JavaScript, HTML y
CSS para trabajar con estas tecnologías.
De acuerdo con la investigación realizada por The State of Jss8 , React
sacó el mayor porcentaje con un 71.7 % cuándo se le preguntó si lo habían
usado y lo seguirían usando. En segundo lugar se encuentra Vue con 40.5 %
y en tercer lugar Angular con 21.9 %.
Cómo se puede observar en la Figura 2.1 , Vue sacó la mayor cantidad de
votos para la opción de “escuche sobre la tecnología y me gustaría aprender“.
También se puede observar una gran disminución en la popularidad y curva
de aprendizaje sobre Angular.
8
https://2019.stateofjs.com/front-end-frameworks/
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 21

Figura 2.1: Resultado General sobre Tecnologías de Frontend.

2.5. Tecnologías para el desarrollo de servido-

res web
En la actualidad existen muchos lenguajes y frameworks para el desarrollo
de servidores web. A continuación se hablará sobre los lenguajes y frameworks
más utilizados y qué beneficios puede ofrecer cada uno de estos. Entre las
más modernas y utilizadas se encuentran Node.js9 y Python10 .

2.5.1. Background
Python es un lenguaje dinámico de alto nivel lanzado en 1991, que ha
ganado popularidad en el último tiempo y de acuerdo a la encuesta de Stack
Overflow es el cuarto lenguaje más utilizado. Tiene bibliotecas de código
abierto para el análisis de datos, frameworks web y testing.
A diferencia de Python, Node.js es un entorno de ejecución de código
abierto lanzado en 2009, liviano y eficiente basado en el motor JavaScript
V811 de Google Chrome, que ayuda a la ejecución de código JavaScript para
el desarrollo de servidores web. Cuenta con un modelo de Entrada/Salida
sin bloqueo (asíncrono) controlado por eventos y diseñado para desarrollar
servidores altamente escalables.
Una de las principales ventajas que tiene Node, es que es una solución
basada en JavaScript, por lo que el desarrollo de backend le permite a los
desarrolladores tener todas las ventajas que este lenguaje tiene para ofrecer,
además de ser el lenguaje más utilizado de acuerdo a la encuesta realizada
por Stack Overflow en 201912 , ocupando el primer lugar desde hace siete
9
https://nodejs.org/es/
10
https://www.python.org/
11
https://v8.dev/
12
https://insights.stackoverflow.com/survey/2019#technology
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 22

años consecutivos. Además, tanto el backend cómo el frontend están escritos

en el mismo lenguaje de programación. Por lo que en la práctica, cualquier
desarrollador JavaScript podría ocuparse del lado del cliente y del lado del
servidor sin tener mayores complicaciones.

2.5.2. Rendimiento
Node ofrece un alto rendimiento, debido a que el código JavaScript es
interpretado por motor JavaScript V8 de Google Chrome. Además de que
soporta operaciones de entrada/salida no bloqueantes, hace que esas solici-
tudes se resuelvan de manerar asíncrona lo que acelera la ejecución de código.
Con respecto a Python, cada solicitud es procesada de manera más lenta.
Por lo que no es recomendable usar Python para aplicaciones que prioricen la
velocidad o involucren soluciones complejas para el desarrollo de servidores
web.

2.5.3. Escalabilidad
Node es apto para una arquitectura de microservicios (separar en peque-
ños modulos la lógica de la aplicación) para mayor escalabilidad. Permite
crear un conjunto de microservicios y módulos, dónde cada uno de ellos se
comunicará de manera sencilla ejecutando su propio proceso. Esto hace que
las aplicaciones creadas con Node sean más flexibles y altamente escalables.
Con respecto a Python, no es recomendable para proyectos a largo plazo,
y esto es debido que a medida que crece, el código se vuelve cada vez más
complejo y difícil de mantener. Y una de las razones por las que no es re-
comendable es porque Python utiliza un Interpretador Global de Bloqueo,
haciendo que no se puedan ejecutar múltiples hilos de ejecución simultáneos.

2.5.4. Frameworks más populares

Express13 es el framework de código abierto más popular de Node. Según
la documentación de la misma, Express ofrece una solución rápida, mini-
malista y flexible para las aplicaciones hechas en Node. Proporciona libertad
para el desarrollo, ofreciendo una buena curva de aprendizaje para los nuevos
desarrolladores. Una de las desventajas que tiene es que no hay una mane-
ra recomendada para organizar y estructurar el proyecto debido a la gran
flexibilidad que posee.
Django14 es un framework de código abierto basado en Python para el
13
https://expressjs.com/es/
14
https://www.djangoproject.com/
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 23

desarrollo de servidores web. Ofrece una arquitectura definida cómo es el

patrón de diseño MVC, y se basa en el desarrollo ágil (desarrolladores pueden
realizar más de una iteración a la vez sin comenzar todo el desarrollo desde
cero). Además, el framework se basa en la filosofía Don’t Repeat Yourself,
dónde los desarrolladores podrán enfocarse en la reutilización de código.

2.5.5. Ventajas y desventajas

Algunas de las ventajas y desventajas que ofrece Python son:

Python permite desarrollar un prototipo en una limitada cantidad de

tiempo, para poder reducir el tiempo de salir al mercado. Eso se debe
a la facilidad que ofrece Python para poder desarrollar.

Python posee una sintaxis sencilla. Una de las principales razones por
las cuáles los desarrolladores eligen Python es debido a que se les per-
mite crear soluciones fáciles en tan sólo pocas líneas de código. Esto
favorece tanto a la hora de resolver errores, cómo a la colaboración.

Python posee una gran variedad de opciones a la hora de elegir fra-

meworks y herramientas. Ofrece librerías para data science, machine
learning, y desarrollo web.

Tiene una gran comunidad. Comparado con Node, Python es un len-

guaje más open-source debido a la cantidad de usuarios que aportan
a la comunidad de desarrolladores. Esto favorece a la hora de buscar
desarrolladores Python, y a la hora de compartir soluciones y mejorar
el lenguaje.

Una de las desventajas que tiene Python, cómo se mencionó anterior-

mente, la velocidad en tiempo de ejecución es más lenta comparada con
otros lenguajes. Puede que no sea la mejor opción para aplicaciones que
implican operaciones complejas.

Mientras que algunas de las ventajas y desventajas que ofrece Node son:

Rápida performance comparando con Python, y esto se debe al motor

V8 de Google.

Cualquier desarrollador JavaScript puede trabajar con Node del lado

del servidor y con alguna biblioteca JavaScript para el lado del cliente,
permitiendo así poder ahorrar costos.
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 24

Debido a que es una arquitectura basada en eventos, es una buena

opción para aplicaciones en tiempo real.

Cualquier tarea que sea costosa en términos computacionales, bloquea-

rá el procesamiento y ralentizará el resto de la aplicación.

En conclusión, Python y Node, ambos tienen sus ventajas y desventajas,

y estos son utilizados en diferentes tipos de proyectos. Lo mejor es decidir
utilizar uno en base a los requerimientos del proyecto(Yarbrough, 2019).

2.6. Sistema de Controlador de Versiones

Un sistema de controlador de versiones (SCV) es un sistema capaz de
registrar los cambios realizados en un archivo o un conjunto de archivos
durante un período de tiempo de tal manera que le permita al usuario retro-
ceder en el tiempo desde el futuro para recordar una versión específica de ese
archivo(Chacon and Straub, 2014) .
Este tipo de sistemas, será el encargado de monitorear los archivos en
busca de cambios y le permitirá etiquetar esos cambios en diferentes niveles
para que pueda volver a visitar esas etapas etiquetadas cuando sea necesario.
El control de versiones es importante para los equipos de desarrollo de
hoy en día. Necesita hacer más que solo administrar y rastrear archivos ya
que tiene que ayudar a desarrollar y entregar productos de una manera más
rápida y eficiente. Esto es especialmente importante para los equipos que
utilizan prácticas cómo la Integración Continua y Entrega Continua para
acelerar la entrega del producto.
A continuación se nombrarán tres razones por las cuáles los equipos de
desarrollo utilizan un controlador de versiones:

1. Almacenamiento de Versiones: Un controlador de versiones sabe que

sólo hay un proyecto, todas las demás versiones están empaquetadas
dentro del SCV.

2. Restauración de versiones previas: Cuándo se necesite alguna versión,

mediante la línea de comandos se podrá acceder en cualquier instante
de tiempo.

3. Permiten ver los cambios que fueron realizados a lo largo del tiempo
en el código, pudiendo retroceder si fuera necesario y deshacer esos
cambios.
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 25

2.6.1. Controlador de Versiones Distribuido

Existen tres tipos de controladores de versiones: local, centralizado y dis-
tribuido; y se diferencian en su modo de operación, aunque en la actualidad
solamente predomina uno sólo y es el controlador de versiones distribuido.
En la Figura 2.2, se puede observar una representación de un sistema
de controlador de versiones distribuido, en dónde cada desarrollador tiene
una copia de todo el proyecto en su computadora. Cada desarrollador, po-
drá trabajar a su propio ritmo, almacenando los cambios que haga a nivel
local(Chacon and Straub, 2014).

Figura 2.2: Controlador de Versiones Distribuido

2.6.2. Git
Git15 es un sistema de controlador de versiones gratuito y de código abier-
to originalmente creado por Linus Torvalds en 2005. A diferencia de otros
sistemas, Git es distribuido, es decir que cada desarrollador tiene la historia
completa del código en su repositorio localmente. Esto hace que la clonación
inicial del repositorio sea lenta, pero cualquier otra operación cómo commits,
merge, log, diff sea mucho más rápida.
Git también da soporte al manejo de ramas y merge. Una de las herra-
mientas más popular en términos de colaboración en el equipo de desarrollo
15
https://git-scm.com/
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 26

son los Pull Request. Git es el sistema de control de versiones más utilizado
en la actualidad y se considera el estándar moderno para el desarrollo de
software.
Un proyecto de Git se encuentra dividido en tres estados o partes (Chacon
and Straub, 2014):

1. La primera parte es el área de trabajo o working directory. Acá es dónde

están todos los archivos que son creados durante la etapa de desarrollo.

2. La segunda parte es el área de staging, acá es dónde se encuentran

todos los archivos que se estén modificando y agregando para una futura
revisión o commit.

3. La última parte es el área de commit o el git directory, que es dónde

se almacenan todas las revisiones

Algunas características que tiene Git son:

Controlador de Versiones distribuido, logrando que desarrolladores pue-

dan trabajar de manera independiente y paralela desde cualquier lugar.

Es lo suficientemente escalable cómo para permitir que cientos de desa-

rrolladores trabajen en un mismo proyecto.

Permite movernos por distintas versiones de código de una manera ágil

y sencilla.

Mantiene la integridad y seguridad de los datos. Git utiliza una función

de hasheo criptográfica, llamada Secure Hash (SHA1), para nombrar e
identificar objetos dentro de su base de datos.

Repositorios completos. Cada desarrollador que tenga acceso a un re-

positorio de código, tendrá acceso a la historia completa del proyecto.

Al ser una herramienta de código abierto, es totalmente gratuita.

2.7. Integración Continua

La integración continua es una práctica en el desarrollo de software dónde
miembros del equipo de desarollo integran el trabajo realizado de manera
frecuente, lo que lleva a múltiples integraciones por día. Cada una de estas
integraciones se verifica mediante una compilación automatizada, que incluye
testeo para detectar errores de integración de la manera más rápida posible.
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 27

Una de las principales ventajas es la reducción de problemas en la inte-

gración y un desarrollo ágil de software (Fowler and Foemmel, 2006).
A continuación, se nombrarán las prácticas que hacen más efectivas a la
integración continua (Fowler and Foemmel, 2006):

Mantener un único repositorio de código: Para esto es necesaria la uti-

lización de un SCV y un administrador de proyectos para mantener
todos los archivos de código de manera local y en un servidor remoto.

Automatizar la compilación: Esto significa poder compilar de manera

automática nuestro código fuente.

Automatizar el testeo de la aplicación. Se debería poder testear de

manera automática cada uno de los test creados para la aplicación.

Cada desarrollador debe realizar los commits a la rama principal de

manera frecuente para evitar conflictos.

Si ocurre algún error en la compilación, se deberá arreglar el error lo más

rápido posible para no atrasar la integración de otros desarrolladores.
En cambio, si no ocurre ningún error, como resultado de este proceso se
obtiene una versión que teóricamente está lista para salir a producción.

2.7.1. Herramientas para la Integración Continua

Para poder generar el flujo correspondiente de Integración Continua, es
necesaria la utilización de alguna herramienta que se encargue de generar
dicho flujo. A continuación, se nombrarán algunas de las herramientas más
utilizadas en el desarrollo de software.
Una de las herramientas es Jenkins16 , esta herramienta es de código abier-
to. Es utilizada por una gran cantidad de empresas, ya que le permite a los
desarrolladores poder generar una compilación y testear. Una de las prin-
cipales ventajas que ofrece esta herramienta, es la flexibilidad mediante la
utilización de plugins. Estos plugins hacen que se pueda extender la funcio-
nalidad de acuerdo a las necesidades de cada proyecto. Aunque la principal
desventaja, es la curva de aprendizaje debido a que puede ser compleja la
configuración de esta herramienta en un proyecto de software(Berg, 2012).
Otra de las herramientas de integración continua que hay en el mercado es
Travis CI17 . Travis CI es un servicio distribuido de integración continua que
se utiliza para compilar y testear proyectos de software que se encuentren
16
https://jenkins.io/
17
https://travis-ci.org/
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 28

en Github. La única desventaja es que los proyectos que sean privados en

esta última plataforma, tendrá un costo adicional para poder utilizar esta
herramienta.

2.8. Inspección Continua

La inspección continua es un paradigma en la gestión de la calidad del
código diseñado para hacer que el software sea una parte integral en el ciclo
de vida del desarrollo. Es un proceso que aumenta tanto la calidad interna
del software cómo la visibilidad de la calidad del software para las partes
interesadas de manera continua. Uno de los conceptos claves en la inspección
continua es la de encontrar problemas de manera temprana, dónde no resulta
tan costoso poder resolverlos (Gaudin, 2012) .
La idea principal es poder agregar una etapa más en el proceso de Inte-
gración Continua para que una herramienta de inspección pueda analizar el
código desarrollado.
A continuación se nombrará alguno de los principios más importantes que
hacen a la inspección continua :

La calidad del software debe ser parte del proceso de desarrollo, lo cuál
significa que debe cumplir con los estándares de calidad para que el
desarrollo sea completo.

En la medida que sea posible, los requisitos de la calidad del software

deben ser comunes a todos los productos, independientemente de los
detalles de cada uno.

Los datos de calidad del software deben estar disponibles tanto en va-
lores absolutos (de todo el código) cómo diferenciales (nuevo código),
para que el equipo de desarrollo pueda tener visibilidad total de algún
nuevo problema.

Todas las partes interesadas del producto, no sólo desarrolladores, debe-

rán tener acceso a los datos generado por las herramientas de inspección
continua.

2.8.1. Herramientas para la Inspección Continua

Una de las herramientas open source más utilizadas es SonarQube18 , pro-
vee una gran cantidad de medidas, gráficos y configuraciones, lo que a su vez
18
https://www.sonarqube.org/
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 29

la vuelve un poco compleja. Posee una gran cantidad de reglas para distintos
tipos de medidas cómo code smells, bugs, vulnerabilities para cada uno de
los lenguajes de programación cómo JavaScript, Java, C# etc. Una de las
principales diferencias que tiene esta herramienta con las demás, es que el
análisis de código se ejecuta externamente al servidor de Integración Con-
tinua y el resultado es enviado. Luego, esta herramienta realiza el análisis
correspondiente y almacena en la base de datos el resultado de la ejecución
(Janes et al., 2017).
Se pueden configurar Quality Profiles, que son el conjunto de reglas para
aplicar en el correspondiente análisis y las Quality Gates, que son los umbrales
para la calidad del código. Este análisis se ejecuta una vez que el código nuevo
es combinado con la rama principal de trabajo.
En conclusión, SonarQube es una herramienta poderosa y gratuita pero
requiere una etapa de configuración e integración con el servidor de integra-
ción continua.
Otra de las herramientas más utilizada es Codacy19 . Codacy posee una
interfaz muy bien diseñada, dónde es fácil encontrar la información importan-
te y es fácil la configuración inicial. Las medidas de calidad están agrupadas
en ocho categorías dentro de las cuáles se destacan code-complexity, security
y performance cómo las más importantes. A diferencia de SonarQube, esta
herramienta tiene un costo que se efectúa por mes, el análisis se realiza antes
de combinar el código nuevo con el código de la rama principal y puede que
el análisis de código, para algunos lenguajes de programación cómo JavaS-
cript, no sea el más eficiente. Por lo que, puede ser que esta herramienta sea
la correcta, pero dependerá mucho del lenguaje que se utilice en el proyecto
(Saorin, 2017).

2.9. Procesos para equipos pequeños

La autora Gancarczyk (Gancarczyk, 2018), define un proceso de Scrum
para que sea pequeño y escalable, denominado Small Scale Scrum. En éste
identifica un conjunto de principios, un manifiesto y el framework, con técni-
cas e implementaciones para un proceso similar a Scrum con tres personas en
el equipo de desarrollo, dos desarrolladores y un administrador del proyecto.
Se realizaron algunas modificaciones cómo por ejemplo: el Product Backlog y
Sprint Backlog por Project Backlog debido a la ausencia del Product Owner ;
en lugar de un incremento de producto tienen una Proof Of Concept/Demo
para que la entrega sea lo más rápida posible, en esta misma no se incluye
ninguna etapa de integración continua, o revisión de código; no hay Daily
19
https://www.codacy.com/
CAPÍTULO 2. FUNDAMENTOS TEÓRICOS 30

Meetings debido a que no se justifica realizarla para pocas personas . En

(Griffin, 2019), el autor escribe sobre el proceso definido anteriormente pero
aplicado en un caso dónde el equipo de desarrollo estuvo formado por un
estudiante, para poder tener en claro cuáles podían ser los beneficios de usar
ese proceso de desarollo aplicados en un equipo de una o dos personas.
Rising y Janof (Rising and Janoff, 2000) proponen un enfoque alternati-
vo a Scrum mediante la disminución de personas en el equipo de desarrollo,
debido a los constantes cambios en los requerimientos durante el desarrollo
de un producto, y descubrieron que estos equipos pequeños pueden ser más
flexibles y adaptativos. Cómo resultado de la interacción de pequeños equipos
y ciclos de desarrollo obtuvieron: un producto convertido a partir de peque-
ñas piezas funcionales; un progreso aunque los requerimientos no hayan sido
claros o hayan cambiado durante el desarrollo del Sprint; los clientes vieron
el incremento esperado al final del Sprint.
Sin embargo, ninguno de estos trabajos mencionan la definición de un
proceso de desarrollo, sino una adaptación de la metodología Scrum. Tam-
poco definen un criterio de done, ni mencionan prácticas cómo la integración
continua e inspección continua, ni la utilización de herramientas de desarrollo
cómo Git, ni de proceso cómo Jira. Hoy en día, la utilización de estas prácti-
cas son altamente requeridas en el desarrollo de software con el surgimiento
de la metodología de trabajo denominada DevOps (Ebert et al., 2016).
Capítulo 3

Adaptación del proceso

En este capítulo se define un proceso de desarrollo de software para equi-

pos unipersonales, que utiliza Scrum, como framework de trabajo, definiendo
un determinado criterio de done. Se presenta cómo se realizó la adaptación
de Scrum para el escenario planteado, junto con: todas las características que
tendrá el proceso (artefactos, eventos y roles de Scrum que serán utilizados
dentro del mismo); la definición del criterio de done; y la integración de todas
las herramientas que formarán parte del proceso.
Este capítulo está organizado de la siguiente forma. Las características
que tendrá el proceso serán presentadas en la sección 3.1, mientras que en la
sección 3.2 se explicará cómo se integrarán todas las herramientas dentro del
mismo.

3.1. Características del proceso de desarrollo

En la Figura 3.1 se puede observar todos los elementos que serán to-
mados de Scrum y serán incorporados dentro del proceso de desarrollo. A
continuación, se explicará cuales son los artefactos, eventos y roles que serán
utilizados en el proceso.

3.1.1. Artefactos
Los artefactos que serán tomados de Scrum y utilizados en el proceso de
desarrollo son: el Product Backlog (PB), Sprint Backlog (SB), y el Incre-
ment una vez finalizado el Sprint. Es decir, se utilizarán todos los artefactos
definidos por Scrum.

31
CAPÍTULO 3. ADAPTACIÓN DEL PROCESO 32

Figura 3.1: Primera parte del proceso de desarrollo

3.1.1.1. Product Backlog

El PB será uno de los artefactos que se utilizará dado que le permitirá
al desarrollador, poder tener una lista de ítems de requerimientos o historias
de usuario, requeridas por el Product Owner (PO). Para la representación
de este artefacto, se utilizará la herramienta Jira.

3.1.1.2. Sprint Backlog

Con respecto al SB, el desarrollador y el PO podrán tener en claro cuáles
son los requerimientos y tareas que tendrán que ser implementados dentro
del Sprint. Es por eso que el SB deberá ser construido a partir del PB, jun-
to con el PO, durante el Sprint Planning. Uno de los objetivos principales
de usar este artefacto, es que será la fuente de tareas que el desarrollador
utilizará durante el Sprint y que organizará mediante el tablero de Scrum.
Este tablero le permitirá al desarrollador y al PO, ver cuáles tareas están
siendo implementadas, cuáles ya fueron finalizadas y cuáles quedan por im-
plementar. Cabe destacar que el tablero de Scrum, va a funcionar como una
herramienta de complemento dentro del proceso de desarrollo. Cómo repre-
sentación de esta herramienta, se utilizará el Scrum Board que proporciona
Jira.
CAPÍTULO 3. ADAPTACIÓN DEL PROCESO 33

3.1.1.3. Increment
Una vez finalizado el sprint, habrá una porción funcional potencialmente
entregable del producto, compuesto por todos los elementos del SB desarro-
llados durante el mismo.
Además dentro del proceso de desarrollo, estará complementado con gráfi-
cos cómo el Sprint Burn-Down chart. Este gráfico le permitirá al desarrollador
ver una estimación del trabajo restante que le queda al Sprint.

3.1.2. Roles
El rol más importante dentro del proceso es el del desarrollador, dado que
este deberá ser el responsable de que el proceso sea llevado a cabo de una
manera exitosa. Además de ser la única persona en el equipo, el mismo deberá
adoptar todas las responsabilidades que tiene el Scrum Master, y desarrollar
el software acorde a los requerimientos producto.
El otro rol que será tomado de Scrum es el del PO. Este rol será tomado
por el dueño del producto o cliente, y será quién tenga la responsabilidad de
transmitir al desarrollador, el producto de software que se desea construir,
junto con las reglas del negocio, y los posibles cambios que surgan durante
el proceso. Además deberá crear, administrar y priorizar todos los items del
PB.

3.1.3. Eventos
3.1.3.1. Sprint
Uno de los eventos más importantes dentro de Scrum es el Sprint, este
será fundamental dentro del proceso de desarrollo dado que nos permitirá
dividir al mismo en diferentes iteraciones, cada una con un objetivo propuesto
distinto. Además, al final de cada sprint, se podrá contar con una porción
del producto final, al que se le irá incrementando a medida que se avanza en
el proceso.
Al comienzo del proceso de desarrollo se realizará la primera reunión con
el PO en dónde se definirán todos los ítems del PB. Cada uno de estos ítems,
deberá ser distinguido entre dos categorías, estas son “D” (deseable) o “I”
(indispensable). Una vez realizada esta división, se realizará un ranking entre
todos los ítems del PB para identificar cuáles de ellos son los más importantes
para el PO a la hora de comenzar el proceso de desarrollo.
CAPÍTULO 3. ADAPTACIÓN DEL PROCESO 34

3.1.3.2. Sprint Planning

Dentro del proceso de desarrollo serán utilizados dos de los eventos más
significativos que define Scrum. El primer evento en el proceso de desarrollo
es el Sprint Planning (SP). Este evento es de suma importancia dado que le
permitirá al desarrollador poder discutir con el PO todos los ítems del PB
a implementar en la presente iteración. El objetivo de esta reunión es poder
definir un Sprint Goal u objetivo para el sprint y la estimación de cada uno
de los ítems que serán agregados al SB.
Para la estimación y planificación de cada uno de los ítems del SB se
aplicará una de las técnicas más utilizadas en las métodologías de desarrollo
ágil, el Planning Poker .
Durante la estimación, el PO o cliente, tendrá que leer un ítem o describir
una funcionalidad al desarrollador y todos deberán realizar una estimación.
Se deberá contar con un mazo de cartas de Planning Poker con los valores:
0, 1, 2, 3, 5, 8, 13, 20, 40 y 100, que es la secuencia de números recomendada
al momento de estimar. Estos valores, representarán la cantidad de “story
points”, es decir la complejidad de la historia de usuario en cuestión.
Una vez que se describa la historia de usuario, cada uno de los presentes en
la reunión, dará vuelta su carta seleccionada (todos deberán mostrar su carta
en el mismo instante de tiempo). Luego, tendrán que empezar a justificar
por qué eligieron dicho valor para la historia de usuario leída. Una vez que
todos hayan dicho su justificación sobre la carta elegida, entre todos tendrán
que llegar a un acuerdo para realizar la estimación. Para poder realizar este
paso se contó con la colaboración de los directores del trabajo final quiénes
ofrecieron otros puntos de vista mediante sus estimaciones.
Una de las principales razones por las cuáles se utilizará este método de
estimación, es porque le permitirá al desarrollador poder detectar posibles ta-
reas ocultas y obstáculos dentro de la historia de usuario. Así podrá detectar
posibles riesgos a la hora de empezar a trabajar durante el Sprint. También
le permitirá al desarrollador conocer el punto de vista de los clientes, con
respecto a la complejidad de dicha historia de usuario.
Para este evento, se utilizará la herramienta Jira, dónde quedará bien
representado cada uno de los items del PB que se implementarán en dicho
Sprint, junto con su objetivo o meta.

3.1.3.3. Sprint Review

Otro de los eventos que nos proporciona Scrum y que será utilizado en el
proceso de desarrollo es el Sprint Review (SR). Este evento se llevará a cabo
al final del Sprint, y se mostrará al PO junto con los clientes, lo implementado
CAPÍTULO 3. ADAPTACIÓN DEL PROCESO 35

en dicha iteración. Además se evaluarán cada uno de los ítems implementados

del SB y si se llevaron a cabo los objetivos definidos al comienzo del Sprint.
Es importante destacar que el desarrollador deberá estar preparado para
mostrar cada uno de los items del SB, en una presentación del producto al
PO.
En caso de ser necesario, se crearán nuevos ítems del PB si surgieron
nuevos cambios durante el Sprint, nuevas ideas o si fueron encontrado errores.
Cabe destacar que la planificación de la siguiente iteración se realizará
luego de haber realizado la revisión del Sprint anterior.

3.1.3.4. Daily Meetings

Con respecto a las reuniones diarias de Scrum o Daily Meetings, en este
proceso de desarrollo, no serán necesarias debido a qué una sola persona
formará parte del equipo de desarrollo y estará al tanto de todo lo que suceda
dentro del proyecto, ya sea avance del mismo, qué es lo que hay que realizar
y que obstáculos van a haber a la hora de desarrollar.

3.1.3.5. Sprint Retrospective

El otro evento que será utilizado en este proceso de desarrollo es la Sprint
Retrospective (SRet). Para este evento el desarrollador deberá tomar en cuen-
ta los resultados del Sprint, discutidos previamente con el PO en la SR. Ten-
drá que preguntarse a sí mismo, que se hizo bien y mal durante el Sprint, y
que puede ser mejorado para los siguientes Sprint. Dicho evento se llevará a
cabo después de la Sprint Review.

3.1.4. Definición de “Done”

La definición de done, es utilizada en los proyectos ágiles, para poder
definir un criterio general necesario para determinar cuando un requerimiento
puede ser validado o aceptado por el PO.
La definición de done le permitirá al desarrollador tener dos ventajas
sumamente importantes a lo largo del proceso de desarrollo:

1. Tener siempre un producto que pueda ser entregable y usable al fina-

lizar cada iteración. Esto le permitirá tanto al desarrollador como al
PO saber claramente en que estado se encuentra el proyecto y tomar
decisiones respecto a lo que se consiguió hasta ese momento.

2. Establecer un criterio de calidad para poder definir, que se debe cumplir

en cada requerimiento u objetivo durante cada una de las iteraciones.
CAPÍTULO 3. ADAPTACIÓN DEL PROCESO 36

De esta manera, se asegura la transparencia y la calidad del producto

al final de cada iteración. Según los autores Sutherland y Schwaber
(Sutherland and Schwaber, 2013), la definición del criterio de done
permite la transparencia con el PO, para determinar cuando un ítem
del SB está realmente terminado.

Al comienzo del proceso de desarrollo, cada requerimiento será representado

a través de una historia de usuario. Este criterio a definir, le permitirá al desa-
rrollador determinar cuando una historia de usuario se encuentra finalizada
(Estayno and Meles, 2014).
En este proceso de desarrollo una historia se considerará como terminada
cuando:

1. La historia de usuario deberá de ser implementada de la mejor forma

posible. Es decir, el código debe de poder ser mantenible, escalable y
legible a largo plazo. También se deberá crear los tests de unidad e
integración.

2. El código desarrollado es actualizado en el controlador de versiones y

logra atravesar con éxito el proceso de integración continua.

3. La historia de usuario es documentada.

4. La historia de usuario es aprobada y validada por el PO.

En la actualidad, hay una gran variedad de criterios de done definidos, en

dónde la mayoría incluyen estos criterios propuestos (Silva et al., 2017).
Según la guía de Scrum (Sutherland and Schwaber, 2013), cada criterio
debe ser definido acorde al contexto de cada equipo de desarrollo, es por eso
que dadas las condiciones de ser solamente una persona en el equipo se eligió
estos cuatro items para definir cuando una historia de usuario se encontrará
terminada.

3.2. Integración del proceso con herramientas

En esta sección se define cómo se integran y conectan cada una de las
herramientas qué se utilizarán dentro del proceso de desarrollo. Además, se
explicará como a partir del uso de estas herramientas, se podrán obtener dos
categorías de métricas.
CAPÍTULO 3. ADAPTACIÓN DEL PROCESO 37

3.2.1. Jira
En la Figura 3.1 se puede observar como se llevará a cabo la metodolo-
gía de desarrollo ágil Scrum en el proceso. Para poder tener en claro todos
los requerimientos del producto; lo qué se realizará en cada Sprint, se dará
soporte a esta metodología con la herramienta Jira. La principal ventaja del
uso de esta herramienta, es qué le permitirá al desarrollador poder organizar
el proceso basado en Scrum y a dejar documentado de una manera correcta
todo el proceso de desarrollo.1

3.2.1.1. Product Backlog

Jira permitirá administrar el PB de una manera ágil y eficiente. Cada uno
de los ítems pertenecientes al PB se van a describir como historias de usuario
dentro de Jira. En la Figura 3.2 y Figura 3.3 se puede observar a modo
de ejemplo como Jira permite la administración y creación de las distintas
historias de usuario dentro del PB. Además, le permitirá al desarrollador
asignar la estimación y prioridad correspondiente. Una vez creada la historia
de usuario, podrá crear distintas sub-tareas dentro de la misma.

Figura 3.2: Product Backlog

3.2.1.2. Sprint Backlog

En la Figura 3.4 se puede ver cómo Jira proporcionará un tablero vir-
tual, siendo éste una representación del Scrum Board (Sprint Backlog) para
ver todas las historias de usuarios qué se tratarán en dicho Sprint con sus
respectivas sub-tareas y su estado actual. Cabe destacar,qué Jira le permi-
tirá personalizar el contenido de las columnas (estado de las tareas), según
1
https://www.atlassian.com/software/jira
CAPÍTULO 3. ADAPTACIÓN DEL PROCESO 38

Figura 3.3: Creación de las historias de usuario

el proceso de desarrollo utilizado por el desarollador. Un posible ejemplo de

un tablero Scrum podría ser: “To do”, “In Progress”, “Code Review ”, “Dev
Done”, “In Testing” y “Done”. En el caso de este proceso se utilizarán las
columnas “To Do”, “In Progress” y “Done”

3.2.1.3. Sprint
Con respecto al Sprint, como se muestra en la Figura 3.6, Jira permitirá
una fácil creación del mismo, permitiendo añadir las historias de usuario qué
se trabajarán dentro del Sprint. En la Figura 3.5, una vez seleccionadas las
historias de usuario, Jira le permitirá al desarrollador seleccionar la duración
y los objetivo del mismo.
Cómo se puede ver en la Figura 3.4, en la esquina superior derecha, una
vez finalizado el Sprint Jira permitirá dejar documentado la finalización del
mismo. En caso de que haya historias de usuarios sin terminar, Jira permitirá
CAPÍTULO 3. ADAPTACIÓN DEL PROCESO 39

Figura 3.4: Sprint Backlog representado mediante Scrum Board

Figura 3.5: Planificación de historias de usuario dentro del Sprint

mover la misma al PB o al Sprint siguiente.

3.2.1.4. Diagramas e Informes

Otra de las ventajas que proporcionará la utilización de esta herramienta
es la obtención de un tipo de categoría de métrica llamada de proceso. Jira
permitirá poder administrar, gestionar y seguir el progreso del proyecto. Esta
categoría permitirá observar con que calidad se llevó a cabo el proceso de
desarrollo. Cómo se muestra en la Figura 3.7, se podrán utilizar gráficos y
diagramas proporcionados por Jira. Algunos de estos son sugeridos por Scrum
como el sprint burndown chart para medir la velocidad. También se podrán
obtener informes de Sprints, diagramas de flujo acumulado, de evolución y
control.
CAPÍTULO 3. ADAPTACIÓN DEL PROCESO 40

Figura 3.6: Edición del Sprint

Figura 3.7: Diagramas e Informes

3.2.1.5. Definición de “Done” en Jira

El criterio de done definido en la Subsección 3.1.4 es el que se aplicará
a cada una de las historias de usuario que haya durante el proceso. Jira le
permitirá al desarrollador poder tener documentado el mismo dentro de la
herramienta. Una vez que la historia de usuario pase al estado o columna
Done, dentro del Scrum Board, aparecerá una ventana.
Cómo se puede observar en la Figura 3.8, aparecerá un listado de todas las
características del criterio de done definido previamente. Es en ese momento,
en que el desarrollador debe corroborar que se hayan cumplido cada uno de
CAPÍTULO 3. ADAPTACIÓN DEL PROCESO 41

los criterios para que la historia de usuario quede finalizada por completo.

Figura 3.8: Historia de Usuario en estado Done

3.2.2. Git
En la Figura 3.10 se puede observar una visión general de la segunda
parte del proceso. En este parte del proceso, es necesario poder contar con
un repositorio de control de código fuente, para llevar a cabo el desarrollo
de software de manera ordenada. El controlador de versiones más utiliza-
do en la actualidad y el que se utilizará en este proceso es Git. Una de las
mayores ventajas que proporciona esta herramienta, es que permite poder
tener una rama principal (máster) y diferentes ramas por cada Sprint, de
código fuente. El cambio entre ramas y “merge”, en el desarrollo de software
es una característica de suma importancia a la hora de desarrollar, dado que
permitirá realizar cambios locales en nuestra rama o cambiar rápidamente
entre diferentes ramas según lo requiera la tarea en cuestión. En la Figura
3.9 se puede observar una representación de como se van a ir creando dis-
tintas ramas o versiones del código fuente a lo largo del proceso. Además,
dependiendo de la complejidad del Sprint, dentro de cada uno, se pueden
ir agregando más ramas en base a la dificultad de las tareas a desarrollar.
También cabe destacar, que se deberá utilizar un software de controlador de
versiones para poder tener un repositorio remoto del código fuente (Bitbuc-
CAPÍTULO 3. ADAPTACIÓN DEL PROCESO 42

ket, Github, Gitlab, etc.).

Figura 3.9: Flujo del uso de la herramienta Git

Cómo se mencionó en la subsección 3.1.1, luego de realizar un merge, se

puede observar un incremento del producto una vez finalizado el Sprint.
Otra de las razones por las cuales utilizaremos Git es que en caso de
perdida o un error interno de la computadora, permitirá tener almacena-
do en el repositorio cualquier archivo que sea de suma importancia para el
desarrollador, ya sea el código fuente, archivos de configuración, grabaciones
de reuniones, imágenes, etc. Por lo mencionado anteriormente, Git es una
herramienta de suma importancia dentro del proceso de desarrollo.

3.2.3. Integración Continua

Dentro del proceso de desarrollo, por el criterio de done definido en la
subsección 3.1.4 se utilizará una herramienta de integración continúa. Esta
herramienta será utilizada cada vez que el desarrollador realice un “merge”
a la rama de desarrollo del proyecto. Una vez que se realice este “merge” y
se resuelvan posibles conflictos de código fuente al momento de realizarse, el
proceso entrará en una etapa de integración continúa. En la Figura 3.10, se
puede observar todos los pasos que se llevan a cabo dentro de la integración
(Smart, 2011). Es importante destacar, que para poder realizar el proceso de
integración, es necesario contar con el controlador de versiones Git mencio-
nado en la Sección 3.2.2, dado que el servidor de integración continua, será
el encargado de monitorear el repositorio y detectar los cambios de manera
automática.
CAPÍTULO 3. ADAPTACIÓN DEL PROCESO 43

A continuación, serán explicadas cada una de las fases por las cuáles atra-
viesa el proceso de integración. Cada una de estas, representa una mejora in-
cremental dentro del propio proyecto, así como mejoras en la infraestructura,
y prácticas del desarrollo.

Figura 3.10: Proceso de Integración Continua

Para que la integración continua funcione correctamente, el desarrollador

deberá establecer algunas políticas que deberá cumplir al momento de realizar
un merge:

No registrar código con errores .

No registrar código sin probar.

No generar nuevas versiones con código que no funciona o no está tes-

teado.

3.2.3.1. Build Server

En primer lugar, el desarrollador debe tener una herramienta que le per-
mita poder realizar compilaciones automatizadas para la integración. Esta
fase, simplemente compila el código para luego poder realizar los test, ins-
peccionar y corroborar que el producto esté listo para producción. Es decir,
la fase de build tiene como resultado situar el código dentro del ambien-
te de nuestra herramienta y poder usar la información que esta misma nos
proporciona.
CAPÍTULO 3. ADAPTACIÓN DEL PROCESO 44

3.2.3.2. Test
Durante la fase de Test, ya se tiene un servidor listo para poder realizar
un build cada vez que el desarrollador realiza un merge a la rama principal
del código fuente. Una vez empezada la compilación, se ejecutarán los test
de unidad y de integración. En caso de que falle alguno de estos, se dará por
rechazada la build, alertando en que falló al desarrollador.

3.2.3.3. Inspección Continua

En la actualidad, existen distintas técnicas para la revisión de código,
pero estas requieren que haya una segunda persona dentro del equipo de
desarrollo. Es por eso, que para el análisis y revisión de código, se tendrá que
utilizar una herramienta de inspección continua.
En esta fase, es dónde se ejecutará el analizador de código para poder
obtener un análisis de la calidad del código fuente. Este análisis nos permi-
tirá obtener otra categoría de métricas con respecto al código desarrollado.
Algunas de las métricas son: porcentaje de cubrimiento de los test, líneas de
código duplicadas, errores de programación, malas prácticas, etc. Esto le per-
mitirá al desarrollador poder mantener una calidad alta de código y reducir
la complejidad del código durante todo el proceso de desarrollo, evitando así
un costo alto de mantenimiento en el futuro.
La principal diferencia que tiene el uso de una herramienta de análisis,
con respecto al análisis de código por parte de una persona, es el costo en
términos de tiempo. El costo de utilizar éstas es muchísimo más bajo, dado
que solo requiere intervención del desarrollador una sola vez para realizar la
configuración inicial. Luego, el proceso es totalmente automatizado, lo que
proporciona al final del proceso un ahorro de tiempo significativo (Duvall
et al., 2007).

3.2.3.4. Resultados
Una vez ejecutado el analizador de código y analizada la cobertura al-
canzada por los test, la herramienta nos dará un resultado. Este resultado
puede exitoso o fallido. En caso de que sea exitoso, el resultado retornará
un número de versión correspondiente al producto y el desarrollador podrá
continuar con el proceso, y obtener un producto listo para poder deployar a
un ambiente de producción. En cambio, si el resultado retorna un fallo, el
programador deberá solucionar el error dependiendo de dónde sea que falló
la compilación, ya sea en la fase de test o luego de realizar el análisis del
código fuente.
Capítulo 4

Validación del proceso

En este capítulo, se explicará la aplicación del proceso explicado en el

Capítulo 3, en un caso real de desarrollo de un producto de software. En
la primera Sección, se hablará del producto a desarrollar, cómo surge, los
objetivos del mismo y las tecnologías seleccionadas para llevar a cabo dicho
proceso. Mientras que en las demás Secciones se hablará sobre los Sprints
trabajados en dónde se repetiran ciertos ciclos de planificación, desarrollo,
revisión y retrospectiva.

4.1. Sprint 0
Durante este Sprint inicial, se contará sobre el producto a desarrollar y
la elección de las tecnologías con las que se trabajará durante el proyecto.

4.1.1. Análisis del Producto

La oportunidad de negocio se visibilizó por la utilización como cliente de
un servicio de liquidación de expensas. Se identificaron muchas posibles me-
joras en el producto dado que la información otorgada a los propietarios era
muy escasa, carecía de información histórica, y los gastos eran agrupados en
base a las posibilidades del sistema, no reflejando la realidad. Esto derivó en
realizar un relevamiento en varias administraciones de propiedades horizonta-
les en la ciudad de Mar del Plata y realizar reuniones con los administradores
de las mismas quiénes informaron las problemáticas de los sistemas actuales
y sus deficiencias. Junto a las que inicialmente se detectaron se desprendieron
muchas mejoras de productos posibles.
De estas reuniones se desprendieron las siguiente problemáticas y posibles
mejoras:

45
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 46

1. La liquidación de expensas no está en mano de las administraciones.

Los sistemas actuales permiten la carga de datos, pero el procesamiento,
impresión y distribución de las mismas son realizadas por las empresas
proveedoras de los sistemas, generando gastos de distribución que po-
drían ser evitados, siendo impreso por los administradores solo en los
casos que los propietarios lo deseen y eliminando los gastos de correo.
2. El sistema deberá permitir generar los distintos tipos de unidades ne-
cesarios para poder distribuir los gastos eficientemente.
3. Se desprende la necesidad que los administradores tengan un acceso
más fluido a la información permitiendo la previsión en los gastos.
4. Sería importante que el sistema permita la comunicación más fluida
entre administrador y propietarios.

4.1.2. Objetivos
Crear una aplicación web, dónde administradores, propietarios y provee-
dores puedan llevar con transparencia y simplicidad la liquidación de expen-
sas en propiedades horizontales, propiedades pre horizontales, barrios priva-
dos, clubes de campo, barrios cerrados, barrios náuticos, etc. Siendo uno de
los objetivos primarios evitar los sobreprecios en las obras de mantenimien-
to o reparaciones, haciendo que los costos sean acordes a los del mercado,
disminuyendo así el costo final de las expensas.
La aplicación tendrá como objetivo principal llevar transparencia al pro-
ceso de liquidación de expensas para hacerlo claro, auditable y eficiente, otor-
gándole nuevas herramientas para la toma de decisiones de los propietarios.
Además esta aplicación de herramientas que le brinden solución a gran
parte de los problemas que diariamente tienen los administradores, haciendo
uso de las más eficientes y modernas tecnologías que existen hoy en día para
el desarrollo de la plataforma.

4.1.3. Captura y análisis de requerimientos

A continuación, se listará cada una de las funcionalidades del proptotipo
de aplicación en base a las necesidades del cliente:
Login para administradores, propietarios y proveedores de servicios.
Sistema de gestión para la administración de consorcios: la aplicación le
permitirá al administrador registrar todos los gastos y procedimientos
necesarios para llevar la administración de los mismos.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 47

Liquidación de expensas: Cargados todos los gastos y obligaciones del

mes corrientes le permitirá llevar a cabo el proceso de liquidación de
expensas con el correspondiente detalle de gastos.
Manejo de proveedores: Se manejara una base de datos única con pro-
veedores para que los administradores puedan asignarlos a un determi-
nado evento (reparación, mantenimiento, insumos).
Creación de alertas por establecimientos: Permitirá simplificar la co-
municación entre administradores y propietarios.
Información de expensas generadas.
Panel de gastos, detallado por categorías y fecha.
Detalles de gastos extraordinarios del mes actualizados al momento de
la registración del administrador.
Alertas de eventos (por ejemplo que se rompa un portón, cortes de luz
o agua programados, etc).
Votación online de los temas tratados en las asambleas para las personas
que no puedan asistir por motivos personales.
Una vez definido el producto, se realizó una reunión con el Dr. Santiago Vidal
y el Dr. Guillermo Rodríguez para el relevamiento de todos los requerimientos
funcionales.
En la reunión se crearon todas las historias de usuario correspondientes:
1. Como usuario del sistema, quiero poder loguearme en el mismo, de
manera segura, rápida y sencilla. (Usuario y contraseña de 8 caracteres,
con mayúscula y caracteres especiales).
2. Como administrador, quiero poder registrar de manera online nuevos
edificios y unidades al sistema.
3. Como administrador, quiero poder registrar cualquier gasto que se reali-
ce en un determinado edificio, para así poder luego respaldar los montos
en las expensas de cada unidad.
4. Como administrador, quiero poder agregar propietarios de las unidades
al sistema, para que los mismos puedan loguearse como propietario.
5. Como administrador, tengo que poder liquidar las expensas de cada
mes (suma de todos los gastos) para luego poder dividir los gastos por
cada unidad.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 48

6. Como administrador, tengo que poder dividir los gastos de las expensas
de cada mes, por unidad, para luego pueda generarse la boleta a abonar
correspondiente.

7. Como administrador quiero poder crear alertas, para así poder dar a
conocer determinados eventos a los propietarios.

8. Como administrador, quiero controlar el registro de nuevos familiares

de los propietarios al sistema.

9. Como administrador, quiero poder generar votaciones online, dispo-

nibles no más de 24 hs, para luego poder determinar decisiones del
consorcio.

10. Como propietario, quiero poder registrar miembros de la familia al

sistema.

11. Como propietario, quiero poder descargar en detalle las expensas con
sus respectivo monto a abonar.

12. Como propietario, quiero poder ver todos los gastos que se realizaron,
pudiendo filtrar búsquedas por categorías y fechas.

13. Como propietario, quiero recibir alertas cada vez que se registra algún
gasto con un costo alto, para así poder estar pendiente de cualquier
noticia que el administrador crea que es importante.

14. Como propietario, quiero recibir cualquier alerta con respecto a algún
evento en el edificio.

15. Como propietario, quiero poder votar en la plataforma los temas tra-
tados en las asambleas.

16. Como proveedor, quiero poder ofrecer y cotizar mis servicios y/o pro-
ductos, para así responder a los requerimientos de los administradores.

17. Como proveedor (si se trata de reparaciones), quiero poder mostrar

como quedo el trabajo finalizado mediante imágenes .jpg, para luego
poder recibir valoraciones.

18. Como proveedor (si se trata de reparaciones), quiero poder recibir va-
loraciones por parte de los propietarios por el trabajo realizado para
poder recibir cualquier tipo de feedback.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 49

19. Como propietario, quiero poder valorar las reparaciones realizadas en

los edificios, para poder dar una opinión personal y recomendar sobre
el trabajo realizado.

Figura 4.1: Historias de Usuario.

En la Figura 4.1, se puede observar el resultado de dicha reunión, dónde

fueron creadas todas las historias de usuario que fueron agregadas al PB.
Además se distinguió cada una de las historias de usuarios entre “D” (desea-
ble) o “I” (indispensable).
Una vez realizada la distinción, se procedió a realizar un ranking de las
historias de usuario más importantes o indispensables a las menos importan-
tes o deseables. En la Figura 4.2, se puede observar el ranking realizado para
cada una de las historias de usuario.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 50

Figura 4.2: Ranking Historias de Usuario.

Mientras que en la Figura 4.3 se puede observar todas las historias de

usuario ingresadas en la herramienta Jira.

Figura 4.3: Historias de Usuario en Jira.

CAPÍTULO 4. VALIDACIÓN DEL PROCESO 51

Cómo primera aproximación al diseño de la aplicación se realizó un Dia-

grama de Casos de Uso (UML), haciendo énfasis en lo que deberá hacer el
sistema. En la Figura 4.4, se puede observar el diagrama correspondiente.

Figura 4.4: Diagrama de Casos de Uso.

4.1.4. Inicio del Proceso de Desarrollo

4.1.4.1. Diseño y Arquitectura de la Aplicación
Al momento de definir la arquitectura de la aplicación, se optó por la
implementación de una aplicación web, es por eso que se eligió una arqui-
tectura Single Page Application. Unas de las principales razones por las que
se eligió este tipo de arquitectura es debido a que provee muchas ventajas
al momento del desarrollo de una aplicación web, separando en dos partes
client-side y server-side ofreciendo un mayor desacoplamiento para poder fa-
cilitar a la separación de “concerns”, el mantenimiento y a la escalabilidad de
la mismas. También, ofrecerán una alta performance debido a que los datos
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 52

se actualizan de manera dinámica, por lo que no es necesario recargar una

página web completamente desde cero (Scott, 2015b).

4.1.4.2. Modelo de Base de Datos

Para la representación del modelo, se optó por la utilización de una base
de datos del tipo relacional debido a que esta favorece al diseño y desarrollo de
la aplicación en base al negocio, la creación de consultas y actualizaciones,
y el procesamiento de los datos (Codd, 1989). En la Figura 4.5, se puede
observar el diseño que se realizó y que tendrá la base de datos para poder
dar soporte a la lógica del negocio requerida.
Para poder implementar la base de datos relacional, se consideraron dos
tecnologías: MySQL1 y PostgreSQL2 . Se optó por la utilización de MySQL
dado que ésta tiene mayor reputación e influencia en la industria del soft-
ware (más recomendable a la hora de desarrollar una aplicación web); ofrece
una alta seguridad y escalabilidad a la hora de la implementación de una
BD(MySQL, 2001). Además de que se favoreció el aprendizaje de una nueva
tecnología, dado que sólo se había visto PostgreSQL en la cursada de Base
de Datos.
1
https://dev.mysql.com/doc/
2
https://www.postgresql.org/docs/
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 53

Figura 4.5: Modelos de la Base de Datos.

4.1.4.3. Backend
Para la implementación de los controladores se utilizó la plataforma de
desarrollo Node.js. Esta plataforma nos permitirá la creación del servidor
para la aplicación web. Además, se utilizó el framework Express.js3 para
agregarle facilidad a la creación del servidor ayudando al manejo de rutas,
parseo de solicitudes HTTP, manejo de errores, logrando evitar la implemen-
tación de grandes cantidades de código (Mardan, 2014)(Bangare et al., 2016).
Las ventajas que presentan estas dos tecnologías juntas son:

La implementación de una aplicación web altamente escalable, robusta

y de alto rendimiento.

Fácil integración con la base de datos MySql. Con respecto al cliente,

proporciona una ventaja dado que en ambas partes se utiliza el lenguaje
de programación JavaScript.

Fácil manejo de autenticación de usuarios mediante la librería JSON

Web Token4 .
3
https://expressjs.com/es/
4
https://jwt.io/
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 54

4.1.4.4. Frontend
Con respecto a la Vista se utilizó la biblioteca de Facebook llamada
React.js5 . Se optó por la utilización de esta librería principalmente por un
interés de aprender esta tecnología. Para manejar el estado de la aplicación
se utilizó la librería Redux.js, junto con la biblioteca Redux-Saga.
Redux-Saga6 es un middleware de Redux para el manejo de los efectos
secundarios dentro de la aplicación, cómo por ejemplo, el manejo de ope-
raciones asíncronas. Esta librería, utiliza los generadores ES6 de JavaScript
para el manejo de este tipo de operaciones. Los generadores, permiten que
el código asíncrono, se vuelva síncrono (secuencial). Se optó por este tipo de
arquitectura para poder obtener como resultado una arquitectura de software
robusta, escalable, fácil de testear y de mantener (Kuparinen, 2019).
Este paradigma permite que el código sea mucho más simple, legible y
fácil de testear debido a que centraliza toda la lógica asíncrona de una manera
más sofisticada. En la Figura 4.6 se puede observar el flujo de datos en este
tipo de Arquitectura, dónde el middleware se encarga de procesar las acciones
antes que lleguen directamente al reducer (red, )(Mahajan, 2018).

Figura 4.6: Arquitectura de alto nivel y Flujo Redux-Saga

Además se utilizaron otras librerías como React-Router7 para el manejo

5
https://reactjs.org/
6
https://redux-saga.js.org/
7
https://reacttraining.com/react-router/web/guides/quick-start
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 55

de las diferentes vistas que tendrá la misma. Para el testing de la aplicación,

se utilizaron en conjunto las librerías Jest8 y Enzyme9 para poder crear de los
test de unidad e integración correspondientes. Con la combinación de estas
dos librerías, se pudo testear tanto la lógica como los componentes creados
en la aplicación.

4.1.4.5. Integración continua

En el Capítulo 3, se mencionó la utilización de una herramienta de integra-
ción continua. Para el desarrollo de esta aplicación, se optó por la utilización
de la herramienta Jenkins10 . Se eligió la misma dado que permite cubrir to-
das las necesidades del proceso mencionadas anteriormente y es una de las
tecnologías más utilizadas en el mercado. Además, la utilización de este tipo
de herramientas se convirtió en uno de los pilares de las metodologías ágiles,
asegurando que todo el sistema funcione de manera correcta en cada commit.
Las principales ventajas que proporciona Jenkins son: es una herramienta
open source por lo cuál no requiere de costo adicional. Posee una sencilla
configuración que permite la creación rápida de nuevos proyectos; mejora la
consistencia y disminuye los costos de mantenimiento; mejora la escalabilidad
y estabilidad del ambiente de desarrollo por su topología; y soporta una gran
variedad de lenguajes de programación (Berg, 2012).
Dado que se utilizan dos repositorios (uno para la vista y otro para el
servidor), será necesario tener dos proyectos distintos dentro de Jenkins.

4.1.4.6. Inspección Continua

En el Capítulo 3, la metodología a emplear indicaba el uso de una herra-
mienta de inspección continua, dentro de la etapa de integración continua.
Para esto, se optó por la utilización de la herramienta SonarQube11 . Esta
herramienta nos permitirá la ejecución de un análisis del código fuente con
base a diferentes métricas. SonarQube se ejecutará luego de haber ejecutado
los tests, usando el Sonar Runner y un archivo de configuración.
Las ventajas que nos dará la utilización de esta herramienta de análi-
sis son: es una herramienta open source; puede ser utilizada para diferentes
lenguajes de programación (JavaScript, Java, C#); la ejecución es general-
mente rápida; la configuración de esta herramienta dentro del ambiente de
Jenkins no requiere de grandes complejidades; incrementa notablemente la
8
https://jestjs.io/
9
https://enzymejs.github.io/enzyme/
10
https://jenkins.io/
11
https://www.sonarqube.org/
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 56

calidad del producto; y aumenta las habilidades del desarrollador, debido a

la constante devolución de métricas por parte de la herramienta.

4.1.4.7. Software de Controlador de Versiones

Con el objetivo de utilizar un repositorio Git12 se optó por la utilización
de Bitbucket13 para mantener los repositorios remotos, uno para el front-end
y otro para el back-end. Una de las ventajas que nos permite Bitbucket es la
fácil integración que tiene con la herramienta Jira (ambos productos ofrecidos
por Attlasian). Esta herramienta nos permitirá tener un backup del código
fuente de la aplicación, documentos, grabaciones o cualquier archivo que sea
importante para el desarrollo.

4.2. Sprint 1
En esta Sección se contará sobre lo planificado en la Sprint Planning y
lo desarrollado durante el Sprint 1. También se hablará de la reunión de
revisión, mostrando el incremento del producto y métricas de código y sobre
la reunión de retrsopectiva de dicho Sprint.

4.2.1. Sprint Planning

Una vez inicializado el ambiente de desarrollo, se procedió a realizar una
reunión para definir el objetivo del Sprint y las historias de usuarios que iban
a ser seleccionadas del PB, en base al objetivo. El objetivo que se definió
para el Sprint 1 fue: “El propietario o administrador, debe tener la posibili-
dad de registrar cualquier tipo de unidad; debe poder agregar propietarios y
proveedores; y debe poder liquidar las expensas de edificios por mes.”
Una vez definido el objetivo, en base al ranking de la Figura 4.2, se se-
leccionaron las historias que iban a formar parte del primer Sprint.
En la Figura 4.7 se pueden observar las historias de usuario que se selec-
cionaron para ser desarrolladas en el Sprint 1.
12
https://git-scm.com/
13
https://bitbucket.org/product/
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 57

Figura 4.7: Historias de Usuario Sprint 1

Una vez elegidas las historias de usuario, se procedió a la estimación

correspondiente mediante la técnica de Poker Planning de cada una de las
historias de usuario. Debido a las estimaciones de cada una de las historias
de usuario, se decidió que la duración del Sprint 1 sea de cuatro semanas.
Con las historias de usuario ya seleccionadas y estimadas para el primer
Sprint, se procedió a creación de las distintas sub-tareas que se corresponden
con cada una de las historias. En la Figura 4.8 se puede observar las distintas
sub-tareas que fueron creadas.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 58

Figura 4.8: Sub-tareas Sprint 1.

4.2.2. Desarrollo del Sprint

Durante el primer Sprint, se pudo completar el objetivo definido en la
Sprint Planning, junto con todas las historias de usuario.
Se crearon los tests de unidad para las vistas de la aplicación y los test
de integración con el Backend. Mientras que del lado de la API se crearon
los test de unidad e integración con la Base de Datos para determinar que
efectivamente las rutas devuelvan las respuestas correctas. Además, para cada
formulario, se implementó la validación de los datos ingresados, mostrando
una notificación de error o éxito dependiendo el caso.
En la Figura 4.9, se puede observar el formulario para poder registrar pro-
pietarios o proveedores. Una vez registrado, el usuario quedará almacenado en
la BD, para que el administrador pueda asignarle la unidad correspondiente
en la vista de asignación en la Figura 4.10.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 59

Figura 4.9: Registrar Usuario.

Figura 4.10: Asignar Propietario.

En la Figura 4.11, se puede observar la vista que le permitirá al ad-

ministrador poder registrar unidades. Dependiendo del tipo de unidad, se
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 60

habilitarán distintos campos para completar.

Figura 4.11: Registrar Unidad.

Figura 4.12: Agregar Gasto.

CAPÍTULO 4. VALIDACIÓN DEL PROCESO 61

Con respecto, al registros de gastos, en la Figura 4.12, se encuentra la vista

que le permitirá al administrador poder registrar todos los gastos que se lleven
a cabo en un determinado Edificio, para poder así realizar la liquidación de
las expensas correspondiente finalizado el mes.
Para la liquidación de expensas, en la Figura 4.13 y 4.14, se puede observar
la correspondiente vista para poder calcular la liquidación de un determinado
edificio, mes y año correspondiente. En dicha vista, se podrá ver el monto
total y todos los gastos que fueron calculados.

Figura 4.13: Liquidación Expensas Edificio.

CAPÍTULO 4. VALIDACIÓN DEL PROCESO 62

Figura 4.14: Liquidación Expensas Edificio.

4.2.3. Sprint Review

Una vez finalizado el Sprint, se realizó una reunión en dónde fue mostrado
el incremento del producto hasta el momento. Se corroboró qué, para cada
historia de usuario, se haya cumplido el criterio de “done” definido para el
proceso.
En la Figura 4.15, se puede observar el resultado general de SonarQube
para el repositorio del lado Servidor una vez finalizado el Sprint.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 63

Figura 4.15: Resultado general para el código fuente de la API.

En la Figura 4.16, se puede observar el resultado general de SonarQube

para el repositorio del lado Cliente una vez finalizado el Sprint.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 64

Figura 4.16: Resultado general del código fuente de la vista del cliente.

En ambos resultados, se puede observar un porcentaje alto de cubrimiento

de los tests. El hecho de que no se introdujeron errores o vulnerabilidades al
código fuente es positivo. Además la duplicación de código fue de 0 % y de
1.5 % . Lo único negativo es que la herramienta detectó algunos code smells
en ambos repositorios, aunque la deuda técnica obtuvo cómo resultado A
(escala más alta). Estos mismos intentarán resolverse durante el desarrollo
del próximo Sprint.
También, y no menos importante, se obtuvo un resultado A en métricas
de Seguridad y Mantenibilidad.

4.2.4. Sprint Retrospective

En dicha reunión se trató sobre responder tres preguntas: qué se hizo bien
y mal durante el Sprint y qué se puede mejorar para el Sprint siguiente:
1. ¿Qué se hizo bien? Se pudo completar el objetivo del Sprint, junto con
todas las historias de usuario elegidas en la Sprint Planning.
2. ¿Qué se hizo mal? Se tendría que haber creado previo al inicio de desa-
rrollo, algún modelo o template de las vistas para facilitar el desarrollo
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 65

de la interfaz de usuario.

3. ¿Qué se puede mejorar? Se podrá realizar algún template de las vis-

tas siguientes a desarrollar para facilitar el desarrollo de la interfaz de
usuario.

4.3. Sprint 2
En esta Sección se contará sobre lo planificado en la Sprint Planning y
lo desarrollado durante el Sprint 2. También se hablará de la reunión de
revisión, mostrando el incremento del producto y métricas de código y sobre
la reunión de retrsopectiva del Sprint.

4.3.1. Sprint Planning

Una vez finalizada la Sprint Review del Sprint 1, se realizó la reunión de
planificación del Sprint 2. Primero se decidió, que la facturación de expensas
se divida en dos historias de usuario, debido a la gran complejidad que ésta
trae. Se dividió en una historia de usuario para calcular las expensas corres-
pondientes a cada una unidad, y otra para poder generar las facturas y el
manejo de cuentas, ya habiendo calculado las mismas previamente.
El objetivo principal de este Sprint es que los usuarios puedan ingresar al
sistema mediante la autenticación de usuario. Que los super-administradores
del sistema puedan cargar nuevos administradores de edificios y nuevas admi-
nistraciones. Que cada administrador pueda calcular las expensas para cada
unidad. Que propietarios, inquilinos y administradores puedan filtrar gastos.
Luego de haber definido el objetivo, se seleccionaron las historias de usua-
rio que iban a formar parte del segundo Sprint. En la Figura 4.17 se puede
observar las historias de usuario y sub-tareas que fueron creadas para este
Sprint.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 66

Figura 4.17: Historias de Usuario Sprint 2.

Luego de haber definido las historias de usuario, se procedió a la estima-

ción de las mismas mediante la técnica de Poker Planning. Se decidió que la
duración del Sprint 2 sea de dos semanas.

4.3.2. Desarrollo del Sprint

Durante el segundo Sprint se pudo completar con las historias de usuario,
exceptuando la historia de usuario correspondiente al filtrado de los gastos.
En la Figura 4.18 se puede observar el formulario de inicio de sesión que
el usuario deberá completar para poder estar logueado dentro del sistema.
Por el lado del servidor, se utilizó la biblioteca de autorización JSON Web
Token.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 67

Figura 4.18: Login.

En la Figura 4.19 se encuentra el Diagrama de Secuencia correspondiente

al inicio de sesión dentro de la aplicación. Dentro del mismo, se puede ob-
servar cómo es la creación del Token encriptado que nos proporciona esta
biblioteca, dependiendo si las credenciales ingresadas por el usuario son las
correctas o no. En caso de que los datos ingresados sean correctos, se llevará
al usuario a una de las vistas de la aplicación. En caso contrario, el usua-
rio será notificado dependiendo del error que se haya detectado, ya sea mail
inexistente o clave incorrecta.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 68

Figura 4.19: Diagrama de Secuencia Login.

Además, para aumentar la seguridad en la aplicación, se utilizó la biblio-

teca bcrypt14 para el encriptado o hasheo de cada una de las contraseñas
de los usuarios. Esta librería nos permitirá también comparar la contraseña
ingresada por el usuario, con la contraseña encriptada en la Base de Datos.
Mientras que para el cálculo de la liquidación de expensas, en la Figura
4.20 se puede ver a modo de ejemplo una tabla con el monto total para cada
una de las unidades de un determinado edificio, junto con el propietario,
fechas de vencimiento y mes-año correspondiente.
14
https://www.npmjs.com/package/bcrypt
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 69

Figura 4.20: Calculo de Expensas por Unidad

4.3.3. Sprint Review

Después de haber finalizado el Sprint, se realizó una reunón para mostrar
el incremento del producto. Cómo en el Sprint anterior, se chequeó que se
haya cumplido el criterio de “done“ para cada una de las historias de usuario
terminadas.
En la Figura 4.21,se puede observar el resultado general de SonarQube
para el repositorio del lado Servidor una vez finalizado el Sprint. En esta
misma se puede observar que aumentó el porcentaje del cubrimiento de los
tests con respecto a las nuevas funcionalidades agregadas al finalizar el Sprint
y se siguió manteniendo una escala A con respecto a la deuda técnica, man-
tenibilidad y seguridad.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 70

Figura 4.21: Resultado general para el código fuente de la API.

En la Figura 4.22, se puede observar el resultado general de SonarQube

para el repositorio del lado Cliente una vez finalizado el Sprint. Se puede ob-
servar que no se introdujeron bugs o vulnerabilidades en la aplicación. Si bien
se resolvieron los code smells del Sprint anterior, surgieron nuevos durante el
desarrollo del segundo Sprint. Se pudo obtener un buen cubrimiento de los
tests sobre lo desarrollado durante el Sprint, aunque bajó un poco el cubri-
miento general de tests, por lo que se intentará obtener un mejor cubrimiento
para el Sprint siguiente.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 71

Figura 4.22: Resultado general para el código fuente de la vista.

Con respecto a la historia de usuario que quedó pendiente, se continuará

con la misma en el siguiente Sprint.

4.3.4. Sprint Retrospective

En la reunión de retrospectiva, se trató sobre responder tres preguntas:
qué se hizo bien y mal durante el Sprint y qué se puede mejorar para el Sprint
siguiente:

1. ¿Qué se hizo bien? Se pudo completar parte el objetivo del Sprint,

habiendo podido completar casi todas las historias de usuario.

2. ¿Qué se hizo mal? La duración del Sprint tendría que haber sido de
mayor tiempo, debido a la complejidad de las tareas que no se tuvo en
cuenta a la hora de la estimación.

3. ¿Qué se puede mejorar? Se podría buscar diferentes enfoques o solu-

ciones, antes de estimar una historia de usuario que sea compleja.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 72

4.4. Sprint 3
En esta Sección se contará sobre lo planificado en la Sprint Planning y
lo desarrollado durante el Sprint 3. También se hablará de la reunión de
revisión, mostrando el incremento del producto y métricas de código y sobre
la reunión de retrsopectiva del Sprint.

4.4.1. Sprint Planning

Luego de haber finalizado la Sprint Review del Sprint 2, se procedió a
la reunión de planificación del Sprint siguiente. Durante la misma, se vió
la oportunidad de realizar una mejora a nivel estructura del proyecto para
ayudar a la escalabilidad del mismo. Por eso, el objetivo establecido para
este Sprint es el de realizar la refactorización necesaria para poder obtener
una aplicación más escalable y robusta.
Para eso se decidió que se creen dos historias de usuario para realizar dicha
modificación en ambos repositorios de código fuente. Para dichas historias de
usuario, se realizó una estimación con la técnica de Poker Planning. Debido
a las estimaciones de cada una de las historias, se optó que la duración del
Sprint sea de dos semanas.
Además, se agregó al Sprint la historia de usuario que quedó pendiente
del Sprint anterior.

Figura 4.23: Historias de Usuario Sprint 2.

4.4.2. Desarrollo del Sprint

Durante el tercer Sprint se pudo completar las historias de Usuario defi-
nidas en la Sprint Planning.
Con respecto a la refactorización, se modificó la estructura de los dos
proyectos, tanto de la vista cómo del controlador.
En la Figura 4.24 se puede observar una representación de la estructura
de la vista, dónde se separó en dos carpetas principales “core“ y “compo-
nents“. En la primera carpeta, contendrá todo lo que tenga que ver con la
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 73

lógica y funcionalidad de la aplicación. Mientras que en la segunda carpeta,

estarán las vistas de la aplicación junto con los componentes que serán com-
partidos en la misma. Se refactorizó código para favorecer a la reusabilidad
de componentes que son compartidos en varias vistas de la aplicación.

Figura 4.24: Estructura proyecto UI

En la Figura 4.25, se puede observar la estructura del repositorio del

controlador. Se dividió al proyecto por entidades, servicios, middlewares y
configuraciones. Dónde cada entidad tiene su respectivo controlador y archivo
de consultas/inserciones a realizar en la base de datos. Mientras que dentro
de la carpeta middlewares, se encuentran los validadores de formularios y el
validador del Json Web Token que viene en cada encabezado HTTP.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 74

Figura 4.25: Estructura API

Se puede observar en la Figura 4.26 que para el filtrado de gastos, se

le permitirá al propietario y administrador, poder filtrar los mismos de un
determinado edificio entre un rango de fechas y cualquier tipo de gasto. Los
datos almacenados en la base de datos, serán mostrados en un formato de
tabla, dónde aparecera por cada fila el monto, detalle y fecha de registro del
mismo.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 75

Figura 4.26: Obtener Gastos

4.4.3. Sprint Review

Luego de haber finalizado el Sprint, se realizó una reunión para mostrar
el incremento del producto. Cómo en el Sprint anterior, se chequeó que se
haya cumplido el criterio de “done“ para cada una de las historias de usuario
terminadas.
En la Figura 4.27, se puede observar el resultado general de SonarQube
para el repositorio del lado Servidor una vez finalizado el Sprint. En dicha
Figura, se puede observar que no hubo muchos cambios con respecto a la
Figura 4.21, esto es debido a que del lado del servidor ya se había imple-
mentado la funcionalidad de filtrar gastos, por lo que hubo poco desarrollo
durante este Sprint en este repositorio.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 76

Figura 4.27: Resultado general para el código fuente de la API.

En la Figura 4.28, se puede observar el resultado general de SonarQube

para el repositorio del lado Cliente una vez finalizado el Sprint. En dicha
Figura se puede observar que no se introdujeron bugs o vulnerabilidades
dentro del código fuente. Se aumentó el cubrimiento de los tests general,
tal cómo se había planteado en el Sprint anterior y también se redujo la
duplicación de bloques de código.
CAPÍTULO 4. VALIDACIÓN DEL PROCESO 77

Figura 4.28: Resultado general para el código fuente de la vista.

4.4.4. Sprint Retrospective

En la reunión de retrospectiva, se trató sobre responder tres preguntas:
qué se hizo bien y mal durante el Sprint y qué se puede mejorar para el Sprint
siguiente:

1. ¿Qué se hizo bien? Se pudo completar el objetivo del Sprint, habiendo

podido completar todas las historias de usuario. Se realizó una rees-
tructuración del proyecto para favorecer a la escalabilidad del mismo y
la refactorización de código para la reutilización de componentes.

2. ¿Qué se hizo mal? Se pudo finalizar sin ningún tipo de problema ya

que no hubo grandes complejidades dentro del Sprint..

3. ¿Qué se puede mejorar? Se puede seguir refactorizando componentes

para que estos puedan ser reutilizables y evitar la repetición de código.
Capítulo 5

Conclusiones

En este trabajo final se ha desarrollado un proceso de desarrollo de softwa-

re para equipos unipersonales. El objetivo principal de este trabajo consistió
en definir un proceso que le permita a una persona de un grupo unipersonal
de desarrollo, poder seguir un framework de trabajo como Scrum, además
siguiendo un determinado criterio de done. Este proceso se basa en adaptar
Scrum y definir un criterio para considerar cuando una historia de usuario
(ítem del Product Backlog) se encuentra terminada.
Durante el presente trabajo se llevó a cabo la definición del proceso de
desarrollo indicando cómo se utilizo el framework de Scrum, especificando
cuáles artefactos, roles y eventos se utilizarían del mismo y cuáles no. El
criterio de done consiste de poder terminar la historia de usuario con buena
calidad de código, atravesar con éxito el proceso de integración continua, y
validar la misma con el dueño del producto. Junto con la adaptación del
framework de Scrum y el criterio de done, se definieron las herramientas que
debían utilizarse para dar soporte al proceso de desarrollo (Git, Jira). Jira se
utilizará para documentar el proceso a lo largo de los Sprints, mientras que
Git se utilizará para administrar el código implementado.
Para poder verificar dicho proceso, se trabajó en un caso real de desa-
rrollo de un producto de software. Se identificó la motivación y los objetivos
del mismo. Se mencionaron las tecnologías utilizadas para dar soporte a la
integración continua, inspección continua y desarrollo del producto. También
se presentaron los Sprints trabajados, con sus respectivos resultados.
Al finalizar la aplicación del proceso, se puede concluir que se obtuvieron
resultados que fueron favorables, pudiendo afirmar que utilizando las prácti-
cas mencionadas anteriormente de la metodología de desarrollo Scrum junto
con el criterio de done definido, puede ser aplicable a un proceso de desarrollo
del cuál participa una sola persona.
El uso de una metodología ágil como Scrum pero adaptada, nos ofreció:

78
CAPÍTULO 5. CONCLUSIONES 79

un proceso flexible y adaptable; con feedback de manera constante debido a

ser la única persona a cargo del proyecto y se entregó software de manera
continua al finalizar cada Sprint.
Debido a la utilización de prácticas cómo la integración continua e ins-
pección continua, se logró que haya una mejora en la calidad del código
desarrollado; se detectaron errores de manera rápida y sencilla; se generó
mayor confianza debido a que permitió obtener un producto funcional y tes-
teado en todo momento; hubo una visibilidad completa del proyecto debido
a las métricas que nos otorgaron éstas prácticas y herramientas cómo Jira.
Una de las limitaciones es que en este proceso de desarrollo la entrega de
software a un ambiente de producción es de forma manual. Entregar software
de manera manual es un proceso que requiere de muchas etapas y es suscepti-
ble a fallas. Otra de las limitaciones es el hecho de no poder recibir revisiones
de código por parte de otra persona, o discutir decisiones de implementación
con otro miembro del equipo. Aunque hoy en día, existe una comunidad muy
grande en el desarrollo de software, lo cuál resulta más accesible poder rea-
lizar preguntas sobre diseño o implementación en foros activos cómo Stack
Overflow1 y Github2 .
Como visión personal del proceso, creo que la experiencia fue muy sa-
tisfactoria y enriquecedora, debido a que se logró fortalecer los conceptos
aprendidos sobre la metodología ágil Scrum y un aprendizaje profundo sobre
el concepto e implementación de prácticas cómo la Integración e Inspección
Continua. Como recomendación final a cualquier desarrollador que quiera
utilizar este proceso, creo que se debería contar con experiencia previa en la
industria del software antes de llevar a cabo el mismo.

5.1. Trabajos Futuros

Cómo se mencionó anteriormente una de las principales limitaciones era
tener que manualmente entregar un software listo para ser deployado a un
ambiente de producción. Es por eso que a partir de estas limitaciones surgen
dos posibles prácticas que pueden ser agregadas al proceso de desarollo.

1. Entrega Continua: Ésta es una práctica en el desarrollo de software que

permite a los equipos seguir produciendo software listo para deployar
a producción. Ésta resulta ser una ampliación de la Integración Con-
tinua debido a que se implementan todos los cambios de código en un
ambiente de pruebas o de producción. La entrega continua automatiza
1
https://stackoverflow.com/
2
https://github.com/
CAPÍTULO 5. CONCLUSIONES 80

todo el proceso de publicación de software, pero la decisión definiti-

va de implementarla en un entorno de producción es tomada por el
desarrollador.

2. Deployment Continuo: Esta práctica es similar a la Entrega Continua

pero, el deployment a producción es de manera automática, no requiere
de una aprobación explícita por parte del desarrollador.
Bibliografía

Bangare, S., Gupta, S., Dalal, M., and Inamdar, A. (2016). Using node. js
to build high speed and scalable backend database server. In National
Conference NCPCI, volume 2016, page 19.

Berg, A. (2012). Jenkins Continuous Integration Cookbook. Packt Publishing

Ltd.

Cadavid, A. N., Martínez, J. D. F., and Vélez, J. M. (2013). Revisión de

metodologías ágiles para el desarrollo de software. Prospectiva, 11(2):30–
39.

Canós, J. H. and Letelier, M. C. P. P. (2012). Metodologías ágiles en el

desarrollo de software.

Chacon, S. and Straub, B. (2014). Pro git. Apress.

Codd, E. F. (1989). Relational database: a practical foundation for produc-

tivity. In Readings in Artificial Intelligence and Databases, pages 60–68.
Elsevier.

Cohn, M. (2004). User stories applied: For agile software development.

Addison-Wesley Professional.

Conallen, J. (1999). Modeling web application architectures with uml. Com-

munications of the ACM, 42(10):63–70.

Duvall, P. M., Matyas, S., and Glover, A. (2007). Continuous integration:

improving software quality and reducing risk. Pearson Education.

Ebert, C., Gallardo, G., Hernantes, J., and Serrano, N. (2016). Devops. Ieee
Software, 33(3):94–100.

81
BIBLIOGRAFíA 82

Estayno, M. and Meles, J. (2014). El rol del product owner en la definición

y validación de las user stories. Ciencia y tecnología, (14):145–162.

Fowler, M. and Foemmel, M. (2006). Continuous integration.

Gallego, M. T. (2012). Metodologia scrum. Universitat Oberta de Catalunya,

pages 32–39.

Gancarczyk, A. (2018). Small scale scrum: A framework for successful im-

plementation of the scrum methodology for small sized teams. Master’s
thesis.

Gaudin, O. (2012). Continuous Inspection - A paradigm shift in software

Quality Management.

Griffin, A. G. L. (2019). Small scale scrum. Agile Conference.

Heidke, N., Morrison, J., and Morrison, M. (2008). Assessing the effectiveness
of the model view controller architecture for creating web applications.
In Midwest instruction and computing symposium, Rapid City, SD.

Hye-young Paik, Emam Hossain, M. A. B. (2009). Using scrum in global

software development: A systematic literature review. Fourth IEEE In-
ternational Conference on Global Software Engineering, pages 175–178.

Janes, A., Lenarduzzi, V., and Stan, A. C. (2017). A continuous software

quality monitoring approach for small and medium enterprises. In Pro-
ceedings of the 8th ACM/SPEC on International Conference on Perfor-
mance Engineering Companion, pages 97–100.

Karlesky, M. and Vander Voord, M. (2008). Agile project management. ESC,

247(267):3.

Kuparinen, E. (2019). Managing application state and control flow using

redux and redux-saga in a web application.

Mahajan, R. (2018). Why use redux-saga?

Mahalakshmi, M. and Sundararajan, M. (2013a). Traditional sdlc vs scrum

methodology–a comparative study. International Journal of Emerging
Technology and Advanced Engineering, 3(6):192–196.

Mahalakshmi, M. and Sundararajan, M. (2013b). Traditional sdlc vs scrum

methodology–a comparative study. International Journal of Emerging
Technology and Advanced Engineering, 3(6):193.
BIBLIOGRAFíA 83

Mardan, A. (2014). Pro express. js: Master express. js: The node. js frame-
work for your web development. Apress.

Martin, S. (2019). Angular vs react vs vue: Which is the best choice for
2019?

MySQL, A. (2001). Mysql.

Nazareno, R., Leone, H. P., and Gonnet, S. M. (2013). Trazabilidad de

procesos ágiles: un modelo para la trazabilidad de procesos scrum. In
XVIII Congreso Argentino de Ciencias de la Computación.

Ramos, V. H. M., Zapata, J., and Ceballos, Y. F. (2015). Herramientas

y buenas prácticas para el aseguramiento de calidad de software con
metodologías ágiles. Revista de Investigación Desarrollo e Innovación:
RIDI, 6(1):73–83.

Rising, L. and Janoff, N. S. (2000). The scrum software development process

for small teams. IEEE software, 17(4):26–32.

Saorin, J. O. (2017). Continuous code and automated code review tools.

Schwaber, K. and Beedle, M. (2002). Agile software development with Scrum,

volume 1. Prentice Hall Upper Saddle River.

Scott, E. (2015a). SPA design and architecture: understanding single page

web applications. Manning Publications Co.

Scott, E. (2015b). SPA design and architecture: understanding single page

web applications (p.12 - p13). Manning Publications Co.

Silva, A., Araújo, T., Nunes, J., Perkusich, M., Dilorenzo, E., Almeida, H.,
and Perkusich, A. (2017). A systematic review on the use of definition
of done on agile software development projects. In Proceedings of the
21st International Conference on Evaluation and Assessment in Softwa-
re Engineering. ACM.

Smart, J. F. (2011). Jenkins: The Definitive Guide: Continuous Integration

for the Masses. .O’Reilly Media, Inc.".

Sutherland, J. and Schwaber, K. (2013). The scrum guide. The definitive

guide to scrum: The rules of the game. Scrum. org, 268.

Thomas, M. T. (2018). React in Action.

BIBLIOGRAFíA 84

Yarbrough, M. C. (2019). Python vs node.js: Which programming language

to choose?