UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA

FACULTAD DE INGENIERÍA DE MINAS, GEOLOGÍA Y CIVIL

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

“MODELO GESTIÓN DE DESARROLLO DE SOFTWARE ÁGIL

MEDIANTE SCRUM Y KANBAN SOBRE LA PROGRAMACIÓN

EXTREMA, 2019”

Tesis presentada por: Bach. Eder Solórzano Huallanca.

Para optar el título profesional de: Ingeniero de Sistemas

Tipo de investigación: Observacional, Retrospectivo y Transversal

Área de investigación: Ingeniería de Software

Asesor: Mg. Ing. Hubner Janampa Patilla.

Ayacucho, 2020
 DEDICATORIA

Primeramente a Dios por guiarme cada día, darme salud y acompañarme en este
camino de vida.

A mi madre por haberme criado de la mejor forma, por sus consejos, su paciencia,
sus exigencias y su apoyo incondicional durante toda mi vida; a mi hermana por
su constante apoyo y preocupación, a Jazmín por su apoyo y deseo perseverante
en la realización durante todo el desarrollo de este proyecto.

ii
 AGRADECIMIENTO

A mi alma mater, Universidad Nacional de San Cristóbal de Huamanga, a los

docentes de la Escuela Profesional de Ingeniería de Sistemas, por su constante
labor en la docencia universitaria que ayudaron mucho en mi vida universitaria, al
Mg. Ing. Hubner Janampa Patilla, por su apoyo, asesoramiento y guía en la
realización de esta tesis.

iii
 CONTENIDO
DEDICATORIA .............................................................................................................. ii
AGRADECIMIENTO ................................................................................................... iii
CONTENIDO ....................................................................................................................i
RESUMEN .................................................................................................................... v
INTRODUCCIÓN ..........................................................................................................vi
CAPÍTULO I
PLANTEAMIENTO DE LA INVESTIGACIÓN
1.1. DIAGNÓSTICO Y ENUNCIADO DEL PROBLEMA .......................... 1
1.2. FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN ............. 2
1.3. OBJETIVOS DE LA INVESTIGACIÓN................................................ 3
1.3.1. OBJETIVO GENERAL ........................................................................... 3
1.3.2. OBJETIVOS ESPECÍFICOS................................................................... 3
1.4. JUSTIFICACIÓN Y DELIMITACIÓN DE LA INVESTIGACIÓN .... 4
1.4.1. IMPORTANCIA DEL TEMA ................................................................. 4
1.4.2. JUSTIFICACIÓN ..................................................................................... 4
1.4.3. DELIMITACIÓN ...................................................................................... 5
CAPÍTULO II
REVISIÓN DE LA LITERATURA
2.1. ANTECEDENTES DE LA INVESTIGACIÓN ...................................... 6
2.2. MARCO TEÓRICO ................................................................................. 6
2.2.1. GESTIÓN DE SOFTWARE ÁGIL ......................................................... 6
2.2.2. MÉTODOS Y TÉCNICAS ....................................................................... 8
2.2.2.1. PROGRAMACIÓN EXTREMA (XP) .................................................... 8
A. VALORES DE LA PROGRAMACIÓN EXTREMA ............................ 9
B. PRINCIPIOS DE LA PROGRAMACIÓN EXTREMA ...................... 11
C. ROLES DE LA PROGRAMACIÓN EXTREMA ................................ 12
D. FASES DEL PROCESO ÁGIL XP ........................................................ 14
E. ARTEFACTOS DE XP ........................................................................... 19
2.2.2.2. MARCO DE TRABAJO SCRUM ......................................................... 21
A. ROLES SCRUM ..................................................................................... 22
B. ACTIVIDADES ....................................................................................... 24
C. ARTEFACTOS ....................................................................................... 31
2.2.2.3. MARCO DE TRABAJO KANBAN ....................................................... 32
A. VALORES ............................................................................................... 32
B. OBJETIVOS ............................................................................................ 34

i
C. AGENDAS ............................................................................................... 34
D. PILARES ............................................................. 35
E. PRACTICAS GENERALES .................................................................. 35
F. ROLES .............................................................. 38
G. FASES ............................................................. 38
H. ARTEFACTOS ....................................................................................... 39
2.2.2.4. PROGRAMACIÓN EXTREMA SOBRE SCRUM.............................. 40
A. SOFTWARE ITERATIVO E INCREMENTAL .................................. 41
B. PRUEBAS UNITARIAS CONTINUAS ................................................ 41
C. RE FACTORIZACIÓN DEL CÓDIGO ............................................... 42
D. CORRECCIÓN DE ERRORES Y CÓDIGO COMPARTIDO ........... 42
2.2.2.5. SCRUMBAN ........................................................................................... 43
A. CARACTERÍSTICAS DE SCRUMBAN .............................................. 43
B. REUNIONES EN SCRUMBAN ............................................................. 45
2.3. HERRAMIENTAS .................................................................................. 46
2.3.1. PROGRAMACIÓN ORIENTADA A OBJETOS (POO) .................... 46
2.3.2. SISTEMA GESTOR DE BASE DE DATOS ........................................ 47
2.4. POBLACIÓN .......................................................................................... 47
2.5. MUESTRA............................................................................................... 48
CAPÍTULO III
METODOLOGÍA DE LA INVESTIGACIÓN
3.1. TIPO Y NIVEL DE INVESTIGACIÓN ................................................ 49
3.1.3. DISEÑO DE LA INVESTIGACIÓN ..................................................... 50
3.2. POBLACIÓN Y MUESTRA .................................................................. 50
3.3. VARIABLES E INDICADORES ........................................................... 51
3.3.1. DEFINICIÓN CONCEPTUAL DE LAS VARIABLES ....................... 51
3.3.2. DEFINICIÓN OPERACIONAL DE LAS VARIABLES DE ESTUDIO
.................................................................................................................. 52
3.4. TÉCNICAS E INSTRUMENTOS PARA RECOLECTAR .....................
INFORMACIÓN............................................................................................................ 53
3.5. HERRAMIENTAS PARA EL TRATAMIENTO DE DATOS E ............
INFORMACIÓN............................................................................................................ 53
3.6. PROPUESTA DE MODELO DE GESTIÓN EN FUNCIÓN A LAS ......
METODOLOGÍAS APLICADAS ................................................................................ 53
ESTRATEGIA DE INTEGRACIÓN ........................................................................... 53
CAPÍTULO IV
ANÁLISIS Y RESULTADOS DE LA INVESTIGACIÓN

ii
4.1. ANÁLISIS DE FACTIBILIDAD DE IMPLEMENTACIÓN DE LA .....
METODOLOGÍA .......................................................................................................... 83
4.5. RESULTADOS...................................................................................... 109
CAPÍTULO V
CONCLUSIONES Y RECOMENDACIONES
5.1. CONCLUSIONES ................................................................................. 114
5.2. RECOMENDACIONES ....................................................................... 115
REFERENCIA BIBLIOGRÁFICA ............................................................................ 116
ANEXOS ................................................................................................................ 123
Anexo A. Plantilla de Product Backlog ...................................................................... 123
Anexo B. Plantilla de Historia de Usuario .................................................................. 124
Anexo C. Plantilla de Tarjeta CRC ............................................................................ 124
Anexo D. Plantilla de Task Card ................................................................................ 124
Anexo E. Encuesta de factibilidad para aplicar una metodología ............................ 125
Anexo F. Fichas bibliográficas .................................................................................... 133
Anexo G. Ficha de análisis documental ...................................................................... 136

ÍNDICE DE FIGURAS

Figura 1. Fases de la metodología XP (Jeffries, Anderson y Hendrickson, 2001) ........... 14

Figura 2. Prácticas de Scrum (Rubín, 2013) .................................................................... 22
Figura 3. Actividades de Scrum (Deemer P. , Benefield, Larman, & Bas, 2011) ............ 24
Figura 4. Actividades de la planificación del Sprint (Rubín, 2013) ................................. 25
Figura 5. Los Sprints son el esqueleto del marco de Scrum (Rubín, 2013). .................... 26
Figura 6. Scrum diario (Rubín, 2013) ............................................................................. 27
Figura 7. Actividad de ejecución de Sprint (Rubín, 2013) .............................................. 28
Figura 8. Actividad de revisión de Sprint (Rubín, 2013) ................................................. 29
Figura 9. Actividad de retrospectiva de Sprint (Rubín, 2013) ......................................... 30
Figura 10. Marco de trabajo “XP + Scrum + Kanban” .................................................... 61
Figura 11. Burn Up Chart. (Palacio, 2007) ..................................................................... 68

ÍNDICE DE TABLAS
Tabla 1 Plantilla para las historias de usuario ............................................................................ 19
Tabla 2 Plantilla para tareas de ingeniería ................................................................................. 20
Tabla 3 Plantilla para las pruebas de aceptación........................................................................ 20
Tabla 4 Plantilla para las tarjetas CRC ...................................................................................... 21
Tabla 5 Herramientas para el tratamiento de datos e información .............................................. 53
Tabla 6 Modelo de integración de las metodologías Xp, Scrum y Kanban (Roles) ....................... 55
Tabla 7 Modelo de integración de las metodologías Xp, Scrum y Kanban (Actividades y Procesos)
.................................................................................................................................................... 56

iii
Tabla 8 Modelo de integración de las metodologías Xp, Scrum y Kanban (Artefactos)................ 57
Tabla 9 Modelo de integración de las metodologías Xp, Scrum y Kanban (Valores) ................... 57
Tabla 10 Modelo de integración de las metodologías Xp, Scrum y Kanban (Practicas) ............... 58
Tabla 11 Propuesta de modelo de gestión de trabajo ágil “XP + Scrum + Kanban” - Roles....... 59
Tabla 12 Propuesta de modelo de gestión de trabajo ágil “XP + Scrum + Kanban” - Actividades
y Procesos ................................................................................................................................... 59
Tabla 13 Propuesta de modelo de gestión de trabajo ágil “XP + Scrum + Kanban” - Artefactos60
Tabla 14 Propuesta de modelo de gestión de trabajo ágil “XP + Scrum + Kanban” - Valores ... 60
Tabla 15 Propuesta de modelo de gestión de trabajo ágil “XP + Scrum + Kanban” - Prácticas
Técnicas ...................................................................................................................................... 60
Tabla 16 Valoración de tabla de puntajes de la encuesta ............................................................ 83

iv
 RESUMEN

Para desarrollar software, es menester, la elección de una metodología. En este

contexto aparecen las metodologías ágiles. Este enfoque muestra su efectividad en
proyectos con requisitos muy cambiantes, así mismo permite reducir los tiempos
de desarrollo, pero manteniendo una alta calidad. Entre las metodologías agiles
más populares tenemos: Programación Extrema (XP), Scrum y Kanban. El
primero está enfocado en la parte de la programación, sin embargo, el segundo
está enfocado en las prácticas de organización y gestión, el tercero gestiona un
óptimo flujo de trabajo dentro del proceso, en consecuencia, estas metodologías
pueden complementarse y obtener un producto de mejor calidad.

El objetivo de este trabajo de investigación es implementar el modelo de

desarrollo de software de la Programación Extrema sobre Scrum y Kanban para
permitir la gestión de software ágil. El tipo de investigación es observacional,
retrospectivo y transversal.

En la presente investigación se busca abstraer los conceptos relevantes de la

Programación Extrema, Scrum y Kanban, para presentar un modelo híbrido que
permitirá desarrollar un software ágil.

Palabras claves: Programación Extrema sobre Scrum y Kanban, Gestión de

Software ágil, Pruebas Unitarias Continuas, metodologías agiles, Modelo Híbrido.

v
 INTRODUCCIÓN

Para desarrollar aplicaciones, es necesario seleccionar una metodología de

desarrollo de software. En la actualidad, las metodologías ágiles son las más
utilizadas, sin embargo, la problemática surge cuando necesitamos una
metodología ágil para gestionar el proceso de desarrollo de software y al mismo
tiempo que se utilice las prácticas de programación, la primera tiene una relación
con la metodología Scrum, una metodología ágil para gestionar el proceso de
desarrollo de software; la segunda está relacionada con la metodología ágil de la
Programación Extrema, el tercero gestiona un óptimo flujo de trabajo dentro del
proceso brindada por Kanban.

Mi motivación para proponer un modelo de desarrollo de software de la

Programación Extrema sobre Scrum y Kanban, es la entrega de un producto
software de alta calidad que reúna los principios de gestión y prácticas de
programación.

Esta metodología híbrida se deriva a partir del análisis exhaustivo de las

metodologías ágiles: Programación Extrema, Scrum y Kanban. Estas
metodologías son ampliamente utilizadas en el desarrollo de aplicaciones en la
actualidad.

Los principales objetivos son: a) Proponer el modelo de gestión de desarrollo de

software ágil mediante Scrum y Kanban para que se adapte al modelo iterativo e
incremental de la Programación Extrema. b) Proponer el modelo de gestión de
desarrollo de software ágil mediante Scrum y Kanban para que se adapte a las
pruebas unitarias de la Programación Extrema. c) Proponer el modelo de gestión
de desarrollo de software ágil mediante Scrum y Kanban para que se adapte a la re
factorización de código de la Programación Extrema. d) Proponer el modelo de
gestión de desarrollo de software ágil mediante Scrum y Kanban para que se
adapte a la corrección de errores y código compartido de la Programación
Extrema.

vi
 CAPÍTULO I

PLANTEAMIENTO DE LA INVESTIGACIÓN

1.1. DIAGNÓSTICO Y ENUNCIADO DEL PROBLEMA

Según Sommerville (2011), la ingeniería de software se interesa por
todos los aspectos de la producción de software, empezando desde las etapas más
tempranas del sistema hasta el mantenimiento que se le da después de
implementar el software. Además, no sólo se interesa en los procesos técnicos del
desarrollo de software, también comprende actividades tales como la
administración de proyectos de software y el desarrollo de herramientas,
aplicando teorías y métodos donde sea adecuado para obtener resultados de la
calidad requerida dentro de una fecha establecida. En la actualidad, las
organizaciones desarrolladoras de software utilizan las metodologías ágiles para
obtener el producto final. Entre las metodologías ágiles destacan, Programación
Extrema, Scrum, Iconix, Kanban, etc. Sin embargo, cada metodología tiene un
enfoque diferente como menciona Kniberg (2007) afirma que Scrum se enfoca en
las prácticas de organización y gestión, mientras que XP se centra más en las
prácticas de programación, Klipp (2014), afirma que Kanban proporciona gestión
y óptimo flujo de trabajo dentro del proceso. En ese contexto cabe mencionar que
una determinada metodología debe contener estas prácticas para obtener un
producto que garantice el costo y el tiempo de desarrollo. Asimismo, DeMarco y
Boehm (2002), proponen que un enfoque híbrido en el cual los métodos ágiles
incorporen algunas técnicas del desarrollo basado en la planificación puede ser lo
mejor a largo plazo.
La gestión de proyectos de software es una parte esencial de la ingeniería de
software. Los proyectos necesitan administrarse porque la ingeniería de software
profesional está sujeta siempre a restricciones organizacionales de presupuesto y
fecha. El trabajo del administrador del proyecto es asegurarse de que el proyecto
de software cumpla y supere tales restricciones, además de que entregue software
de alta calidad. La buena gestión no puede garantizar el éxito del proyecto. Sin
embargo, la mala gestión, por lo general, da como resultado una falla del

1
proyecto: El software puede entregarse tarde, costar más de lo estimado
originalmente o no cumplir las expectativas de los clientes (Sommerville, 2011).
Probablemente las metodologías ágiles más conocidas y las más utilizadas son la
Programación Extrema, Scrum y Kanban entre las muchas que existen. Por lo
tanto, es necesario resaltar que el primero está orientado al desarrollo del
software, mientras que el segundo está orientado a la gestión del proyecto, el
tercero gestiona un óptimo flujo de trabajo dentro del proceso. Sin embargo, estos
enfoques pueden capitalizarse con la finalidad de proponer una metodología
híbrida, es decir, combinando las tres metodologías ágiles y de esta manera buscar
el complemento.

1.2. FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN

1.2.1. PROBLEMA PRINCIPAL

¿Cómo el modelo de gestión de desarrollo de software ágil mediante
Scrum y Kanban se adapta a la Programación Extrema, 2019?

1.2.2. PROBLEMAS SECUNDARIOS

a. ¿Cómo el modelo de gestión de desarrollo de software ágil mediante
Scrum y Kanban se adapta al modelo iterativo e incremental de la
Programación Extrema, 2019?
b. ¿Cómo el modelo de gestión de desarrollo de software ágil mediante
Scrum y Kanban se adapta a las pruebas unitarias de la
Programación Extrema, 2019?
c. ¿Cómo el modelo de gestión de desarrollo de software ágil mediante
Scrum y Kanban se adapta a la re factorización de código de la
Programación Extrema, 2019?
d. ¿Cómo el modelo de gestión de desarrollo de software ágil mediante
Scrum y Kanban se adapta a la corrección de errores y código
compartido de la Programación Extrema, 2019?

2
1.3. OBJETIVOS DE LA INVESTIGACIÓN

1.3.1. OBJETIVO GENERAL

Implementar el modelo de gestión de desarrollo de software ágil
mediante Scrum y Kanban a la Programación Extrema, 2019.

1.3.2. OBJETIVOS ESPECÍFICOS

a. Proponer el modelo de gestión de desarrollo de software ágil
mediante Scrum y Kanban para que se adapte al modelo iterativo
e incremental de la Programación Extrema, 2019.

b. Proponer el modelo de gestión de desarrollo de software ágil

mediante Scrum y Kanban para que se adapte a las pruebas
unitarias de la Programación Extrema, 2019.

c. Proponer el modelo de gestión de desarrollo de software ágil

mediante Scrum y Kanban para que se adapte a la re factorización
de código de la Programación Extrema, 2019.

d. Proponer el modelo de gestión de desarrollo de software ágil

mediante Scrum y Kanban para que se adapte a la corrección de
errores y código compartido de la Programación Extrema, 2019.

3
1.4. JUSTIFICACIÓN Y DELIMITACIÓN DE LA INVESTIGACIÓN

1.4.1. IMPORTANCIA DEL TEMA

IMPORTANCIA TÉCNICA

El modelo de desarrollo de software de la Programación Extrema sobre

Scrum y Kanban, busca contribuir a que los desarrolladores utilicen este modelo
como una metodología para desarrollar software ágil de calidad, para lo cual se ha
adoptado las mejores prácticas de programación de la metodología Programación
Extrema y las prácticas de gestión de las metodologías Scrum y Kanban.

Los métodos híbridos basan su existencia en las debilidades de los métodos

anteriormente nombrados, con la finalidad de crear un método robusto pero al
mismo tiempo flexible, que combine las bondades de dos o más metodologías
ágiles. (Leiva & Villalobos, 2015).

IMPORTANCIA ECONÓMICA
La adecuada gestión de software ágil, permitirá estimar el tamaño de lo
que estamos construyendo y medir la velocidad en el que podemos hacer el
trabajo. Con esta información podemos estimar el costo correspondiente,
asimismo el modelo de desarrollo de software usando Scrum y Kanban sobre la
Programación Extrema, reducirá el costo de los cambios generados en etapas
posteriores en el desarrollo del proyecto.

La ingeniería de software es el establecimiento y uso de principios fundamentales

de la ingeniería con objeto de desarrollar en forma económica software que sea
confiable y que trabaje con eficiencia en máquinas reales. (Pressman, 2010).

1.4.2. JUSTIFICACIÓN
Según Vlaanderen, Jansen, Brinkkemper y Jasper (2011), en los últimos
años se ha introducido los principios ágiles como una de las mayores
innovaciones en la metodología de software. Uno de los puntos fuertes de la
metodología ágil es que el trabajo se vuelve dinámico, aceptando los cambios que
se puedan dar a lo largo del desarrollo, colaborando con los clientes y eligiendo al

4
software por encima de la documentación exhaustiva. Estos principios son
comunes a las diferentes metodologías ágiles de programación, sin embargo, una
metodología ágil debe tener dos componentes importantes: Prácticas de
programación y la parte de gestión de software ágil.

Kniberg (2007), afirma que Scrum se enfoca en las prácticas de organización y

gestión, mientras que la programación extrema se centra más en las prácticas de
programación, Klipp (2014), afirma que Kanban proporciona gestión y óptimo
flujo de trabajo dentro del proceso. Por consiguiente, en este trabajo de
investigación se está planteando una metodología híbrida para el desarrollo de
aplicaciones, es decir, combinar los procesos de la Programación Extrema, Scrum
y Kanban, desde una perspectiva de la reducción del tiempo y costo, con una
adecuada planificación durante el desarrollo del producto software.

1.4.3. DELIMITACIÓN
En la siguiente investigación nos limitaremos al análisis de la metodología
de desarrollo de software ágil de la Programación Extrema y el marco de trabajo
Scrum y Kanban, ya que el primero aplica correctamente las prácticas de
programación, mientras el segundo se caracteriza por las prácticas de gestión y
organización, el tercero gestiona un óptimo flujo de trabajo dentro del proceso.

5
 CAPÍTULO II

REVISIÓN DE LA LITERATURA

2.1. ANTECEDENTES DE LA INVESTIGACIÓN

Según Carrasco, Ocampo, Ulloa y Azcona (2019), en su investigación
denominada “Metodología híbrida de desarrollo de software combinando XP y
Scrum”, de la Universidad Regional Autónoma de Los Andes de Ecuador,
concluyen que la combinación de la metodología XP y el marco de trabajo Scrum
son de gran ayuda en el desarrollo de software. Los procesos y el ciclo de vida
ideal que propone XP junto con los eventos y artefactos Scrum aportaron vital
importancia para que el desarrollo sea versátil y limpio, de manera que permita
realizar cualquier cambio en el producto que surja a lo largo de los Sprints, sin
necesidad de comprometer las funcionalidades ya desarrolladas.

Según Gamboa (2014), en su investigación denominada “Aumento de la

productividad en la gestión de proyectos, utilizando una metodología ágil aplicada
en una fábrica de software en la ciudad de Guayaquil”, de la Universidad Espíritu
Santos de Ecuador, afirma que uno de los principales problemas que enfrentan
actualmente las empresas que se dedican al desarrollo de software, es la lucha
constante contra el tiempo. El cliente siempre buscará calidad en el menor tiempo
posible y para la disminución de tiempos se requiere de más personal capacitado.
Por eso y más factores hoy las empresas que desarrollan software se ven en la
necesidad de implementar métodos que ayuden en la gestión de sus proyectos.

2.2. MARCO TEÓRICO

2.2.1. GESTIÓN DE SOFTWARE ÁGIL

La ingeniería de software comprende múltiples actividades que incluyen
desde la captura de requisitos, análisis, gestión de procesos, diseño, codificación y
pruebas. Una de las actividades más importantes es la de “gestionar” el proyecto
software. El concepto de software management o software Project management

6
engloba un conjunto diverso de ideas y actividades. Al igual que en otras
disciplinas, “gestionar” implica coordinar grupos para realizar tareas que no se
pueden terminar por un solo individuo y, además, completarlas de manera
eficiente. La gestión de proyectos comprende cinco grandes bloques: planificar,
gestionar personal, organizar, controlar y dirigir (Tuya, Ramos y Dolado, 2007).

Sommerville (2010) afirma que la gestión de proyectos de software es una parte

esencial de la ingeniería de software. Esta no garantiza el éxito del proyecto, sin
embargo, usualmente una mala gestión lleva al fracaso. El software es entregado
tarde, los costos son mayores que los estimados y los requerimientos no se
cumplen, por lo tanto, la gestión efectiva de un proyecto de software depende de
planificar completamente su progreso, debido a que la ingeniería de software
siempre está sujeta a restricciones organizacionales de tiempo y presupuesto.

Fitsilis (2008), afirma que la gestión de proyectos ágil de software se basa en los
siguientes principios: abrazar el cambio, centrarse en el valor para el cliente,
entregar parte de la funcionalidad de forma incremental.

Como un resumen de los principios del manifiesto ágil, mencionados en

(Agilemanifesto, 2020), dicen: “estamos descubriendo mejores formas de
desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este
trabajo hemos llegado a valorar:

 Individuos e interacciones sobre procesos y herramientas.

 Software de trabajo sobre documentación completa.
 Colaboración del cliente sobre negociación de contrato.
 Responder al cambio sobre seguir un plan.

Es decir, si bien hay valor en los elementos de la derecha, valoramos más los
elementos de la izquierda.”

7
2.2.2. MÉTODOS Y TÉCNICAS

2.2.2.1. PROGRAMACIÓN EXTREMA (XP)

Según Pardo (2010), es uno de los procesos ágiles de desarrollo de

software más populares. Al igual que éstos, la programación extrema se diferencia
de las metodologías tradicionales principalmente en que pone más énfasis en la
adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los
requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable
del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de
requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y
más realista que intentar definir todos los requisitos al comienzo del proyecto e
invertir esfuerzos después en controlar los cambios en los requisitos.

Según Canos (2004), es una disciplina de desarrollo de software basada en los

valores de simplicidad, comunicación, retroalimentación y valor. En XP cada
participante del proyecto es una parte integral del equipo. El equipo se forma
alrededor de un representante llamado el cliente, que se sienta con el equipo y
trabaja con ellos diariamente. Los equipos de XP usan una forma simple de
planificación y seguimiento para decidir qué se debe hacer a continuación y para
predecir cuando el proyecto será finalizado. Focalizado en el valor del negocio, el
equipo produce software en una serie de pequeños entregables integrados, que
aprueban todos los testeos que ha definido el cliente. Los programadores de XP
trabajan juntos en pares y como un grupo, con un código testeado de forma
obsesiva y de diseño simple, mejorando el diseño continuamente para mantenerlo
siempre acorde a las necesidades actuales.

Sommerville (2011), menciona que la Programación Extrema (XP) es

posiblemente el método ágil más conocido y ampliamente utilizado debido al
enfoque con la cual fue desarrollada utilizando buenas prácticas reconocidas como
el desarrollo iterativo, y con la participación del cliente en niveles extremos.

8
A. VALORES DE LA PROGRAMACIÓN EXTREMA
Según Beck y Andrés (2005), XP es una filosofía de desarrollo de
software basado en valores de la comunicación, retroalimentación, sencillez, el
coraje y el respeto.

a. COMUNICACIÓN
Debe ser fluida entre todos los participantes en el proyecto; además el
entorno tiene que favorecer la comunicación espontánea, ubicando a todos los
miembros en un mismo lugar. La comunicación directa nos da mucho más valor
que la escrita, podemos observar los gestos del cliente, o la expresión de
cansancio de nuestro compañero (Fernández, 2014).

Muchos de los problemas que existen en proyectos de software, se deben a

problemas de comunicación entre las personas. La comunicación permanente es
fundamental en XP, dado que los artefactos son pocos, el dialogo frontal, cara a
cara, entre desarrolladores, administrador y el cliente es el medio básico de
comunicación. Una buena comunicación se debe mantener durante todo el
proyecto (Beck, 1999).

b. SIMPLICIDAD
El proceso XP, es una metodología ágil, que apuesta por la sencillez, en
su máxima expresión. Sencillez en diseño, en código, en los procesos, etc. La
sencillez es fundamental para que todos entiendan el código y se trata de mejorar
mediante re codificaciones continuas (Beck, 1999).

XP le pide a cada miembro del equipo que construya lo más sencillo que funcione
hoy. XP se basa en hacer algo simple hoy y crear un ambiente donde el costo del
cambio sea lo más bajo posible (Canos, 2004).

c. REALIMENTACIÓN
El usuario debe utilizar desde la primera entrega el software desarrollado,
dándonos sus impresiones y sus necesidades no satisfechas, de manera que esas
historias vuelvan a formar parte de los requisitos del sistema (Fernández, 2014).

9
La retroalimentación debe practicarse en forma permanente. El cliente debe
brindar retroalimentación de las historias de usuario desarrolladas, a fin de
considerar sus comentarios para la siguiente iteración, y para entender cada vez
más sus necesidades. Los resultados de las pruebas unitarias son también una
retroalimentación permanente que tienen los desarrolladores acerca de la calidad
de la aplicación (Beck, 1999).

d. CORAJE
Coraje para vencer la frase más típica de los desarrolladores: "si funciona
no lo toques". Con XP debemos tocar continuamente cosas que ya funcionan, para
mejorarlas. Hemos de cambiar esta frase por la de: "si funciona, puedes
mejorarlo". Y eso, os lo aseguramos, requiere de mucho valor y coraje
(Fernández, 2014).

Cuando se encuentran problemas serios en el diseño, o en cualquier fase del ciclo

de XP, se debe tener el coraje suficiente para encontrar la solución, sin importar
que tan difícil sea. Si es necesario cambiar completamente parte del código, hay
que hacerlo, sin importar cuánto tiempo se ha invertido en desarrollar el código a
cambiar (Beck, 1999).

e. RESPETO
Todos dan y sienten el respeto que merecen como miembros valiosos del
equipo. Todos aportan valor, incluso si es simplemente entusiasmo. Los
desarrolladores respetan la experiencia de los clientes y viceversa. La gerencia
respeta nuestro derecho de aceptar la responsabilidad y recibir autoridad sobre
nuestro propio trabajo (Wells, 2019).

Es el valor que resume los otros cuatro y sin el que los demás no funcionarán. Si
no hay respeto entre los miembros del equipo y éstos no respetan al proyecto y a
sus compañeros, difícilmente se obtendrá un feedback correcto. No tendrán el
coraje suficiente para tomar las mejores y más simples decisiones y fallará la
comunicación. Nadie, en un equipo de trabajo que usa XP, es más importante que

10
nadie. Ni lo es el jefe del proyecto sobre el resto de miembros ni lo es el
ingeniero software sénior con muchos años de experiencia en el trabajo. (Martel,
2018).

B. PRINCIPIOS DE LA PROGRAMACIÓN EXTREMA

Somerville (2005) plantea los siguientes principios o prácticas de la

Programación Extrema:

a. Planificación incremental, los requerimientos se registran en tarjetas de

historias y las historias a incluir en una entrega se determinan según el
tiempo disponible y su prioridad relativa. Los desarrolladores dividen
estas historias en tareas de desarrollo.

b. Entregas pequeñas, el mínimo conjunto útil de funcionalidad que

proporcione valor de negocio se desarrolla primero. Las entregas del
sistema son frecuentes e incrementalmente añaden funcionalidad a la
primera entrega.

c. Diseño sencillo, sólo se lleva a cabo el diseño necesario para cumplir los
requerimientos actuales.

d. Desarrollo previamente probado, se utiliza un sistema de pruebas de

unidad automatizado para escribir pruebas para nuevas funcionalidades
antes de que éstas se implementen.

e. Re factorización, se espera que todos los desarrolladores re factoricen el

código continuamente tan pronto como encuentren posibles mejoras en el
código. Esto conserva el código sencillo y mantenible.

f. Programación en pareja, los desarrolladores trabajan en parejas,

verificando cada uno el trabajo del otro y proporcionando la ayuda
necesaria para hacer siempre un buen trabajo.

11
g. Propiedad colectiva, las parejas de desarrolladores trabajan en todas las
áreas del sistema, de modo que no desarrollen islas de conocimientos y
todos los desarrolladores posean todo el código. Cualquiera puede
cambiar cualquier cosa.

h. Integración continua, en cuanto acaba el trabajo en una tarea, se integra

en el sistema entero. Después de la integración, se deben pasar al sistema
todas las pruebas de unidad.

i. Ritmo sostenible. No se consideran aceptables, grandes cantidades de

horas extras, ya que a menudo el efecto que tienen es que se reduce la
calidad del código y la productividad a medio plazo.

j. Cliente presente, debe estar disponible al equipo de la XP un

representante de los usuarios finales del sistema (cliente) a tiempo
completo. En un proceso de la programación extrema, el cliente es
miembro del equipo de desarrollo y es responsable de formular al equipo
los requerimientos del sistema para su implementación.

C. ROLES DE LA PROGRAMACIÓN EXTREMA

Según Beck (2004), los roles de XP son:
Programador. Es quien produce el código del sistema y escribe las Pruebas
unitarias. Debe existir una comunicación y coordinación adecuada entre los
programadores y otros miembros del equipo.

Cliente. Es quien escribe las historias de usuario y las pruebas funcionales para
validar la implementación. Además, debe asignar la prioridad a las historias de
usuario y decide en que iteración debe ser implementada. Por cliente se entiende
la persona que toma decisiones empresariales.

Encargado de pruebas (tester). Es quien ejecuta las pruebas y luego informa los
resultados al equipo, además ayuda al cliente a escribir las pruebas funcionales

12
(…). Es alguien que tiene que ejecutar todas las pruebas de forma regular (si no
puede hacer funcionar su unidad y pruebas de funcionamiento en conjunto),
resultados de pruebas de difusión, y para asegurarse de que herramientas de
prueba funciona bien.

Encargado de seguimiento (traker). Realiza el seguimiento del progreso de cada

iteración y proporciona la realimentación al equipo de trabajo (…). Mantiene un
registro de los resultados de las pruebas funcionales.

Entrenador (coach). Es el responsable del proceso global. Debe proveer guías al

equipo de forma que se apliquen las prácticas XP y se siga el proceso
correctamente.

Consultor. Es un miembro externo del equipo, quien posee conocimiento en

algún tema necesario para el proyecto.

Gestor (BigBoss). Es el gran jefe, es el vínculo entre clientes y programadores, su

función principal es la coordinación.

13
D. FASES DEL PROCESO ÁGIL XP

Figura 1. Fases de la metodología XP (Jeffries, Anderson y Hendrickson, 2001)

A. PLANIFICACIÓN
Según Jeffries, Anderson y Hendrickson (2001), el proceso XP plantea la
planificación mediante el diálogo continuo entre los integrantes del proyecto,
siendo los conceptos básicos de la planificación lo siguiente:

a. Historia de usuario: Las “historias de usuario” sustituyen a los

documentos de especificación funcional y a los “casos de uso”. Estas “historias”
son escritas por el cliente, en su propio lenguaje, como descripciones cortas de lo
que el sistema debe hacer. La diferencia más importante entre estas historias y los
tradicionales documentos de especificación funcional se encuentra en el nivel de
detalle requerido. Las historias de usuario deben tener el detalle mínimo, para que
los programadores puedan estimar el tiempo de desarrollo. En el momento de la
implementación, los desarrolladores dialogarán directamente con el cliente para
obtener todos los detalles necesarios (Jeffries, Anderson y Hendrickson, 2001).

b. Plan de entregas (Release Plan): El cronograma de entregas establece

qué historias de usuario serán agrupadas para conformar una entrega y el orden de
las mismas. Este cronograma será el resultado de un acuerdo entre todos los

14
actores del proyecto (cliente, desarrolladores, administradores, etc.). En el proceso
XP se denomina a esta reunión “Juego de planeamiento” (“Planninggame”), pero
puede denominarse de una forma apropiada al tipo de empresa y cliente (Por
ejemplo, Reunión de planeamiento, “Planningmeeting” o “Planningworkshop”).
El cliente ordenará y agrupará según sus necesidades las historias de usuario
(Beck, 1999).

c. Velocidad del proyecto: La velocidad del proyecto es una medida que

representa la rapidez con la que se desarrolla el proyecto; estimarla es muy
sencillo, basta con contar el número de historias de usuario que se pueden
implementar en una iteración; de esta forma, se sabrá el cupo de historias que se
pueden desarrollar en las distintas iteraciones. Usando la velocidad del proyecto
controlaremos que todas las tareas se puedan desarrollar en el tiempo del que
dispone la iteración. Es conveniente reevaluar esta medida cada 3 o 4 iteraciones y
si se aprecia que no es adecuada hay que negociar con el cliente un nuevo
“Release Plan”.

d. Plan de iteraciones: Las historias de usuarios seleccionadas para cada

entrega son desarrolladas y probadas en un ciclo de iteración, de acuerdo al orden
preestablecido. Al comienzo de cada ciclo, se realiza una reunión de planificación
de la iteración, cada historia de usuario se traduce en tareas específicas de
programación (Beck, 1999).

e. Rotaciones: Evitarán que las personas se conviertan en un cuello de

botella. Las rotaciones permitirán que todo el mundo conozca cómo funciona el
sistema.

f. Reuniones: Es necesario que los desarrolladores se reúnan diariamente y

expongan sus problemas, soluciones e ideas de forma conjunta. Las reuniones
tienen que ser fluidas y todo el mundo tiene que tener voz y voto.

15
B. DISEÑO
Según Jefferies, Anderson y Hendrickson (2001), la metodología XP
hace especial énfasis en los diseños simples y claros. Los conceptos más
importantes de diseño en esta metodología son los siguientes:

a. Simplicidad: La metodología XP sugiere que hay que conseguir diseños

simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible
para conseguir un diseño fácilmente entendible e implementable que a la larga
costará menos tiempo y esfuerzo a desarrollar.

b. Metáfora del sistema: Usar glosarios de términos y una correcta

especificación de los nombres de métodos y clases ayudará a comprender el
diseño y facilitará sus posteriores ampliaciones y la reutilización del código.

c. Tarjetas CRC: El uso de las tarjetas C.R.C (Clase, Responsabilidad y

Colaboración) permiten al programador centrarse y apreciar el desarrollo
orientado a objetos olvidándose de los malos hábitos de la programación
procedural clásica. Las tarjetas C.R.C representan objetos: la clase a la que
pertenece el objeto se puede escribir en la parte de arriba de la tarjeta, en una
columna a la izquierda se pueden escribir las responsabilidades u objetivos que
debe cumplir el objeto y a la derecha, las clases que colaboran con cada
responsabilidad.

d. Soluciones puntuales: Al ocurrir problemas técnicos, o cuando es

complejo estimar el tiempo para implementar una historia de usuario, pueden
utilizarse pequeños programas de prueba (llamados “spike”), para explorar
diferentes soluciones.
Estos programas sólo sirven para probar o evaluar una solución y son descartados
luego de su evaluación.

e. Funcionalidad mínima: Nunca se debe añadir funcionalidad extra al

programa, aunque se piense que en un futuro será utilizada. Sólo el 10% de la

16
misma es utilizada, lo que implica que el desarrollo de funcionalidad extra es un
desperdicio de tiempo y recursos.

f. Re factorizar: Es mejorar y modificar la estructura y codificación de

códigos ya creados sin alterar su funcionalidad. Re factorizar supone revisar de
nuevo estos códigos para procurar optimizar su funcionamiento. Es muy común
reutilizar códigos ya creados que contienen funcionalidades que no serán usadas y
diseños obsoletos. Esto es un error porque puede generar código completamente
inestable y muy mal diseñado, por este motivo, es necesario re factorizar cuando
se va a utilizar código ya creado.

C. DESARROLLO
Según Jeffries, Anderson y Hendrickson (2001), los conceptos más
importantes del desarrollo en esta metodología son los siguientes:

a. Disponibilidad del cliente: Uno de los requerimientos de XP es tener al

cliente disponible durante todo el proyecto, no sólo como apoyo a los
desarrolladores, sino formando parte del grupo, el cliente involucrado es
fundamental para desarrollar un proyecto con el proceso XP.

b. Unidad de prueba: En las metodologías tradicionales, la fase de pruebas,

incluyendo la definición de las pruebas, es realizada al final del proyecto, al final
del desarrollo de cada módulo. El proceso XP propone un modelo inverso, lo
primero que se escribe son los test que el sistema debe pasar, luego el desarrollo
debe ser el mínimo necesario para pasar las pruebas previamente definidas.

c. Programación por parejas: XP propone codificar en pares de

programadores, ambos trabajando juntos en una misma computadora, ésta práctica
aparentemente duplica el tiempo asignado al proyecto y por ende los costos en
recursos humanos, al trabajar en pares se minimizan los errores y se logran
mejores diseños, compensando la inversión.

17
d. Integración: Todos los desarrolladores necesitan trabajar siempre con la
“última versión”, realizar cambios o mejoras sobre versiones antiguas originan
graves problemas y retrasan al proyecto, por eso XP promueve publicar lo antes
posible las nuevas versiones, aunque no sean las últimas, siempre que estén libres
de errores.
Idealmente, todos los días deben existir nuevas versiones publicadas, para evitar
errores, sólo una pareja de desarrolladores puede integrar su código a la vez.

D. PRUEBAS
Según Jeffries, Anderson y Hendrickson (2001), los conceptos más
importantes de las pruebas en esta metodología son los siguientes:

A. Pruebas unitarias: Todos los módulos deben pasar las pruebas unitarias
antes de ser liberados o publicados, las pruebas unitarias deben ser definidas antes
de realizar el código.

B. Detección y corrección de errores: Cuando se encuentra un error

(“bug”), éste debe ser corregido inmediatamente y se deben tener precauciones
para que errores similares no vuelvan a ocurrir. Asimismo, se generan nuevas
pruebas para verificar que el error haya sido resuelto.

C. Implantación: El código será implantado cuando supere sus

correspondientes unidades de test.

D. Pruebas de aceptación: Las pruebas de aceptación son creadas en base a

las historias de usuarios, en cada ciclo de la iteración del desarrollo, el cliente
debe especificar uno o diversos escenarios para comprobar que una historia de
usuario ha sido correctamente implementada, las pruebas de aceptación son
consideradas como “pruebas de caja negra”, los clientes son responsables de
verificar que los resultados de éstas pruebas sean correctos.

18
E. ARTEFACTOS DE XP
HISTORIAS DE USUARIO
Las historias de usuario son la técnica utilizada en XP para especificar
los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente
describe brevemente las características que el sistema debe poseer, sean requisitos
funcionales o no funcionales. El tratamiento de las historias de usuario es muy
dinámico y flexible, en cualquier momento las historias de usuario pueden
romperse, reemplazarse por otras más específicas o generales, añadirse nuevas o
ser modificadas. Cada historia de usuario es lo suficientemente comprensible y
delimitada para que los programadores puedan implementarla en unas semanas
(Letelier y Penadés, 2006).

Tabla 1

Plantilla para las historias de usuario

HISTORIA DE USUARIO
Numero: Usuario:
Nombre Historia:
Prioridad en Negocio: Riesgo en Desarrollo:
Puntos Estimados: Iteración Asignada:
Programador Responsable:
Descripción:
Observaciones:

TAREAS DE INGENIERÍA
Una historia de usuario se descompone en varias tareas de ingeniería, las
cuales describen las actividades que se realizaran en cada historia de usuario,
asimismo las tareas de ingeniería se vinculan más al desarrollador, ya que permite
tener un acercamiento con el código (Ferreira, 2013).

19
Tabla 2

Plantilla para tareas de ingeniería

TAREA DE INGENIERÍA
Numero de Tarea: Numero de Historia (Nro. y
Nombre):
Nombre de Tarea:
Tipo de Tarea: Puntos Estimados:
Desarrollo/Corrección/ Mejora/
Otra (especificar)
Fecha Inicio: Fecha Fin:
Programador Responsable:
Descripción:

PRUEBAS DE ACEPTACIÓN
Las pruebas de aceptación son de vital importancia para el éxito de una
iteración y el comienzo de la siguiente, con lo cual el cliente puede conocer el
avance en el desarrollo del sistema y a los programadores lo que resta por hacer.
Además, permite una retroalimentación para el desarrollo de las próximas
historias de usuario a ser entregadas (Jeffries, 2013).
Tabla 3

Plantilla para las pruebas de aceptación

PRUEBAS DE ACEPTACIÓN
Código: N° Historia de Usuario:
Historia de Usuario:
Condiciones de Ejecución:
Entrada/ Pasos de ejecución:
Resultado Esperado:
Evaluación de la Prueba:

20
 TARJETAS CRC (CLASE-RESPONSABILIDAD
COLABORACIÓN)
Las tarjetas CRC, permiten conocer que clases componen el sistema y
cuáles interactúan entre sí, se dividen en tres secciones: Nombre de la Clase,
Responsabilidad y Colaboradores.
Tabla 4

Plantilla para las tarjetas CRC

TARJETAS CRC
Nombre de la Clase: Nombre de la clase al cual hace referencia la
tarjeta.
Responsabilidades: Atributos y Colaboradores: Clases que
operaciones de la clase. colaboran con la clase citada en la
tarjeta.

2.2.2.2. MARCO DE TRABAJO SCRUM

Según Schwaber y Sutherland (2013) Es un marco de trabajo por el cual

las personas pueden acometer problemas complejos adaptativos, a la vez que,
entregar productos del máximo valor posible, productiva y creativamente.

Según Díaz (2009) define a Scrum, como una colección de procesos para la
gestión de proyectos, que permiten centrarse en la entrega de valor para el cliente
y la potenciación del equipo para lograr su máxima eficiencia, dentro de un
esquema de mejora continua.

Según Sommerville (2011) afirma que Scrum es un método ágil que ofrece un
marco de referencia para la administración del proyecto. Se centra alrededor de un
conjunto de Sprints, que son periodos fijos cuando se desarrolla un incremento de
sistema. La planeación se basa en priorizar un atraso de trabajo y seleccionar las
tareas de importancia más alta para un Sprint.

21
 Figura 2. Prácticas de Scrum (Rubín, 2013)

A. ROLES SCRUM

a. El dueño de Producto (Product Owner)

El propietario del producto es el punto central empoderado del liderazgo
del producto. E1 es la única autoridad responsable de decidir qué características y
funcionalidades construir y el orden en el cual construirlos. El dueño del producto
mantiene y comunica a todos los demás participantes una visión clara de lo que el
equipo Scrum está tratando de lograr. Como tal, el propietario del producto es
responsable del éxito general de la solución que está siendo desarrollado o
mantenido (Rubín, 2013).

Schwaber y Sutherland (2013) afirman que el dueño de producto es el responsable

de maximizar el valor del producto y del trabajo del equipo de desarrollo. El cómo
se lleva a cabo esto podría variar ampliamente entre distintas organizaciones,

22
Equipos Scrum e individuos. El Dueño de Producto es la única persona
responsable de gestionar la Lista del Producto (Product Backlog).

b. El Scrum Master
Según Schwaber y Sutherland (2013), es el responsable de asegurar que
Scrum es entendido y adoptado. Los Scrum Masters hacen esto asegurándose de
que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum.
El Scrum Master ayuda a las personas externas al equipo Scrum a entender qué
interacciones con el equipo Scrum pueden ser de ayuda y cuáles no. El Scrum
Master ayuda a todos a modificar estas interacciones para maximizar el valor
creado por el equipo Scrum.

Es el responsable de ayudar a comprender y adoptar los valores, principios y

prácticas de Scrum. Ellos actúan como entrenadores tanto para el equipo de
desarrollo como para el propietario del producto. También proporciona liderazgo
de procesos, ayudando al equipo Scrum y al resto de la organización (Rubín,
2013).

c. El Equipo de desarrollo (Development Team)

Según Schwaber y Sutherland (2013), consiste en los profesionales que

desempeñan el trabajo de entregar un incremento de producto “Terminado”, que
potencialmente se pueda poner en producción, al final de cada Sprint. Solo los
miembros del Equipo de Desarrollo participan en la creación del incremento. Los
Equipos de Desarrollo son estructurados y empoderados por la organización para
organizar y gestionar su propio trabajo. La sinergia resultante optimiza la
eficiencia y efectividad del Equipo de Desarrollo.

Es una colección multifuncional de personas (arquitecto, programador, tester,

administrador de base de datos, diseñador de interfaz de usuario, etc.) que tienen
habilidades requeridas para entregar el producto (software) con el valor comercial
solicitado por el propietario del producto (Rubín, 2013).

23
B. ACTIVIDADES

Figura 3. Actividades de Scrum (Deemer P. , Benefield, Larman, & Bas, 2011)

a. Planificación de Sprint (Sprint Planning)

Es la planificación del trabajo a realizarse durante el Sprint. Este plan se
crea mediante el trabajo colaborativo del equipo Scrum completo. La
planificación de Sprint tiene un máximo de duración de ocho horas para un Sprint
de un mes. Para Sprints más cortos, el evento usualmente es más corto. El Scrum
Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan
su propósito. El Scrum Master enseña al equipo Scrum a mantenerse dentro del
bloque de tiempo (Schwaber y Sutherland, 2013).

La planificación se realiza al comienzo de cada Sprint. Durante esta ceremonia,

participan el Dueño del Producto, el Scrum Master y el Scrum Team. El objetivo
de esta ceremonia, es que el Dueño de Producto, pueda presentar al equipo, las
historias de usuario prioritarias, comprendidas en el Product Backlog; que el
equipo comprenda el alcance de las mismas mediante preguntas; y que ambos
negocien cuáles pueden ser desarrolladas en el Sprint que se está planificando.
Una vez definido el alcance del Sprint, es cuando el equipo divide cada historia de
usuario en tareas, las cuales serán necesarias para desarrollar la funcionalidad
descrita en la historia (Bahit, 2012).

24
Durante la planificación del Sprint, el propietario del producto y el equipo de
desarrollo acuerdan un objetivo de Sprint que define lo que se supone que
alcanzará el próximo Sprint. Usando este objetivo el equipo de desarrollo revisan
el backlog de producto y determina los elementos de alta prioridad que el equipo
puede lograr de manera realista en el próximo Sprint trabajando a un ritmo
sostenible, un ritmo al que el equipo de desarrollo pueda trabajar cómodamente
por un periodo prolongado de tiempo (Rubín, 2013).

Figura 4. Actividades de la planificación del Sprint (Rubín, 2013)

b. Sprint
Schwaber y Sutherland (2013), es un bloque de tiempo (time-box) de un
mes o menos durante el cual se crea un incremento de producto “terminado”,
utilizable y potencialmente desplegable. Es más conveniente si la duración de los
Sprints es consistente a lo largo del esfuerzo de desarrollo. Cada nuevo Sprint
comienza inmediatamente después de la finalización del Sprint previo.

25
 Figura 5. Los Sprints son el esqueleto del marco de Scrum (Rubín, 2013).

c. Daily Scrum

El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos

para que el equipo de desarrollo sincronice sus actividades y cree un plan para las
siguientes 24 horas. Esto se lleva a cabo inspeccionando el trabajo avanzado
desde el último Scrum Diario y haciendo una proyección que podría completarse
antes del siguiente (Schwaber y Sutherland, 2013).

Las reuniones diarias para Scrum, son “conversaciones” de no más de 5-15

minutos, que el Scrum Master tendrá al comienzo de cada día, con cada miembro
del equipo. En esta conversación, el Scrum Master deberá ponerse al día de lo que
cada miembro ha desarrollado (en la jornada previa), lo que hará en la fecha
actual, pero, sobre todo, conocer cuáles impedimentos estén surgiendo, a fin de
resolverlos y que el Scrum Team pueda continuar sus labores, sin preocupaciones
(Bahit, 2012).

26
 Figura 6. Scrum diario (Rubín, 2013)

d. Ejecución del Sprint (Sprint execution)

Durante la ejecución del Sprint, los miembros del equipo de desarrollo
realizan activamente trabajo creativo de diseño, construcción, integración y
prueba de elementos de la lista de productos en incrementos de funcionalidad.
Para hacer esto, se auto organizan y deciden como planificar, administrar y
comunicar el trabajo. El equipo de desarrollo pasa la mayor parte de su tiempo
realizando ejecución de Sprint (Rubin, 2013).

27
 Figura 7. Actividad de ejecución de Sprint (Rubín, 2013)

e. Revisión de Sprint (Sprint review)

La revisión de Sprint se realiza al final del Sprint, cuya finalidad es para
inspeccionar el incremento y adaptar la lista de productos si fuese necesario.
Durante la revisión de Sprint, el equipo Scrum y los interesados colaboran acerca
de lo que se hizo durante el Sprint, los asistentes colaboran para determinar las
siguientes cosas que podrían hacerse para optimizar el valor. Se trata de una
reunión informal, no una reunión de seguimiento, y la presentación del
incremento tiene como objetivo facilitar la retroalimentación de información y
fomentar la colaboración (Schwaber y Sutherland, 2013).

Durante la ceremonia de revisión en Scrum, el equipo presentará al Dueño de

Producto las funcionalidades desarrolladas. Las explicará y hará una demostración
de ellas, a fin de que, tanto Dueño de Producto como la eventual audiencia,
puedan experimentarlas. El Dueño de Producto podrá sugerir mejoras a las
funcionalidades desarrolladas, aprobarlas por completo o eventualmente,
rechazarlas si considera que no se ha cumplido el objetivo. La ceremonia de

28
revisión se lleva a cabo el último día del Sprint, y no tiene una duración fija. En la
práctica, se utiliza el tiempo que sea necesario (Bahit, 2012).

Rubin (2013) afirma que el objetivo de esta actividad es inspeccionar y adaptar el

producto que se está construyendo. Crítico para esta actividad es la conversación
que tiene lugar entres sus participantes, que incluyen el equipo Scrum,
stakeholders, patrocinadores, clientes y miembros interesados de otros equipos. La
conversación se centra en revisar las características que se acaban de completar en
el contexto del esfuerzo de desarrollo general. Todos los asistentes obtienen una
visibilidad clara de lo que está ocurriendo y tiene la oportunidad de ayudar a guiar
el próximo desarrollo para garantizar la solución más adecuada para el negocio.

Figura 8. Actividad de revisión de Sprint (Rubín, 2013)

f. Retrospectiva de Sprint (Sprint Retrospective)

Es una oportunidad para el equipo Scrum de inspeccionarse a sí mismo y
crear un plan de mejoras que sean abordadas durante el siguiente Sprint. La
retrospectiva de Sprint tiene lugar después de la revisión del Sprint y antes de la
siguiente reunión de planificación de Sprint. Se trata de una reunión restringida a
un bloque de tiempo de tres horas para Sprints de un mes. Para Sprints más cortos
se reserva un tiempo proporcionalmente menor (Schwaber y Sutherland, 2013).

29
Como última ceremonia de Sprint, Scrum propone efectuar al equipo, una
retrospectiva en forma conjunta con el Scrum Master y opcionalmente, el Dueño
de Producto. El objetivo de esta retrospectiva, como su nombre lo indica, es
“mirar hacia atrás (en retrospectiva)”, realizar un análisis de lo que se ha hecho y
sus resultados correspondientes, y decidir qué medidas concretas emplear, a fin de
mejorar esos resultados. La retrospectiva en Scrum suele ser vista como una
“terapia de aprendizaje”, donde la finalidad es “aprender de los aciertos, de los
errores y mejorar todo aquello que sea factible” (Bahit, 2012).

Esta actividad ocurre con frecuencia después de la revisión de Sprint y antes de la

próxima planificación de Sprint. Durante la retrospectiva de Sprint el equipo de
desarrollo, Scrum Master y el propietario del producto se unen para discutir qué
funciona y qué no funciona con Scrum y las prácticas técnicas asociadas. La
retrospectiva es una oportunidad para inspeccionar y adaptar el proceso. Al final
de una retrospectiva de Sprint, el equipo Scrum debería tener identificado y
comprometido un número práctico de acciones de mejora de procesos que será
llevado a cabo por el equipo Scrum en el próximo Sprint (Rubin, 2013).

Figura 9. Actividad de retrospectiva de Sprint (Rubín, 2013)

30
C. ARTEFACTOS

a. Lista de Producto (Product backlog)

Es una lista ordenada de todo lo que podría ser necesario en el producto,
y es la única fuente de requisitos para cualquier cambio a realizarse en el
producto. La lista de producto enumera todas las características, funcionalidades,
requisitos, mejoras y correcciones que constituyen cambios a ser hechos sobre el
producto para entregas futuras. Los elementos de la lista de producto tienen como
atributos la descripción, la ordenación, la estimación y el valor (Schwaber y
Sutherland, 2013).

Es una lista priorizada (u ordenada) de la funcionalidad deseada del producto. El

propietario del producto colabora con las partes interesadas internas y externas
para reunirse y definir los elementos de la lista de productos. Luego se asegura de
que los elementos de la lista de producto se coloquen en la secuencia correcta
(utilizando factores como el valor, costo, conocimiento y riesgo) para que los
elementos de alto valor aparezcan en la parte superior y los elementos de menor
valor aparezcan hacia abajo. La lista de productos es un artefacto en constante
evolución, porque los elementos pueden ser agregados, eliminados y revisados por
el propietario del producto como los cambios de las condiciones comerciales, o
según la comprensión del producto por parte del equipo Scrum (a través de
comentarios sobre el software producido durante cada Sprint) (Rubin, 2013).

b. Sprint backlog
Es el conjunto de elementos de la lista de productos seleccionados para el
Sprint, más un plan para entregar el incremento de producto y conseguir el
objetivo del Sprint. La lista de pendientes del Sprint es una predicción hecha por
el equipo de desarrollo acerca de que funcionalidad formará parte del próximo
incremento y del trabajo necesario para entregar esa funcionalidad en un
incremento terminado (Schwaber y Sutherland, 2013).

31
c. Incremento del Producto
El incremento es la suma de todos los elementos de la lista de producto
completados durante un Sprint y el valor de los incrementos de todos los Sprints
anteriores. Al final del Sprint, el nuevo incremento debe estar “terminado”, lo cual
significa que está en condiciones de ser utilizado y que cumple la definición de
“terminado” del equipo Scrum. El incremento debe estar en condiciones de
utilizarse sin importar si el dueño del producto decide liberarlo o no (Rubín,
2013).

2.2.2.3. MARCO DE TRABAJO KANBAN

Kanban es un método para definir, gestionar y mejorar los servicios que
entregan trabajo de conocimiento, como servicios profesionales, creativos
esfuerzos y el diseño de productos físicos y de software. Eso puede caracterizarse
como un método de "comenzar desde lo que haces ahora", un catalizador para un
cambio rápido y enfocado dentro de las organizaciones, eso reduce la resistencia
al cambio beneficioso en línea con la organización y metas (Carmichael y
Andreson, 2015).

Kanban es una herramienta para gestionar el flujo de materiales o información (o

lo que sea) en un proceso. No tener los materiales, ya sea una parte, un documento
o información de un cliente, en el momento en que la necesita causa retraso y
residuos. Por otro lado, tener demasiadas partes en mano o demasiado trabajo en
proceso (WIP) también es una forma de residuos. Kanban es una herramienta para
aprender y gestionar un óptimo flujo de trabajo dentro del proceso (Klipp, 2014).

A. VALORES
Para Carmichael y Anderson (2015) Los valores de Kanban pueden
resumirse en esa sola palabra, "Respeto". Sin embargo, es útil expandir esto en un
conjunto de nueve valores (incluido respeto) que encapsula por qué los principios
y prácticas de Kanban existen.

a. Transparencia

32
 La creencia de que compartir información mejora abiertamente el flujo
de negocios valor. Usando claro y sencillo el vocabulario es parte de este valor.

b. Balance
La comprensión de que diferentes aspectos, puntos de vista, y todas las
capacidades deben estar equilibrados para su efectividad. Algunos aspectos (como
la demanda y la capacidad) causarán un colapso si están fuera de balance por un
período prolongado.

c. Colaboración
Trabajando juntos. El método Kanban fue formulado para mejorar la
forma en que las personas trabajan juntas, por lo que la colaboración es en sí, su
corazón.

d. Enfoque en el cliente
Conocer el objetivo del sistema. En cada Kanban el sistema fluye a un
punto de valor cuando los clientes reciben un artículo o servicio requerido. Los
clientes en este contexto son externos al servicio, pero puede ser interno o externo
a la organización como todo. Los clientes y el valor que reciben es el punto
natural de enfoque en Kanban.
e. Flujo
La comprensión de que el trabajo es un flujo de valor, ya sea continuo o
episódico. Ver el flujo es un punto de partida esencial para usar Kanban.

f. Liderazgo
La capacidad de inspirar a otros a la acción a través del ejemplo, palabras
y reflexión. La mayoría de las organizaciones tienen cierto grado de estructura de
jerarquía, pero en Kanban se necesita liderazgo en todos los niveles para lograr
entrega de valor y mejora.

33
g. Comprensión
Principalmente autoconocimiento (tanto del individuo y de la
organización) para avanzar. Kanban es un método de mejora, y saber el punto de
partida es fundamental.

h. Acuerdo
El compromiso de avanzar juntos hacia las metas, respetando, y donde
sea posible, complaciente con las diferencias de opinión o enfoque. Esto no es
gestión por consenso, sino un co compromiso dinámico con la mejora.

i. Respeto
Valorar, comprender y mostrar consideración por personas. Al pie de esta
lista, es la base de que los otros valores descansan.

B. OBJETIVOS
Para Richter (2011) los objetivos personales de Kanban son:

a. Al visualizar su flujo de trabajo, su trabajo aparecerá en su propio

contexto que es fácil de comprender y fácil de reflexionar.

b. A través de la reflexión, comenzará a mejorar su flujo de trabajo y

alcanzará un mayor valor de este esfuerzo.

c. Al limitar su trabajo en progreso, usted guiará su enfoque y logrará un

rendimiento más alto.

C. AGENDAS
Para Carmichael y Anderson (2015) Kanban reconoce tres agendas
basadas en necesidad organizacional:

a. La sostenibilidad
La agenda es sobre encontrar un sostenible ritmo y mejorando el enfoque.

34
b. El servicio Orientación Agenda
Enfoca atención al rendimiento y cliente satisfacción.

c. La supervivencia
La agenda está preocupada con mantenerse competitivo y adaptativo.

D. PILARES
Para Richter (2011) son 3 pilares personales de efectividad:

a. Importancia
 Aprende a seguir tu trabajo.
 Aprenda a priorizar su trabajo.
 Aprenda a respetar su propia priorización.

b. Atención
 Limitar el trabajo en progreso lo ayudará a mantener el enfoque.
 Aprender a manejar interrupciones externas.
 Aprender a manejar el retraso.
 Trabaja enfocado por 25 minutos y recompénsate con un freno de 5
minutos.

c. Valor
 Visualice su flujo de trabajo para aprender implícitamente sobre su flujo
de valor.
 Limite el trabajo en progreso para ayudarlo implícitamente a seguir,
aumentar su rendimiento y, por lo tanto, agregar más valor.
 Mapee su flujo de valor para visualizar etapas de agregar valor y cuellos
de botella en su flujo de trabajo.
 Aprender sobre ciudadanos e integrarlos como parte de su personalidad.

E. PRACTICAS GENERALES
Carmichael y Anderson (2015) definen 6 de ellos:

35
a. Visualiza
Un tablero Kanban es una, aunque no la única, forma de visualizar el
trabajo y el proceso para que sea un sistema Kanban en lugar de simplemente un
sistema de flujo, se deben definir los puntos de compromiso y entrega, y los
límites de WIP deben mostrarse para limitar el trabajo en progreso en cada etapa
entre estos puntos. El acto de hacer el trabajo y políticas visibles, ya sea en un
tablero de pared, en pantallas electrónicas u otros medios: es el resultado de un
importante viaje de colaboración para comprender el sistema actual y encontrar
áreas potenciales para mejorar.

b. Limite el WIP
Introducir y respetar los límites de WIP cambia un sistema "push" en un
sistema de "extracción", en el que los elementos nuevos no se inician hasta el
trabajo se completa (o en raras ocasiones, se aborta). Tener demasiado el trabajo
parcialmente completo es derrochador y costoso y, crucialmente alarga los plazos
de entrega, evitando que la organización sea receptiva a sus clientes y
circunstancias cambiantes y a las oportunidades.

c. Administrar flujo
El flujo de trabajo en un sistema Kanban debería maximizar la entrega de
valor, minimizar los tiempos de entrega y ser tan suave (es decir, predecible)
como sea posible. Estos son objetivos a veces conflictivos y, desde los entregables
suelen ser complejos, control empírico a través de la transparencia, se requiere
inspección y adaptación. Los cuellos de botella, donde ocurren están limitados por
un subproceso particular y bloqueadores, donde hay dependencias de otros
servicios, es importante tenerlos en cuenta y gestionarlos.

d. Hacer políticas explícitas

Las políticas explícitas son una forma de articular y definir un proceso
que va más allá de la definición del flujo de trabajo. Un proceso expresado como
flujo de trabajo y las políticas crean restricciones en la acción, se empodera las
restricciones y da como resultado características emergentes que pueden ser

36
sintonizados por el experimento. Las políticas de proceso deben ser escasas,
simples, bien definidas, visibles, siempre aplicadas y fácilmente modificables por
los que prestan el servicio. Tenga en cuenta que "siempre aplicado" y "fácilmente
cambiable" van juntos. Establecer límites de WIP, y luego nunca desafiar,
cambiando o rompiendo los límites para ver si diferentes límites en diferentes
circunstancias mejoran los resultados, sería un pobre aplicación de esta práctica.

e. Implementar bucles de retroalimentación

Los circuitos de retroalimentación son una parte esencial de cualquier
proceso controlado y son especialmente importantes para el cambio evolutivo.
Mejorando la retroalimentación en todas las áreas del proceso es importante, pero
lo es particularmente en el siguiendo:

 Alineación de la estrategia
 Coordinación operativa
 Gestión de riesgos
 Mejora del servicio
 Reposición
 Fluir
 Entregas a clientes

f. Mejorar colaborativamente, evolucionar experimentalmente

Kanban es fundamentalmente un método de mejora. A menudo, la
transformación los programas se inician con el objetivo de cambiar procesos a un
nuevo enfoque predefinido. En contraste, Kanban comienza desde el organización
tal como es ahora y utiliza el paradigma Lean flow (viendo trabajar como un flujo
de valor) para perseguir continua e incremental mejora. Kanban aprovecha un
proceso evolutivo para permitir un cambio beneficioso que puede ocurrir dentro
de una organización, protegiéndola de otro proceso natural evolutivo: ¡extinción!
Las organizaciones no pueden optar por no participar en la evolución: funciona
para ellos o les sucede a ellos. Pero pueden optar por alentar que el cambio ocurra

37
desde adentro, en lugar de encontrarlo, no puede responder a amenazas
existenciales desde afuera. Kanban facilita esto.

F. ROLES
Kanban es y sigue siendo el método "comienza con lo que haces ahora",
donde inicialmente nadie recibe nuevos roles, responsabilidades o títulos de
trabajo. Por lo tanto, no hay roles obligatorios en Kanban y el método no crear
nuevos puestos en la organización. Sin embargo, dos roles vienen surgiendo de la
práctica común en el campo y ahora se definen en el método mismo. Es el
propósito de los roles lo que es importante, en lugar de asignarle a alguien un
título de trabajo, por lo que puede ser útil pensar en los roles como "sombreros"
que la gente usa para llevar a cabo estos funciones: (Carmichael y Anderson,
2015).

A. El administrador de solicitudes de servicio (Service Request Manager),

es responsable de comprender las necesidades y expectativas de los
clientes, y para facilitar, seleccionar y ordenar elementos de trabajo en la
respectiva reunión. Los nombres alternativos para el rol son Product
Manager, Propietario del producto y Gerente de servicio.

B. El Service Delivery Manager es responsable del flujo de trabajar en la

entrega de artículos seleccionados a los clientes y facilitar la reunión de
Kanban y la planificación de la entrega. Alternativa los nombres para
este rol son Flow Manager, Delivery Manager o incluso Flow Master.

G. FASES
Según lo establecido por (Ballesteros, 2008), se realiza mediante la
ejecución de 4 fases necesarias para su correcta aplicación, las cuales son:

 Fase 1: Entrenar a todo el personal en los principios de Kanban y los

beneficios de usarlo.

38
 Fase 2: Implementar Kanban en los componentes con más problemas
para facilitar su manufactura y para resaltar los problemas escondidos. El
entrenamiento con el personal continúa en la línea de producción.

 Fase 3: Implementar Kanban en el resto de los componentes. Se deben

tomar en cuenta todas las opiniones de los operadores, ya que ellos son
los que mejor conocen el sistema. Es importante informarles cuando se
va a estar trabajando en su área de responsabilidad.
 Fase 4: Esta es la fase para la revisión del sistema Kanban, los puntos de
re orden y los niveles de re orden. Es importante tomar en cuenta las
siguientes recomendaciones para el funcionamiento correcto de este
sistema:
a. Ningún trabajo debe ser hecho por fuera de secuencia.
b. Si se encuentra algún problema, notificar al supervisor
inmediatamente.

H. ARTEFACTOS
Según (Kanbanize, 2020) son:

a. El tablero Kanban es la herramienta para mapear y visualizar su flujo de

trabajo y uno de los componentes claves del método Kanban. Originalmente, se
utilizaba una pizarra blanca (o un tablero de corcho) que se dividía en columnas y
filas. Cada columna visualiza una fase de su proceso y las filas representan
diferentes tipos de actividades específicas (diseño, errores, deuda técnica, etc.).

Al mismo tiempo, cada tarea que entra en su flujo de trabajo aparece en el tablero
como una tarjeta Kanban. El punto de entrada de cada tarjeta es la columna “Por
hacer”.
Hoy en día, existen soluciones de tarjetas Kanban digitales más prácticas y
accesibles a nivel global que son perfectas tanto para para los equipos remotos
como para los equipos que desarrollan su actividad en el lugar donde se realiza el
proyecto.

39
b. Una tarjeta Kanban es el elemento clave de un tablero Kanban. Cada
tarjeta representa una tarea o un trabajo que debe realizarse.

Una tarjeta Kanban contiene información significativa sobre la tarea y su estado

en el tablero Kanban, como por ejemplo el tiempo del ciclo, la fecha límite, etc.
Toda esta información sirve como un canal de comunicación entre los diferentes
miembros del equipo.

En realidad, la aplicación real de las tarjetas Kanban es visualizar el progreso de

las tareas desde el momento en que se solicitan hasta el momento en que se
consideran hechas. Durante este proceso, las tarjetas:

 Sirven como centros de información

 Reducen la necesidad de reuniones
 Mejoran la transparencia del flujo de trabajo

Algo muy importante es que la cantidad de tarjetas Kanban que están en progreso
en el tablero esté limitada. De esta forma evitará el cambio de contexto y los
problemas con la productividad.

2.2.2.4. PROGRAMACIÓN EXTREMA SOBRE SCRUM

La metodología de desarrollo ágil XP y el marco de trabajo Scrum se
complementan entre sí. Del lado de XP, se destacan las prácticas, valores y el
ciclo de vida que esta metodología propone, misma que se compone de seis fases:
Exploración, Planeación, Diseño, Codificación, Pruebas del Proyecto. En lo que
respecta a Scrum, se destacan los eventos y artefacto que posee este marco de
trabajo para cubrir las necesidades del producto. La combinación de XP y Scrum
supuso una gran ayuda en el proceso de desarrollo, evitando la documentación
exhaustiva y haciendo del cliente un miembro más del equipo (Carrasco, Ocampo,
Ulloa, Azcona, 2019).

Scrum se enfoca en las prácticas de organización y gestión, mientras que XP se

centra más en las prácticas de programación. Esa es la razón de que funcionan tan

40
bien juntas: Tratan de áreas diferentes y se complementan entre ellas (Kniberg,
2015).

A. SOFTWARE ITERATIVO E INCREMENTAL

Significa que la aplicación se divide en pequeños proyectos, los cuales
incorporan una parte de las especificaciones, y el desarrollo de la misma es una
iteración que va incrementando la funcionalidad del sistema de manera progresiva
(Silva, Barrera, Arroyave y Pineda, 2007).
Consiste en entregar prototipos ejecutables o porciones de un sistema operativo en
periodos cortos de tiempo, de modo que la adaptación vaya a ritmo con el cambio
(impredecible). Este enfoque iterativo permite que el cliente evalúe en forma
regular el incremento de software, dé la retroalimentación necesaria al equipo de
software e influya en las adaptaciones del proceso que se realicen para aprovechar
la retroalimentación (Pressman, 2010).

Los requerimientos funcionales del producto, son fragmentados en lo que se

denomina “Historias de Usuario” y, basándose en la prioridad del cliente y el
esfuerzo disponible para el desarrollo, se hace una selección de historias de
usuario a ser desarrolladas en un periodo de tiempo fijo y al finalizar dicho
periodo, las historias de usuario habrán sido convertidas en software que puede
utilizarse y, por tanto, se entrega al cliente. Este ciclo, es continuo (al finalizar un
ciclo comienza el siguiente) y esto, genera una entrega rápida y continuada al
cliente (Bahit, 2012).

B. PRUEBAS UNITARIAS CONTINUAS

Según Tuya, Ramos, Dolado (2007), constituyen el primer paso para
detectar errores en el código, pues se centran en la menor unidad de diseño del
software: el módulo – por ejemplo, un método de una clase o una clase. El
objetivo principal de estas pruebas es detectar errores en cada uno de los módulos
del software al ser ejecutados independientemente del resto de componentes.
Estas pruebas suelen ser ejecutadas por el programador que construye el módulo.
Se centran en los aspectos estructurales, intentando asegurar algún tipo de
cobertura de código, y en los aspectos funcionales, para comprobar la integridad

41
de la información en las estructuras de información locales y la interfaz del
módulo.

Según Bahit (2012), representan el alma de la programación dirigida por pruebas.

Son test que se encargan de verificar de manera simple y rápida el
comportamiento de una parte mínima de código, de forma independiente y sin
alterar el funcionamiento de otras partes de la aplicación.

C. RE FACTORIZACIÓN DEL CÓDIGO

Consiste en simplificar y optimizar el programa sin perder funcionalidad,
es decir, alterar su estructura interna sin afectar su comportamiento externo
(Abrahamsson, Salo, Ronkainen y Warsta, 2002).

Es el proceso de cambiar la estructura de código, reformulándolo, sin cambiar su

significado o comportamiento. Está acostumbrado a mejorar la calidad del código,
combatir la inevitable entropía del software y facilitar agregando nuevas
características (Shore y Warden, 2008).

D. CORRECCIÓN DE ERRORES Y CÓDIGO COMPARTIDO

Cuando se encuentra un error (“bug”), éste debe ser corregido
inmediatamente y se deben tener precauciones para que errores similares no
vuelvan a ocurrir. Asimismo, se generan nuevas pruebas para verificar que el error
haya sido resuelto (Jeffries, Anderson y Hendrickson, 2001).

La propiedad colectiva del código tiene por objetivo que todos los miembros del
equipo conozcan “qué” y “cómo” se está desarrollando el sistema, evitando así, lo
que sucede en muchas empresas, que existen “programadores dueños de un
código” y cuando surge un problema, nadie más que él puede resolverlo, puesto
que el resto del equipo, desconoce cómo fue hecho y cuáles han sido sus
requerimientos a lo largo del desarrollo (Bahit, 2012).

42
2.2.2.5. SCRUMBAN
Para (Pérez, 2011) sostiene que, Scrumban (o Scrum-ban) es una
metodología derivada de los enfoques Scrum y Kanban. Esta metodología, por
cierto, híbrida, contempla componentes y conceptos de ambas que se
complementan entre sí, para lograr una mejor optimización del proceso de
desarrollo.

El término “Scrumban” fue utilizado por primera vez por Ladas (2008), en su
publicación “Scrumban-Essays on Kanban System for Lean Software
Development”.

En la actualidad, muchas organizaciones definen a Scrumban como un enfoque

avanzado y orientado a la mejora del proceso de desarrollo, ya que permite
adoptar una combinación de reglas que ambas metodologías por separado no
permiten.
Existen dos (2) líneas de pensamiento en relación a Scrumban como enfoque
híbrido:

 Se destacan algunos elementos de Scrum que son aplicados directamente

al enfoque de Kanban, donde el proceso es mayormente inclinado hacia
Kanban y

 Algunos elementos de Kanban que son aplicados al enfoque de Scrum,

donde el proceso es mayormente inclinado hacia Scrum. Además, desde
una perspectiva de implementación, Scrumban permite un grado de
flexibilización mayor, para partir desde una base simple y de forma
gradual, llegar a una base compleja.

A. CARACTERÍSTICAS DE SCRUMBAN
Para (Ahmad, 2014) define las principales actividades que se realizan en
Scrumban:

43
a. Visualizar el flujo de trabajo
Esta es una de las herramientas más importantes tomadas de Kanban y que
se aplica a Scrumban, la cual se refiere a literalmente visualizar cada historia de
usuario en cada una de las etapas (o columnas) del flujo del proceso. Esto infiere
que cada ítem en el tablero es observado de su comienzo en el sprint backlog (en
un tablero Scrumban, primera columna a la izquierda), hasta su etapa final
“Completado” o “Done” (por lo general, la última columna a la derecha. La
visualización ayuda al equipo de trabajo, a identificar los cuellos de botellas en el
flujo del proceso. A su vez, esta observación del tablero completo ayuda a la
sincronización del equipo, ya que ayuda a saber en qué está trabajando cada
integrante.

b. Cola de trabajo
Como fue definido anteriormente, una de las características de Scrum, es
que las historias de usuario priorizadas y seleccionadas para ser trabajadas dentro
de un sprint en particular, son un compromiso de entrega por parte del equipo
hacia el cliente. Esto quiere decir que una vez que el sprint es iniciado, no son
aceptados cambios en su contenido (es decir, en sus historias de usuario). En
Scrumban, esto no sucede de esta forma, ya que se utilizan las denominadas colas
de trabajo de Kanban, que permiten que los sprints sean alterados cuando sea
requerido, sin producir grandes impactos.

c. Limitar el trabajo en progreso (WIP)

Otro de los aspectos de Scrumban es el de aplicar límites al trabajo en los
puntos de progreso de todas las etapas, basado en la capacidad del equipo. De esta
forma, al revés de ingresar más trabajo al flujo del proceso, el equipo se enfoca en
localizar el cuello de botella (o el WIP limitado) en alguna de las fases, para
ayudar a resolverlo y estar en condiciones nuevamente retomar nuevas
actividades.

44
d. Reglas explícitas
En Scrum, los equipos son auto-organizados, trabajan y se coordinan a sí
mismos con reglas implícitas. Sin embargo, en la práctica existen siempre
diferencias entre cómo un equipo debe organizarse y cómo están funcionando en
la realidad. Es por eso que en Scrumban, las reglas (o políticas) del equipo se
hacen efectivamente explícitas, para que todos en el equipo estén facultados para
auto-organizarse, con el fin de lograr flujos de trabajos más dinámicos y efectivos.
Así, esto permite que los integrantes del equipo puedan tomar decisiones rápidas
sin poner mucho esfuerzo en el pensamiento, e incluso reducir la posibilidad de
decidir incorrectamente y también, de ceder a las peticiones especiales bajo estrés.
Estas reglas explícitas tratan de hacer frente a situaciones recurrentes, en las que
alguien necesita tomar una decisión sobre cómo proceder o qué hacer, si surge una
situación de algún tipo en particular.

B. REUNIONES EN SCRUMBAN
Las reuniones de Scrum son uno de los elementos que se mantienen sin
grandes cambios en Scrumban. El único cambio que predomina entre cada
enfoque es la periodicidad en la cual las reuniones son realizadas.

a. Reuniones de Planificación
A diferencia de Scrum, Scrumban tiene reuniones de planificación más
cortas, con el fin de actualizar el backlog cuando sea necesario. El equipo siempre
debe planificar para el período más corto por delante. Tener reuniones de
planificación más largas no tiene sentido en el caso de que las prioridades
cambien a menudo. Esto reduce significativamente el tiempo en las que las
reuniones de planificación se llevan a cabo (Ladas, 2008).

b. Reunión Stand-up (diaria)

Como en el enfoque Scrum, esta reunión diaria es de carácter operativa y
ayuda a coordinar las actividades diarias y también, a remover cualquier
impedimento que se presente durante el flujo.

45
c. Reunión de Revisión de Sprint
Se consideran las mismas características que en el enfoque Scrum, para
estas reuniones de revisiones.

d. Reunión de Retrospectiva
La periodicidad de esta reunión puede diferir en cada equipo/proyecto a
donde se implementa el enfoque Scrumban. Sin embargo, en Scrumban se hace
especial hincapié en los cuellos de botellas presentados durante el trabajo pasado,
de forma de entender las razones de los mismos y poder anticiparse en futuras
reincidencias.

2.3. HERRAMIENTAS

2.3.1. PROGRAMACIÓN ORIENTADA A OBJETOS (POO)

Según Pérez (2014), la programación orientada a objetos (POO) es un
paradigma de programación que usa objetos y sus interacciones, para diseñar
aplicaciones y programas informáticos. Está basada en varias técnicas, incluyendo
herencia, abstracción, polimorfismo y encapsulamiento.

Según Martínez (2016), es una técnica de análisis y diseño de software que orienta
a los elementos de un sistema, sus atributos y responsabilidades en vez de
centrarse en el flujo de los procesos. El modelo abstracto está formado de clases.
Una clase describe a un conjunto de objetos que comparte los mismos atributos,
comportamiento y semántica.
La programación orientada a objetos es un importante conjunto de técnicas que
pueden utilizarse para hacer el desarrollo de programas más eficientes, a la par
que mejora la fiabilidad de los programas de computadora. En la programación
orientada a objetos, los objetos son los elementos principales de construcción; sin
embargo, la simple comprensión del concepto de objetos, o bien el uso de objetos
en un programa, no significa que estén programados en un modo orientada a
objetos, un concepto importante en un sistema es el modo en que los objetos se
interconectan y comunican entre sí. La idea principal de la programación

46
orientada a objetos es un conjunto de objetos que interactúan entre si y que están
organizados en clases (Joyanes, 2005).

2.3.2. SISTEMA GESTOR DE BASE DE DATOS

Un Sistema Gestor de Bases de Datos (SGBD) o DBMA (Database
Management System) es una colección de programas cuyo objetivo es servir de
interfaz entre la base de datos, el usuario y las aplicaciones. Se compone de un
lenguaje de definición de datos, de un lenguaje de manipulación de datos y de un
lenguaje de consulta. Un SGBD permite definir los datos a distintos niveles de
abstracción y manipular dichos datos, garantizando la seguridad e integridad de
los mismos (Castillo, 2011).
Un sistema gestor de base de datos (SGBD) consiste en una colección de datos
interconectados y un conjunto de programas para acceder a dichos datos. La
colección de datos normalmente denominadas base de datos, contiene información
relevante para una empresa. El objetivo principal de SGBD es proporcionar una
forma de almacenar y recuperar la información de una base de datos de manera
que sea tanto practica como eficiente (Silberschatz et al., 2006).
Un sistema de administración de base de datos (DBMS) es el software que
permite a una organización centralizar los datos, administrar eficientemente y
proporcionar, mediante los programas de aplicación, el acceso a los datos
almacenados. El DBMS actúa como una interfaz entre los programas de
aplicación y los archivos de datos físicos (Laudon, K. y Laudon, J., 2008).

2.4. POBLACIÓN
Según Chávez (2007), la población “es el universo de estudio de la
investigación, sobre el cual se pretende generalizar los resultados, constituida por
características o estratos que le permiten distinguir los sujetos unos de otros”.

Según Monroy (2008), es la totalidad de los elementos que conforman el universo

de estudio. Es el conjunto de valores de una variable por el cual existe algún
interés.

47
Según Córdova (2003), se denomina población, a un conjunto de elementos (que
consiste de personas, objetos, etc.), que contienen una o más características
observables de naturaleza cualitativa o cuantitativa que se pueden medir en ellos.
A cada elemento de una población se denomina unidad elemental o unidad
estadística.

2.5. MUESTRA
Según Monroy (2008), Es una parte de una población. El tamaño
completo de una población aun siendo finita, puede ser demasiado grande o
también a veces no se puede estudiar toda, por cuestiones de costos y recursos.
Por eso es necesario o conveniente examinar sólo una fracción (muestra) de la
población.

Según Córdova (2003), se denomina muestra a una parte de la población

seleccionada de acuerdo con un plan o regla, con el fin de obtener información
acerca de la población de la cual proviene. La muestra debe ser seleccionada de
manera que sea representativa de la población. Un método de selección de
muestras representativas es al azar simple, esto es, cada elemento de la población
tiene la misma posibilidad de ser seleccionada para la muestra.

48
 CAPÍTULO III

METODOLOGÍA DE LA INVESTIGACIÓN

3.1. TIPO Y NIVEL DE INVESTIGACIÓN

3.1.1. TIPO DE INVESTIGACIÓN

En los estudios observacionales no existe intervención de ningún tipo por parte

del investigador, de manera que los datos observados y la información consignado
refleja la evolución natural de los eventos (Supo, 2012). Por esta consideración la
investigación es de tipo observacional.

Los estudios retrospectivos utilizan datos que se obtienen de registros

preexistentes, datos que provienen de mediciones en donde el investigador no
tuvo participación alguna. A este tipo de información se le suele llamar datos
secundarios (Supo, 2012). Por esta consideración la investigación es de tipo
retrospectivo.

En un estudio transversal todas las variables (incluyendo la variable de estudio)

son medidas en una sola ocasión bajo esta condición, si realizamos comparaciones
entre estas mediciones se les suele llamar entre muestras independientes, aunque
el nombre correcto sería entre grupos independientes (Supo, 2012). Por esta
consideración la investigación es de tipo transversal.

3.1.2. NIVEL DE INVESTIGACIÓN

Los estudios descriptivos buscan especificar las propiedades, las características y

los perfiles de personas, grupos, comunidades, procesos, objetos o cualquier otro
fenómeno que se someta a un análisis. Es decir, únicamente pretenden medir o
recoger información de manera independiente o conjunta sobre los conceptos o las
variables a las que se refieren, esto es, su objetivo no es indicar como se

49
relacionan estas (Hernández, et al, 2014). Por esta consideración el nivel de
investigación es Descriptiva.

3.1.3. DISEÑO DE LA INVESTIGACIÓN

Los diseños no experimentales son estudios que se realizan sin

manipular deliberadamente variables. Es decir, se trata de estudios en los que
no hacemos variar en forma intencional las variables independientes para ver su
efecto sobre otras variables. Lo que hacemos en la investigación no experimental
es observar fenómenos tal como se dan en su contexto natural, para analizarlos
(Hernández et al., 2014). Por tanto, el diseño de investigación es no
experimental.

Los diseños de investigación transversal recolectan datos en un solo

momento, en un tiempo único. Su propósito es describir variables y analizar su
incidencia e interrelación en un momento dado. Es como tomar una fotografía de
algo que sucede (Hernández et al., 2014). Por esta consideración la investigación
es transversal.

La investigación está enmarcada en el diseño no experimental, puesto

que el caso de estudio no amerita la manipulación de las variables. Asimismo, se
ha considerado el diseño transversal, ya que la recolección de datos se realizará
en un solo momento.

3.2. POBLACIÓN Y MUESTRA

3.2.1. POBLACIÓN
La población de estudio estará compuesta por todos los modelos de
gestión de desarrollo de software ágil.

3.2.2. MUESTRA
Se tomó los modelos de gestión de desarrollo de software ágil a Scrum y
Kanban.

50
3.3. VARIABLES E INDICADORES

3.3.1. DEFINICIÓN CONCEPTUAL DE LAS VARIABLES

VARIABLE DE ESTUDIO

Modelo de gestión de desarrollo de software ágil. Es una parte de la ingeniería

de software debido a que siempre está sujeta a restricciones organizacionales de
tiempo y presupuesto. Son un conjunto de actividades que abarca la planificación,
estimación de costos y tiempos, la gestión de personal y la gestión de riesgos.

INDICADORES DE LA VARIABLE

Scrum. Método ágil que ofrece un marco de referencia para la administración del
proyecto. Se centra alrededor de un conjunto de Sprints, que son periodos fijos
cuando se desarrolla un incremento de sistema. La planeación se basa en priorizar
un atraso de trabajo y seleccionar las tareas de importancia más alta para un
Sprint.

Kanban. Método para definir, gestionar y mejorar los servicios que entregan
trabajo de conocimiento, como servicios profesionales, creativos, de esfuerzos y
el diseño de productos físicos y de software.

VARIABLE ESTUDIO

Programación extrema. Es posiblemente el método ágil más conocido y

ampliamente utilizado debido al enfoque con la cual fue desarrollada utilizando
buenas prácticas reconocidas como el desarrollo iterativo, y con la participación
del cliente en niveles extremos.

INDICADORES DE LA VARIABLE

Software iterativo e incremental. Es la entrega de prototipos ejecutables en

periodos cortos de tiempo. Este enfoque permite aprovechar la retroalimentación
entre el cliente y el equipo de desarrolladores, por tanto, se incrementa la
funcionalidad del sistema de manera progresiva.

51
Software a través de las pruebas unitarias. Es el proceso de detectar errores en
cada uno de los módulos (métodos o clases) del software, independientemente del
resto de componentes, estas pruebas son ejecutadas por el programador.

Software a través de la re factorización del código. Consiste en simplificar y

optimizar el programa, a través del proceso del cambio en la estructura del código,
mejora de la calidad del código sin afectar su comportamiento externo del
programa.

Software a través de corrección de errores y código compartido. Cuando se

encuentra un error (“bug”), éste debe ser corregido inmediatamente y se deben
tener precauciones para que errores similares no vuelvan a ocurrir.
La propiedad colectiva del código tiene por objetivo que todos los miembros del
equipo conozcan “qué” y “cómo” se está desarrollando el sistema, evitando así, lo
que sucede en muchas empresas, que existen “programadores dueños de un
código” y cuando surge un problema, nadie más que él puede resolverlo, puesto
que el resto del equipo, desconoce cómo fue hecho y cuales han sido sus
requerimientos a lo largo del desarrollo.

3.3.2. DEFINICIÓN OPERACIONAL DE LAS VARIABLES DE

ESTUDIO

VARIABLE DE ESTUDIO
X: Modelo de gestión de desarrollo de software ágil.
INDICADORES
X1: Scrum.
X2: Kanban.

VARIABLE DE ESTUDIO
Y: Programación Extrema.
INDICADORES
Y1: Iterativo e incremental.
Y2: Pruebas unitarias continúas.

52
 Y3: Refactorización del código.
Y4: Corrección de errores y código compartido.

3.4. TÉCNICAS E INSTRUMENTOS PARA RECOLECTAR

INFORMACIÓN

3.4.1. TÉCNICAS
 Análisis documental.

3.4.2. INSTRUMENTOS
 Registro de ficha.

3.5. HERRAMIENTAS PARA EL TRATAMIENTO DE DATOS E

INFORMACIÓN

Son seleccionadas tomando en cuenta la ayuda que nos brindará en el tratamiento

de los datos e información obtenidos. Se ha seleccionado las tecnologías según la
tabla.
Tabla 5

Herramientas para el tratamiento de datos e información

SOFTWARE FABRICANTE SERVICIO

Windows 10 Microsoft Corporation Versión más reciente de este S.O.
Netbeans 8.2 Sun Microsystems Orientada a objetos, desarrollo de
software por módulos.
Mysql MySQL AB, Sun Sistema de gestión de bases de datos
Microsystems y Oracle relacionales de código abierto con un
Corporation modelo cliente-servidor.
Jira Atlassian Jira Software

3.6. PROPUESTA DE MODELO DE GESTIÓN EN FUNCIÓN A LAS

METODOLOGÍAS APLICADAS

ESTRATEGIA DE INTEGRACIÓN
Con el objetivo de brindar un conjunto de buenas prácticas que permitan a
las empresas gestionar de mejor forma sus procesos de desarrollo de software
basados en la combinación de las metodologías mencionadas anteriormente, se

53
plantea realizar un esquema de integración de las metodologías Scrum, Kanban y
Xp, basados en una matriz de cruce, en donde se detallan las prácticas de cada una
de las metodologías, con sus estándares, relaciones, etc.

Se consolidará las mejores prácticas de Xp que está más enfocado a las técnicas
de programación y pruebas del software, combinándolo con Scrum que está más
enfocado a las prácticas de gestión y organización y Kanban más enfocado en
gestionar de manera general como se van completando tareas y en la mejora
continua, adaptándose como la base de esta propuesta de modelo de gestión de
trabajo.

El cliente puede empezar antes a recuperar su inversión (y/o autofinanciarse)

comenzando a utilizar un producto al que sólo le faltan características poco
relevantes, puede sacar al mercado un producto antes que su competidor, puede
hacer frente a urgencias o nuevas peticiones de clientes, etc.” En base a estas
premisas se procede a generar un modelo de integración de las metodologías Xp,
Scrum y Kanban expresadas en las siguientes matrices:

54
Tabla 6

Modelo de integración de las metodologías Xp, Scrum y Kanban (Roles)

XP SCRUM KANBAN NOTA

Cliente Product Owner Service Request Manager Similares funciones
Encargado de
Scrum Master Service Delivery Manager Similares funciones
seguimiento
ROLES
Programador Scrum Team Similares funciones
Adoptado en esta propuesta de
Encargado de pruebas
modelo de gestión de trabajo ágil

55
Tabla 7

Modelo de integración de las metodologías Xp, Scrum y Kanban (Actividades y Procesos)

XP SCRUM KANBAN NOTA

Product Backlog (Pila del

Planeación Similares funciones
producto)
Concientización de la
metodología Complementar con el análisis de
Análisis
Sprint Planning requerimientos
ACTIVIDAD Y PROCESOS

Diseño
Diseño simple fácilmente entendible
Codificación Sprint Implementar priorizando que ayudará en la comunicación y
componentes con más desarrollo
dificultades
Pruebas
Pruebas unitarias Se adoptará en esta propuesta de
Implementar el resto de modelo de gestión de trabajo ágil
Pruebas de aceptación
componentes
Pruebas de integración
Scrum diario
Sprint Review Meeting
Revisión del Sistema Adoptar en esta propuesta de modelo
Retrospectiva Kanban de gestión de trabajo ágil
Re Release Planning
Meeting

56
Tabla 8

Modelo de integración de las metodologías Xp, Scrum y Kanban (Artefactos)

XP SCRUM KANBAN NOTA

Product Backlog (Pila del
ARTEFACTOS

Historias de usuario
producto)
Tarjetas CRC Sprint Backlog Combinadas unas con otras para
mejorar las especificaciones del
Task Cards
cliente
Burndown chart Tablero Kanban
Burn up chart Cartas Kanban

Tabla 9
Modelo de integración de las metodologías Xp, Scrum y Kanban (Valores)
XP SCRUM KANBAN NOTA
Transparencia
Comunicación Comunicación Colaboración
Entendimiento
Equilibrio
Retroalimentación Retroalimentación
Enfoque al cliente
VALORES Similitud conceptual
Sencillez Flujo
Valentía Responsabilidad
Liderazgo
Respeto Acuerdo
Respeto

57
Tabla 10

Modelo de integración de las metodologías Xp, Scrum y Kanban (Practicas)

XP SCRUM KANBAN NOTA

Cliente presente en todo el
Cliente in situ proceso
Visualizar el flujo de
Semana de 40 horas Iteración de 2 a 4 semanas trabajo
Metáfora Gestionar el flujo
PRACTICAS

Diseño simple Políticas explícitas

Re factoring Retroalimentación
Programación en parejas Eliminar interrupciones Combinar unas con otras para poder
Liberaciones cortas Liberaciones cortas mejorar pruebas, estandarizar código,
Pruebas etc.
Código estándar
Integración continua Integración continua
Propiedad colectiva
Juego de planificación

58
De esta manera la propuesta de modelo de gestión de trabajo ágil “XP + Scrum +
Kanban”, tendríamos una nueva matriz:

Tabla 11
Propuesta de modelo de gestión de trabajo ágil “XP + Scrum + Kanban” - Roles

Product Owner
Scrum Master
ROLES
Scrum Team
Encargado de pruebas

Tabla 12

Propuesta de modelo de gestión de trabajo ágil “XP + Scrum + Kanban” - Actividades y

Procesos

Planeación

Análisis Concientizar
nueva
ACTIVIDADES Y PROCESOS

metodología
Políticas explícitas Sprint
Diseño
Planning
Diseño simple

Codificación
Implementación
Sprint de todos los
Pruebas unitarias
componentes
Pruebas Pruebas de aceptación
Pruebas de integración
Scrum diario
Sprint Review Meeting Revisión del
Retrospectiva sistema
Re Release Planning Meeting

59
Tabla 13

Propuesta de modelo de gestión de trabajo ágil “XP + Scrum + Kanban” - Artefactos

Historias de
Product Backlog
ARTEFACTOS
Usuario
Tablero Kanban
Tarjetas CRC
Sprint Backlog
Task Cards
Burndown chart Cartas Kanban
Burn up chart

Tabla 14

Propuesta de modelo de gestión de trabajo ágil “XP + Scrum + Kanban” - Valores

Comunicación
Enfoque al cliente
VALORES Sencillez
Responsabilidad
Retroalimentación

Tabla 15

Propuesta de modelo de gestión de trabajo ágil “XP + Scrum + Kanban” - Prácticas Técnicas

Iteración de 2 a 4 semanas Limitar el WIP

Visualizar el flujo de trabajo
Liberaciones cortas
Programación en parejas
Re factoring
PRÁCTICAS TÉCNICAS Código estándar

Integración continua

Propiedad colectiva

60
Figura 10. Marco de trabajo “XP + Scrum + Kanban”

61
1. Juego de planificación
Se toman las características del sistema las cuales conformarán las historias de
usuario y también se definen los lanzamientos del proyecto. Durante la
planificación de la iteración, las historias de usuario son seleccionadas para la
iteración y se desglosan en tareas de desarrollo.

Se define el trabajo que se va a realizar en el proyecto, se especifican funciones

generales, es decir aquellas que tienen mayor importancia y pueden ser realizadas
en un periodo de tiempo fijo. Es usado como un plan del proyecto y una
estimación inicial de los requerimientos. Cuando un proyecto comienza es muy
difícil tener claro todos los requerimientos sobre el producto. Sin embargo, suelen
surgir los más importantes que casi siempre son más que suficientes para un
Sprint. La Product Backlog List puede crecer y modificarse a medida que se
obtiene más conocimiento acerca del producto y del cliente (dinámico). El
objetivo es asegurar que el producto definido al terminar la lista es el más
correcto, útil y competitivo posible y para esto la lista debe acompañar los
cambios en el entorno y el producto.

“Al comienzo de cada Sprint se hace la Reunión de Planificación del Sprint. Se

divide en dos reuniones”. (Deemer, Benefield, Larman, & Bas, 2009).

• Parte uno: ¿Qué vamos a hacer?

La meta de la primera parte de la reunión de planeación del Sprint es adquirir los

compromisos frente a las listas de requerimientos priorizadas estimando los
esfuerzos. El Propietario del producto presenta lo que le gustaría que el equipo
completara en el Sprint. Los miembros del equipo discuten sobre ellos con el
Propietario del producto y revisan los criterios de aceptación para asegurarse del
común entendimiento de lo que esperan. (Cifuentes Lozano, 2014). Visión y
expectativas del cliente con respecto a los objetivos y entregas del producto,
indicando los requerimientos funcionales y no funcionales, las tareas y los
posibles bugs. Todos los miembros del equipo, incluidos el ScrumMaster y el
propietario del producto, participan en reuniones de planificación de sprint.

62
El cliente será el responsable de crear y gestionar esta planificación, aunque
cualquier miembro del equipo puede agregar ítems. Esta lista contiene los
requisitos del cliente a nivel macro, que serán expresados en Historias de Usuario
en las que se indica el valor que cada requisito aportará al cliente.

Se recomienda registrar las mismas en un formato estándar que permitirá obtener

la información necesaria de cada requerimiento, con su prioridad, importancia,
estado. En el Anexo A se encuentra el modelo de Historia de Usuario que se usará
en este esquema de trabajo.

Antes del comienzo de cada sprint, se realiza una reunión de planificación para
determinar qué características se incluirán en el sprint, que es priorizada por el
propietario del producto. La primera vez que se produce esta reunión en un
proyecto, se crea la acumulación de productos. Puedes pensar en esto como sprint
0. Las historias de usuario elegidas por el propietario del producto para ser
incluidas en el sprint se dan al equipo y a través de una herramienta llamada
Planning Poker, se redimensionan para mostrar la complejidad de una historia
relacionada con las otras historias en grupo.

Planning Poker

Técnica ágil de estimación y planificación basada en el consenso. Para comenzar

una planificación de póker sesión, el propietario del producto o el cliente lee una
historia de usuario ágil o describe una característica a los estimadores. Cada
estimador tiene una baraja de cartas de Planning Poker con valores como 0, 1, 2,
3, 5, 8, 13, 20, 40 y 100. Los valores representan la cantidad de puntos de la
historia, días ideales u otras unidades en las que el equipo estima. Los estimadores
discuten la característica y hacen preguntas al propietario del producto según sea
necesario. Cuando la característica ha sido completamente discutida, cada
estimador selecciona en privado una tarjeta para representar su estimación. Todas
las cartas son entonces reveladas al mismo tiempo. Si todos los estimadores
seleccionaron el mismo valor, se convierte en la estimación. Si no, los
estimadores discuten sus estimaciones.

63
Los estimadores altos y bajos deben compartir especialmente sus razones.
Después de una discusión adicional, cada estimador vuelve a seleccionar una
tarjeta de estimación, y todas las tarjetas se revelan nuevamente al mismo tiempo.

El proceso de planificación del póker se repite hasta que se logre el consenso o

hasta que los estimadores decidan que ágil estimación y planificación de un
artículo en particular debe diferirse hasta que se pueda adquirir información
adicional. (Cohn, 2006).

La estimación grupal de las historias de los usuarios es una parte importante de la

programación extrema (XP), utilizada tanto para la planificación de lanzamientos
como para las iteraciones. La investigación ha demostrado que aunque la
estimación grupal en muchos casos es superior a la estimación individual, todavía
hay margen de mejora. Por ejemplo, el rendimiento de la estimación grupal se
puede reducir mediante personalidades dominantes y efectos de anclaje. A través
del análisis de 101 estimaciones de historias de usuarios, realizadas por un equipo
de XP para la planificación de lanzamientos, investigamos si la introducción del
proceso de estimación de póker de planificación mejoró la capacidad de
estimación del equipo. Los resultados muestran que la planificación del póker
mejoró el rendimiento de la estimación del equipo en la mayoría de los casos,
pero que aumentó el error de estimación en los casos extremos. (Haugen, 2006).

Se establecen los roles:

Product Owner

Persona responsable de asegurar que el equipo aporte valor al negocio. Representa

las partes interesadas internas y externas, por lo que debe comprender y apoyar las
necesidades de todos los usuarios en el negocio, así como también las necesidades
y el funcionamiento del equipo.

Scrum Master

Brinda ayuda a los equipos de desarrollo para resolver problemas que a estos se
les presente en el proceso de desarrollo.

64
Scrum Team

Equipo con un mínimo de integrantes, procurando un número par de miembros.

Encargado de Pruebas

Controla la marcha de las pruebas funcionales, de los errores reportados, de las

responsabilidades aceptadas y de las pruebas añadidas por los errores encontrados.

SprintBacklog

Documento donde se registra el detalle de los requerimientos a desarrollar en una

iteración. El cliente debe de estar presente en las reuniones en las que el equipo de
trabajo realice la Planificación del Sprint para posibles resoluciones de dudas en
las historias de usuario y llevar mejor el cumplimiento de estas.

2. Metáfora del sistema

Cuando se comunica con la empresa, es útil tener un lenguaje común entre
programadores y usuarios, para que los sistemas complejos se puedan explicar
fácilmente. Usar glosarios de términos y una correcta especificación de los
nombres de métodos y clases ayudará a comprender el diseño y facilitará sus
posteriores ampliaciones y la reutilización del código.

Parte dos ¿Cómo lo Vamos a hacer?

Los equipos comienzan a descomponer la lista de requerimientos seleccionados en

tareas, que para entregarlas deben estar completas. Las tareas pueden ser:
conseguir una entrada adicional del usuario, diseñar una nueva pantalla, adicionar
nuevas columnas a la base de datos, etc. En esta parte se definen las tareas
necesarias para complementar cada objetivo o requisito creando la lista de tareas
de la iteración (Sprint Backlog) basándose en la definición de Hecho (Cifuentes
Lozano, 2014).

Una vez que las historias de usuario son dimensionadas, se convierten en una serie
de tareas por el equipo y una estimación de tiempo sobre cuánto tiempo tomará
cada tarea. Una vez hecho todo esto, el equipo examinará la lista completa de
trabajos enviados para el sprint y decida si pueden comprometerse a completar el

65
trabajo al final del sprint. Para decidir esto, el equipo vota con cinco dedos para
evaluar las opiniones de los miembros individuales.

Un miembro del equipo simplemente levanta la mano y, a través de la cantidad de

dedos que sostiene, muestra lo que mejor refleja su nivel de confianza. Un valor
manual de "1" significa que el miembro del equipo está Muy dudoso de la
propuesta. Un valor manual de "5" significa que el miembro del equipo tiene
mucha confianza en la propuesta. Si nadie tiene un valor de "1" o "2", entonces el
equipo se compromete a ese trabajo para el sprint. Si se muestra un valor de "1" o
"2", entonces el equipo discute por qué ese miembro del equipo votó de esta
manera y ajusta la propuesta en consecuencia.

Una vez que el equipo se compromete a entregar la lista de historias de usuarios y

tareas dentro del sprint, el ScrumMaster promulga una congelación de cambios
para permitir que el equipo desarrolle la historia del usuario como se escribió
anteriormente. Un backlog de Sprint está compuesto por todas las historias de
usuarios y tareas requeridas para completar el sprint.

En esta actividad se realizan las siguientes sub actividades:

• Detallar las Tareas: Descomposición de la lista de requerimientos

priorizados que tienen una duración de entre 4 y 16 horas.

• Determinar responsabilidades: Cada tarea debe tener un responsable que

es un miembro del equipo.

• Identificar los riesgos: Determinar aquellos requerimientos que pueden

llegar a tener problemas.

• Estimación del tiempo de cada miembro del equipo: Aquí se determina

el tiempo o día laboral que tiene cada uno de los miembros del equipo
descontando el tiempo que pasa en reuniones, leyendo los correos,
comiendo y otras posibles actividades laborales que no tengan que ver
explícitamente con el desarrollo. Generalmente esto significa un tiempo
promedio de entre 4 y 6 horas de tiempo disponible al día para el trabajo
relacionado con el correspondiente Sprint.

66
• Tablero de tareas – Task Board: Es un tablero en el que se puede
distinguir 3 columnas la primera está determinada por lo que hay que
hacer, lo que se está haciendo, y por último lo que está hecho, el propósito
es el de tener una idea del estado en el que se encuentran las tareas
asociadas a un determinado Sprint. Es de mucha importancia para los
equipos, ya que este tablero permite mantener informado a todo el equipo
de los avances en las labores, por lo que es importante que cada miembro
del equipo reporte sus avances diariamente.

• Figura de Producto – Burn Up Chart: Es una de las herramientas de

planificación que es más usada por el propietario del proyecto. En esta se
visualizará el proceso evolutivo del proyecto o producto, ya que muestra
en el tiempo como se va construyendo el producto, todo esto en base a la
velocidad que mantenga el equipo de trabajo. Este Gráfico representa el
plan del producto, es decir permite que el Dueño del Producto vea la
evolución de su requerimiento de una forma general en cada Sprint. Este
gráfico es responsabilidad del Dueño del Producto, tanto en su confección
como en su mantenimiento. Tanto el equipo de trabajo como el Scrum
Master deben tener conocimiento de esta gráfica, para poder solicitar
aclaraciones sobre dudas que puedan presentarse durante el desarrollo del
mismo.

Permite conocer al Product Owner las versiones previstas, las

funcionalidades de cada una, velocidad estimada, fechas previstas, margen
error y velocidad real. (Palacio, 2007).

67
 Figura 11. Burn Up Chart. (Palacio, 2007)

Tarjetas CRC (Clase Responsabilidad Colaboración)

Se propone a la creación de una tarjeta CRC por cada una de las clases que se
presentan en el proyecto mencionando sus responsabilidades en la parte izquierda
de la tarjeta y en la parte derecha la lista de los colaboradores de la clase. Esto
ayuda a los miembros del equipo de desarrollo a tener un mayor grado de
entendimiento al momento de desarrollar las tareas asignadas. En el Anexo B se
tiene una plantilla de las tarjetas CRC.

El formato físico de las tarjetas CRC facilita la interacción entre los stakeholders,
en sesiones en las que se aplican técnicas de grupo como tormenta de ideas o
juego de roles, y se ejecutan escenarios a partir de especificación de requisitos,
historias de usuario o casos de uso. De esta forma, van surgiendo las entidades del
sistema junto con sus responsabilidades y colaboraciones. Luego en un estadío de
diseño avanzado o ya en la implementación del sistema, las tarjetas CRC se
convierten en clases con métodos, atributos, relaciones de herencia, composición
o dependencia. (Casas & Reinaga, 2009).

68
Valor: Responsabilidad

Empoderar a cada miembro del equipo de su trabajo y terminar las tareas de forma
adecuada con la calidad así como en el tiempo estimado por el mismo miembro.

3. Diseño simple
El diseño del sistema de alto nivel ocurre al inicio y durante una iteración.
Una vez que finaliza la reunión de planificación, el equipo se reunirá sin el dueño
del producto para discutir el diseño de alto nivel del sistema.

Usaremos las Tareas de ingeniería para determinar las tareas que cada uno de los
miembros del equipo deben trabajar, así como para poder tener un control de que
es lo que cada quien debe hacer, estas tarjetas se representan mediante una forma
gráfica, misma que sirve también en las reuniones diarias en el tablero de tareas.
El modelo usado se aprecia en el Anexo C.

Un diseño simple se implementa más rápidamente que uno complejo. Por ello XP
propone implementar el diseño más simple posible que funcione. Se sugiere nunca
adelantar la implementación de funcionalidades que no correspondan a la
iteración en la que se esté trabajando. (Joskowicz, 2008).

Valor: Sencillez – Simplicidad

Tareas sencillas. Pero en el transcurso del desarrollo del proyecto hay tareas que
no pueden ser ejecutadas en esos términos, por lo tanto fueron divididas en
iteraciones hasta que se reduzca su nivel de complejidad.

Tablero Kanban

Es una gran herramienta de ayuda que sirve para mejorar la eficiencia del flujo de
trabajo porque visualiza todas las tareas en un proceso de trabajo y proporciona
una transparencia general de la organización, permitiendo a los equipos tener una
clara visión de todos los elementos de trabajo y controlarlos a través de las
diferentes etapas de su flujo de trabajo.

En Scrum los tableros se van a resetear al final de cada Sprint, es decir, conforme
vamos finalizando el mismo, el tablero queda vacío y comenzamos de nuevo

69
añadir nueva nuevas historias de usuario, las siguientes en prioridad. En Kanban,
como vamos a tener un flujo de entrada-salida, conforme las tarjetas van pasando
por cada uno de los estados hasta llegar al estado final, cuando llegan a ese estado
salen del tablero y se archivan, vamos a tener un flujo continuo.

Cartas Kanban

Se usó post it el cual ayudó en la identificación de las tareas que estaban por
hacer, las que se están haciendo y las que ya se hicieron.

Valor: Visualizar el flujo de trabajo

La visualización de todas las tareas y elementos de la tabla contribuyó a que todos

los miembros del equipo se mantengan al corriente con su trabajo.

4. Cliente en el sitio
Durante una iteración, es ideal que el cliente esté en el sitio para ayudar a
responder rápidamente los detalles de una historia de usuario. Mientras las
reuniones físicas son ideales, las reuniones virtuales son mejores que ninguna
reunión. El punto importante es tener un cliente disponible que pueda
proporcionar respuestas rápidamente a medida que los desarrolladores exploran
los detalles de una historia de usuario.
La colaboración con el cliente más que la negociación de un contrato. Las
características particulares del desarrollo de software hacen que muchos proyectos
hayan fracasado por intentar cumplir unos plazos y unos costes preestablecidos al
inicio del mismo, según los requisitos que el cliente manifestaba en ese momento.
Por ello, se propone que exista una interacción constante entre el cliente y el
equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha
del proyecto y asegure su éxito. (Letelier & Penadés, 2006).

Valor: Enfoque al cliente

El proyecto tiene mayor fluidez y la satisfacción del cliente cuando reciben un

producto o servicio exigido. Los clientes en este contexto son externos al servicio,
pero pueden ser internos o externos a la organización en su conjunto. Los clientes
y el valor que reciben es el punto de atención natural.

70
5. Equipo sentados juntos
Es importante para todo el equipo comprometido con el proyecto, debiendo
estar dentro de la distancia en donde podrían “comunicarse” de gritos el uno al
otro. Esto mejora la comunicación e imparte un sentimiento de camaradería.

“Entorno físico debe ser un ambiente que permita la comunicación y colaboración

entre todos los miembros del equipo durante todo el tiempo, cualquier resistencia
del cliente o del equipo de desarrollo hacia las prácticas y principios puede llevar
el proceso al fracaso (el clima de trabajo, la colaboración y la relación contractual
son claves), el uso de tecnologías que no tengan un ciclo rápido de realimentación
o que no soporten fácilmente el cambio, etc.” (Letelier & Penadés, Repositorio
institucional de la Universidad de Las Tunas, 2012).

Sentarse juntos es esencial para una programación de pareja efectiva, quizás en un

nivel más fundamental, es esencial reunir al equipo junto con los clientes para una
comunicación fácil y efectiva, sentarse juntos aumenta la comprensión compartida
del equipo y ayuda a construir el espíritu de equipo, que es crucial al
comprometerse como equipo para un proyecto. Crear espíritu de equipo es
importante porque, con el tiempo, las relaciones comienzan a formarse con los
miembros del equipo. Las buenas relaciones y el espíritu de equipo realmente
aumentan la productividad. Todas las tareas son manejadas por el equipo en lugar
de "arrojado por la pared" a alguien que no conoces, una gran parte del
vocabulario personal está en el lenguaje corporal, y esto solo se puede notar al
sentarse juntos.

Valor: Comunicación

Aplicado desde la creación de la lista priorizada de requisitos que se realiza con el

cliente, así como en las reuniones de re planificación y en las estimaciones de
esfuerzos en el trabajo durante las reuniones de planificación, las reuniones diarias
y retrospectivas. Es muy importante mantener a los equipos juntos en un mismo
espacio físico para que se maximice la comunicación frente a frente.

71
BurnDown Chart

Este gráfico es usado en las iteraciones para determinar la velocidad de trabajo del
equipo, así como para conocer si existen retrasos en el proyecto, además es usado
en las reuniones con el cliente para explicaciones de avances en los trabajos.

El Scrum Master debe estar en constante supervisión de los avances o retrasos en

el proyecto y el Equipo de trabajo es responsable de la actualización diaria de las
tareas para que se vea reflejado en gráfico el estado a la fecha del desarrollo de la
iteración.

Scrum Diario

Es una reunión que se realiza aproximadamente por un periodo de 15 minutos

diariamente con el objetivo de hacer un resumen de las actualizaciones, y
coordinaciones entre los miembros del equipo. En estas reuniones existen 3
preguntas fundamentales que son ¿Qué se hizo ayer?, ¿Qué se va a hacer hoy?,
¿Se tiene algún impedimento? Con lo que cada miembro del equipo está al tanto
del avance del proyecto y se pueden sacar a conocimiento si existen impedimentos
que interrumpan el normal desarrollo de las actividades.

Se realiza el análisis del gráfico de Burn-Down y del Tablero Kanban, para lo cual
todos los miembros del equipo anticipadamente deben haber actualizado sus
tareas, usando las Cartas Kanban.

Como buena práctica la reunión se realiza de pie de preferencia junto al tablero en

el cual se encuentren todas las tareas/actividades del equipo, este tablero puede ser
una pizarra/pared libre en la que se encuentren escritas o puestas las Cartas
Kanban, se sugiere mantener una buena organización y actualización del gráfico y
tablero de avance.

6. Programación en pareja

La programación en pareja es una práctica de desarrollo que empareja

desarrolladores para que puedan trabajar juntos en un problema. Un par
compartirá una máquina de desarrollo, y mientras uno codifica, el otro ayudará
con el diseño decisiones y mirar hacia la próxima característica. Con

72
programación en pares, el código y las revisiones se convierten en "tiempo real",
produciendo un nivel de calidad que deja de ser "solo de inspección". Con dos
personas en desarrollo, es muy poco probable que ambos pasar por alto el mismo
error.

Colaboración continúa y aprendizaje de los miembros del equipo que se integran

en etapas posteriores del proyecto, así como colaboradores en la calidad de los
productos.

Otra ventaja adicional en el mundo de la empresa de tener dos programadores

realizando tareas conjuntamente es por la alta movilidad laboral. Es bien sabido,
que muchos proyectos pierden un tiempo valiosísimo cuando uno de los
integrantes del equipo deja el trabajo (una situación que, por cierto, se ha dado
con una pasmosa frecuencia en los últimos tiempos). La programación por parejas
intenta mitigar este efecto, ya que de los dos programadores se quedará uno que
tendrá el conocimiento suficiente sobre lo que estaba haciendo la pareja como
para poder seguir adelante. Sin embargo, también en este caso, las condiciones
que se dan en el desarrollo de software libre hacen que esto no sea tan
problemático. (Robles & Ferrer, 2002).

7. Limitar el WIP

Restringir la cantidad máxima de elementos de trabajo en las diferentes etapas

(columnas del tablero Kanban) del flujo de trabajo. La implementación de los
límites de WIP ayudó al equipo a enfocarse solo en las tareas actuales y así le
permitió terminar más rápido con los elementos de trabajo individuales.

Debemos tener en cuenta que limitar el WIP no se aplica solo a la fase de

desarrollo, sino que también las fases previas de definición y análisis de tareas
deben tener un cierto límite WIP. En la gestión ágil de proyectos la clave es
experimentar empíricamente e iterar para mejorar decisiones tomadas con
anterioridad. Así que lo que vamos a hacer será limitar el WIP en un número no
demasiado pequeño al principio. Al inicio de la adopción del Kanban en el
equipo, es importante empezar con un límite de WIP suficientemente cómodo
para que no sea demasiado traumático al principio. La mejor opción es optar por

73
un límite alto e irlo bajando a cada dos o tres semanas hasta encontrar el
equilibrio. (Bermejo, 2011).

8. Propiedad del código colectivo

A través de la programación en pareja, todo el equipo comparte una

propiedad colectiva de la base del código. Todos los desarrolladores pueden
arreglar y trabajar en cualquier parte de la base del código.

Gracias a XP todos tienen responsabilidad sobre todo el código del sistema. El

código creado es propiedad del equipo completo, no de uno de los desarrolladores
específicos, promoviendo a que el equipo entero trabaje mucho más junto,
buscando producir diseños, códigos y casos de test de alta calidad.

De esta forma todos pueden conocer lo que se está realizando así como obtener
ayuda de cosas que otra persona haya creado y que sirva como referencia.

La propiedad del código compartida promueve que todo el personal pueda

involucrarse para corregir y ampliar cualquier parte del código, además, todo lo
anterior en conjunto con las pruebas frecuentes garantizan que los errores sean
detectados de manera temprana. (Balza, Briceño, Lobo, & Nuñez, 2017).

9. Normas de codificación

Para ayudar con la propiedad colectiva, se utilizan las mejores prácticas para
mantener un diseño simple y garantizar que todo el código se cree de manera
coherente.

Esto asegura que el código fuente se pueda entender rápidamente cuando se

trabaja en cualquier parte del sistema y con cualquier otro desarrollador.

Nombres de variables nemotécnicos con el fin de saber el tipo de cada variable

solo con ver el mismo. Nombres de Variables Sugestivos, para saber de forma
natural el uso y finalidad de las mismas.

Para que estas cosas no pasen y tu código siempre esté a la altura, debemos seguir
siempre un estándar de codificación o Code Standard en inglés. Los estándares de
código, son parte de las llamadas buenas practicas o mejores prácticas, estas son

74
un conjunto no formal de reglas, que han ido surgiendo en las distintas
comunidades de desarrolladores con el paso del tiempo y las cuales, bien
aplicadas pueden incrementar la calidad de tu código, notablemente. Entendemos
como estándar de código a un conjunto de convenciones establecidas de ante
mano (denominaciones, formatos, etc.) para la escritura de código. Estos
estándares varían dependiendo del lenguaje de programación elegido y además
varían en cobertura, algunos son más extensos que otros. (ohmyroot!, 2017).

Por ejemplo:

 strUsuario (str = variable de tipo string + Nombre Descriptivo de la

variable)
 intIdUsuario (int = variable de tipo entero + Nombre Descriptivo de la
variable)

10. Pruebas

Para garantizar que la calidad se entrega al cliente, se hace hincapié en prueba

a través del proceso XP. Las pruebas comienzan identificando los criterios de
aceptación de historias de usuarios. Estos criterios de aceptación se utilizan para
escribir pruebas unitarias e iniciar en estilo Desarrollo basado en Pruebas. La
prueba de aceptación del usuario también se deriva de criterios de aceptación y se
automatizará tanto como sea posible.

Se aplicó la técnica del semáforo en la que si la prueba da rojo aún no ha pasado

la misma, verde significa re factoring, es decir primero escribimos la prueba,
probamos, falla, luego escribimos el código necesario para que funcione y se
procede a comprobar si existe algo que se pueda mejorar o re factorizar.

Al terminar las codificaciones y funcionalidades, se realizan pruebas de

aceptación a través del personal asignado con la supervisión, para esto se procedió
a la utilización de casos de pruebas, en estos, se indicó las funcionalidades que
debía cumplir la aplicación, áreas a las que pertenecen las pruebas y los resultados
obtenidos. Pudiéndose encontrar varios errores y afinamientos que serán
reportados a los miembros del equipo de desarrollo a través de los casos de prueba

75
y actualizando en el tablero pero identificando a las tareas como bug, o
afinamientos, luego en las reuniones diarias se procedieron a revisar estas y se
discutió la prioridad para la terminación del Sprint, si estas eran demasiado
críticas se procedía a su corrección caso contrario se las pasaba para ser atendidas
en las próximas iteraciones.

Re factoring

Tenemos un código mucho más limpio y optimizado removiéndose código

innecesario, comentado para otros programadores.

Las refactorizaciones son ampliamente reconocidas como formas de mejorar la

estructura interna del software orientado a objetos mientras se mantiene su
comportamiento externo. (Du Bois, Demeyer, & Verelst, 2004).

Una buena práctica para el re factoring es: La primera vez que hacemos algo, lo
hacemos, la segunda vez igual lo haremos pero notaremos que estamos
duplicando código y la tercera vez que hagamos lo mismo, se re factoriza.

11. Integración continua

Para garantizar que todo el código realmente funciona, el equipo se integra a

menudo y temprano. Un servidor de integración continua (CI) extraerá la base de
código de un control de origen, lo compilará y ejecutará todas las pruebas
automatizadas para garantizar que la compilación este correcta. La salida del
servidor CI se puede notificar instantáneamente a desarrolladores, clientes y
gerentes de proyecto. Este informe incluye: El número de pruebas aprobadas /
reprobadas en este punto. El seguimiento diario proporciona un Indicador de
progreso en la creación de valor para el cliente. Este bucle de retroalimentación
rápida también permite a los desarrolladores arreglar la compilación. Cuanto antes
se identifique un problema, es más barato arreglarlo.

El proceso de integración de componentes que se requiere en los proyectos no es

una tarea simple. La integración de software es un problema complejo sobre todo
en sistemas que involucran código desarrollado por diferentes personas, por esta
razón es necesario contar con un entorno que garantice la adecuada integración de

76
las partes de un proyecto y posibilite visualizar los resultados de la integración de
una manera fácil y clara. En este marco la Integración Continua ofrece un
esquema que permite realizar integraciones a medida que se lleva a cabo el
desarrollo generando incrementos pequeños y mostrando los resultados obtenidos.
(Salamon, y otros, 2014).

Se hace una comprobación continua del código para poder integrar poco a poco
las mejoras o ir actualizando a diario para obtener un resultado mucho más fiable
y en un periodo menor de tiempo, garantizando resultados de calidad y un
funcionamiento correcto del proyecto gracias a su continua supervisión y a la
reducción de errores.

Incrementos del producto

Al final de cada Sprint, el equipo de desarrollo es responsable de presentar un

incremento de producto potencialmente entregable. El Incremento es la suma de
todos los elementos de la Lista de Producto completados durante una iteración y
el valor de los incrementos de todas las iteraciones anteriores.

En Scrum es necesario que los equipos construyan o productos en incrementos

cuya funcionalidad sea potencialmente entregable, lo que significa que debe estar
“Hecho”.

El corazón de Scrum es un Sprint, es un intervalo prefijado durante el cual se crea

un incremento de producto "Hecho o Terminado" utilizable, potencialmente
entregable.

12. Ritmo sostenible

Debido a los cortos ciclos de liberación y la naturaleza iterativa de XP,

recopilación de requisitos, diseño, desarrollo, pruebas e implementación de todo,
sucede a menudo. Esto significa que los problemas encontrados después de la
revisión y las pruebas pueden ser incorporados en la próxima iteración. Este
modelo de retroalimentación rápida asegura que los desarrolladores pueden
trabajar a un ritmo sostenible. Por lo tanto, ahorran largas semanas en
comparación con las metodologías de desarrollo más tradicionales que tienen

77
claramente etapas definidas para el ciclo de vida del desarrollo, dejando
comentarios y pruebas hasta el final. El ritmo sostenible también ayuda a la
gerencia a planificar más eficientemente las vacaciones del personal, ausencias no
planificadas y ocasionales "incendios" de producción que necesita ser extinguido
inmediatamente.

La metodología XP indica que debe llevarse un ritmo sostenido de trabajo.

Anteriormente, ésta práctica se denominaba “Semana de 40 horas”. Sin embargo,
lo importante no es si se trabajan, 35, 40 o 42 horas por semana. El concepto que
se desea establecer con esta práctica es el de planificar el trabajo de manera de
mantener un ritmo constante y razonable, sin sobrecargar al equipo. (Rosas,
2017).

Sprint

Procedimiento de adaptación de las cambiantes variables del entorno

(requerimientos, tiempo, recursos, conocimiento, tecnología). Son ciclos iterativos
en los cuales se desarrolla o mejora una funcionalidad para producir nuevos
incrementos. Durante un Sprint el producto es diseñado, codificado y probado. Y
su arquitectura y diseño evolucionan durante el desarrollo. El objetivo de un
Sprint debe ser expresado en pocas palabras para que sea fácil de recordar y esté
siempre presente en el equipo.

Las actividades que se desarrollan durante del Sprint son: Sprint Planning
Meeting, Sprint Backlog, Daily Scrum Meetings y Sprint Review Meeting.

Dar la información y conocimiento suficiente al equipo de trabajo para que este

pueda comenzar a trabajar en la iteración que se plantea, además de dar al dueño
del producto la confianza de que tendrá un avance significativo de su producto, a
través de entregables continuos. En este marco de trabajo la meta de cada Sprint
se concentrará en hacer algo que no se haya hecho aún, algo que no se haya
logrado de forma que no se pierda el rumbo del camino global que es la
terminación y entrega de un proyecto final.

78
Con cada equipo se revisa las historias de usuario y tareas que se pretende realizar
para finalizar esta iteración, decidan en qué tarea trabajar y estimen el tiempo que
les llevará, así garantizar el compromiso y responsabilidad.

Se procede a la codificación de las tareas, es decir al desarrollo en sí. Con esta

propuesta de modelo de gestión de trabajo, los equipos de trabajo deben ser auto
organizados, puedan tomar decisiones oportunas al momento que algún
requerimiento generé dudas o problemas.

Durante el desarrollo de las tareas deben pasar por las pruebas unitarias de
software, se procede a definir las pruebas (casos de pruebas) y una vez estén listas
se procederá a desarrollar código para que la funcionalidad pase estas pruebas. La
forma del procedimiento es la siguiente:

 Coger un determinado requerimiento o tarea, ya bien definida.

 Escribir el código para las pruebas que este requerimiento necesite.
 Desarrollar el código o funcionalidad que pase o apruebe el caso de
prueba.
 El Tester y el programador verifican el éxito o fracaso del caso de prueba
y a continuación se los marca, surgiendo nuevos casos de pruebas y
afinamientos.
 Refactorización del código existente para pasar casos de pruebas
adicionales.

De esta manera el requerimiento cumple con las expectativas y criterios de

aceptación del cliente final. Una vez se tiene una cantidad de funcionalidad
adecuada, se procede a realizar pruebas de integración para corrección y
refactorización de código y por ultimo con la ayuda del Tester se trabajará en las
pruebas de aceptación del Cliente.

Release Planning Meeting (Reunión de Entrega)

Se establece el plan y los objetivos de la entrega, además de decir la estrategia que

el equipo Scrum y el resto de la organización van a seguir. Esta reunión se trata de
contestar las siguientes preguntas:

79
• ¿Cómo podemos transformar el objetivo en un producto de calidad de la mejor
manera posible?

• ¿Cómo podemos dejar al cliente satisfecho y conseguir un buen retorno de la

inversión?

También se define el incremento específico del producto que se entregará, lo cual

involucra la identificación y compromiso de la meta a lograr con la entrega, el
conjunto de historias que serán desarrolladas y la estimación de cada una de ellas
junto con su fecha de entrega. Esta reunión no es obligatoria.

Re Release Planning Meeting

Reunión con el cliente para revisar y replantear las prioridades del proyecto.

El problema de planificación de lanzamiento (RP) puede investigarse desde dos

dimensiones: qué liberar y cuándo liberar. Investigamos la decisión de "qué"
publicar en términos de qué nuevas características o solicitudes de cambio deben
asignarse e implementarse en qué versiones de un sistema de software. El RP para
sistemas en evolución es un desafío, porque las nuevas características pueden
requerir cambios en el sistema existente. Una desventaja importante de los
métodos de RP existentes es que no consideran los sistemas existentes al tomar
decisiones de RP. (Saliu & Ruhe, 2007).

Planificación de la siguiente iteración

Se analizó el cambio potencial del Product Backlog en base a las observaciones

que los involucrados tuvieron en la reunión de demo.

Sprint Review Meeting

El Sprint Review es uno de los cinco eventos de Scrum, y ocurre en el final del
Sprint, para inspeccionar el incremento y adaptar el Product Backlog en caso de
que sea necesario. Es una gran oportunidad para poder recibir feedback sobre el
desarrollo del producto. El objetivo principal del Sprint Review es brindar
transparencia tanto al equipo como al cliente.

80
Tiene una duración de 4 horas para Sprints de 4 semanas. Para Sprints más cortos,
esta reunión tenderá a ser más corta. Este evento es organizado por el Product
Owner, y es necesaria la presencia de todo el equipo de Scrum. El rol del Scrum
Master es asegurar que el evento ocurre y que cumple los tiempos establecidos,
además de asegurar una colaboración de todo el equipo.

El Product Owner explica qué ítems del Product Backlog han sido finalizados, y
cuáles no. Es importante tener en cuenta que se debe de ir actualizando el Tablero.

En esta reunión se realizan las siguientes actividades:

• Presentación del incremento comprometido (Demo)

• Revisión de las tareas que no se cumplieron en el Sprint

• Inclusión y revisión de cambios.

Retrospectiva

Esta reunión se realiza al finalizar cada Sprint y una vez realizada el Sprint review
meeting, en esta, el equipo de trabajo, trabaja en el análisis de cómo se realizó el
trabajo durante la última iteración, se describe lo que se realizó bien, lo que fallo
en el mismo y como pueden mejorar para la próxima iteración.

El enfoque de Scrum está dado para construir con calidad, los procedimientos que
respetan la calidad son aquellos que son entendidos, mejorados y conocidos por el
equipo de trabajo.

Aunque es frecuente realizarlas al final de cada sprint, no deben confundirse con

las reuniones de revisión del sprint.

En esta reunión se hace un recuento de todo lo que se realizó en la iteración

terminada, analizando por qué se está consiguiendo o no los objetivos planteados.
Obteniéndose un plan de acciones de mejora y un acuerdo de equipo actualizados.

Última ceremonia de un Sprint. Oportunidad para el equipo de inspeccionarse a sí

mismo, y crear un plan de mejora para el siguiente Sprint. (Tesei, Cabrera,
Vaquero, & Tedini, 2019),

81
13. Pequeños lanzamientos

XP tiene que ver con la satisfacción del cliente y la entrega de negocios de

valor a través de software de calidad. En lo que respecta al negocio, cuanto más a
menudo esto puede suceder, mejor. XP promueve lanzamientos frecuentes, que
pueden ser relativamente pequeños, pero destaca las características priorizadas por
el negocio. XP no permite que el equipo de desarrollo se oculte durante meses,
esperando que el proyecto se complete a tiempo. Esta transparencia de frecuente
lanzamientos alienta a los clientes mostrándoles que el equipo está agregando
valor al proyecto a lo largo del camino.

Así el cliente puede ver y tener versiones listas para trabajar de los productos que
él requiera.

Por lo tanto, partiendo de todas las características aquí expuestas, se puede definir
una metodología ágil, como aquella que busca y prioriza la satisfacción del cliente
a través frecuentes y pequeños evaluables de software, facilitando de esta manera,
una comunicación fluida entre todos los participantes (indiferentemente del rol
que jueguen) implicados en el desarrollo del proyecto; además de un mejor y
mayor control en la calidad del software elaborado. Como anteriormente se ha
comentado, las metodologías ágiles priorizan las entregas y/o animan a realizar
pequeños entregables de manera que haya una evaluación continua y constante.
En SCRUM estas entregas se controlan a través de iteraciones llamadas sprints.
(Moré Martín, 2011).

82
 CAPÍTULO IV

ANÁLISIS Y RESULTADOS DE LA INVESTIGACIÓN

4.1. ANÁLISIS DE FACTIBILIDAD DE IMPLEMENTACIÓN DE LA

METODOLOGÍA

Estudio de factibilidad para la aplicación de la metodología

Para la implementación de esta propuesta de marco de trabajo híbrido de
desarrollo de software, es importante un análisis de factibilidad de su uso y
aplicación, para lo cual primero se procede a hacer una encuesta, misma que
permitirá obtener información básica de lo que se requiere en la institución para
proceder a aplicar esta propuesta de marco de desarrollo ágil.

Para evaluar el estado de adaptación de la institución a una metodología híbrida

ágil se ha procedido de la siguiente manera:

Se realizan preguntas referentes a diversos procesos como manejo de personal,

métricas, trabajo con pruebas, jerarquías y estructuras de la institución, se
proponen con respuestas del tipo cerrado, bajo la siguiente tabla de puntajes:

Tabla 16

Valoración de tabla de puntajes de la encuesta

RESPUESTA PUNTAJE

Generalmente no se utiliza o se usa en < 40 puntos

situaciones concretas

Se usa en la mayor parte de situaciones 40 – 60 puntos

Usada en casi todas las áreas 60 – 85 puntos

Usada de forma total > 85 puntos

83
Valoración menor de 40 puntos: Deben tomarse medidas correctoras para
implantar un sistema de gestión de desarrollo eficaz tradicional o ágil.

Entre 40 y 60 puntos: El sistema de gestión de desarrollo se cumple, pero con

deficiencias.

Entre 60 y 85 puntos: El sistema de gestión de desarrollo se cumple, con leves

deficiencias.

Más de 85 puntos: Su empresa gestiona de manera correcta en cuanto a políticas

de calidad y gestión de desarrollo de productos de software, es apta para aplicar
metodologías de desarrollo ágil.

Se recomienda la aplicación de esta metodología a partir de aquellas instituciones

o empresas con puntuación sobre los 70 puntos, ya que es posible mediante
disciplina lograr una adaptabilidad y mejora en el proceso de gestión de
desarrollo. En el Anexo D se encuentra el modelo de la encuesta.

4.2. CONFORMACIÓN DEL EQUIPO

Se cambia los equipos de desarrollo en metodologías tradicionales pues poseen

estructuras de mando o jerárquicas bien definidas en las que los roles están
dedicados a realizar su trabajo o tarea especializada sin ir más allá.

Por lo tanto en esta propuesta de marco de trabajo son equipos auto- organizados,
con un alto nivel de alineamiento y empoderamiento en cuanto al proyecto en el
que se trabaja, con lo que se logra tener alta flexibilidad, disciplina y
responsabilidad por parte de cada miembro. Estos equipos ágiles son capaces de
participar y tomar decisiones en igualdad de condiciones empoderándose del
proyecto, si bien existe al igual que en otras metodologías una jerarquía se tratará
de que todos se sientan dueños del proyecto.

El equipo para esta propuesta de modelo de gestión de trabajo ágil estará

conformado por miembros que se motiven y tengan un real interés por trabajar
dentro de un grupo de profesionales que tienen en mente ayudarse mutuamente,
mismos que deberán tener múltiples habilidades técnicas tanto de programación

84
como habilidades para comunicarse con el resto de sus compañeros como con los
mismos usuarios.

4.3. CAPACITACIÓN

Al tratarse de una propuesta de marco de trabajo se debe realizar una capacitación

total, es decir:

 Introducción breve a metodologías ágiles

 Resumen del Manifiesto Ágil
 Resumen de Metodología XP
 Resumen de Metodología Scrum
 Resumen de Metodología Kanban
 Introducción a la propuesta de modelo de marco de trabajo ágil
 Roles
 Actividades
 Artefactos
 Valores
 Prácticas y Técnicas

4.4. DESARROLLO DE LA METODOLOGÍA

4.4.1. JUEGO DE PLANIFICACIÓN
Se procedió a realizar una reunión en la que se conversó con el Cliente, quien
entregó al equipo de desarrollo la lista de requerimientos y funcionalidades del
proyecto y priorizando los requerimientos para la iteración. Se resolvieron las
dudas junto con el cliente, en aquellas funciones más importantes. Se hizo el
compromiso de los integrantes del equipo con la realización del proyecto, se
establecen los roles.

85
Se procede a construir el Product Backlog de la siguiente manera

Debe permitir Debe mostrar el Debe permitir

registrar a todo el logo de la mover al personal
personal de la institución. modificar sus datos.
institución.

Debe poder registrar Debe poder cambiar el Debe permitir

todo el equipo, equipo, inventario, de la
generar reportes de
institución, en cuanto a
inventario de la todo el inventario de
sus características.
institución. la institución.

Debe permitir Debe permitir generar

generar reportes de reportes de inventario

inventario por área por persona para el

para el control. control.

Se procedió a elaborar las historias de usuario:

a. Historia de usuario N°01: Agregar nuevo trabajador

b. Historia de usuario N°02: Cambiar datos del trabajador
c. Historia de usuario N°03: Agregar nuevo equipo
d. Historia de usuario N°04: Cambiar datos de equipo
e. Historia de usuario N°05: Listado de todos los equipos
f. Historia de usuario N°06: Listado de todos los equipos de un área
g. Historia de usuario N°07: Listado de todos los equipos de un
trabajador de un área

86
HISTORIA DE USUARIO N° 03

HISTORIA DE USUARIO

Número: 03 Nombre de la historia: Agregar nuevo equipo

Usuario: Trabajadores de la institución Prioridad: Alta

Descripción: El encargado de la oficina de patrimonio quiere que se guarden

todos el equipo y demás enseres existentes en la institución, así como los que
serán recién adquiridos, todas sus características como son nombre, color, medida,
marca, modelo, serie, estado, así como a qué oficina y trabajador pertenece.

Observaciones: Los muebles no tienen serie, pero todo el inventario tendrá un

registro único que se identificará por un código de barra, pegado en cada
inventario.

HISTORIA DE USUARIO N° 07

HISTORIA DE USUARIO

Número: 03 Nombre de la historia: Listado de todos los

equipos de un trabajador de un área

Usuario: Responsable de oficina de Prioridad: Alta

Patrimonio

Descripción: El responsable de la oficina de patrimonio quiere que se pueda

obtener un listado de todo el inventario que pertenece a un trabajador X, qué
trabajador lo registró, indicando todas sus características como son nombre, color,
medida, marca, modelo, serie, estado, así como a qué oficina y trabajador
pertenece.

Observaciones: Este listado tendrá validez para rendir informe de inventario al

área de patrimonio.

87
Procederemos a usar la técnica del Planning Poker para la estimación de las

historias de usuario, cuando todo el equipo está alineado, tengamos el material

necesario para la sesión y entiende la tarea que se tiene que puntuar.

Todo el equipo “se encierra” para estimar, y todos conocen lo que se va a estimar.
Si hay gente que no está al tanto de lo que se va a estimar la sesión debe comenzar
con una explicación y una sesión de preguntas para despejar cualquier duda sobre
las historias que se van a estimar.

Una por una se leen y discuten las historias de usuario. Una vez todos tienen claro
en qué consiste cada uno elige una carta en función del esfuerzo que prevé
requerirá esa historia. No es posible seleccionar un valor no incluido en la
baraja. Solo estiman los que después desarrollan (ni el Scrum Master ni el Product
Owner estiman, solo resuelven dudas).

Al no haber consenso se abre la discusión. Explicando su elección el que tiene la

puntuación más baja y más alta. Se repite la estimación nuevamente en busca de
consenso. Si no se consigue a la segunda se vuelve a discutir. A la tercera si no
hay consenso se escoge o bien la media o bien el máximo (mejor el máximo).

Al final de la sesión el resultado es una estimación consensuada y validada por

todo el equipo para cada una de las 07 historias de usuario.

HISTORIA DE USUARIO ESTIMACIÓN

Historia de usuario N°01: Agregar

5
nuevo trabajador

Historia de usuario N°02: Cambiar

3
datos del trabajador

Historia de usuario N°03: Agregar

8
nuevo equipo

Historia de usuario N°04: Cambiar

3
datos de equipo

88
Historia de usuario N°05: Listado de
13
todos los equipos

Historia de usuario N°06: Listado de

13
todos los equipos de un área

Historia de usuario N°07: Listado de

todos los equipos de un trabajador de 13
un área

En conjunto con el Scrum Master se planificó la iteración, analizando los

requerimientos, los tiempos y la utilización del menor esfuerzo. Para esto el
equipo de desarrollo se apoyó en la utilización de diseño simple de tareas,
elaborándose el SprintBacklog:

ITERACIÓN HISTORIAS DE ESTIMACIÓN TOTAL

USUARIO

1 Historia de usuario 8 16
N°03: Agregar
nuevo equipo

Historia de usuario 5
N°01: Agregar
nuevo trabajador

Historia de usuario 3
N°02: Cambiar
datos del trabajador

2 Historia de usuario 13 16
N°05: Listado de
todos los equipos

Historia de usuario 3

89
 N°04: Cambiar
datos de equipo

3 Historia de usuario 13 26
N°07: Listado de
todos los equipos
de un trabajador de
13
un área

Historia de usuario
N°06: Listado de
todos los equipos
de un área

4.4.2. Metáfora del sistema

Luego de la descomposición de los requerimientos en tareas, determinando

responsabilidades, riesgos, estimación de tiempo. Se procede a elaborar el Task
Board para este Sprint.

90
HISTORIA DE USUARIO PARA HACER EN PROCESO PARA PRUEBAS HECHO

Historia de usuario N°03: Elaborar interfaz Cambiar Elaborar interfaz registro de Elaborar interfaz Elaborar esquema
Agregar nuevo equipo datos del trabajador. inventario. registro de persona. de la base de datos.

Historia de usuario N°01: Programación de botones. Programación de los botones. Programación de los
Agregar nuevo trabajador botones.

Historia de usuario N°02:

Cambiar datos del
trabajador

Historia de usuario N°05:

Listado de todos los equipos

Historia de usuario N°04:

Cambiar datos de equipo

Historia de usuario N°07:

Listado de todos los equipos
de un trabajador de un
área

Historia de usuario N°06:

Listado de todos los equipos
de un área

91
Gráfico Burn up Chart

92
Se procede a la definición de las tareas que se van a realizar para completar cada
historia de usuario comprometida en el Product Backlog para la iteración, todo
esto basado siempre en una definición de listo. Cabe mencionar que la
planificación de la iteración fue determinada para un periodo de tiempo de 2
semanas (9 días hábiles) con lo que se cumple con la práctica de esta propuesta de
modelo de gestión de trabajo de tener iteraciones cortas de trabajo.

TARJETAS CRC

NOMBRE DE LA CLASE Guardar_Inventario

RESPONSABILIDADES COLABORADORES

Permite crear, modificar, editar, eliminar Guardar_Persona

los registros del inventario.

Gestiona los datos registrados para su

registro en la base de datos.

Fuente: (Chiluisa & Loarte, 2014).

4.4.3. Diseño simple

Se elabora las Tareas de Ingeniería con el fin de determinar las tareas que cada
miembro del equipo tiene.

Tareas de Ingeniería

TAREA: Registrar_Inventario

N° DE TAREA: 01 N° DE HISTORIA: 03

TIPO DE TAREA Desarrollo

FECHA INICIO: 11/03/2019 FECHA FIN: 18/03/2019

PROGRAMADOR RESPONSABLE Eder Solórzano Huallanca

DESCRIPCIÓN

El sistema permitirá registrar el inventario que pertenezcan a la Ugel Huamanga. Los

datos que se requiere para el registro de inventario son: Código (se manejara un
código interno), nombre, en caso de que sea necesario llenar marca, modelo, serie,
color, también indicar la cantidad, el estado (malo, regular, bueno, nuevo) y la fecha
de registro. Si desea indicar una descripción. También puede añadir una foto del
inventario.

93
Dar clic en el botón guardar si todo está correcto, guardara el nuevo inventario, caso
contrario aparece un mensaje de error.
Dar clic al botón nuevo si se desea limpiar los campos y registrar un nuevo
inventario.
Dar clic al botón cancelar para salir de esta ventana.

Fuente: (Ferreira, 2013).

Mantenemos el diseño simple desde el principio y mejorándolo continuamente, en

lugar de conseguir que todo funcione desde el principio y entonces congelarlo.
Esto lo estamos haciendo bastante bien, es decir, empleamos una cantidad
razonable de tiempo re factorizando y mejorando los diseños existentes, y rara vez
empleamos tiempo haciendo grandes diseños desde el principio. A veces metemos
la pata, claro, por ejemplo permitiendo que un diseño inestable nos obstaculice
fuertemente de tal forma que la refactorización se convierta en un proyecto
grande. Pero en términos generales el equipo está satisfecho. La mejora continua
del diseño es sobre todo un efecto secundario automática de hacer Desarrollo
Orientado a Test. (Henrik, 2007).

Con el fin de tener una correcta visualización del flujo del trabajo de todo el
proyecto se procede a elaborar el Tablero Kanban.

Fuente: Elaboración propia.

94
4.4.4. Cliente en el sitio

Se mantuvo una coordinación mutua con el jefe del área de patrimonio, o algún
encargado de dicha oficina, con el cual se pudo solucionar dudas y errores en
forma oportuna.

4.4.5. Equipo sentado juntos

Al estar en el ambiente de la oficina de Informática, hubo una buena

comunicación, con lo cual se aprovechó la comprensión compartida y un mejor
compromiso con el proyecto. Se procedió a elaborar el BurnDown chart para
poder ver la velocidad de trabajo del equipo y también usarlo en los Scrum diarios

95
96
97
98
99
100
En las reuniones del Scrum diario se pudo constatar generalmente que se avanza
tal cual se estuvo proyectado, salvo con uno que otro inconveniente propio de una
institución pública, como actividades extra laborales, reuniones del personal,
procesos de contrata y adjudicaciones, etc., gracias a la colaboración conjunto
entre todos los stakeholders del proyecto se fue logrando cada objetivo. Se va
revisando y actualizando los tableros, siendo el de mejor visualización el Tablero
Kanban.

Se organizó a partir de las 9 de la mañana cada día durante el primer Sprint

realizar una reunión de no más de 15 minutos después de que el equipo haya
actualizado sus tareas, permitiendo la sincronización de todo el equipo además de
establecer la planificación de actividades para las siguientes horas de trabajo. Los
miembros del equipo están enterados del propósito de esta reunión y se pidió
principalmente estar enfocados en 3 temas fundamentales:

Las entradas principales que se manejaron fueron:

 Pila del Sprint, gráficos de burndown y up y el tablero actualizado a la

fecha.
 Información del avance de cada miembro del equipo, reflejado en el
tablero de tareas.
4.4.6. Programación en pareja

Juntos al responsable de la oficina de Informática, se pudo revisar tanto las

interfaces, el código, revisiones, con lo cual se aceleraron tiempos y se mejoró la
calidad.

4.4.7. Limitar el WIP

Es el mayor inconveniente que se tuvo en el desarrollo del proyecto, producto de

las actividades propias de una institución pública, por lo cual las cartas Kanban se
iban acumulando en las columnas del tablero, teniendo que dedicar más días en la
realización del proyecto que fueron subsanadas durante el mismo.

4.4.8. Propiedad del código colectivo

A través de este principio, cualquiera de los miembros pudo arreglar partes de

código y poder re factorizar, modificar diseños.

4.4.9. Normas de codificación

Mejores prácticas en la codificación.

101
4.4.10. Pruebas

Se hace las 3 clases de pruebas:

Test unitarios:

Aquí se encarga de probar el código de manera individual, forma parte de la

técnica conocida como TDD (Test Driven Development). Con el objetivo de
comprobar la correcta estructura y que cumplen con su funcionalidad. Hubo
componentes que no cumplían con la funcionalidad requerida, por lo que se
procedió a rectificarlos. Algunas de las pruebas ejecutadas son:

102
 PRUEBA DESCRIPCIÓN RESULTADO STATUS COMENTARIOS
ESPERADO

01 Log in usuario Función que genera una Correcto Validación de credenciales de acceso del usuario, si es
conexión válido obtiene el acceso, de no ser validos los datos de
conexión la función devuelve un mensaje de error.

02 Log out usuario Función que genera el Correcto Esta función sirve para cerrar una sesión previamente
cierre de sesión. generada.

03 executeUpdate Función que actualiza un Correcto Agrega un ítem más a la base de datos.
inventario más.

04 Cambiar datos del Función que actualiza datos Correcto Manejar excepciones si ocurriese un error.
trabajador de un usuario registrado.

05 Cambiar datos de Función que actualiza datos Correcto Manejar excepciones si ocurriese un error.
equipo de un inventario registrado.

06 Generar Listado de Se lista todo el inventario Correcto Manejar excepciones si ocurriese un error.
todos los equipos registrado.

07 Generar Listado de Se lista el inventario Correcto Manejar excepciones si ocurriese un error.

todos los equipos de un registrado por todos los
área usuario de un área.

08 Generar reporte por Se lista el inventario Correcto Manejar excepciones si ocurriese un error.

103
 usuario. registrado por un usuario.

Test de aceptación:

Prueban la funcionalidad del código, su comportamiento. Se realizan pruebas del prototipo base de proyecto integrado en su totalidad para
verificar la funcionalidad del programa en general y su aceptación y posterior puesta en ejecución. El proyecto base deja de ser prototipo y
pasa a ser el software como tal, Sistema de Control de Inventario.

PROCESO SUB PROCESO DESCRIPCIÓN ENTRADA SALIDA STATUS

Login Ingreso de usuario y Validación de Ingreso de usuario y Pantalla principal OK

contraseña controles contraseña

Cerrar una sesión

Registro y Registro de Interfaces donde se Intentar registrar sin Mensaje de error OK

modificación de inventario podrá registrar o completar todo el exigiendo que debe
inventario modificar el formulario de ingresar todos los
Cambiar datos de inventario datos
equipo

Reportes Listado de todos los Interfaces para cada Realizar un reporte Se obtiene el listado OK
equipos, por área y tipo de reporte con con ayuda de los del inventario del
sus respectivos

104
 usuarios campos controles reporte seleccionado

Descargar un reporte Se descarga el

reporte en formato
pdf.

Test de integración:

Tiene la responsabilidad de integrar todos los otros test mencionados anteriormente, para así validar el correcto funcionamiento de la
aplicación en su totalidad.

PRUEBA DESCRIPCIÓN RESULTADO ESPERADO STATUS COMENTARIOS

01 Login Funcionamiento correcto de login, OK Los campos usuario y contraseña son

si el usuario es válido la obligatorios. El mensaje de error debe de ser
aplicación debe de otorgar acceso aceptado para desaparecer.
al menú principal, si el usuario es
invalido la aplicación debe de
mostrar mensaje de error.

02 Módulo inventario Funcionamiento correcto de todo OK Los campos deben ser llenados en su totalidad
el registro y modificación de a pesar de no tener valor, de lo contrario el
inventario, sin ningún error que mensaje de error debe ser explícito, al igual si
pueda ocasionar la salida de la se quiere modificar un registro.
aplicación.

105
03 Modulo reporte Funcionamiento correcto de todos OK Establecer un mensaje de error si se quiere
los reportes, así como su posterior generar un reporte sin haber especificado el
descarga. tipo.

106
Durante el proceso de pruebas se aplicará el re factoring de todo el código
duplicado.

4.4.11. Integración continua

Tomando en cuenta la complejidad, se procede a realizar la integración de los
componentes, en la que se fueron agregando una por una las funcionalidades que
ya fueron probadas y aprobadas en las pruebas unitarias hasta integrar todo lo que
se necesita para el proyecto.

Al final de la Iteración 1 se presenta un incremento de producto en cuanto al

funcionamiento correcto del registro de inventario, registro y modificación de
persona.

En las iteraciones siguientes se cumplió con los objetivos establecidos, con

funcionalidades probadas y aprobadas.

4.4.12. Ritmo sostenible

Iteración 2

Se empezó la codificación en esta iteración 2, se hizo mejoras basadas ya en las

lecciones aprendidas en la iteración anterior tal es el caso de los estándares de
programación. También se mejoró las pruebas al tener control sobre los guiones
de pruebas con lo que se trabajó.

107
La refactorización y la propiedad colectiva de código siguen manteniendo el
mismo formato de trabajo debido a que ya se ha logrado que los miembros del
equipo se acoplen a la misma. Sin embargo la programación en pares si bien en la
primera iteración fue buena, tuvo sus problemas de acoplamiento que en esta
iteración se han visto reflejados pero en menor medida.

Scrum Diario Iteración 2

Las reuniones siguen el mismo estándar del Sprint anterior con revisiones y
preguntas frecuentes y las correspondientes revisiones en el tablero y gráficos de
avances. En esta iteración se pudo verificar y corregir el hecho de que los
programadores no actualizaban sus tareas diariamente, con esto se llegó a tener
mejor control en los cuadros, gráficos e indicadores de avances del proyecto.

Retrospectiva Iteración 2

Las expectativas que se tenía para este Sprint en comparación al anterior se

llegaron a cumplir de mejor forma, por lo que se puede sacar como resumen que
se cumplió la meta de mejora, cumpliendo los 16 puntos en la iteración y
mejorando el rendimiento del equipo.

Planificación de la siguiente iteración

En reuniones con los dueños del proyecto se realizó los correspondientes análisis
para ver potenciales cambios de las priorizaciones, pero en esta ocasión para la
iteración 3 no se obtuvieron cambios en el orden de desarrollo de las tareas, pero
si se encontraron varios ajustes que se procederá a realizar en algunas de las
funcionalidades. Para este caso solamente hubo observaciones de forma más que
de fondo, el Product Backlog cambio en la prioridad de registrar bienes y
servicios, por una observación realizada por el Product Owner en la reunión de
demostración en la historia de usuario.

4.4.13. Pequeños lanzamientos

Lecciones aprendidas generales, cierre del proyecto

Para esta fase se procederá a hacer un resumen general de las lecciones aprendidas
durante todo el sprint usando las plantillas de cada una de las iteraciones, se

108
tomarán las lecciones más importantes que tenga que ver con mejoras en cuanto a
la gestión y aquellas técnicas que puedan ser más importantes para ser aplicadas
en nuevos proyectos.

El cierre formal del proyecto una vez terminados todas las iteraciones y realizadas
las validaciones de los usuarios con su entera satisfacción se procede a la firma
del acta de entrega recepción del producto a los usuarios finales.

4.5. RESULTADOS
Una vez aplicada esta propuesta de modelo de gestión de trabajo ágil (“XP
+ Scrum + Kanban”) a lo largo de todas las iteraciones del proyecto, mostró los
siguientes resultados tanto positivos como negativos:

Con la aplicación de la encuesta se dio conocer que es mucho más fácil la

aplicación de esta propuesta de modelo de gestión de trabajo en empresas que
tienen ya una formación o conocimiento en metodologías ágiles.

Las empresas con un puntaje menor a 60 necesitaran de un mayor trabajo para

aplicar este marco u cualquier metodología.

Hubo una excesiva dependencia del equipo de trabajo hacia el Scrum Master, para
saber qué hacer. Esto fue un impedimento al inicio de la iteración 1 que se fue
solucionando poco a poco y mostro mejorías en la iteración 2.

A pesar de tener planificadas las tarea, costó al principio a los miembros del
equipo comprometerse y responsabilizarse de la culminación de las mismas.

Al principio costó mucho la forma de trabajar en pares entre los miembros del
equipo, por lo que por estrategia fue necesario realizar una demostración con
experimentación con un par de miembros del equipo quienes cada día reportaban
sus experiencias favorables así como las limitaciones.

Los puntos de mejora que se han visto beneficiados con este marco de trabajo ágil
pasan a ser descritos a continuación:

Se ha logrado que el equipo de trabajo esté enfocado en un determinado proyecto

y no en varios a la vez, esto permite que el equipo reaccione y se ajuste a las

109
necesidades de un solo proyecto y esté totalmente concentrado en este trabajo a
tiempo completo.

Con la adopción de esta propuesta de modelo de gestión se crearon equipos multi

disciplinarios y auto organizados con una visión clara de roles y
responsabilidades, haciendo que el trabajo en equipo se convierta en una
herramienta eficiente.

Al trabajar con el esquema de iteraciones cortas y entregas de código funcional en

cada una de estas, se ayuda a que el usuario tenga funcionalidades del proyecto
deseado, esto permite en gran medida que los proyectos sean entregados a tiempo
y con calidad.

Las historias de usuario usadas en esta propuesta de modelo de gestión de trabajo

ágil, permiten tener una forma documentada de lo que se va a ir creando además
de darle al usuario la posibilidad de priorizar la importancia de las mismas, así
como también ayudaron a que los miembros del equipo se comprometan en la
entrega de resultados finales. Así mismo la organización en los board cards en
donde se organizó las historias de usuario por tareas ha permitido en las
iteraciones 1 y 2 ir cerrando los procesos.

De igual manera con la entrega de software funcional en cada iteración y con la

revisión y pruebas realizadas con los usuarios correspondientes se cierra la brecha
y se puede medir la satisfacción del cliente. De igual manera esto se pudo probar
en la otra iteración.

Al tener reuniones periódicas con el equipo de trabajo y los usuarios se logró que
los miembros del equipo de desarrollo tengan una visión mucho más amplia del
proyecto esto pudo ser comprobado en las reuniones diarias mantenidas en las que
una vez que se discutían los estados de las tareas los miembros se ayudaban entre
sí.

Otro de los puntos que se ha visto mejorado es la elección del trabajo por parte de
los miembros del equipo de acuerdo a sus aptitudes.

110
El hecho de llevar una plantilla de lecciones aprendidas es de gran ayuda puesto
que permite registrar errores y soluciones que bien documentadas puede ayudar a
otros equipos a no caer en las mismas problemáticas.

El uso de la reunión de retrospectiva es una de las mejores experiencias,

permitieron ayudar al equipo a ver las deficiencias que se dieron en el trabajo de
la primera iteración y ver cómo solucionarlos para los futuros sprint.

Las expectativas del cliente en la primera iteración han sido resueltas en la

mayoría de los casos, se han mantenido en constante comunicación con el mismo
y se lo ha involucrado en el proyecto de una forma muy activa tanto en el
levantamiento de los requerimientos como en las pruebas del mismo. De modo
que cuando el cliente llegó a la reunión de demostración su conocimiento del
trabajo realizado era amplio.

La entrega de resultados anticipados, puesto que de esta manera el cliente está en

posición de comenzar a usar partes de su producto antes de que el proyecto se
encuentre finalizado. Esto depende mucho de que el cliente manifieste la prioridad
de sus requerimientos y el valor que cada una de las cosas que solicita. Como se
tiene entendido esto se realiza al inicio de cada iteración. De esta forma se puede
ir midiendo el progreso que vaya teniendo el proyecto. Al finalizar la primera
iteración el cliente de este caso de estudio además de tener ya una parte de su
software funcionando, conoce cómo trabajar con él debido a su participación en
las pruebas.

Al usar las mejores prácticas de Scrum y Kanban se ha logrado obtener una

gestión de desarrollo de proyectos de software mucho más eficaz debido al uso de
elementos como reuniones diarias, el uso y revisión del tablero de control, cuadros
de control y toma de decisiones como los Burn Down.

El uso de las mejores prácticas de XP por su parte ha ayudado a este marco de

trabajo a conseguir lo siguiente:

Creación de software con calidad mediante la aplicación de las correspondientes

pruebas unitarias, de concepto y de aceptación se ha logrado que en la primera

111
iteración el producto entregable final sea de un alto grado de calidad y adaptado
totalmente a las necesidades del cliente y probado por el mismo cliente.

Permite atender las necesidades del cliente con mayor exactitud. El uso de tarjetas
CRC han dado una gran ventaja y ayuda al momento de levantar las historias de
usuario de cada uno de los requerimientos.

Definitivamente un gran aporte ha sido el tener una codificación mucho más

simple y entendible con lo que se reduce el número de errores gracias al uso de re
factoring y como se ha podido ver en este Capítulo también ha sido de mucha
ayuda el manejar código estándar.

El uso de la práctica de programación en pares, si bien es cierto que para muchas

personas puede resultar tediosa, ha sido de gran aporte, ya que ha permitido a los
programadores aplicar buenas prácticas al momento de codificar, probar y
controlar el código.

El uso por separado de estas metodologías hubieran dado buenos resultados pero,
no hubieran complementado cosas muy importantes tal es el caso por ejemplo:

Si el proyecto se hubiese realizado estrictamente con XP, la calidad de las

aplicaciones tendría un mayor grado, la propiedad colectiva del código se
manejaría de mejor manera, la programación en pares hubiera permitido trabajar
de mejor forma a los programadores, pero la gestión de desarrollo y con el cliente
pudiera ser menos eficaz, lo que ocasionaría que existan muchos reprocesos.

Si se hubiese usado únicamente Scrum en el proyecto, se hubiera podido realizar

el trabajo de levantamiento de requerimientos, desarrollo y entrega de producto en
iteraciones pero de una forma tradicional y monótona, el seguimiento y gestión de
desarrollo se llevaría a cabo de una forma controlada, pero la calidad del software
tendría sus cuestionamientos ya que no se hubieran tomado las consideraciones de
pruebas como se hizo en este caso de estudio.

Si se hubiese realizado únicamente con Kanban, se hubiese tenido una mejor

forma de ver las tareas de todo el proyecto, aquellas por hacer, aquellas en
proceso y aquellas ya realizadas, así como el limitar la cantidad de tareas en las

112
que trabaja el equipo simultáneamente, consiguiente un mayor control de las fases
del proyecto, flexibilidad y disminución del tiempo dedicado a tareas poco
productivas, pero hubiésemos tenido un resultado de poca calidad, además de
reducir la interacción del equipo.

El uso combinado de las características expuestas en los capítulos anteriores de

este documento referentes a XP, Scrum y Kanban han permitido que este marco
de trabajo logre tener a parte de una adecuada gestión de desarrollo de productos
de software al llevar un control y mejor comunicación tanto internamente como
externamente, una gestión de calidad en los productos que se van desarrollando
como se puede apreciar a través de estrictos controles mediante el uso de pruebas
del software, refactorización de código, propiedad colectiva, así como tener una
clara visualización del flujo de trabajo, entre otras.

113
 CAPÍTULO V

CONCLUSIONES Y RECOMENDACIONES

5.1. CONCLUSIONES

a) De acuerdo al numeral 4.6., del Capítulo IV – Resultados, se comprueba

que el modelo de gestión de desarrollo de software ágil mediante Scrum y
Kanban se adapta al modelo iterativo e incremental de la Programación
Extrema.

b) De acuerdo al numeral 4.6., del Capítulo IV – Resultados, se comprueba

que el modelo de gestión de desarrollo de software ágil mediante Scrum y
Kanban se adapta a las pruebas unitarias de la Programación Extrema.

c) De acuerdo al numeral 4.6., del Capítulo IV – Resultados, se comprueba

que el modelo de gestión de desarrollo de software ágil mediante Scrum y
Kanban se adapta a la refactorización de código de la Programación
Extrema.

d) De acuerdo al numeral 4.6., del Capítulo IV – Resultados, se comprueba

que el modelo de gestión de desarrollo de software ágil mediante Scrum y
Kanban se adapta a la corrección de errores y código compartido de la
Programación Extrema.

114
5.2. RECOMENDACIONES

a) Se recomienda la aplicación de esta propuesta de modelo de gestión de

trabajo con más proyectos para poder tener así un mayor grado de
comparación en cuanto a sus beneficios y falencias.

b) Con esta propuesta de modelo de gestión de trabajo hibrido, existe mayor

control en los roles y funciones que cada uno de los miembros de los
equipos, se recomienda la especialización de los mismos en tareas o áreas
más específicas, puesto que ayudaría a tener mayor grado de calidad en el
producto, con una disminución en el tiempo de las iteraciones.

c) Mientras que el desarrollo de nuevos proyectos estén inmersos en

metodologías ágiles, se recomienda la propuesta que se ha dado en este
trabajo para uso en proyectos de cualquier tamaño.

d) La motivación de los equipos de trabajo es fundamental para el éxito de

estas metodologías, por lo que es totalmente recomendable mantener
elevada la moral de los equipos, con actualizaciones, cursos, promociones
que ayuden a su desarrollo profesional y personal, lo que da como
resultado mejoras para la Institución.

e) Al principio de la utilización de esta propuesta de modelo de gestión de

trabajo, puede provocar una diversidad de falencias, con lo que se querrá
renunciar al cambio y querer volver a las metodologías tradicionales; sin
embargo, es recomienda no cambiar y continuar con el proceso, ya que
ayudará a la Institución, con una mejor experiencia documentada para
futuros proyectos y equipos.

115
REFERENCIA BIBLIOGRÁFICA

Abrahamsson, P., Salo, O., Ronkainen, J. y Warsta, J. (2002). Agile Software

Development methods: Review and Analysis.

Agilemanifesto (2019). Agilemanifesto. Recuperado el 21 de febrero de 2020, de:

https://agilemanifesto.org/iso/es/principles.html.

Ahmad, Z. (2014). Scrumban - Adaptive Agile Development Process. Using

Scrumban to improve software development process. Tesis de maestría. Helsinki
Metropolia University of Applied Sciences. Finlandia.
Disponible:https://www.theseus.fi/bitstream/handle/10024/77014/Khan_Zahoor.p
df? sequence=1

Bahit, E. (2012). Scrum y Extreme Programming. Argentina, Buenos Aires.

Ballesteros, D. “A practical form to apply the System Kanban in the Colombian

Mypimes”. Scientia et Technica Año XIV, N.° 39. 2008.

Balza, L. M., Briceño, T., Linares, B., Lobo, R., & Nuñez, C. INFORME SOBRE
XP. Universidad Valle del Momboy. 2007

Beck, K. y Andrés, C. (2005). Extreme Programming Explained: Embrace

Change. USA, Boston: Addison- Wesley.

Bermejo, M. (2011). El Kanban. Barcelona, España: UOC.

Canos, J., Leteller, P. y Penades, C. (2004). Metodologías Agiles en el Desarrollo

de Software. Valencia, España.

Carmichael, A. y Anderson, D. (2015). Essential Kanban Condensed.

116
Carrasco, M., Ocampo, W., Ulloa, L. y Azcona, J (2019). Metodología híbrida de
desarrollo de software Combinando XP y Scrum. Mikarimin, 5(2),109-116.

Casas, S., Reinaga, H. (2009). Aspectos tempranos: Un enfoque basado en

tarjetas CRC. Sociedad Colombiana de Computación.
https://www.researchgate.net/publication/220136724_Aspectos_tempranos_Un_e
nfoque_basado_en_tarjetas_CRC

Chiluisa Pallo, A. P., & Loarte Cajamarca, B. G. (2014). Desarrollo e

Implantación del Sistema de Control de Inventarios y Gestión de Laboratorios
para la Facultad de Ciencias de la Escuela Politécnica Nacional. Quito.

Cifuentes Lozano, A. (2012). Integración de Buenas Prácticas. Recuperado el 24

de Noviembre de 2014, de:
http://bibliotecadigital.icesi.edu.co/biblioteca_digital/bitstream/10906/68430/5/mo
delo_integracion_practicas.pdf

Cohn, M. (2006). Planning Poker. Mountain Goat Software, 56-59.

Córdova, M. (2003). Estadística Descriptiva e Inferencial. Perú, Lima: Moshera

S.R.L.

Deemer, P., Benefield, G., Larman, C., & Bas, V. (2009). The Scrum Primer
Versión en Español. California, Estados Unidos.

Deemer, P., Benefield, G., Larman, C., & Bas, V. (2009). Información Básica de
Scrum the Scrum Primer Version 1.1. Scrum Training Institute. Traducción de
Leo Antoli. Agile-Spain. Disponible en: http://www.
goodagile.com/scrumprimer/scrumprimer_es.pdf. Consulta: 30 de mayo del 2011.

DeMarco, T. y Boehm, B. (2002). The agile methods fray. United States, New
York.

117
Díaz, R. (2009). Las metodologías agiles como garantía de calidad de software.
España.

Du Bois, B., Demeyer, S., & Verelst, J. (2004, November). Refactoring-improving

coupling and cohesion of existing code. In 11th working conference on reverse
engineering.IEEE.144-151.

Fernández, J. (2014). Las Metodologías Agiles. España, Barcelona.

Ferreira Escutia, R. (2013). XP Extreme Programming. Recuperado el 2015, de

http://slideplayer.es/slide/84721/

Fitsilis, P. (2008). Comparing PMBOK and Agile Project Management Software

Development Processes in Advances Computer and Information Sciences and
Engineering. Netherlands: Springer.

Gamboa, J. (2014). Aumento de la Productividad en la Gestión de Proyectos,

Utilizando una Metodología Ágil Aplicada en una Fábrica de Software en la
Ciudad de Guayaquil. Tecnológica Espol. 27(2), 1-36.

Haugen, N. C. (2006, July). An empirical study of using planning poker for user
story estimation. In AGILE 2006 (AGILE'06). IEEE.9.

Hernández, R., Baptista, P. y Fernández, C. (2014). Metodología de la

Investigación. México: McGraw-Hill/ Interamericana Editores.

Jeffries, R., Anderson, A. y Hendrickson, C. (2001). Extreme Programming

Installed. USA: Addison-Wesley.

Joskowicz, J. (2008). Reglas y prácticas en eXtreme Programming. Universidad

de Vigo, 22.

118
Kanbanize (2020). Kanbanize. Recuperado el 3 de enero de 2020, de:
https://kanbanize.com/es/recursos-de-kanban/primeros-pasos/que-es-tablero-
kanban/

Klipp, P. (2014). Getting Started with Kanban.

Kniberg, H. (2007). Scrum y XP desde las trincheras. USA: C4Media Inc.

Ladas, C. (2008). Scrumban Essays on Kanban Systems for Lean Software

Development. Disponible en:
https://books.google.co.ve/books?hl=es&lr=&id=SQFdAgAAQBAJ&oi=fnd&pg
=PA7&dq=Scrumban-
Essays+on+Kanban+Systems+for+Lean+Software+Development&ots=c89XRBX
GNg&sig=I59JUW5uUe2KDdWgc-LuJnkQKd8#v=onepage&q=Scrumban-
Essays%20on%20Kanban%20Systems%20for%20Lean%20Software%20Develo
pment&f=false

Laudon, K. y Laudon, J. (2004). Sistemas de Información Gerencial. México:

Pearson Educación.

Leiva, I., & Villalobos, M. (2015). Método ágil híbrido para desarrollar software
en dispositivos móviles. Ingeniare. Revista Chilena de Ingeniería, 473-488.

Letelier, P., & Penadés, M. C. (2006). Metodologías ágiles para el desarrollo de

software: eXtreme Programming (XP). Ciencia y Técnica Administrativa.

Letelier, P., & Penadés, M. C. (13 de Marzo de 2012). Repositorio institucional de

la Universidad de Las Tunas. Obtenido de
http://roa.ult.edu.cu/bitstream/123456789/476/1/TodoAgil.pdf
Martel, A. (2018). Antonio Martel Blog. Recuperado el 9 de diciembre de 2018,
de: https://www.antoniomartel.com/2018/12/los-valores-de-extreme-
programming.html.

119
Martínez, J. (2016). Fundamentos de Programación en Java. España, Madrid:
EME.

Monroy, S. (2008). Estadística Descriptiva. México.

Moré Martín, A. (2011). MPlu+ a Ágil: el modelo de proceso centrado en el

usuario como metodología ágil. Recuperado el 9 de febrero de 2011, de:
https://repositori.udl.cat/handle/10459.1/45841.

Ohmyroot!. Estándares de codificación. Recuperado el 12 de enero de 2017, de:

https://www.ohmyroot.com/buenas-practicas-legibilidad-del-codigo/

Palacio, J. (2007). Flexibilidad con Scrum Principios de diseño e implantación de

campos de Scrum. Safe Creative.

Pardo, M. y Murado, E. (2010). Metodologías de desarrollo agiles: Scrum y

Extreme Programming.

Pérez, M. (2014). Guía comparativa de metodologías ágiles. Tesis de Grado en

Ingeniería Informática de servicios y aplicaciones no publicado. España:
Universidad Valladolid. Recuperado el 17 de febrero de 2016, de:
https://uvadoc.uva.es/bitstream/10324/1495/1/TFG-B.117.pdf.

Pérez, M. (2014). Lenguajes de Programación Orientada a Objetos. USA.

CreateSpace Independent Publis.

Pressman, R. (2011). Ingeniería del software. United States, New York: The
McGraw-Hill.
Pressman, R. (2010). Ingeniería del Software. Un enfoque práctico. México DF:
Mc Graw Hill.

Richter, T. (2011). Personal Kanban stop wasting your life.

120
Robles, G., & Ferrer, J. (2002). Programación eXtrema y Software
Libre. Universidad Politécnica de Madrid. España.

Rosas, A.K. (2017). Sistema web para control de inventarios y rendimientos.

Repositorio Institucional de Investigación. Universidad Tecnológica del Centro de
Veracruz, Recuperado el 4 de abril de 2017, de:
http://reini.utcv.edu.mx/handle/123456789/239.

Rubin, K. (2013). Essential Scrum. USA: Pearson Education.

Salamon, A., Maller, P. A., Boggio, A., Mira, N., Perez, S., & Coenda, F. (2014).
La integración continua aplicada en el desarrollo de software en el ámbito
científico–técnico. In XX Congreso Argentino de Ciencias de la Computación
(Buenos Aires, 2014).

Saliu, M. O., & Ruhe, G. (2007, September). Bi-objective release planning for
evolving software systems. In Proceedings of the 6th joint meeting of the
European software engineering conference and the ACM SIGSOFT symposium
on The foundations of software engineering (pp. 105-114).

Schwaber, K. y Sutherland, J. (2017). The Scrum Guide.

Shore, J. y Warden, S. (2008). The art of Agile Development.

Silva, M., Barrera, A., Arroyave, J. y Pineda, J. (2007). Un método para la

trazabilidad de requisitos en el Proceso Unificado de Desarrollo.

Sommerville, I. (2010). Ingeniería de software. España, Madrid: Pearson

Education Limited.

Supo, J. (2012). Seminarios de Investigación Científica. Arequipa:

121
Tesei, F., Cabrera, M., Vaquero, M., & Tedini, D. (2019). Acercando la academia
al mundo real: una experiencia de aplicación de Metodologías Agile al proceso
de enseñanza-aprendizaje en una asignatura de desarrollo de software. In I
Simposio Argentino de Educación en Informática (SAEI 2019)-JAIIO 48 (Salta).

Tuya, J., Ramos, I., Dolado, J. (2007). Técnicas Cuantitativas para la Gestión en
la Ingeniería del Software. España, La Coruña: Netbiblo S.L.

Vlaanderen, K., Jansen, S., Brinkkemper, S. y Jasper, E. (2011). The agile

requirements refinery: Applying SCRUM principies to software product
management. Information and Software Technology, 53(1),58-70
doi:10.1016/j.infsof 2010.08.004.

Wells, D. (2019). Programación extrema: una introducción suave. Recuperado el

28 de diciembre de 2019, de: http://www.extremeprogramming.org/values.html.

122
 ANEXOS

Anexo A. Plantilla de Product Backlog

Id de la Enunciado de la historia Estado Iteración Prioridad Comentarios
historia (Sprint)

XXXX Rol – descripción de la funcionalidad -  Por hacer X Baja …………………….

finalidad
 En proceso
Media
 Terminada
Alta

123
Anexo B. Plantilla de Historia de Usuario

HISTORIA DE USUARIO

Número: Nombre de la historia:

Usuario: Prioridad:

Descripción:

Observaciones:

Anexo C. Plantilla de Tarjeta CRC

NOMBRE DE LA CLASE

RESPONSABILIDADES COLABORADORES

Anexo D. Plantilla de Task Card

TAREA:

N° DE TAREA: N° DE HISTORIA:

TIPO DE TAREA

FECHA INICIO: FECHA FIN:

PROGRAMADOR RESPONSABLE

DESCRIPCIÓN

124
Anexo E. Encuesta de factibilidad para aplicar una metodología
La presente encuesta es parte del trabajo de titulación de la carrera de Ingeniería
de Sistemas de la Universidad Nacional de San Cristóbal de Huamanga. La
información consignada en este documento será mantenida confidencialmente y
únicamente se utilizaran los datos estadísticos totales con fines académicos.

Datos de la Empresa Encuestada

Nombre de la Empresa:…………………………………………………………...

Ciudad:…………….. Cargo:……………………………….

Email de contacto: ……………………………………

Fecha:……………………………….

¿Número de empleados de su empresa?

1-5

6-10

11-20

21-49

50 a más

Cuestionario
1. ¿Los Ingenieros/Programadores, trabajan en varios proyectos en forma
simultánea a tiempo exclusivo?
Nunca

Casi nunca

A veces

Casi siempre

Siempre

125
2. ¿Cuál considera que es el nivel de aplicación de metodologías de gestión de
desarrollo en su empresa?
Muy bajo

Bajo

Regular

Aceptable

Muy alto

3. ¿Está establecida la política de la calidad y los objetivos de la calidad?

Prácticamente no se realiza

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

4. ¿Están definidas las responsabilidades y autoridad entre ellas la función de

calidad?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

5. ¿Los roles están bien definidos y limitan o aumentan las posibilidades de

las personas?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

126
6. ¿Los proyectos anteriores han sido entregados en tiempo y forma o han
sufrido retrasos?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

7. ¿Asegura la dirección la disponibilidad de los recursos necesarios:

Humanos, instalaciones y equipos?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

8. ¿Se tienen identificados los requisitos de los clientes tanto los especificados
por ellos como los no especificados, así como los requisitos legales y
reglamentarios?

Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

9. ¿Se revisan los requisitos del producto o servicio antes de adquirir un

compromiso con el cliente?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

127
10. ¿El cliente final está contento con el producto?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

11. ¿Se realizan planes para el personal (admisión, formación, desarrollo,

etc.) evaluando el rendimiento y las necesidades de desarrollo de todas las
personas?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

12. ¿Es prioridad satisfacer al cliente mediante la entrega temprana y

continua de software con valor?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

13. ¿Se entrega software funcional frecuentemente?

Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

128
14. ¿Se acepta que los requerimientos cambien incluso en etapas tardías del
desarrollo?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

15. ¿Los proyectos se desarrollan en torno a individuos motivados?

Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

16. ¿El método más eficiente y efectivo de comunicar información al equipo

de desarrollo y entre sus miembros es la conversación cara a cara?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

17. ¿El software funcionando es la medida principal de progreso?

Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

129
18. ¿Los promotores, desarrolladores y usuarios son capaces de mantener un
ritmo constante de forma indefinida?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

19. ¿Se analizan e interpretan las métricas y datos obtenidos?

Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

20. ¿El equipo de desarrollo y jefes de producto están físicamente en la

misma área?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

21. ¿Los desarrolladores conocen la visión completa del producto?

Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

130
22. ¿Las decisiones de cambio son discutidas con el equipo de desarrollo o
tomadas por la parte gerencial?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

23. ¿Existe rotación de las personas y roles o cada individuo trabaja en su

especialidad?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

24. ¿Las personas pueden elegir su trabajo o tareas basadas en sus

conocimientos o les son asignadas?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

25. ¿Su empresa Realiza pruebas de software?

Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

131
26. ¿Existe un programa de mejora continua que afecta a todas las
actividades de la empresa empleando herramientas adecuadas y
estableciendo objetivos de mejora?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

27. ¿Cuáles considera que son las principales dificultades en la aplicación de

estándares de control de calidad?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

28. ¿Se controlan las no conformidades y se asegura que el producto no

conforme es identificado y controlado para prevenir una utilización o entrega
no intencionada?
Prácticamente no

Se realiza en ocasiones puntuales

Se realiza en la mayoría de casos

Se realiza en casi todas las áreas

Se realiza siempre y de forma total

1 2 3 4 5
Total marcados
x1 x2 x3 x4 x5
Suma total de puntos

132
Anexo F. Fichas bibliográficas

FICHA BIBLIOGRÁFICA

Libro Scrum y Extreme Programming

Autor Eugenia Bahit

Edición Auto edición

Publicación Argentina

Editorial Safe Creative

Año 2012

FICHA BIBLIOGRÁFICA

Libro Essential Kanban Condensed

Autores Andy Carmichael, David J. Anderson

Edición Volumen 2

Publicación Argentina

Editorial Blue Hole Press

Año 2015

FICHA BIBLIOGRÁFICA

Tesis Modelo de integración de buenas prácticas para la gestión de

proyectos de desarrollo de software para empresas donde dichos
proyectos no son su objetivo de negocio

Autor Adriana Y. Cifuentes Lozano

Fecha 23 de mayo de 2012

Publicación Colombia

133
Editorial Universidad Icesi

Fichero https://repository.icesi.edu.co/biblioteca_digital/bitstream/10906/6
8430/1/cifuentes_modelo_integracion_2012.pdf

FICHA BIBLIOGRÁFICA

Página Principios del Manifiesto Ágil

Autor Agilemanifesto

Fecha 2019

Fichero https://agilemanifesto.org/iso/es/principles.html

FICHA BIBLIOGRÁFICA

Libro The Scrum Primer Versión en Español

Autores Pete Deemer, Gabrielle Benefield, Craig Larman y Bass Vodde

Versión 1.1

Publicación Estados Unidos

Editorial Scrum Training Institute

Año 2009

Fichero http://www.goodagile.com/scrumprimer/scrumprimer_es.pdf

FICHA BIBLIOGRÁFICA

Libro Reglas y prácticas en eXtreme Programming

Autor José Joskowicz

Publicación España

Editorial Universidad de Vigo

134
Año 2008

FICHA BIBLIOGRÁFICA

Página Estándares de codificación

Autor Ohmyroot!

Fecha 12 de enero de 2017

Fichero https://www.ohmyroot.com/buenas-practicas-legibilidad-del-
codigo/

FICHA BIBLIOGRÁFICA

Libro Flexibilidad con Scrum Principios de diseño e implantación de

campos de Scrum

Autor Juan Palacio

Publicación España

Año 2007

FICHA BIBLIOGRÁFICA

Libro Ingeniería del software

Autor Ian Sommerville

Edición 9na edición

Publicación España

Editorial Pearson Education

Año 2010

135
Anexo G. Ficha de análisis documental

FICHA DE ANÁLISIS DOCUMENTAL

Nombre del documento (registre el nombre o

título del documento consultado)

Autor (registre el nombre completo del autor o

autores del documento)

Referencia bibliográfica según norma APA

(registre la referencia bibliográfica completa de
acuerdo a la estructura que corresponda en
normal APA)

Palabras clave de búsqueda (registre las

palabras con las que realizó la búsqueda de
cada documento)

Palabras claves del texto (registre las palabras

claves que aparecen en éste, en caso tal que no
las tenga, se deja espacio en blanco o se
escribe: No tiene)

Ubicación (dirección electrónica específica)

y/o clasificación topográfica de la biblioteca
donde se encuentra (registre la URL para
documentos encontrados en la red, o los datos
correspondientes para documentos consultados
en físico, como por ejemplo en bibliotecas,
centros de documentación, entre otros, de
acuerdo con las normas APA)

Descripción del aporte al tema seleccionado

(presente una descripción argumentada de
aportes que considera pertinentes para el tema
seleccionado, de acuerdo con lo que plantean
el o los autores)

Conceptos abordados (conceptos claves que

le aporta a su tema explicando el por qué)

136