El Estado Actual Das Metodologías Agiles 2012

INTITUTO TECNOLOGICO DE ZACATECAS
DEPARTAMENTO DE SISTEMAS Y COMPUTACION

INGENIERIA INFORMATICA
PROYECTO DE INVESTIGACION DE TALLER DE INVESTIGACIÓN II
“EL IMPACTO Y EL ESTADO ACTUAL DE LAS

METODOLOGÍAS ÁGILES EN LAS ORGANIZACIONES”
PRESENTA:
ERIK JACOB SALAS CRUZ
ASESOR:
MASI. SILVIA JIMÉNEZ HERNÁNDEZ
ZACATECAS ZAC. ENERO – JUNIO 2017

El Impacto y el estado actual de las
Metodologías ágiles en las organizaciones
.
Agradecimiento
Extiendo mi total gratitud a mis padres ya que me apoyaron de forma económica para
poder solventar los gastos que conllevo elaborar el presente proyecto de
investigación y al apoyo moral que me brindaron en diferentes circunstancias. Del
mismo modo extiendo mi agradecimiento a mi docente facilitar Silvia Jiménez
Hernández quien me apoyo en la asesoría y coordinación para llevar a cabo un buen
proyecto de investigación.
Resumen
Este proyecto tiene como finalidad plasmar el estado actual de las metodologías
agiles para el desarrollo de software en las organizaciones, cuales es el impacto que
tiene la agilidad, que fallas tienen las metodologías agiles, cuales las herramientas y
técnicas más usadas por los desarrolladores. En el que se muestra cómo es que el rey
de las metodologías agiles es y seguirá siendo por mucho SCRUM, y como es que el
factor más importante que frena la implementación y el uso correcto de la agilidad es
la cultura de la empresa contra los principios de la agilidad y la falta de capacidad
para cambiar la cultura de la organización.
El presente proyecto de investigación como ya mencionamos muestra el estado actual

de las metodologías agiles para el desarrollo de software por tal motivo tiene un
tiempo de vida muy corto, por lo que en un tiempo no mayor a tres años perderá
esencia.
El mismo proyecto muestra cuales son las características que le han permitido a
SCRUM posicionarse como el padre de la agilidad y porque las metodologías
hibridas han obtenido cada vez mayor fuerza entre los desarrolladores de software.
Contenidos
1 Introducción ........................................................................................................ 10
2 Antecedentes del problema ................................................................................... 9
3 Planteamiento del Problema ................................................................................ 10
4 Objetivos ............................................................................................................. 11
4.1 Objetivo General: .............................................................................................. 11
4.2 Objetivos Específicos:....................................................................................... 11
5 Justificación......................................................................................................... 12
6 Marco Teórico ..................................................................................................... 16
6.1 Capítulo I Introducción a las Metodologías Agiles...................................... 16
6.1.1 Manifiesto Ágil .......................................................................................... 17
6.1.2 Diferencia entre metodologías agiles y tradicionales................................. 20
6.1.3 Metodologías agiles ................................................................................... 21
6.2 Capítulo II Estado actual de las metodologías agiles ....................................... 64
6.2.1 ¿Qué Beneficios aporta la Agilidad a tu empresa? .................................... 64
6.2.2 ¿Qué técnica ágil es la más usada? ........................................................... 68
6.2.3 Porque falla la agilidad y los proyectos agiles .......................................... 72
6.2.4 Quien frena la implantación de la Agilidad ............................................... 76
6.2.5 Las herramientas más utilizadas................................................................. 79
6.2.6 ¿Qué Metodologías se usan más? ............................................................. 81
6.3 Capítulo III Tendencia de las metodologías agiles: SCRUM ......................... 85
6.3.1 Introducción ............................................................................................... 85
6.3.2 ¿Por qué utilizar SCRUM?......................................................................... 86
6.3.3 Principios de SCRUM ............................................................................... 89
6.3.4 Organización .............................................................................................. 92
6.3.5 Procesos de SCRUM ................................................................................. 95
6.3.6 Scrum vs. Proyectos tradicional .............................................................. 102
6.3.7 Practicas .................................................................................................. 103
7 Método empleado en la investigación, instrumentos empleados. ..................... 107
8 Análisis estadístico e inferencias de los datos obtenidos. ................................. 108
9 Análisis comparativo de los resultados obtenidos contra los esperados. .......... 111
10 Elaboración de conclusiones ......................................................................... 118
11 Hipótesis ........................................................................................................ 120
12 Bosquejo del método ..................................................................................... 121
13 Cronograma ................................................................................................... 122
14 Presupuesto y/o financiamiento .................................................................... 124
15 Lista de referencias ....................................................................................... 126
Índice de tablas y figuras
Tabla 1 Diferencia entre metodologías agiles y tradicionales .................................... 20

Tabla 2 Resumen de los procesos de SCRUM ........................................................... 96
Tabla 3 Scrum vs Proyectos tradicionales ................................................................ 102
Tabla 4 Beneficios que aporta la agilidad en las empresas ....................................... 108
Tabla 5 Técnica ágil mas usadas en 2015, 2016 y 2017 ........................................... 108
Tabla 6 Porque falla la agilidad y los proyectos agiles ............................................ 109
Tabla 7 Quien frena la implantación de la Agilidad ................................................. 109
Tabla 8 Las herramientas más utilizadas en 2015, 2016 y 2017 ............................... 110
Tabla 9 Metodologias mas usadas en 2015, 2016 y 2017 ......................................... 110
Tabla 10 Presupuesto al periodo Agosto-Diciembre 2016 ....................................... 124
Tabla 11 Presupuesto al periodo Enero-Julio 2017................................................... 125
Tabla 12 Presupuesto Total de la Investigación ........................................................ 125
Figura 1 Proceso de Scrum ......................................................................................... 23

Figura 2 Ficha de Producto Backlog utilizada en Scrum ............................................ 25
Figura 3 Ficha de Sprint Backlog utilizadas en Scrum ............................................... 27
Figura 4 Pasos del Proceso de Extreme Programming .............................................. 30
Figura 5 Las prácticas se refuerzan entre sí. ............................................................. 35
Figura 6. Proceso de FDD ........................................................................................... 43
Figura 7. Clasificación de los roles de FDD ............................................................. 44
Figura 8. Fases e interacción de RUP durante el ciclo de vida ................................... 51
Figura 9. Prácticas de RUP ......................................................................................... 55
Figura 10. Prácticas de DSDM ................................................................................... 60
Figura 11. Flujo de SCRUM para Sprint ................................................................... 86
Figura 11. Principios de SCRUM ............................................................................... 90
Figura 12 Organización en SCRUM ........................................................................... 95
Figura 13 Ficha de Producto Backlog utilizada en Scrum ....................................... 103
Figura 14 Ficha de Sprint Backlog utilizadas en Scrum ........................................... 105
Índice de Graficas
Grafica 1 Beneficos de la agilidad 2015 ................................................................... 65

Grafica 2 Beneficios de la agilidad 2016 ................................................................... 66
Grafica 3 Beneficios de la agilidad 2017 ................................................................... 67
Grafica 4 Técnicas más usadas 2015 ......................................................................... 69
Grafica 7 Fallas de la agilidad y procesos agiles 2015 ............................................. 73
Grafica 8 Falla de la agilidad y los proyectos 2016 ................................................. 74
Grafica 9 Falla de la agilidad y proyectos 2017 ........................................................ 75
Grafica 10 Quien frena la implementación de la agilidad 2015................................. 76
Grafica 11 Quien frena la implementación de la agilidad 2016................................. 77
Grafica 12 Quien frena la implemetación de la agilidad............................................ 78
Grafica 13 Herrmientas mas usadas del 2015 ........................................................... 79
Grafica 14 Herramientas mas usadas del 2016 ........................................................ 80
Grafica 15 Herramientas mas usadas del 2017 ......................................................... 81
Grafica 16 Metodologías mas usadas en el 2015 ....................................................... 82
Grafica 17 Metodologías mas usadas en el 2016 ....................................................... 83
Grafica 18 Metodologías mas uasadas en el 2017 ..................................................... 84
Grafica 19 Aumento de la productividad del Equipo.............................................. 111
Grafica 20 Aumento de la productividad en los proyectos ...................................... 112
Grafica 21 Técnicas más usadas en 2015, 2016 y 2017 ........................................... 113
Grafica 22 Herramientas más usadas en 2015, 2016 y 2017 .................................. 114
Grafica 23 Metodologías más usadas en 2015, 2016 y 2017 ................................... 115
Grafica 24 Capacidad para cambiar la cultura de las organizaciones ...................... 116
Grafica 25 Falta de experiencia en metodologías agiles .......................................... 117
1 Introducción
En la presente investigación, se plasma algunas de las metodologías agiles más

usadas para el desarrollo de software dentro de una organización dedicada a estés
medio, además dar a conocer el estado actual de las metodologías agiles basado en
los estudios realizados por profesionistas que tiene una interacción continua con
dichas metodologías, plasmando también la metodología más usada y por qué la
selección de esta. Para que así el lector tenga una visión más clara y asertiva al
momento de seleccionar una metodología para el desarrollo de software, tomando
como referencia la experiencia de empresas desarrolladoras de software.
Para abordar la investigación, se dividió la misma en tres capítulos. En el Capítulo

uno se plasma las metodologías agiles más usadas y más comunes dentro del
desarrollo de software, en las cuales de describe por cada una de ellas una breve
historia de su surgimiento, sus procesos, roles y prácticas propias de cada
metodología. En el Capítulo dos, se describen las fallas, los beneficios e impactos
actuales que han tenido las organizaciones al aplicar una metodología de desarrollo
ágil y las herramientas más usadas que apoyan a la gestión de desarrollo de
software. Y en el Capítulo tres, se describe la mitología ágil más usadas y porque de
esta, también las fallas y contratiempos que tiene aplicar esta metodología llamada
SCRUM.
2 Antecedentes del problema
El árbol del problema es una forma de representar el problema ayuda a encontrar

soluciones a través del mapeo del problema. Identifica en la vertiente superior, las
causas o determinantes y en la vertiente inferior las consecuencias o efectos.
eXtreme Programming
Criterios de selección de metodologías de

desarrollo de software
9
3 Planteamiento del Problema
El desarrollo de software no es una tarea nada sencilla, sobre todo cuando no se

cuenta con la experiencia necesaria para laborar en esta actividad, por mucho tiempo
esta labor se ha llevado adelante sin la utilización de una metodología definida.
Pero no fue hasta 1970 que Wiston Royce W. Publico la primera descripción formal
del modelo de “cascada”. A partir de allí respecto a las metodologías de desarrollo de
software se han entablado dos grandes corrientes, por un lado, las denominadas
metodologías tradicionales centradas en el control del proceso, con un riguroso
seguimiento de las actividades involucradas en ellas, es decir imponen una disciplina
de trabajo en el procesos de desarrollo de software con el fin de conseguir un
software más eficiente. Por otro lado, las metodologías agiles, centradas en el factor
humano, en la colaboración y participación del cliente en el proceso de desarrollo de
software a un incesante incremento de software con internaciones muy cortas.
En los últimos años se ha popularizado el uso de metodologías ágiles aplicadas al

desarrollo de software. Scrum, eXtream Programming, Kanban, Lean Software
Development o ScrumBan son términos que empezaron a ser conocidos y utilizados
en el mundo del desarrollo con cierta asiduidad. Este tipo de prácticas modificaron la
tradicional visión de proyectos en cascada aportando una alternativa interesante a este
tipo de desarrollos y merece la pena, explorarlos y conocerlos para saber si son de
utilidad en todo tipo de proyectos. Por tal motivo esta investigación tiene como
finalidad elaborar un compendio que plasme el estado actual de las metodologías
agiles para el desarrollo de software, los beneficios que tiene la aplicación de dichas
mitologías en las organizaciones, el impacto que tienen en las pequeñas, medianas y
grandes empresas, así sus herramientas de desarrollo y tendencias, permitiendo una
mejor visión para la selección y adopción de una metodología ágil a un proyecto
nuevo de desarrollo de software.
10
4 Objetivos
4.1 Objetivo General:
Presentar el estado actual de las metodologías agiles para el desarrollo de software,

los beneficios e impacto que tiene la aplicación de metodologías agiles en las
diferentes organizaciones.
4.2 Objetivos Específicos:
 Conceptualizar las metodologías agiles más usadas por las organizaciones,

plasmando sus roles, actividades y prácticas.
 Presentar el impacto que tiene la aplicación de metodologías agiles en las

pequeñas, medianas y grandes empresas.
 Mostrar los beneficios y fallas que tiene la aplicaciones de metodologías

agiles a las organizaciones.
 Analizar las técnicas más usadas dentro de las metodologías agiles para el
desarrollo de software.
 Conocer las herramientas para el desarrollo de software en las metodologías

agiles.
11
5 Justificación
El motivo que me llevo a investigar los beneficios, fallas, impactos y otros aspectos
que tienen las metodologías agiles para el desarrollo de software en las
organizaciones, se centra principalmente en que la mayoría de nosotros como
estudiantes, tenemos noción de que es una metodología ágil para el desarrollo de
software, pero no tenemos claro en que basarnos para elegir alguna metodología ágil
para el desarrollo de software, por lo que es necesario investigar qué tipo de
metodología ágil resulta adecuada a una empresa. Y porque adopto dicha
metodologías en base a sus actividades y experiencias en el desarrollo de software,
así como a experiencia y opiniones de programadores agiles, para que el lector en
base a su propia visión y criterios tome una decisión asertiva en la selección de una
metodología ágil, que le permita aumentar la productividad en el desarrollo de
software dentro de una empresa.
Impacto Social:
Hoy en día con el auge de la tecnología, y con el objetivo de agilizar y automatizar

los procesos en el desarrollo de software, nos vemos en la necesidad de implantar
Metodologías de Desarrollo de Software ágil que nos ayuden a entregar un producto
de calidad en tiempo estimados, las metodologías ágiles de desarrollo de software han
despertado interés gracias a que proponen simplicidad y velocidad para desarrollar
software. Sin embargo existen organizaciones que no se adaptan a las nuevas
necesidades o expectativas que tiene los clientes hoy en día, Pues estos cambios
generalmente implican altos costos, demanda de tiempo y la reestructuración total de
procesos que se esté llevando. El impacto social al llevar a cabo esta investigación
se centra en proponer un cambio del paradigma en la forma en la que
habitualmente trabajan las organizaciones, en otras palabras es mostrar un cambio
12
en la forma de trabajar de las empresas al desarrollar un determinado producto de
software y al temor que tiene las empresas al adoptar un cambio en la restructuración
total de sus procesos, pensando que la permanencia es más factible en un mundo
cambiante o por el no poder asumir los gastos que requiere un cambio.
Impacto Económico:
El impacto económico de un proyecto social se entiende como el nivel de eficiencia

económica del mismo; es decir, corresponde a una comparación de la totalidad de los
costos y beneficios sociales resultantes del proyecto, es por eso que para alcanzar
dicho nivel de eficiencia las organizaciones desarrolladoras de software deben optar
por adoptar una buena metodología para el desarrollo de software y utilizar esta
adecuadamente para reducir gastos y realizar una buena estimación del valor de cada
proyecto.
El impacto económico tiene mucho en común con el impacto social ya que este afecta
en los potenciales impactos sobre el empleo, que es de donde se estima el valor de
cada proyecto, en el caso de las metodologías agiles se utilizan practicas empíricas
basadas en el juicio de expertos para estimar el costo de desarrollo para un nuevo
producto, se pueden utilizar diferentes prácticas para estimar dichos costo dentro de
las cuales las más comunes involucran como métrica base a los SP (Story Points -
Cohn, 2005; Sulaiman y Barton, 2006;) y a los FP (Function Points - Kang y Choi,
2010). Que le permita al responsable de cada proyecto dar un valor al negocio por su
respectivo proyecto, programas o carteras.
Por lo cual la elaboración del presente documento de investigación sobre las

metodologías agiles tendrá un costo aproximado de 13,600 pesos, ya que se estima la
investigación en varios documentos, tesis, artículos y estudios realizados en las
empresas, además se considera el esfuerzo que se le dedica a la presente
13
investigación. En la presente investigación sobre las metodologías agiles está
planeado en un tiempo estimado de 14 semanas distribuidas en las diferentes etapas;
1na semana de planeación y análisis de la investigación, 12 semanas para la
elaboración de la investigación, y 1 semana para elaboración de presentación,
entrega de la investigación y entrega de la misma. En el cual documentaremos y
expondremos el beneficio, las y el impacto que puede presentar la implementación
de una metodología agile en las organizaciones.
Impacto Tecnológico:
Hoy en día la tecnología y comunicación avanzan a una velocidad considerable, lo

que ha provocado que la gestión de proyectos de software deba alcanzar la velocidad
de los cambios ocasionados por esta aceleración.
Esto por cierto, ha traído consigo la utilización de distintas herramientas que apoye la
gestión de proyectos de software, obteniendo un impacto favorable en la calidad,
eficiencia, flexibilidad y rapidez en la entrega de un determinado producto,
verificando su pertinencia y optimizando el uso de herramientas para mejorar la
productividad.
En esta investigación es palpable el uso de tecnologías en la utilización de
herramienta como soporte a las metodologías agiles, que apoyen a los programadores
en la gestión de proyectos de software, por mencionar algunas como Microsoft
Excel, Atlassian/JIRA, Microsoft Project, VersionOne.
Impacto Ético
Esta investigación está fundamentada en la visión que tienen los profesionistas que
han realizado estudios previos y actividades continuas con las metodologías agiles y
con el impacto que tiene las empresas al aplicar una metodología para el desarrollo de
software, otorgándoles créditos a su arduo trabajo de investigación, documentación
14
y prácticas realizadas. Por tal motivo esta investigación pretende que los
desarrolladores tengan una visión de que metodología de desarrollo utilizar en las
organizaciones. Los códigos éticos deben influir en las habilidades de los
programadoras garantizando al cliente un producto de calidad, eficiente, flexible y de
rápida entrega.
Impacto Ambiental:
Este tipo de investigación no tiene un impacto directo con ambiente, ya que es un

trabajo de tipo documental con el que se pretende recabar información que apoyo la
selección adecuada de una metodología ágil. Sin embargo un impacto indirecto que
pudiera considerarse seria que al adoptar una metodología ágil se debe contar con
tecnología actualizada actualizadas que sean más amigable con el medio ambiente
(Green Computing), teniendo como consecuencia la minimización al deterioro del
medio ambiente, disminución del consumos de energía y promover el reciclaje
computacional para lo cual se pretende que la metodología utilizada sea la más viable
también en este sentido.Agregar
15
6 Marco Teórico
6.1 Capítulo I Introducción a las Metodologías Agiles
En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término “ágil”
aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos
de la industria del software, incluyendo algunos de los creadores o impulsores de
metodologías de software. Su objetivo fue esbozar los valores y principios que
deberían permitir a los equipos desarrollar software rápidamente y respondiendo a
los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una
alternativa a los procesos de desarrollo de software tradicionales, caracterizados por
ser rígidos y dirigidos por la documentación que se genera en cada una de las
actividades desarrolladas.
Tras esta reunión se creó “The Agile Alliance”, una organización, sin ánimo de
lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de
software y ayudar a las organizaciones para que adopten dichos conceptos. El punto
de partida es fue el Manifiesto Ágil, un documento que resume la filosofía “ágil”
16
6.1.1 Manifiesto Ágil
El manifiesto se valora:
 Al individuo y las interacciones del equipo de desarrollo sobre el proceso

y las herramientas.
La gente es el principal factor de éxito de un proyecto software. Es más

importante construir un buen equipo que construir el entorno. Muchas veces
se comete el error de construir primero el entorno y esperar que el equipo se
adapte automáticamente. E mejor crear el equipo y que éste configure su
propio entorno de desarrollo en base a sus necesidades.
 Desarrollar software que funciona más que conseguir una buena

documentación.
La regla a seguir es “no producir documentos a menos que sean necesarios de

forma inmediata para tomar un decisión importante”. Estos documentos deben
ser cortos y centrarse en lo fundamental.
 La colaboración con el cliente más que la negociación de un contrato.
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.
 Responder a los cambios más que seguir estrictamente un plan.
17
La habilidad de responder a los cambios que puedan surgir a los largo del
proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.)
determina también el éxito o fracaso del mismo. Por lo tanto, la planificación
no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son características
que diferencian un proceso ágil de uno tradicional. Los dos primeros principios son
generales y resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso
a seguir y con el equipo de desarrollo, en cuanto metas a seguir y organización del
mismo. Los principios son:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas

entregas de software que le aporte un valor.
II. . Dar la bienvenida a los cambios. Se capturan los cambios para que el
cliente tenga una ventaja competitiva.
III. Entregar frecuentemente software que funcione desde un par de semanas

a un par de meses, con el menor intervalo de tiempo posible entre
entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo

largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno
y el apoyo que necesitan y confiar en ellos para conseguir finalizar el
trabajo.
18
VI. El diálogo cara a cara es el método más eficiente y efectivo para
comunicar información dentro de un equipo de desarrollo.
VII. El software que funciona es la medida principal de progreso.
VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberían ser capaces de mantener una paz
constante.
IX. La atención continua a la calidad técnica y al buen diseño mejora la

agilidad.
X. La simplicidad es esencial.
XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos

organizados por sí mismos.
XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser
más efectivo, y según esto ajusta su comportamiento.1
Grupo ISSI (ingeniería de Software y Sistemas de Informacion), (12 al 14 de Noviembre de 2003). Metodologias Agiles en el
Desarrollo de Software. Pg 59. Alicante, España. Universidad Politecnica de Valencia
19
6.1.2 Diferencia entre metodologías agiles y tradicionales
Tabla 1 Diferencia entre metodologías agiles y tradicionales
20
6.1.3 Metodologías agiles
Scrum
Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco
para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10
años. Está especialmente indicada para proyectos con un rápido cambio de requisitos.
Sus principales características se pueden resumir en dos. El desarrollo de software se
realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El
resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La
segunda característica importante son las reuniones a lo largo proyecto, entre ellas
destaca la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e
integración.2
Proceso
El proceso de Scrum consta de tres fases: pre-game, desarrollo o game y post-game.
 Pre-Game, Subfase Planning: El planteamiento incluye la definición del

sistema a desarrollar y asegurar la financiación. Se crea una lista de
acumulación o pila de producto, Product Backlog list conteniendo todos los
requisitos conocidos hasta el momento. Los requisitos los puede originar el
2
Grupo ISSI (ingeniería de Software y Sistemas de Informacion), G. I. (12 al 14 de Noviembre de
2003). Metodologias Agiles en el Desarrollo de Software. Pg 59. Alicante, España
21
cliente, los programadores o los departamentos de ventas, marketing o
atención al cliente. Se priorizan los requisitos y se estima el esfuerzo
necesario para su desarrollo. La Product Backlog list se actualiza
constantemente con puntos nuevos y más detalles, así como con estimaciones
más exactas y el nuevo orden de prioridades. El planning también incluye la
definición del equipo del proyecto, herramientas y otros recursos, la
valoración de riesgos, necesidades de formación y la aprobación de la gestión
de comprobaciones. En cada iteración, el equipo(s) de Scrum revisa la
Product Backlog list actualizada. En la jerga de Scrum, se llaman paquetes a
los objetos o componentes que necesitan cambiarse en la siguiente iteración.
 La Fase Desarrollo (Game): Esta fase, la parte ágil de Scrum, se trata como
una caja negra donde se espera lo imprevisible. Las diferentes variables
técnicas y de entorno que pueden cambiar (calendario, calidad, requisitos,
recursos, tecnologías, herramientas, e incluso métodos de desarrollo) se
observan y controlan durante los sprints. En lugar de considerar estos puntos
sólo al principio del proyecto, Scrum los controla constantemente para
adaptarse a los cambios. En la fase de desarrollo, el sistema funciona en
sprints o carreras cortas. Los sprints son ciclos iterativos donde se desarrollan
o mejoran las funcionalidades para producir los nuevos incrementos. Cada
sprint incluye las fases habituales de desarrollo del software: requisitos,
análisis, diseño, desarrollo y entrega. La arquitectura y el diseño del sistema
evolucionan durante el desarrollo del sprint. Un sprint dura de una semana
a un mes. Puede haber de tres a ocho sprints, por ejemplo, antes de que el
sistema esté listo para lanzarse. También puede haber más de un equipo que
construya cada incremento.
22
 La Fase Post-Game: Contiene el cierre de la versión. Se entra en esta fase
cuando se completan todos los requisitos. En este caso, no se incorpora ni
mejora ninguna función. El sistema ya está listo para lanzarse (release) y
ahora se integra, se pone a prueba y se documenta.
Figura 1 Proceso de Scrum
Roles
Los papeles en Scrum tienen tareas y propósitos diferentes durante el proceso y sus
prácticas. Son: Scrum Master, Product Owner, equipo de Scrum, Cliente o usuario y
Dirección o Gestión. Veamos sus funciones:
23
 Scrum Master: El Scrum Master es responsable de asegurar que el proyecto
se realiza según las prácticas, valores y reglas de Scrum y que progresa como
estaba previsto. Actúa recíprocamente tanto con el equipo del proyecto como
con el cliente. También es responsable de resolver cualquier impedimento
para seguir trabajando tan productivamente como sea posible.
 Propietario Del Producto:El propietario del producto es oficialmente

responsable del proyecto, gestionando, controlando, y haciendo visible la
Product backlog list. Es elegido por el Scrum Master, el cliente y la dirección.
Toma las últimas decisiones de las tareas relacionadas con la Product backlog
list, participa estimando el esfuerzo de desarrollo para los puntos del Backlog
y los concreta en funcionalidades a desarrollar.
 Equipo De Scrum: El equipo de Scrum tiene autoridad para decidir las

acciones pertinentes para organizarse lograr lo propuesto en cada sprint. El
equipo de Scrum está involucrado, por ejemplo, en estimar el esfuerzo
requerido para cada parte, crear y revisar la Product Backlog list e identificar
problemas a tratar.
 Cliente: El cliente participa en las tareas relacionadas con los puntos del
Backlog para diseñar o mejorar el sistema.
 Director: La gestión o dirección toma la última decisión y se encarga de los

documentos, normas y convenciones seguidas en el proyecto. La dirección
también participa en identificar objetivos y requisitos. Por ejemplo, ayuda a
seleccionar el product owner, valorar los progresos y reducir el Backlog con el
Scrum Master.
24
Practicas
 Product Backlog: El Product Backlog define todo lo necesario en el producto

final, basándose en los conocimientos de ese momento. Por tanto, define el
trabajo a hacer en el proyecto. incluye una lista ordenada por prioridades y
actualizada de requisitos técnicos para que el sistema se haga o mejore. Los
puntos del Product Backlog, por ejemplo, pueden incluir características,
funciones, parches para bugs, defectos, peticiones de mejoras o
actualizaciones de tecnología. También se incluyen temas que requieren
solución para poder hacer otros puntos de la lista. A la lista de backlog puede
contribuir el cliente, el equipo del proyecto y los departamentos de ventas,
marketing y atención al cliente.
Figura 2 Ficha de Producto Backlog utilizada en Scrum
 Estimación De Esfuerzo: La estimación de esfuerzo es un proceso iterativo

donde las estimaciones de cada punto se detallan más a fondo partiendo de la
información disponible en cada momento. El Product Owner junto con el
equipo se encarga de estas estimaciones.
25
 Sprint: El sprint consiste en adaptarse a las condiciones cambiantes del
proyecto como requisitos, tiempo, recursos, conocimiento, tecnología, etc. El
Equipo de Scrum se organiza para producir un nuevo incremento ejecutable en
un sprint que dura aproximadamente un mes natural. Las herramientas activas
del equipo son las reuniones para planear el sprint, el Sprint Backlog y las
reuniones diarias de Scrum.
 Reunión Para Planear El Sprint: El Sprint Planning meeting consta de dos

fases y la organiza el Scrum Master. En la primera fase, los clientes, usuarios,
la dirección, el Product Owner y el equipo, eligen los objetivos y las
funcionalidades del próximo sprint. En la segunda fase, el Scrum Master y el
equipo concretan la manera de conseguir esos objetivos (product increment)
en el siguiente sprint.
 Sprint Backlog: Es el punto de partida para cada sprint, una lista de puntos
de la lista del Product Backlog seleccionados para llevarse a cabo en el
próximo sprint. El equipo de Scrum junto con el Scrum Master y el Product
Owner seleccionan los puntos en la reunión para planear el Sprint, basándose
en los puntos con prioridad y los objetivos de ese sprint. A diferencia del
Product Backlog, el Sprint Backlog no se modifica hasta que el sprint (es
decir, 30 días) termina. Cuando todos los puntos del Sprint Backlog están
completos, se prepara una nueva iteración del sistema.
26
Figura 3 Ficha de Sprint Backlog utilizadas en Scrum
 Reunión Diaria De Scrum: Se organizan reuniones de Scrum diarias para

seguir el progreso del equipo y planear las reuniones: qué se ha hecho desde la
última reunión y qué se hará para la siguiente. también se ponen sobre la
mesa problemas y otros asuntos que puedan aparecer en esta reunión diaria de
unos 15 minutos. Se busca y soluciona cualquier deficiencia o imprevisto del
proceso. El Scrum Master dirige las reuniones. La dirección (Management),
también puede colaborar en la reunión.
 Sprint Review Meeting: En el último día del sprint, el equipo y el Scrum

Master presentan los resultados del sprint, (el incremento producido) a la
dirección, clientes, usuarios y Product Owner en una reunión informal. Los
participantes evalúan la evolución y deciden sobre las siguientes actividades.
La reunión de la revisión puede revelar nuevos puntos e incluso cambiar la
dirección tomada del sistema que se está construyendo.
27
eXtream Programming (XP)
Extreme Programming (a veces escrito eXtreme Programming) o programación

extrema, surgió como respuesta a la lentitud de los modelos tradicionales de
desarrollo. En 1999, Kent Beck6 puso por escrito la metodología de XP. Aunque las
tácticas por separado que utiliza XP no son novedosas, la manera de unirlas sí. El
adjetivo “eXtreme” viene de llevar al extremo principios de sentido común: “si
diseñar es bueno, diseñemos todo el tiempo”, “si las pruebas son buenas, probemos
todo el tiempo”. Se suele conocer como los “three extremoes” a Kent Beck, Ron
Jeffries y Ward Cunningham. Las siglas XP no tienen relación con la versión Xp de
Windows, donde significan “experience”, aunque Microsoft utiliza prácticas ágiles. 3
Procesos
 En la fase de Exploración, los clientes escriben las historias en las tarjetas o

fichas (story cards) lo que desean en la primera versión o release. Cada tarjeta
describe una característica a implementarse, por ejemplo “Cuando el cliente
encuentra un producto que quiere comprar, lo añade a su carrito de la
compra y continúa la compra”. A partir de estas historias y de la prioridad
que los clientes les asignan, se construye toda la planificación.
 La fase de Planificación de las versiones establece el orden de prioridad de

las fichas y las funciones de la primera versión. Los programadores estiman
3
Raúl Úbeda González. (Marzo de 2009). Métodos ágiles para el desarrollo de software. Proyecto de
Titulacio, Pg 407. Catalunya, España
28
cuánto tiempo requiere cada función y se acuerda un calendario. El tiempo
para la primera versión normalmente no excede de dos meses. La propia fase
de planificación necesita un par de días. La fase de Planificación de las
Iteraciones para lanzar una versión incluye varias iteraciones de los sistemas
antes de la primera versión. El calendario propuesto en la etapa de
planificación se divide en un número de iteraciones de entre una y cuatro
semanas. La primera iteración crea un sistema con la arquitectura del sistema
completo. Esto es posibles gracias a elegir las historias que serán la base del
sistema, no detalles. El cliente decide las historias para cada iteración. Las
pruebas funcionales, propuestas por el cliente, se realizan al final de cada
iteración. Al final de la última iteración, el sistema está listo para la
producción.
 La fase de Productionizing requiere más pruebas y verificar el rendimiento

del sistema antes de dárselo al cliente. Aquí, todavía pueden encontrarse
nuevos cambios y se deberán hacer si se pactaron para esa versión
determinada. Es posible que algunas iteraciones tengan que acelerarse. Las
ideas pospuestas y sugerencias se documentan para realizarlas más adelante,
por ejemplo, en la fase de mantenimiento.
 La fase de Muerte está cercana cuando el cliente ya no tiene ninguna

funcionalidad o historia pendiente de ser implementada. Esto implica que el
sistema satisface en todos los aspectos (rendimiento, fiabilidad, etc.) al
cliente. Ahora es cuando se escribe la documentación ya que no se harán más
cambios. Esta fase también puede ocurrir si el sistema no proporciona los
29
resultados esperados o si se hace demasiado caro para continuar
desarrollándolo.47
Figura 4 Pasos del Proceso de Extreme Programming
Roles
Hay diferentes papeles en XP para cada tarea y propósito durante el proceso y su

práctica:
 Programador: Los programadores escriben las pruebas y mantienen el

código del programa tan simple y optimizado como sea posible. Para que XP
4
o Grupo ISSI (ingeniería de Software y Sistemas de Información), G. I. (12 al 14 de Noviembre
de 003). Metodologías Agiles en el Desarrollo de Software. Pg 59. Alicante, España
30
tenga éxito, debe haber comunicación y coordinación entre los programadores
y los otros miembros del equipo. Se encargan de estimar el tiempo que llevará
implementar las funciones del sistema asociadas a cada historia, definir las
tareas que conlleva cada una e implementan las historias y las pruebas
unitarias.
 Cliente “En Casa” (On-Site): El cliente escribe las historias en fichas y las
pruebas funcionales, decidiendo cuándo dar por válida cada funcionalidad. El
cliente establece la prioridad de implementación de los requisitos o
funcionalidades. En la segunda versión de XP, el papel del cliente ha
cambiado ligeramente: originalmente era una sola persona, correspondía al
perfil de un cliente real (preferentemente, un usuario final del sistema) y
permanecía durante todo el proyecto en la misma habitación que el equipo de
programadores. Después, el papel de Cliente se asignó a un solo analista de
negocios, en lugar de a un cliente real o a un usuario. En la actualidad, el
papel del cliente lo suele desempeñar un equipo de analistas.
 TesterLos verificadores/comprobadores ayudan al cliente a escribir las

pruebas funcionales que ejecutan regularmente. También informan de los
resultados y mantienen las herramientas para verificar. De acuerdo con Beck,
“Un tester XP no es una persona separada, dedicada a romper el sistema y
humillar a los programadores”.
 Supervisor (Tracker): Se encarga de proporcionar feedback. Hace un

seguimiento de las estimaciones hechas por el equipo dando feedback para
saber cuán precisas son, para tener más precisión en estimaciones futuras.
También sigue el progreso de cada iteración y evalúa si el calendario
establecido es viable o si se ha de modificar parte del proceso.
31
 Entrenador O Instructor: El coach, con un sólido conocimiento de XP,
guiará a los miembros del equipo y es el responsable del proceso en conjunto.
Vigila todo el proceso y se asegura de que el proyecto continúa siendo
extremo, es decir, que se cumplen las doce prácticas. Beck comenta que la
función más relevante del coach es la adquisición de juguetes y comida; otros
dicen que está para servir café. Lo importante es que el coach se vea como un
“facilitador” o ayudante, antes que como alguien que da órdenes. Métodos
ágiles para el desarrollo de software Métodos
 Consultor: El consultor o asesor es un miembro externo que posee el

conocimiento técnico específico necesario. El consultor guía al equipo para
resolver problemas específicos.
 Gestor O Director (Manager, Big Boss): El director toma las decisiones. Se

comunica con el equipo del proyecto para determinar la situación actual y
para distinguir cualquier dificultad o deficiencia en el proceso. 5
Practicas
La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica

curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que
el diseño evolutivo funcione. Esto se consigue gracias a las tecnologías disponibles
5
Titulación, Pg 407. Catalunya, España
32
para ayudar en el desarrollo de software y a la aplicación disciplinada de las
siguientes prácticas.
 El juego de la planificación. Hay una comunicación frecuente el cliente y los

programadores. El equipo técnico realiza una estimación del esfuerzo
requerido para la implementación de las historias de usuario y los clientes
deciden sobre el ámbito y tiempo de las entregas y de cada iteración.
 Entregas pequeñas. Producir rápidamente versiones del sistema que sean

operativas, aunque no cuenten con toda la funcionalidad del sistema. Esta
versión ya constituye un resultado de valor para el negocio. Una entrega no
debería tardar más 3 meses.
 Metáfora. El sistema es definido mediante una metáfora o un conjunto de

metáforas compartidas por el cliente y el equipo de desarrollo. Una metáfora
es una historia compartida que describe cómo debería funcionar el sistema
(conjunto de nombres que actúen como vocabulario para hablar sobre el
dominio del problema, ayudando a la nomenclatura de clases y métodos del
sistema).
 Diseño simple. Se debe diseñar la solución más simple que pueda funcionar y
ser implementada en un momento determinado del proyecto.
 Pruebas. La producción de código está dirigida por las pruebas unitarias.

Éstas son establecidas por el cliente antes de escribirse el código y son
ejecutadas constantemente ante cada modificación del sistema.
33
 Refactorización (Refactoring). Es una actividad constante de
reestructuración del código con el objetivo de remover duplicación de código,
mejorar su legibilidad, simplificarlo y hacerlo más flexible para facilitar los
posteriores cambios. Se mejora la estructura interna del código sin alterar su
comportamiento externo.
 Programación en parejas. Toda la producción de código debe realizarse con

trabajo en parejas de programadores. Esto conlleva ventajas implícitas (menor
tasa de errores, mejor diseño, mayor satisfacción de los programadores, …)
 Propiedad colectiva del código. Cualquier programador puede cambiar

cualquier parte del código en cualquier momento.
 Integración continua. Cada pieza de código es integrada en el sistema una

vez que esté lista. Así, el sistema puede llegar a ser integrado y construido
varias veces en un mismo día.
 40 horas por semana. Se debe trabaja r un máximo de 40 horas por semana.

No se trabajan horas extras en dos semanas seguidas. Si esto ocurre,
probablemente está ocurriendo un problema que debe corregirse. El trabajo
extra desmotiva al equipo.
 Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo
para el equipo. Éste es uno de los principales factores de éxito del proyecto
XP. El cliente conduce constantemente el trabajo hacia lo que aportará mayor
valor de negocio y los programadores pueden resolver de manera inmediata
cualquier duda asociada. La comunicación oral es más efectiva que la escrita.
34
 Estándares de programación. XP enfatiza que la comunicación de los
programadores es a través del código, con lo cual es indispensable que se
sigan ciertos estándares de programación para mantener el código legible
Figura 5 Las prácticas se refuerzan entre sí.
Crystal Methodologies
Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas

por estar centradas en las personas que componen el equipo y la reducción al máximo
del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn.
El desarrollo de software se considera un juego cooperativo de invención y
comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un
factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y
destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas
35
dependerán del tamaño del quipo, estableciéndose una clasificación por colores, por
ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).6
Procesos
Todas las metodologías de Crystal proporcionan pautas de política de estándares,

workproducts o artefactos, “local matters”, herramientas, estándares y papeles que se
deben hacer en el proceso de desarrollo.
 Estándares De Política: Estas prácticas deben aplicarse durante el proceso

de desarrollo. Tanto Crystal Clear como Crystal Orange proponen las
siguientes normas:
a. Entregas incrementales regulares. Crystal Clear propone entregas

incrementales cada 2 o 3 meses y en Crystal Orange pueden ser hasta
cada 4 meses. Es la única diferencia entre las normas de política.
b. Seguimiento del progreso basado en las entregas de software y

decisiones importantes más que en documentos escritos.
c. Implicación directa del usuario.
6
Grupo ISSI (ingeniería de Software y Sistemas de Informacion), G. I. (12 al 14 de Noviembre
de 2003). Metodologias Agiles en el Desarrollo de Software. Pg 59. Alicante, España
36
d. Test de regresión automatizado, es decir, aplicado después de algún
cambio para ver si la resolución ha causado algún fallo en algo que
antes funcionaba.
e. Dos user viewings por versión.
 Workproducts: Los requisitos para los workproducts difieren hasta cierto

punto, según sea para Crystal clear o Crystal Orange. Los puntos comunes
para ambos son: secuencia de versiones, modelos de objetos comunes, manual
del usuario, casos de test y migración de código.
 Local Matters: Estos “asuntos internos” son procedimientos a aplicar,

aunque su realización se deja al propio proyecto. No difieren demasiado para
Clear y Orange: ambas metodologías sostienen que el propio equipo debe
establecer y mantener las plantillas para los orkproducts, así como tests de
regresión, y las normas del interfaz de usuario. Por ejemplo, la documentación
del proyecto es necesaria, pero su contenido y forma son un local matter.
Además de esto, las técnicas para los papeles individuales en el proyecto no
están definidas por Crystal Clear ni Orange.
 Estándares: Crystal Orange propone seleccionar las normas de notación, las

convenciones del plan, y las normas de formato y de calidad que se usarán en
el proyecto.
37
Roles
 PatrocinadorSe encarga de la Declaración de Misión con Prioridades de

Compromiso (Trade-off). Consigue los recursos y define la totalidad del
proyecto.
 Usuario Experto: Junto con el experto comercial, crea la Lista de Actores-

Objetivos y el Archivo de Casos de Uso y Requisitos. Debe familiarizarse con
el uso del sistema, sugerir atajos de teclado, modos de operación, información
a visualizar simultáneamente, navegación, etc.
 Diseñador Principal: Produce la Descripción Arquitectónica. El Diseñador

Principal tiene funciones de coordinador, arquitecto, mentor y programador
más experto. Se supone que debe ser al menos un profesional de nivel 3
 Diseñador-Programador: Junto con el Diseñador Principal se encarga de:7
a) Borradores
b) Modelo Común de Dominio
c) Notas y Diagramas de Diseño
d) Código Fuente
e) Código de Migración
f) Pruebas
38
g) Empaquetado del sistema
 Experto Comercial: Junto con el Usuario Experto crea la Lista de Actores-

Objetivos y el Archivo de Casos de Uso y Requisitos. Debe conocer las reglas
y políticas del negocio.
 Coordinador: Con la ayuda del equipo, crea el Mapa de Proyecto, el Plan de

Entrega, el Estado del Proyecto, la Lista de Riesgos, el Plan y Estado de
Iteración y la Agenda de Visualización.
 Verificador: Confecciona el informe de bugs. Puede ser un programador a

tiempo parcial, o un equipo.
 Escritor Técnico: Elabora el manual del usuario.7
Practicas
• Exploración de 360°. Verificar o tomar una muestra del negocio del

proyecto, los requisitos, el modelo de dominio, la tecnología, el plan del
proyecto y el proceso. La exploración es preliminar al desarrollo y equivale a
la fase inicial de RUP.
7
39
• Victoria temprana. Es mejor buscar pequeños triunfos iniciales que aspirar a
una gran victoria tardía. Usualmente, la primera victoria temprana consiste en
la construcción de un Esqueleto Ambulante. Conviene no utilizar la técnica de
“lo peor primero” de XP, porque puede bajar la moral. La preferencia de
Cockburn es “lo más fácil primero, lo más difícil segundo”.i
• Esqueleto ambulante. Es un paso que debe ser simple, pero completo. Podría
ser una rutina de consulta y actualización en un sistema cliente-servidor, o la
ejecución de una transacción en un sistema transaccional de negocios. Un
Esqueleto Ambulante no suele ser robusto; sólo camina, y carece de la “carne”
o funcionalidad de la aplicación real, que se agregará incrementalmente. Es
diferente de una spike, porque ésta es “la más pequeña implementación que
demuestra un éxito técnico plausible” y después se tira, porque puede ser
peligrosa; una spike sólo se usa para saber si se está en la dirección correcta
• Rearquitectura incremental. Se ha demostrado que no es conveniente

interrumpir el desarrollo para corregir la arquitectura. Más bien, la
arquitectura debe evolucionar en etapas, manteniendo el sistema en ejecución
mientras se modifica.
• Radiadores de información. Es una lámina pegada en algún lugar que el

equipo pueda observar mientras trabaja o camina. Tiene que ser comprensible
para el observador informal, entendida de un vistazo y renovada
periódicamente para que valga la pena visitarla.8
8
40
Feature -Driven Development (FDD)
Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2
semanas). Se centra en las fases de diseño e implementación del sistema partiendo de
una lista de características que debe reunir el software. Sus impulsores son Jeff De
Luca y Peter Coad. 9
Proceso
A continuación, se describen los cinco procesos según Palmer y Felsing:
 Elaborar Un Modelo General: Cuando empieza el desarrollo de un modelo

global, los domain experts (ver 2.4.2) ya son conscientes de las limitaciones,
contexto y requisitos del sistema a construir. Es probable que en esta fase, ya
exista la documentación de requisitos como los casos o las especificaciones
funcionales. Sin embargo, FDD no se dirige explícitamente a recoger y
gestionar los requisitos. Los expertos del dominio presentan el llamado
walkthrough o ensayo donde se informa a los miembros del equipo y al
arquitecto jefe (chief architect) de la descripción de alto nivel del sistema. El
dominio general se vuelve a dividir en diferentes áreas de dominio y se realiza
un ensayo más detallado para cada uno de ellos por los miembros del
dominio. Después de cada ensayo, un equipo de desarrollo trabaja en
pequeños grupos para producir modelos de objeto para el área del dominio. El
9
Grupo ISSI (ingeniería de Software y Sistemas de Informacion), G. I. (12 al 14 de Noviembre de
2003). Metodologias Agiles en el Desarrollo de Software. Pg 59. Alicante, España
41
equipo de desarrollo entonces discute y elige los modelos apropiados de
objeto para cada área del dominio. Simultáneamente, se construye un
diagrama del modelo global para el sistema.
 Construir Una Lista De Características (Features): Los ensayos, modelos

de objeto y la documentación existente de los requisitos son una buena base
para construir una lista extensa de características del sistema a desarrollar. En
la lista, el equipo de desarrollo presenta cada una de las funciones valoradas
por el cliente e incluidas en el sistema. Las funciones se presentan a cada área
del dominio y estos grupos de funciones se basan en conjuntos de
características principales (major feature sets). Además, los conjuntos de
características principales se dividen en conjuntos de características que
representan las diferentes actividades dentro de las áreas del dominio. Los
usuarios y patrocinadores repasan la lista de características del sistema para
validarla y completarla.
 Planear Por Característica: Este proceso incluye la creación de un plan a

alto nivel donde los conjuntos de características van en secuencia según su
prioridad y dependencias, y se asignan a los programadores jefe (chief
programmers,). Además, se asignan a los diseñadores individuales
(propietarios de las clases) las clases identificadas en el proceso de elaborar
un modelo general. También pueden establecerse horarios y milestones o
puntos de referencia para conjuntos de características.
 Diseñar Por Característica (Iterativa): Se selecciona un grupo pequeño de

características del conjunto de características, feature set(s), y los propietarios
de las clases forman los feature teams necesarios para desarrollar las
características seleccionadas. Diseñar y construir por característica son
42
procedimientos iterativos durante los cuales se confeccionan las
características seleccionadas.
 Construir Por Característica (Iterativa): Una iteración debería durar entre

unos días y 2 semanas. Puede haber varios feature teams diseñando
concurrentemente y construyendo su propio conjunto de características. Este
proceso iterativo incluye inspección del diseño, codificación, comprobar las
unidades e integración. Después de una iteración exitosa, las características
completadas se incorporan al programa principal (main build) mientras la
iteración de diseñar y construir vuelve a empezar con un nuevo grupo de
características del conjunto (set) de características.10
Figura 6. Proceso de FDD
10
43
Roles
FDD clasifica sus roles en tres categorías:
Figura 7. Clasificación de los roles de FDD
Un miembro del equipo puede tener varios papeles, y un mismo papel puede ser
compartido por varias personas. Los miembros y sus respectivas responsabilidades
son:
 Manager Del Proyecto: El director del proyecto es el líder administrativo y

financiero del proyecto. Una de sus tareas es proteger al equipo de
distracciones externas y permitirle avanzar proporcionado condiciones
favorables. En FDD, el director tiene la última palabra respecto alcance
(scope), horarios (schedule) y personal del proyecto (staffing).
44
 Arquitecto Jefe: El diseñador principal es responsable del diseño global del
sistema y de hacer los talleres con el equipo. También es quien toma las
últimas decisiones en todos los temas de diseño. Si fuera necesario, este papel
puede ser dividido en dos: arquitecto del dominio y arquitecto técnico.
 Manager De Desarrollo: El director de desarrollo dirige las actividades de

desarrollo diarias y resuelve cualquier conflicto que puede ocurrir dentro del
equipo, así como problemas de provisión de recursos o resourcing. Las
funciones de este papel pueden combinarse con las del arquitecto jefe o
Project Manager.
 Programador Jefe: El programador principal es experimentado y participa

en el análisis de requisitos y diseño de los proyectos. También es responsable
de encabezar los equipos pequeños en el análisis, diseño y desarrollo de
nuevas características.
 Propietarios De Las Clases: Los propietarios de las clases trabajan bajo la

orientación del programador principal en las tareas de diseño, codificación,
testeo y documentación. El propietario de una clase es responsable del
desarrollo de la clase que se le ha designado. Los propietarios de las clases
forman los feature teams. En cada iteración, participan cuando sus clases
están incluidas en la característica que se está programando.
 Experto Del Dominio: El Domain Expert puede ser un usuario, un cliente,

un patrocinador, analista comercial o una mezcla de éstos. Su función es saber
cómo deberían funcionar los diferentes rrequisitos del sistema para explicarlo
a los diseñadores y asegurar que entregan un sistema adecuado.
45
 Gestor Del Dominio: El Domain Manager dirige a los expertos del dominio
y resuelve sus diferencias de opiniones acerca de los requisitos para el
sistema.
 Gestor De Versiones: El Release Manager controla el progreso repasando

los informes de los programadores principales y manteniendo breves
reuniones con ellos. Informa del progreso al jefe del proyecto.
 Experto Del Lenguaje: El llamado language lawyer/guru es un miembro del

equipo que debe poseer un conocimiento exhaustivo de un lenguaje de
programación específico o tecnología. Este papel es particularmente
importante cuando el equipo del proyecto trata con alguna nueva tecnología.
 Build Engineer: Es la persona responsable de preparar, mantener y construir

el build process, incluyendo la memoria de las versiones y la documentación.
 Toolsmith: Se encarga de construir pequeñas herramientas para los equipos

de desarrollo, testeo y conversión de datos. También, puede preparar y
mantener bases de datos y sitios web para propósitos específicos del proyecto.
 Administrador De Sistemas: Las tareas de un administrador de sistema

comprenden:
a) Configurar, gestionar y solucionar problemas de los servidores y la

red.
b) Desarrollar y probar entornos utilizados por el equipo del proyecto.
46
c) También puede ser involucrado en el productionizing del sistema.
 Tester: Los probadores verifican y validan (V&V) que el sistema cumpla las
especificaciones y requisitos del cliente. Puede ser un equipo independiente o
una parte del equipo del proyecto.
 Distribuidor O Desplegador (Deployer): Su trabajo consiste en convertir

los datos existentes al formato requerido por el nuevo sistema y participar en
el despliegue de nuevas versiones. Puede ser un equipo independiente o una
parte del equipo del proyecto.
 Escritor Técnico: Prepara la documentación para el usuario final. Puede ser

parte del equipo o independiente.11
Practicas
FDD consiste en un conjunto de mejores prácticas, que no son nuevas, pero que la
mezcla específica de ellas, hacen que los cinco procesos de FDD sean únicos para
cada caso. Palmer y Felsing también defienden que deberían usarse todas las prácticas
disponibles para conseguir el mayor beneficio, ya que ninguna práctica domina por
completo todo el proceso. FDD involucra las prácticas siguientes:
11
47
• Modelado de los objetos del dominio: Exploración y explicación del dominio
del problema. Los resultados se engloban en el framework donde se agregan
las funcionalidades.
• Desarrollar por característica: Desarrollar y seguir el progreso a través de

una pequeña lista de funciones importantes para el cliente descompuesta por
funcionalidades.
• Propiedad individual de la clase (código): Cada clase tiene una única persona
responsable de la fiabilidad, rendimiento, e integridad conceptual de la clase.
• Equipos de características: Referido a los equipos pequeños y formados

dinámicamente.
• • Inspección: Referido al uso de los mejores mecanismos para detectar fallos.
• Builds regulares: Asegurar que siempre haya disponible un sistema que

funcione para mostrar. Son las bases donde se añadirán nuevas
funcionalidades.
• Gestión de configuración: Permite la identificación y control de las últimas

versiones de cada fichero de código fuente completado.
• Informes de progreso: Se informa a todos los niveles organizativos

necesarios del progreso basándose en partes completadas. 12
12
48
Rational Unified Process (RUP)
RUP fue desarrollado por Philippe Kruchten, Ivar Jacobsen y otros en la Rational
Corporation para complementar UML, Unified Modelling Language actualmente
propiedad de IBM.1 Junto con el Lenguaje Unificado de Modelado UML, constituye
la metodología estándar más utilizada para el análisis, diseño, implementación y
documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos
firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y
necesidades de cada organización.
Proceso
La duración de un proyecto de RUP se divide en cuatro fases [Kruchten 2000]:

Concepción, Elaboración, Construcción y Transición. Estas fases se dividen en
iteraciones, cada una con el propósito de crear un fragmento de software operativo.
La duración de una iteración puede variar de dos semanas o menos a seis meses.
A continuación, se detallan las fases de RUP según Kruchten:
 Fase Concepción (Inception): En la fase de concepción, se definen los

objetivos del ciclo de vida o duración del proyecto para tener en cuenta las
necesidades de cada participante, como el usuario final, comprador, o
contratista. Esto conlleva, por ejemplo, establecer las posibilidades, límites, y
criterio de aceptación del proyecto. Se identifican los casos de uso críticos que
49
determinarán la funcionalidad del sistema. Se diseñan posibles arquitecturas, y
se estima el calendario y costo para el proyecto entero. Además, se hacen las
estimaciones para la siguiente fase.
 Fase De Elaboración: La fase de la elaboración establece la base de la

arquitectura del software. Se analiza el problema o reto, teniendo en cuenta
que se construirá el sistema por completo. Se define el plan del proyecto. RUP
asume que la fase de la elaboración proporcionará una arquitectura
suficientemente sólida y que los requisitos y planes son suficientemente
estables. Se describe el proceso y el entorno de desarrollo en detalle. RUP
pone énfasis en la automatización de herramientas y también se considera en
esta fase.
 Fase De Construcción: Aquí se desarrollan los componentes y

características restantes y se integran en el producto para pasar las pruebas.
RUP considera la fase de construcción un proceso industrial donde se enfatiza
gestionar los recursos y controlar los costos, horarios, y calidad. Los
resultados de la fase de construcción (versiones alfa, beta, etc.) se crean tan
rápidamente como sea posible, pero sin olvidar la calidad. Durante esta fase,
se hacen una o más versiones, antes de la siguiente fase.
 Fase De Transición: Se entra en esta fase cuando el software está

suficientemente maduro (determinado, por ejemplo, a partir del número e
importancia de los cambios pedidos) para ser mostrado a los usuarios. Según
su feedback, se crearán nuevas versiones para corregir problemas o terminar
características pospuestas. La fase de la transición consiste en probar las
50
versiones beta, preparar a los usuarios y gestores de los sistemas, y pasar el
producto a los departamentos de marketing, distribución y ventas. 13
Figura 8. Fases e interacción de RUP durante el ciclo de vida
13
51
Roles
 Analistas:
a) Analista de procesos de negocio.
b) Diseñador del negocio.
c) Analista de sistema.
d) Especificador de requisitos.
 Desarrolladores:
a) Arquitecto de software.
b) Diseñador
c) Diseñador de interfaz de usuario
d) Diseñador de cápsulas.
e) Diseñador de base de datos.
f) Implementador.
g) Integrador.
52
 Gestores:
a) Jefe de proyecto
b) Jefe de control de cambios.
c) Jefe de configuración.
d) Jefe de pruebas
e) Jefe de despliegue
f) Ingeniero de procesos
g) Revisor de gestión del proyecto
h) Gestor de pruebas.

Apoyo:
a) Documentador técnico
b) Administrador de sistema
c) Especialista en herramientas
d) Desarrollador de cursos
e) Artista gráfico
53
 Especialista en pruebas:
a) Especialista en Pruebas (tester)
14
b) Analista de pruebas
Practicas
Las piedras angulares de RUP son seis que quedan bajo las fases de los workflow y
los papeles de RUP. Las prácticas son:15
14
http://desarrollodefw.blogspot.mx/2012/10/roles-en-rup.html
15
54
Figura 9. Prácticas de RUP
Dynamic Systems Development Method (DSDM)
Desde su origen en 1994, DSDM16, se popularizó en el reino Unido para RAD,

Rapid
Application Development. DSDM es un framework para el desarrollo de RAD sin
ánimo de lucro y no propietario, mantenido por el DSDM Consortium. Sus
creadores, 16 expertos en RAD, afirman que además de servir como un método
también proporciona un framework de controles para RAD, complementado con
consejos sobre cómo usarlos eficazmente.
55
Proceso
DSDM consiste en cinco fases [Stapleton 1997]: estudio de viabilidad, estudio

comercial, iteración del modelo funcional, iteración de diseño y construcción, e
iteración de implementación. Las primeras dos fases son secuenciales, y sólo se hacen
una vez; las tres últimas fases durante las que se desarrolla el trabajo, son iterativas e
incrementales.
Las fases de DSDM, con sus documentos resultantes son:
 Estudio De Viabilidad: El estudio de viabilidad no debería durar más de

unas semanas y evalúa la conveniencia de DSDM para un proyecto dado. Se
tiene en cuenta el tipo de proyecto y la gente que lo usará. Además, se
preocupa por las posibilidades técnicas de llevar a cabo el proyecto y los
riesgos que conllevaría. Se preparan dos workproducts: un informe de
viabilidad, y un esbozo del plan para el desarrollo. Opcionalmente, puede
hacerse un prototipo rápido si el negocio o tecnología son nuevos, para decidir
si continuar con la siguiente fase o no.
 Estudio Comercial: En el estudio comercial se analizan las características

esenciales del negocio y la tecnología. Se recomienda organizar talleres con
un número suficiente de expertos en clientes para poderconsiderar todos los
posibles casos del sistema y establecer las prioridades del desarrollo. Se
describen los procesos comerciales afectados y los tipos de usuario en una
 Definición de Área Comercial, Business Area Definition. Se presentan

descripciones de alto nivel de los procesos en formato conveniente, como
diagramas ER.
56
 Iteración Del Modelo Funcional: La fase de iteración del modelo funcional
es la primera fase iterativa e incremental. En cada iteración, se decide el
contenido y el enfoque adecuado a partir de los resultados de iteraciones
anteriores. Se realiza el análisis, la codificación y los prototipos. Los
prototipos no se desechan completamente, sino que se mejoran gradualmente
hasta poder incluirlos en el sistema final. En los diferentes pasos de las fases,
se generan en total cinco outputs o resultados:
1) Un Modelo Funcional con el código prototipo y los modelos de

análisis. El este continuo aquí es fundamental.
2) Las Funciones Priorizadas son una lista priorizada de las funciones

que se entregan al final de la iteración.
3) Los Documentos de la Revisión del Prototipo Funcional

(Functional prototyping review documents) recogen los comentarios
de los usuarios del incremento actual para tenerse en cuenta en las
siguientes iteraciones.
4) Se enumeran los Requisitos no funcionales, principalmente para ser

tratados en la próxima fase.
5) El Análisis de riesgo de más desarrollos es un documento

importante, porque de la próxima fase (iteración diseñar y construir)
en adelante, los problemas que surjan serán más difícilmente atacables.
 Iteraciones Diseñar Y Construir: El resultado es un sistema testeado que

cumple por lo menos el conjunto mínimo de requisitos. Diseño y
Construcción es una fase iterativa, y tanto el diseño como los prototipos son
57
revisados por los usuarios, ya que el desarrollo posterior vendrá determinado
por susimpresiones.
 Implementación: En la última fase, el sistema se transfiere del entorno de

desarrollo al propio entorno de producción. Se forma a los usuarios y se les
entrega el software. Si existen muchos usuarios o se requiere mucho tiempo,
esta fase podría iterarse. En esta fase se entrega: Software, Manual y un
Informe de Revisión de Proyecto.
Roles
 Patrocinador Ejecutivo: Es la persona que posee autoridad y responsabilidad

financiera, y quien tiene la última palabra en las decisiones importantes.
 Visionario: Es el usuario que tiene la percepción más exacta de los objetivos

del sistema y del proyecto. Asegura que se cumplan los requisitos esenciales y
que el proyecto vaya en la dirección adecuada desde el punto de vista de los
requisitos.
 Usuario Embajador: Proporciona al proyecto conocimiento de la

comunidad de usuarios a la que se dirige el proyecto y difunde información
sobre el progreso del sistema a otros usuarios. Es clave para asegurar un
diseño adecuado. Revisa la documentación, crea la documentación para el
usuario y supervisa tanto los tests de los usuarios como su formación.
58
 Usuario Asesor (Advisor): Representa otros puntos de vista importantes;
puede ser alguien del personal de IT o un auditor financiero. Aprueba los
diseños y los prototipos.
 Jefe De Proyecto: El project manager se asegura que se entreguen todos los

aspectos del proyecto. Tiene la responsabilidad de coordinar e informar a los
gestores, elaborar el calendario, supervisar el progreso, controlar la gestión de
riesgos, tratar problemas inesperados, etc.
 Coordinador Técnico: Define la arquitectura del sistema y es responsable de

la calidad técnica del proyecto, del control técnico y la configuración del
sistema. Es el encargado del control de versiones.
 Líder Del Equipo: Se encarga que todo el equipo vaya en la misma

dirección. Gestiona el control de cambios y la documentación. Informa al jefe
de proyecto del progreso.
 Desarrolladores: Los developers modelan e interpretan los requisitos,

convirtiéndolos en prototipos y código entregable. No hay distinción entre
analista, diseñador y programador.
 Testeador: Realiza los tests (no de usuario ni tests de unidad) según la

estrategia de tests del plan de desarrollo. El tester es parte del equipo de
desarrollo. El usuario embajador es el responsable de todos los tests de
usuario.
 Escriba: El scribe registra los requisitos, acuerdos y decisiones alcanzadas en

las reuniones, talleres y sesiones acerca de los prototipos. Distribuye la
documentación.
59
Practica
Figura 10. Prácticas de DSDM 16
16
60
Adaptive Software Development – ASD
El Desarrollo Adaptativo de Software 17 , creado por el miembro del Cutter

Consortium James A. Highsmith III, y se publicó el año 2000. Muchos de los
principios de ASD provienen de las primeras investigaciones de Highsmith en los
métodos de desarrollo iterativos. El predecesor más notable de ASD, “RADical
Software Development”, fue desarrollado por Highsmith y S. Bayer en 1994. ASD
está dirigido principalmente a problemas en sistemas complejos y grandes. El método
propone un desarrollo incremental, iterativo, con continuos prototipos. En esencia,
ASD trata de “hacer equilibrios al límite del caos”.
Proceso
Adaptive Software Development da forma a las fases básicas de la gestión ágil en:
 Especulación
Compuesta por 5 pasos:

1.- Inicio para determinar la misión del proyecto.
2.- Determinación del marco temporal del proyecto.
3.- Determinación del nº de iteraciones y la duración de cada una.
4.- Determinación del objetivo de cada una.
5.- Asignación de funcionalidad a cada iteración.
61
 Colaboración : Desarrollo concurrente del trabajo de construcción y gestión
del producto
 Aprendizaje
a) En cada iteración se revisa:
b) Calidad, con criterios de cliente.
c) Calidad, con criterios técnicos.
d) Funcionalidad desarrollada
e) Estado del proyecto
f) Las características básicas de ASD son:
g) Trabajo orientado y guiado por la misión del proyecto.
h) Basado en la funcionalidad
i) Desarrollo acotado temporalmente
j) Guiado por los riesgos
k) Trabajo tolerante al cambio.17
17
http://adaptivesoftwaredevelopment.blogspot.mx/
62
Roles
El proceso ASD se origina de la cultura organizativa y de gestión, pero sobre todo, de

la importancia de la colaboración entre equipos y del trabajo en equipo. A pesar de
esto, Highsmith, no describe la estructura del equipo en detalle. Igualmente, se citan
muy pocos papeles o responsabilidades:
• Un patrocinador ejecutivo que tiene la responsabilidad global del producto.
• Los participantes en una sesión JAD:
o Un ayudante para planear y moderar la sesión,

o Un secretario para tomar actas,
o El jefe del proyecto,
o Representantes del cliente, y
o Representantes de los programadores.
Practicas
ASD propone muy pocas prácticas para el trabajo diario. Básicamente, expresamente
cita tres:
• Desarrollo iterativo
• planning basado en características (basadas en componentes),
• revisiones en grupo enfocadas al cliente.
De hecho, quizás el problema más significante con ASD es que sus prácticas son
difíciles identificar, y deja muchos puntos sin especificar.
63
6.2 Capítulo II Estado actual de las metodologías agiles
En este segundo capítulo se plasmara los resultados del análisis que

realiza VersionOne cada año sobre el estado actual de la agilidad en las
organizaciones y comparaciones con resultados entre los años 2015, 2016 y 2017,
informe que responden las siguientes interrogantes; ¿Qué habrá pasado? ¿Habrá
mejorado algo?, ¿Cuál ha sido el impacto al utilizar metodologías agiles?, ¿Quién es
el rey de las metodologías agiles?, ¿Qué herramientas destacan? ¿Cuáles son los
métodos ágiles más utilizados? ¿Cuáles son los mayores beneficios por los cuales los
agilistas usan técnicas ágiles? ¿Cuál es el mayor impedimento que encuentran al
implantar métodos ágiles en una organización?
6.2.1 ¿Qué Beneficios aporta la Agilidad a tu empresa?
Según Julián Gómez; Una de las cuestiones que siempre se plantean a la hora de
implantar una metodología ágil en una organización que todavía no lo ha hecho es el
tema de los beneficios, ¿qué voy a obtener a cambio del esfuerzo de implantar una
metodología ágil?
64
Resultado del análisis del año 2015
Beneficios que aporta la gilidad a las

empresa 2015
Capacidad de gestionar el cambio
de prioridades
9%
17% Aumentar la Productividad del
Equipo
9%
Aumentar la visibilidad del
proyecto
Acelerar la entrega del producto
10%
16%
Mejorar la capacidad de adaptarse
al cambio de prioridades
Aumentar la productividad
11%
Incrementar la calidad del software

16%
12%
Incrementar la predictibilidad de la
entrega
18
Grafica 1 Beneficos de la agilidad 2015
18
Ref 4
65
Resultados del análisis del año 2016

empresa 2016
Capacidad de gestionar el
8% cambio de prioridades
17%
9%
Aumentar la Productividad del
Equipo
11% Aumentar la visibilidad del

16% proyecto
Acelerar la entrega del

11% producto
16% Mejorar la capacidad de

12% adaptarse al cambio de
prioridades
Grafica 2 Beneficios de la agilidad 2016 19
19
Ref 3
66
Resultado del análisis del año 2017

empresa 2017
Capacidad de gestionar el
8% cambio de prioridades
17%
9% Aumentar la Productividad del
Equipo
11% Aumentar la visibilidad del

16% proyecto
Acelerar la entrega del

12% producto
16% Mejorar la capacidad de

11% adaptarse al cambio de
prioridades
Grafica 3 Beneficios de la agilidad 201720
El primero de la lista es algo que nos preocupa a todos y es el time to market, desde
que tenemos un requisito hasta que finalmente la aplicación lo satisface. ¿Quién no
desea mejorarlo? Cuanto antes estemos en el mercado antes podremos probar si
funciona o no.
20
Ref 14
67
Salvo algún punto más en los valores de alguna de las respuestas la clasificación
permanece inalterada con respecto al año pasado. Como vemos la mayoría de las
necesidades son las de siempre: Hacer más cosas en menos tiempo con mayor
calidad para un determinado tipo de proyectos.
6.2.2 ¿Qué técnica ágil es la más usada?
Julián Gómez comenta que: Las metodologías ágiles frecuentemente utilizan técnicas
similares, por eso es interesante conocer más allá de dichas metodologías cuales son
las técnicas ágiles más valoradas y utilizadas en el día a día:
68
Resultados del año 2015
¿Qué técnica ágil es la más usada? 2015
Reunión diaria de pie

18% 21%
Iteraciones cortas
Backlog priorizados
19%
21% Planificación de las
iteraciones
Retrospectivas
21%
Grafica 4 Técnicas más usadas 2015
69
¿Qué técnica ágil es la más usada?

2016
19% 22% Iteraciones cortas
Backlog priorizados
18%
iteraciones
21% Retrospectivas
21
Ref 14
70
¿Qué técnica ágil es la más usada? 2017

19% 22%
Iteraciones cortas
Backlog priorizados
18%
iteraciones
Retrospectivas
21%
De entre todos los datos cabe destacar las subidas de los Backlog priorizados (desde
la tercera a la segunda posición) y las Retrospectivas (de la quinta a la cuarta).
En general, los datos son muy similares. Si no conoces en qué consisten estas técnicas
te las resumo brevemente las tres más usadas:
 Reuniones diarias de pie. El sentido de que sean de pie, por si no estás

familiarizado o familiarizada con estas técnicas, es para que sea breves. Su
22
Ref 14
71
objetivo es conocer todos los días el estado de las tareas que hicimos el día
anterior, los problemas que nos encontramos y las tareas que haremos hoy.
Corto, conciso, escueto y para todo el equipo.
 Backlog priorizados. El Product Manager gestiona, alimenta y prioriza el

backlog, la pila del producto con las historias de usuario a realizar. Se encarga
de priorizarlas y el equipo del proyecto las asigna a cada iteración en función
de la prioridad y la estimación.
 Iteraciones cortas. En cada iteración se completan los requisitos del cliente

definidos a través de historias de usuarios en el backlog y que se habían
priorizado para realizar.23
6.2.3 Porque falla la agilidad y los proyectos agiles
Julián Gómez comenta; Es un dato bien interesante. En esta ocasión los valores están
más repartidos entre todas las opciones pero las primeras posiciones son bastantes
representativas, la causa del fracaso de los proyectos ágiles es:
23
Ref 3
72
Falla de la agilidad y los proyectos agiles

2015
Falta de experiencia en
métodos ágiles
18%
23% La cultura de la empresa
contra los principios de la
agilidad
Falta de soporte por parte
de la dirección
19%
21% Presión externa para seguir

procesos de cascada
tradicional
19% Falta de soporte para la
transición cultural
Grafica 7 Fallas de la agilidad y procesos agiles 2015 24
2424
Ref 4
73

2016
métodos ágiles
19% 20%
La cultura de la empresa
agilidad
Falta de soporte por parte de la
dirección
19%
23% Presión externa para seguir
procesos de cascada
tradicional
Falta de soporte para la
19% transición cultural
25
Grafica 8 Falla de la agilidad y los proyectos 2016
25
Ref 3
74

2017
métodos ágiles
18%
24%
La cultura de la empresa
agilidad
Falta de soporte por parte de la
dirección
18%
Presión externa para seguir
19% procesos de cascada
tradicional
Falta de soporte para la
21% transición cultural
Grafica 9 Falla de la agilidad y proyectos 2017 26
Parece que con la difusión de la agilidad las empresas cuentan con personal con
experiencia en la misma y, por tanto, en lugar de desconocimiento encuentran más
reticencia al cambio. Con respecto al año pasado ha habido un relevo en la primera
posición y el quinto aparece por primera vez.
26
Ref 14
75
6.2.4 Quien frena la implantación de la Agilidad
Según Julián Gómez Hay ciertos factores que influyen en que la implantación de la
Agilidad no vaya tan rápida o suave como debiera. Es importante conocerlos para
evitarlos en nuestros desarrollos. Los más importantes son:
Quien frena la implantación de la

Agilidad 2015
La falta de capacidad para
cambiar la cultura de la
17% organización
25%
Insuficiente personal con la
adecuada experiencia en la
agilidad
18% Resistencia general al
cambio en la organización
20%
20% Marco de trabajo

preexistente en
cascada/rígido
Grafica 10 Quien frena la implementación de la agilidad 201527
27
Ref 3
76
Quien frena la implantación de la Agilidad

2016

14% cambiar la cultura de la
organización
27% Insuficiente personal con la
agilidad
20%
Resistencia general al cambio
en la organización
19% Marco de trabajo preexistente

en cascada/rígido
20%
Soporte de la dirección
28
Ref 4
77
Quien frena la implantación de la

Agilidad 2017
cambiar la cultura de la
16% organización
25% Insuficiente personal con la
agilidad
17% Resistencia general al cambio
en la organización
18%
Marco de trabajo preexistente
en cascada/rígido
24%
Soporte de la dirección
El año pasado la falta de formación/experiencia y la resistencia al cambio eran los

dos frenos más importantes de la agilidad, pero este año ya vemos que hay una mayor
experiencia entre el personal, por ello, aparece la resistencia al cambio como fuerza
de rozamiento.
29
Ref 14
78
6.2.5 Las herramientas más utilizadas
Análisis del año 2015
Julián Gómez; Por último vamos a ver la utilización de herramientas como soporte a
la metodología ágil. Lo que más me sorprende es el primer puesto ya que es un todo
terreno en cada oficina que lo mismo sirve para cuadrar un balance como para
gestionar el backlog, Microsoft Excel:
Las herramientas más utilizadas 2015
11%
Microsoft Excel
32%
15% Microsoft Project
Atlassian/JIRA
VersionOne
21% Microsoft TFS
21%
Grafica 13 Herrmientas mas usadas del 2015 30
30
Ref 3
79
En la a utilización de herramientas como soporte a la metodología ágil. Microsoft

Excel sigue estando en lo más alto, pero su liderazgo está puesto en duda ya que ha
bajado bastante en su porcentaje con respecto al año pasado
12%
Microsoft Excel
31%
Atlassian/JIRA
VersionOne
17% Microsoft TFS
26%
31
Grafica 14 Herramientas mas usadas del 2016
31
Ref 4
80
Como se observa la herramienta Microsoft Excel sigue encabezando la lista la

herramienta Atlassian/JIRA a tomado fuerza entro de las metodologías agiles.
12%
Microsoft Excel
13%
Atlassian/JIRA
VersionOne
Microsoft TFS
30% 15%
iceScrum
Grafica 15 Herramientas mas usadas del 2017 32
6.2.6 ¿Qué Metodologías se usan más?
32
Ref 14
81
Hay un ganador claro y es Scrum. No sólo por ser la metodología más usada con
diferencia (56%) si no porque también está en la segunda posición Híbrida
Scrum/XP(10%) y en la cuarta Scrumban (6%):
Metodologías mas usadas en el 2015

Scrum
6%
7%
Híbrida Scrum/XP
9%
Híbrida personalizada
(múltiples metodologías)
12%
66% Scrumban
Kanban
Grafica 16 Metodologías mas usadas en el 2015
Sigue habiendo un lider indiscutible Scrum/Scrum de Scrums. No hay sorpresas

si Scrum nos funciona para un equipo ¿por qué no debe funcionarnos para más? Es un
método escalable al que se le sabe sacar todo el partido.33
33
Ref 4
82
Además de seguir siendo la metodología más utilizada, ha aumentando su distancia

con respecto al resto en 2 puntos más. Pero no sólo aparece en la primera posición,
también aparece en otras de las opciones seleccionadas como en la segunda
posición Híbrida Scrum/XP (10%) y en la cuarta Scrumban (7%).
Aquí tienes el resto de resultados:

Scrum
6%
8%
Híbrida Scrum/XP
9%
11%
66% Scrumban
Kanban
Grafica 17 Metodologías mas usadas en el 2016
Los únicos valores que cambian, y a mejor, son Scrum y Scrumban el resto
permanecen igual que el año pasado.34
34
Ref 3
83
Para esta año 2017 el rey indiscutible es Scrum esto se debe a su efectividad y la
capacidad de poder realizar combinaciones con otras metodologías como XP o
Caban.

Scrum
5%
8%
Híbrida Scrum/XP
10%
11%
Scrumban
66%
Kanban
Grafica 18 Metodologías mas uasadas en el 2017
84
6.3 Capítulo III Tendencia de las metodologías agiles: SCRUM
En este capítulo se hablará de la tendencia de las metodologías agiles para el

desarrollo de software las cual hace referencia a la metodología SCRUM
específicamente.
6.3.1 Introducción
Un proyecto Scrum implica un esfuerzo de colaboración para crear un nuevo

producto, servicio, o cualquier otro resultado como se define en la Declaración de la
visión del proyecto. Los proyectos se ven afectados por las limitaciones de tiempo,
costo, alcance, calidad, recursos, capacidades organizativas, y otras limitaciones que
dificultan su planificación, ejecución, administración y, finalmente, su éxito. Sin
embargo, la implementación exitosa de los resultados de un proyecto terminado le
proporciona ventajas económicas significativas a una organización. Por lo tanto, es
importante que las organizaciones seleccionen y practiquen una metodología
adecuada de gestión de proyectos. Scrum es una de las metodologías Ágil más
populares. Es una metodología de adaptación, iterativa, rápida, flexible y eficaz,
diseñada para ofrecer un valor significativo de forma rápida en todo el proyecto.
Scrum garantiza transparencia en la comunicación y crea un ambiente de
responsabilidad colectiva y de progreso continuo. El marco de Scrum, tal como se
define en la Guía SBOK™, está estructurado de tal manera que
es compatible con los productos y el desarrollo de servicios en todo tipo de industrias
y en cualquier tipo de proyecto, independientemente de su complejidad.
85
Figura 11. Flujo de SCRUM para Sprint 35
6.3.2 ¿Por qué utilizar SCRUM?
Algunas de las ventajas principales de la utilización de Scrum en cualquier proyecto

son:
a. Adaptabilidad—El control del proceso empírico y el desarrollo

iterativo hacen que los proyectos sean adaptables y abiertos a la
incorporación del cambio.
b. Transparencia—Todos los radiadores de información tales como un

Tablero de Scrum (del inglés Scrumboard) y una Gráfica del trabajo
pendiente del sprint (del inglés Sprint Burndown Chart) se comparten,
lo que conduce a un ambiente de trabajo abierto.
35
SCRUMstudy Targeting succes. (Enero de 2016). Guia para el cuerpo de conocimientos de
SCRUM. GUIA SBOK, Pg. 330. Mexico.
86
c. Retroalimentación continua—La retroalimentación continua se
proporciona a través de los procesos llamados Llevar a cabo la reunión
diaria y Demostración y validación del sprint.
d. Mejora continua—Los entregables se mejoran progresivamente

sprint por sprint a través del proceso de Mantenimiento de la lista
priorizada de pendientes del producto (del inglés Groom Prioritized
Producto Backlog).
e. Entrega continúa de valor—Los procesos iterativos permiten la

entrega continua de valor tan frecuentemente como el cliente lo
requiere a través del proceso de Envío de entregables (del inglés Ship
Deliverables).
f. Ritmo sostenible—Los procesos Scrum están diseñados de tal manera

que las personas involucradas pueden trabajar a un ritmo sostenible
(del inglés sustainable pace) que, en teoría, se puede continuar
indefinidamente.
g. Entrega anticipada de alto valor—El proceso de Creación de la lista

priorizada de pendientes del producto asegura que los requisitos de
mayor valor del cliente sean los primeros en cumplirse.
h. Proceso de desarrollo eficiente—La asignación de un bloque de

tiempo fijo (del inglés Timeboxing) y la reducción al mínimo del
trabajo que no es esencial conducen a mayores niveles de eficiencia.
87
i. Motivación—Los procesos de Llevar a cabo la reunión diaria y
Retrospectiva del sprint conducen a mayores niveles de motivación
entre los empleados.
j. Resolución de problemas de forma más rápida—La colaboración y

colocación de equipos interfuncionales conducen a la resolución de
problemas con mayor rapidez.
k. Entregables efectivos—El proceso de Creación de la lista priorizada

de pendientes del producto, y las revisiones periódicas después de la
creación de entregables aseguran entregas eficientes al cliente.
l. Centrado en el cliente—El poner énfasis en el valor del negocio y

tener un enfoque de colaboración con los socios asegura un marco
orientado al cliente.
m. Ambiente de alta confianza—Los procesos de Llevar a cabo la

reunión diaria y la Retrospectiva del sprint promueven la transparencia
y colaboración, dando lugar a un ambiente de trabajo de alta confianza
que garantiza una baja fricción entre los empleados.
n. Responsabilidad colectiva—El proceso de Aprobación, estimación y

asignación de historias de usuarios permite que los miembros del
equipo hagan suyo el proyecto y su trabajo conlleve a una mejor
calidad.
o. Alta velocidad—Un marco de colaboración que le permite a los
equipos interfuncionales altamente cualificados alcanzar su potencial y
alta velocidad.
88
p. Ambiente innovador—Los procesos de Retrospectiva de sprint y
Retrospectiva del proyecto crean un ambiente de introspección,
aprendizaje y capacidad de adaptación que conllevan a un ambientede
36
trabajo innovador y creativo
6.3.3 Principios de SCRUM
Los principios de Scrum son las pautas básicas para aplicar el marco de Scrum, y
deben utilizarse obligatoriamente en todos los proyectos Scrum. Los seis principios
de Scrum que se presentan en el capítulo 2 son los siguientes:
1. Control del proceso empírico.
2. Auto-organización
3. Colaboración
4. Priorización basada en el valor
5. Asignación de un bloque de tiempo
6. Desarrollo iterativo37
36
Gallego, M. T. (01 de 11 de 2015). Metodologias SCRUM. Gestion de poryectos informaticos, Pg.
56 Mexico.
37
SCRUM. GUIA SBOK, Pg. 330. Mexico
89
Figura 11. Principios de SCRUM
Los principios de Scrum pueden aplicarse a cualquier tipo de proyecto en cualquier

organización, y deben cumplirse a ellos a fin de garantizar la aplicación efectiva del
marco de Scrum. Los principios de Scrum no están abiertos a la discusión ni pueden
modificarse, y deben aplicarse como se especifica en la Guía SBOK™. El mantener
los principios intactos y usarlos apropiadamente infunde confianza en el marco de
Scrum con respecto al cumplimiento de los objetivos del proyecto. Los aspectos y
procesos de Scrum, sin embargo, pueden modificarse para cumplir con los requisitos
del proyecto o la organización.
90
1. Control del proceso empírico—Este principio pone de relieve la
filosofía entral de Scrum en base a las tres ideas principales de
transparencia, inspección y adaptación.
2. Auto-organización—Este principio se centra en los trabajadores de

hoy en día, que entregan un valor significativamente mayor cuando se
organizan a sí mismos, lo cual resulta en equipos que poseen un gran
sentido de compromiso y responsabilidad; a su vez, esto produce un
ambiente innovador y creativo que es más propicio para el
crecimiento.
3. Colaboración—Este principio se centra en las tres dimensiones

básicas relacionadas con el trabajo colaborativo: conocimiento,
articulación y apropiación. También fomenta la gestión de proyectos
como un proceso de creación de valor compartido con equipos que
trabajan e interactúan conjuntamente para ofrecer el mayor valor.7
4. Priorización basada en valor—Este principio pone de relieve el

enfoque de Scrum para ofrecer el máximo valor de negocio, desde el
principio del proyecto hasta su conclusión.
5. Asignación de un bloque de tiempo—Este principio describe cómo

el tiempo se considera una restricción limitante en Scrum, y cómo este
se utiliza para ayudar a manejar eficazmente la planificación y
ejecución del proyecto. Los elementos del bloque de tiempo en Scrum
incluyen sprints, reuniones diarias de pie, reuniones de planificación
del sprint, y reuniones de revisión del sprint.
91
6. Desarrollo Iterativo—Este principio define el desarrollo iterativo y
enfatiza cómo manejar mejor los cambios y crear productos que
satisfagan las necesidades del cliente. También delinea las
responsabilidades del propietario del producto y las de la organización
relacionadas con el desarrollo iterativo.
6.3.4 Organización
Entender los roles y responsabilidades definidos en un proyecto Scrum es muy

importante a fin de asegurar la implementación exitosa del método de Scrum.
Los roles de Scrum se dividen en dos grandes categorías:
Roles Centrados
Los roles centrales son aquellos que se requieren obligatoriamente para crear el
producto o servicio del proyecto. Las personas a quienes se les asignan los roles
centrales están plenamente comprometidas con el proyecto, y son las responsables del
éxito de cada iteración del mismo, así como del proyecto en su totalidad.
Estas funciones incluyen:
 El propietario del producto es la persona responsable de lograr el máximo

valor empresarial para el proyecto. Este rol también es responsable de la
articulación de requisitos del cliente y de mantener la justificación del negocio
para el proyecto. El propietario del producto representa la voz del cliente.
92
 El Scrum Master es un facilitador que asegura que el equipo Scrum esté
dotado de una ambiente propicio para completar el proyecto con éxito. Este
rol guía, facilita y les enseña las prácticas de Scrum a todos los involucrados
en el proyecto; elimina los impedimentos que encuentra el equipo; y, asegura
que se estén siguiendo los procesos de Scrum.
 El equipo Scrum es el grupo o equipo de personas responsables de la

comprensión de los requisitos especificados por el propietario del producto y
de la creación de los entregables del proyecto.
Roles no Centrales
Los roles no centrales son los que no son obligatoriamente necesarios para el
proyecto Scrum, y estos pueden incluir a miembros de los equipos que estén
interesados en el proyecto. No tienen ningún papel formal en el equipo del proyecto,
y pueden interactuar con el equipo, pero pueden no ser responsables del éxito del
proyecto. Los roles deben tenerse en cuenta en cualquier proyecto de Scrum.
Los roles no centrales incluyen los siguientes:
 Los socio(s), que es un término colectivo que incluye a clientes, usuarios y

patrocinadores, con frecuencia interactúan con el equipo principal de Scrum, e
influyen en el proyecto a lo largo de su desarrollo. Lo más importante es que
el proyecto produzca beneficios de colaboración para los socios.
 El cuerpo de asesoramiento de Scrum es un rol opcional, que generalmente

consiste en un conjunto de documentos y/o un grupo de expertos que
normalmente están involucrados en la definición de los objetivos relacionados
93
con la calidad, las regulaciones gubernamentales, la seguridad y otros
parámetros claves de la organización. El cuerpo guía el trabajo llevado a cabo
por el propietario del producto, el Scrum Master y el equipo Scrum.
 Los vendedores, incluyendo a individuos u organizaciones externas, ofrecen
productos y/o servicios que no están dentro de las competencias centrales de
la organización del proyecto.
 El jefe propietario del producto es un rol para proyectos más grandes con
múltiples equipos Scrum. Este rol se encarga de facilitar el trabajo del
propietario del producto, y de mantener la justificación del negocio para el
proyecto más grande.
 El jefe Scrum Master es el responsable de coordinar las actividades

relacionadas con Scrum en proyectos grandes, los cuales pueden requerir que
varios equipos Scrum trabajen paralelamente.
94
Figura 12 Organización en SCRUM38
6.3.5 Procesos de SCRUM
Los procesos de Scrum abordan las actividades y el flujo específico de un proyecto

Scrum. En total hay diecinueve procesos que se agrupan en cinco fases. Estas fases
se presentan la siguiente tabla en los puntos del 8 al 12.
38
56 Mexico.
95
Tabla 2 Resumen de los procesos de SCRUM
Las fases describen en detalle cada proceso, incluyendo sus entradas, herramientas y
salidas asociadas. En cada proceso, algunas entradas, herramientas y salidas son
obligatorias (las que tienen un asterisco después de sus nombres), mientras que otras
son opcionales. La inclusión de las entradas, herramientas y/o salidas opcionales
dependerá del proyecto en particular, organización o industria. Las entradas,
herramientas y salidas indicadas como obligatorias son importantes para la
implementación exitosa de Scrum en cualquier organización.
96
Inicio
1. Creación de la visión del proyecto—En este proceso, se revisa el caso de

negocio del proyecto a fin de crear un declaración de la visión del proyecto
que servirá de inspiración y proporcionará un enfoque para todo el proyecto.
En este proceso se identifica al propietario del producto.
2. Identificación del Scrum Master y el(los) socio(s)—En este proceso, se

identifica al Scrum Master y al socio utilizando criterios de selección
específicos.
3. Formación de equipos Scrum—En este proceso, se identifica a los miembros

del equipo Scrum. Normalmente, el propietario del producto es el responsable
principal de la selección de los miembros del equipo, pero con frecuencia lo
hace en colaboración con el Scrum Master.
4. Desarrollo de épica(s)—En este proceso, la declaración de la visión del

proyecto sirve como la base para el desarrollo de épicas. Se pueden llevar a
cabo reuniones de grupos de usuarios para hablar sobre las épicas que sean
adecuadas.
5. Creación de la lista priorizada de pendientes del producto—En este proceso,

se refinan y crean las épicas, y luego se priorizan para crear una lista
priorizada de pendientes del producto. En ese momento también se establecen
los criterios de terminado.
6. Realizar la planificación del lanzamiento—En este proceso, el equipo

principal de Scrum revisa las historias de usuario en la lista priorizada de
97
pendientes del producto para desarrollar un cronograma de planificación del
lanzamiento, que es esencialmente un programa de implementación por fases
que se puede compartir con los socios del proyecto. También se determina la
duración del sprint en este proceso.
Planificación y estimación
1. Creación de historias de usuario—En este proceso, se crean las historias de

usuario y los criterios de aceptación de las historias de usuario. Las historias
de usuario son generalmente escritas por el propietario del producto, y están
diseñadas para asegurar que los requisitos del cliente estén claramente
representados y puedan ser plenamente comprendidos por todos los socios. Se
pudieran llevar a cabo ejercicios de escritura de historias de usuario, lo cual
involucra a los miembros del equipo Scrum, resultando en la creación de
dichas historias. Estas se incorporan a la lista priorizada de pendientes del
producto.
2. Aprobación, estimación y asignación de historias de usuario—En este

proceso, el propietario del producto aprueba las historias de usuario para un
sprint. Luego, el Scrum Master y el equipo Scrum estiman el esfuerzo
necesario para desarrollar la funcionalidad descrita en cada historia de
usuario, y el equipo Scrum se ompromete a entregar los requisitos del cliente
en forma de historias de usuario aprobadas, estimadas y asignadas.
3. Creación de tareas—En este proceso, las historias de usuario aprobadas,

estimadas y asignadas se dividen en tareas específicas y se compilan en una
98
lista de tareas. Con frecuencia, una reunión de planificación de tareas se
convocará para este efecto.
4. Estimación de tareas—En este proceso, durante las reuniones de planificación

de tareas, el equipo Scrum estima el esfuerzo necesario para realizar cada
tarea en la lista. El resultado de este proceso es una lista de tareas de esfuerzo
estimado.
5. Creación de la lista de pendientes del sprint—En este proceso, el equipo

principal de Scrum lleva a cabo un una reunión de planificación del sprint
donde el grupo crea una lista priorizada de pendientes del Sprint, que
contiene todas las tareas que deben completarse en el sprint.
Implementación
1. Creación de entregables—En este proceso, el equipo Scrum trabaja en las

tareas de la lista priorizada de pendientes del sprint para crear los entregables
del sprint. Se utiliza a menudo un tablero de Scrum para realizar el
seguimiento del trabajo y las actividades que se realizan. Las cuestiones o
problemas que enfrenta el equipo Scrum pudieran actualizar se en un registro
de impedimentos.
2. Realizar reunión diaria de pie—En este proceso, se lleva a cabo diariamente
una reunión muy centrada que se asigna a un bloque de tiempo fijo, llamada
reunión diaria de pie. Es aquí donde los miembros del equipo Scrum se
actualizan el uno al otro referente a sus progresos y sobre los impedimentos
que pudieran enfrentar.
99
3. Mantenimiento de la lista priorizada de pendientes del producto—En este
proceso, lista priorizada de pendientes del producto se actualiza y se mantiene
continuamente. Se puede considerar realizar una reunión de revisión de la lista
priorizada de pendientes del producto, en la que se discute y se incorpora la
lista priorizada de pendientes del producto de forma adecuada.
Revisión y retrospectiva
1. Convocar el Scrum de Scrums—En este proceso, representantes del equipo

Scrum convocan un Scrum of Scrums en intervalos predeterminados, o
cuando sea necesario, para colaborar y realizar un seguimiento de su
respectivo progreso, los impedimentos, y las dependencias entre otros
equipos. Esto es relevante sólo para grandes proyectos en los que participan
varios equipos Scrum.7
2. Demostración y validación del sprint—En este proceso, el equipo Scrum le

demuestra el entregable del sprint al propietario del producto y a los socios
relevantes durante una reunión de revisión del sprint. El propósito de esta
reunión es asegurar la aprobación y aceptación del propietario del producto
de los entregables creados en el sprint.
3. Retrospectiva de Sprint—En este proceso, el Scrum Master y el equipo

Scrum se reúnen para discutir las lecciones aprendidas durante todo el Sprint.
Esta información se documenta como lecciones aprendidas que pueden
aplicarse a los futuros sprints. Frecuentemente, como resultado de esta
discusión, puede haber mejoras accionables aceptadas o recomendaciones
actualizadas por parte del cuerpo de asesoramiento de Scrum.
100
Lanzamiento
1. Envío de entregables—En este proceso, los entregables que se aceptan se

entregan o pasan a los socios relevantes. Un acuerdo formal de entregables
funcionando documenta la finalización con éxito del sprint.
2. Retrospectiva del proyecto—En este proceso, mismo que completa el
proyecto, los socios y miembros del equipo principal de Scrum se reúnen
para hacer una retrospectiva del proyecto e identificar, documentar e
internalizar las lecciones aprendidas. A menudo, estas lecciones llevan a la
documentación de mejoras accionables aceptadas, que se aplicarán en futuros
proyectos. 39 40
39
56 Mexico.
40
SCRUM. GUIA SBOK, Pg. 330. Mexico.
101
6.3.6 Scrum vs. Proyectos tradicional
Tabla 3 Scrum vs Proyectos tradicionales
102
6.3.7 Practicas
 Product Backlog: El Product Backlog define todo lo necesario en el producto

final, basándose en los conocimientos de ese momento. Por tanto, define el
trabajo a hacer en el proyecto. incluye una lista ordenada por prioridades y
actualizada de requisitos técnicos para que el sistema se haga o mejore. Los
puntos del Product Backlog, por ejemplo, pueden incluir características,
funciones, parches para bugs, defectos, peticiones de mejoras o
actualizaciones de tecnología. También se incluyen temas que requieren
solución para poder hacer otros puntos de la lista. A la lista de backlog puede
contribuir el cliente, el equipo del proyecto y los departamentos de ventas,
marketing y atención al cliente.
Figura 13 Ficha de Producto Backlog utilizada en Scrum
103
 Estimación De Esfuerzo: La estimación de esfuerzo es un proceso iterativo
donde las estimaciones de cada punto se detallan más a fondo partiendo de la
información disponible en cada momento. El Product Owner junto con el
equipo se encarga de estas estimaciones.
 Sprint: El sprint consiste en adaptarse a las condiciones cambiantes del

proyecto como requisitos, tiempo, recursos, conocimiento, tecnología, etc. El
Equipo de Scrum se organiza para producir un nuevo incremento ejecutable en
un sprint que dura aproximadamente un mes natural. Las herramientas activas
del equipo son las reuniones para planear el sprint, el Sprint Backlog y las
reuniones diarias de Scrum.
 Reunión Para Planear El Sprint: El Sprint Planning meeting consta de dos

fases y la organiza el Scrum Master. En la primera fase, los clientes, usuarios,
la dirección, el Product Owner y el equipo, eligen los objetivos y las
funcionalidades del próximo sprint. En la segunda fase, el Scrum Master y el
equipo concretan la manera de conseguir esos objetivos (product increment)
en el siguiente sprint.
 Sprint Backlog: Es el punto de partida para cada sprint, una lista de puntos
de la lista del Product Backlog seleccionados para llevarse a cabo en el
próximo sprint. El equipo de Scrum junto con el Scrum Master y el Product
Owner seleccionan los puntos en la reunión para planear el Sprint, basándose
en los puntos con prioridad y los objetivos de ese sprint. A diferencia del
Product Backlog, el Sprint Backlog no se modifica hasta que el sprint (es
decir, 30 días) termina. Cuando todos los puntos del Sprint Backlog están
completos, se prepara una nueva iteración del sistema.
104
Figura 14 Ficha de Sprint Backlog utilizadas en Scrum
 Reunión Diaria De Scrum: Se organizan reuniones de Scrum diarias para

seguir el progreso del equipo y planear las reuniones: qué se ha hecho desde la
última reunión y qué se hará para la siguiente. también se ponen sobre la
mesa problemas y otros asuntos que puedan aparecer en esta reunión diaria de
unos 15 minutos. Se busca y soluciona cualquier deficiencia o imprevisto del
proceso. El Scrum Master dirige las reuniones. La dirección (Management),
también puede colaborar en la reunión.
 Sprint Review Meeting: En el último día del sprint, el equipo y el Scrum

Master presentan los resultados del sprint, (el incremento producido) a la
dirección, clientes, usuarios y Product Owner en una reunión informal. Los
participantes evalúan la evolución y deciden sobre las siguientes actividades.
105
La reunión de la revisión puede revelar nuevos puntos e incluso cambiar la
dirección tomada del sistema que se está construyendo..41
41
Gallego, M. T. (01 de 11 de 2015). Metodologias SCRUM. Gestion de poryectos
informaticos, Pg. 56 Mexico
106
7 Método empleado en la investigación, instrumentos empleados.
Seleccione el método estadístico porque este método cuenta con dos grandes estepas
para la obtención y comparación de resultados, me refiero al análisis y síntesis de
información. La capacidad de análisis y síntesis nos permite conocer más
profundamente las realidades con las que nos enfrentamos, simplificar su descripción,
descubrir relaciones aparentemente ocultas y construir nuevos conocimientos a partir
de otros que ya poseíamos.
Los procesos de análisis y síntesis depende en gran medida de tres elementos: 1) La

información y conocimientos previos que posee el individuo o grupo que llevará a
cabo la tarea, 2) su habilidad en la percepción del detalle y de relaciones novedosas
entre elementos propios de la realidad objeto de estudio y de otros ajenos a ella, y 3)
los objetivos del estudio, que ayudarán a establecer criterios para seleccionar la
información relevante y organizarla en la construcción de la síntesis.
El método estadístico consiste en una secuencia de procedimientos para el manejo de

los datos cualitativos y cuantitativos de la investigación.
Las características que adoptan los procedimientos propios del método estadístico
dependen del diseño de investigación seleccionado para la comprobación de la
consecuencia verificable en cuestión.
107
8- Análisis estadístico e inferencias de los datos obtenidos.
Beneficios que aporta la agilidad a tu empresa

2015 2016 2017
Capacidad de gestionar el cambio de prioridades 87 87 88
Aumentar la Productividad del Equipo 84 85 87
Aumentar la visibilidad del proyecto 82 84 84
Acelerar la entrega del producto 59 61 61
Mejorar la capacidad de adaptarse al cambio de 56 56 62
prioridades
Aumentar la productividad 53 55 58
Incrementar la calidad del software 46 47 48
Incrementar la predictibilidad de la entrega 44 44 44
Tabla 4 Beneficios que aporta la agilidad en las empresas
¿Qué técnica ágil es la más usada?

2015 2016 2017
Reunión diaria de pie 80 83 84
Iteraciones cortas 79 79 79
Backlog priorizados 79 82 80
Planificación de las iteraciones 71 69 72
Retrospectivas 69 74 74
Tabla 5 Técnica ágil mas usadas en 2015, 2016 y 2017
108
Porque falla la agilidad y los proyectos agiles
2015 2016 2017
Falta de experiencia en métodos ágiles 44 42 40
La cultura de la empresa contra los principios de la 42 46 36
agilidad
Falta de soporte por parte de la dirección 38 38 38
Presión externa para seguir procesos de cascada 37 38 34
tradicional
Falta de soporte para la transición cultural 36 38 34
Tabla 6 Porque falla la agilidad y los proyectos agiles
Quien frena la implantación de la Agilidad

2015 2016 2017
La falta de capacidad para cambiar la cultura de la 44 45 45
organización
Insuficiente personal con la adecuada experiencia en la 35 39 31
agilidad
Resistencia general al cambio en la organización 34 42 43
Marco de trabajo preexistente en cascada/rígido 32 40 30
Soporte de la dirección 29 28 29
Tabla 7 Quien frena la implantación de la Agilidad
109
Las herramientas más utilizadas
2015 2016 2017
Microsoft Excel 68 60 59
Microsoft Project 46 51 28
Atlassian/JIRA 45 33 58
VersionOne 33 28 26
Microsoft TFS 24 24
iceScrum 23
Tabla 8 Las herramientas más utilizadas en 2015, 2016 y 2017
¿Qué Métodos se usan más?

2015 2016 2017
Scrum 56 58 61
Híbrida Scrum/XP 10 10 10
Híbrida personalizada (múltiples metodologías) 8 8 9
Scrumban 6 7 7
Kanban 5 5 5
Tabla 9 Metodologias mas usadas en 2015, 2016 y 2017
110
9. Análisis comparativo de los resultados obtenidos contra los
esperados.
En esta grafica se muestra el aumento de la productividad del equipo desarrollador

en 3% a escala de 100%, entre los años 2015 al 2017.
Grafica 19 Aumento de la productividad del Equipo
111
En la presente grafica se muestra el aumento de productividad de los proyectos de
desarrollo de software, comparación entre los años 2015, 2016 y 2017.
Grafica 20 Aumento de la productividad en los proyectos
112
En la presente grafica se muestra las técnicas más usadas en el desarrollo de software
con metodologías agiles entre los años 2015, 2016 y 2017, en donde claramente se
observa que la técnica más usada en los tres años son as reuniones diarias.
Grafica 21 Técnicas más usadas en 2015, 2016 y 2017
113
En la presente grafica se observa la herramienta más usada entre los años 2015, 2016
y 2017, donde claramente se be que la herramienta más usada en el apoyo a la
administración de metodologías agiles es Microsoft Excel.
Grafica 22 Herramientas más usadas en 2015, 2016 y 2017
114
En la siguiente grafica se muestra las metodologías agiles comparando los años entre
2015 y 2017 en donde indiscutiblemente el rey de las metodologías agiles es Scrum
y sigue en aumento.
Grafica 23 Metodologías más usadas en 2015, 2016 y 2017
115
Anteriormente hemos hablado de las estadísticas que beneficias las metodologías
agiles, pero no todo favorece a las metodologías agiles, pues hay factores que afectan
el desarrollo de las metodologías agiles tal es el caso de la siguiente grafica que
muestra como la capacidad para cambiar la cultura de una organización es una factor
muy importante para adoptar una buena metodología agil.
Grafica 24 Capacidad para cambiar la cultura de las organizaciones
116
En la siguiente grafica se muestra como la aceptación y el estudio por metodologías
agiles es casa ves es más aceptada por los nuevos programadores, ya que la falta de
experiencia con las metodologías agiles es un factor que poco a poco va
disminuyendo el la adopción de una metodología ágil para el desarrollo de software.
Grafica 25 Falta de experiencia en metodologías agiles
117
10. Elaboración de conclusiones
Después de haber realizado el análisis comparativo de los resultados obtenidos con

los esperados, es posible concluir que las organizaciones que adoptan una
metodología ágil para el desarrollo de sus proyectos de software tiene como resultado
un impacto que favorece directamente a la empresa, los clientes y el equipo
desarrollador de software. Pues la productividad de los equipos desarrolladores y de
los proyectos de software han aumentado un 3 y 5 por ciento respectivamente en los
últimos 3 años, dando como resultado a la organización la optimización de los
diferentes recursos y la entrega de productos de mayor calidad en menor tiempo
posible a sus clientes.
Dentro de las técnicas en el desarrollo de software que se han seguido usado en los
últimos años destaca las Reuniones de pie o reuniones diarias ya que es una técnica
fundamental en la agilidad que tiene como objetivo conocer todos los días el estado
de las tareas que se hicieron el día anterior, los problemas que se tuvieron y las
tareas que se harán hoy. En cambio la técnica que ha tomado fuerza con el paso de
los años es la Retrospectiva que tiene como objetivo mejorar de manera continua su
productividad y la calidad del producto que está desarrollando.
Para un buen desempeño y administración de los proyectos de software los

desarrolladores suelen apoyarse de herramientas que faciliten estas tareas, de las
cuales las más usadas en los últimos años son Microsoft Excel y Microsoft Project,
con un porcentaje que abarca entre 68 a 59 y 46 a 28 respectivamente, aunque
Microsoft TFS se había mantenido con un porcentaje estable de 24%, en 2017
iceScrum llega para quitarlo dentro de las 5 más usadas para posicionarse en su
lugar con 23%.
118
Como hemos observado en las estadísticas hasta ahora Scrum llegó para quedarse,
pues indiscutiblemente ocupa el primer lugar en la listas de las metodologías más
usadas con 56, 58 y 61 por ciento y sigue en aumento, aunque muy despacio XP le
sigue el paso permanente con un porcentaje de 10. Lo que es importante mencionar
es que para el año 2017 la utilización de múltiples metodologías (Hibrida
personalizada) tuvo un aumento de 1% lo cual significa que se opta más por
combinar no solo Scrum/Xp si no realizar más combinaciones con más
metodologías agiles.
Por otro lado al comparar los análisis de factores que no favores o frenan las
agilidad nos encontramos, que la falta de capacidad para cambiar la cultura de la
organización ha ido en aumento en los últimos años del 44 al 45 por ciento, esto
quiere decir que las empresas no quieren asumir los gastos y la reorganización de
procesos que implican adoptar una metodología ágil para el desarrollo de software.
Pero no todo va mal pues la falta de experiencia en metodologías agiles un factor que
frenaba la agilidad ha ido en decremento considerablemente de un 44 a un 40 por
ciento, esto nos indica que los desarrolladores buscan cada vez más capacitarse en
las metodologías agiles.
119
11. Hipótesis
Es importante entender como las metodologías agiles como Scrum o eXtreme

Programming, son cada vez más puestas en práctica en las empresas desarrolladoras
de software ocupando el 55% y 11% de uso respectivamente, y como es que
aportan grandes beneficios a las organizaciones que deciden adoptarlas, destacando
el aumento de productividad, optimización de recursos, entregas del producto con
mayor rapidez y de mejor calidad, ofreciendo una alternativa a la forma tradicional de
desarrollar software. No es fácil hacer una descripción del tema debido al cambio
constante en dichas metodologías por lo que se pretende realizar un análisis a fondo
de la temática a sabiendas de la caducidad temprana de la información.
120
12. Bosquejo del método
Esta investigación está orientado a documentar el estado actual de las metodologías

agiles así como el impacto favorable o negativo que tiene las empresas al adoptar una
metodología para el desarrollo de software. Para muchas organizaciones el
seleccionar y/o adoptar una buena mitología de software para aplicar a su empresa le
resulta difícil por varios motivos dentro los cuales se encuentra la cultura que tiene
las organizaciones al desarrollar un producto de software nuevo y a al no querer
asumir los gastos y el desgaste de recursos que implica adoptar las metodologías de
software.
La investigacion se realiza investigando en documentos, tesis, reportes,

publicaciones y censos realizados por profesionistas que han tenido practicas
continuas con las metodologías agiles, con el propósito de apoyar al lector en la
selección asertiva de una metodología ágil para el desarrollo de software en una
organizaciones, y tenga una noción más clara del impacto que han tenido las
empresas al seleccionar una metodología y aplicarla de manera adecuada en sus
proyectos de software.
121
13. Cronograma
Un Cronograma es una representación gráfica y ordenada con tal detalle para que un
conjunto de funciones y tareas se lleven a cabo en un tiempo estipulado.
122
123
14. Presupuesto y/o financiamiento
Se denomina presupuesto al cálculo y negociación anticipada de los ingresos y

egresos de una actividad económica personal, familiar, un negocio, una empresa, una
oficina, un gobierno también hará gastos de una receta durante un período, por lo
general en forma anual.
Presupuesto
Presupuesto al periodo Agosto – Diciembre 2016
Tabla 10 Presupuesto al periodo Agosto-Diciembre 2016
124
Presupuesto al periodo Enero – Julio 2017
Tabla 11 Presupuesto al periodo Enero-Julio 2017
Presupuesto Total de la Investigación.
Tabla 12 Presupuesto Total de la Investigación
125
15. Lista de referencias
Ref 1 Raúl Úbeda González. (Marzo de 2009). Métodos ágiles para el desarrollo de
software. Proyecto de Titulación, Pg 407. Catalunya, España
Ref 2 Grupo ISSI (ingeniería de Software y Sistemas de Informacion), G. I. (12 al 14

de Noviembre de 2003). Metodologias Agiles en el Desarrollo de Software.
Pg 59. Alicante, España
Ref 3 Ingeniero Superior en Informática, C. y. (2016). elLABORATORIOdelasTI.

Recuperado el 19 de Septiembre de 2016, de El informe sobre el Estado de la
Agilidad 2016: http://www.laboratorioti.com/2016/09/19/informe-estado-la-
agilidad-2016/
Ref 4 Ingeniero Superior en Informática, C. y. (2016). elLABORATORIOdelasTI.

Recuperado el 19 de Septiembre de 2016, de ¿Qué métodos, técnicas y
herramientas Ágiles se utilizan más y Por qué?:
http://www.laboratorioti.com/2015/05/13/que-metodos-tecnicas-herramientas-
agiles-utilizan-mas-por-que/
Ref 5 Gallego, M. T. (01 de 11 de 2015). Metodologias SCRUM. Gestion de

poryectos informaticos, Pg. 56 Mexico.
Ref 6 Lerner, J. & Tirole, J. The Simple Economics of Open Source. 2001.
http://www.people.hbs.edu/jlerner/publications.html
Ref 7 C. B. Jones. Systematic Software Development Using VDM. Prentice Hall,

1986. The SLAM website. http://lml.ls.fi.upm.es/slam.
126
Ref 7 SCRUMstudy Targeting succes. (Enero de 2016). Guia para el cuerpo de
conocimientos de SCRUM. GUIA SBOK, Pg. 330. Mexico.
Ref 8 Herranz and J. Moreno-Navarro. Formal extreme (and extremely formal)

programming. Fourth International Conference on eXtreme Programming and
Agile Processes in Software Engineering (XP’03), May 2003.
Ref 9 Maurer, F. & Martel, S. On the Productivity of Agile Software Practices: An

Industrial Case Study.
http://ebe.cpsc.ucalgary.ca/ebe/Wiki.jsp?page=Publications, 2002
Juan Carlos Yelmo
Ref 10 Juan Carlos Yelmo Seminario 1

https://www.youtube.com/watch?v=p9MYRrQEOGI - Metodologías ágiles. El
proceso SCRUM
Ref 11 Juan Carlos Yelmo Seminario 2 -

https://www.youtube.com/watch?v=rQAPBTBq-OQ - Experiencia práctica en
la implantación y uso de Scrum
Ref 12 Juan Carlos Yelmo Seminario 3

https://www.youtube.com/watch?v=sXO02jqO-ZU - Escalando Agile a
proyectos de escala empresarial
Ref 13 Juan Carlos Yelmo Seminario 4-

https://www.youtube.com/watch?v=PEaqUlwyDS4 - Métodos ágiles e
ingeniería de requisitos con historias de usuario
127
Ref 14 Fernandez, A. D. (08 de Febrero de 2017). atSistemas. Recuperado el 02 de 03 de 2017, de La
Agilidad en el ciclo de vida de desarrollo:
https://www.atsistemas.com/es/novedades/webinars/Microservicios,-contenedores,-
DevOps%E2%80%A6-La-Agilidad-en-desarrollo-de-Software-seg%C3%BAn-atSistemas
Ref 15. http://www.scrumalliance.org
128
ANEXOS

El Estado Actual Das Metodologías Agiles 2012

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

El Estado Actual Das Metodologías Agiles 2012

Cargado por

Copyright:

Formatos disponibles

INTITUTO TECNOLOGICO DE ZACATECAS

DEPARTAMENTO DE SISTEMAS Y COMPUTACION

PROYECTO DE INVESTIGACION DE TALLER DE INVESTIGACIÓN II

“EL IMPACTO Y EL ESTADO ACTUAL DE LAS

ZACATECAS ZAC. ENERO – JUNIO 2017

Metodologías ágiles en las organizaciones

El presente proyecto de investigación como ya mencionamos muestra el estado actual

Tabla 1 Diferencia entre metodologías agiles y tradicionales .................................... 20

Figura 1 Proceso de Scrum ......................................................................................... 23

Grafica 1 Beneficos de la agilidad 2015 ................................................................... 65

En la presente investigación, se plasma algunas de las metodologías agiles más

Para abordar la investigación, se dividió la misma en tres capítulos. En el Capítulo

El árbol del problema es una forma de representar el problema ayuda a encontrar

Criterios de selección de metodologías de

El desarrollo de software no es una tarea nada sencilla, sobre todo cuando no se

En los últimos años se ha popularizado el uso de metodologías ágiles aplicadas al

4.1 Objetivo General:

Presentar el estado actual de las metodologías agiles para el desarrollo de software,

4.2 Objetivos Específicos:

 Conceptualizar las metodologías agiles más usadas por las organizaciones,

 Presentar el impacto que tiene la aplicación de metodologías agiles en las

 Mostrar los beneficios y fallas que tiene la aplicaciones de metodologías

 Conocer las herramientas para el desarrollo de software en las metodologías

Hoy en día con el auge de la tecnología, y con el objetivo de agilizar y automatizar

El impacto económico de un proyecto social se entiende como el nivel de eficiencia

Por lo cual la elaboración del presente documento de investigación sobre las

Hoy en día la tecnología y comunicación avanzan a una velocidad considerable, lo

Este tipo de investigación no tiene un impacto directo con ambiente, ya que es un

6.1 Capítulo I Introducción a las Metodologías Agiles

 Al individuo y las interacciones del equipo de desarrollo sobre el proceso

La gente es el principal factor de éxito de un proyecto software. Es más

 Desarrollar software que funciona más que conseguir una buena

La regla a seguir es “no producir documentos a menos que sean necesarios de

 La colaboración con el cliente más que la negociación de un contrato.

Se propone que exista una interacción constante entre el cliente y el equipo de

 Responder a los cambios más que seguir estrictamente un plan.

I. La prioridad es satisfacer al cliente mediante tempranas y continuas

III. Entregar frecuentemente software que funcione desde un par de semanas

IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo

VII. El software que funciona es la medida principal de progreso.

VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores,

IX. La atención continua a la calidad técnica y al buen diseño mejora la

XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos

Tabla 1 Diferencia entre metodologías agiles y tradicionales

El proceso de Scrum consta de tres fases: pre-game, desarrollo o game y post-game.

 Pre-Game, Subfase Planning: El planteamiento incluye la definición del

Figura 1 Proceso de Scrum

 Propietario Del Producto:El propietario del producto es oficialmente

 Equipo De Scrum: El equipo de Scrum tiene autoridad para decidir las

 Director: La gestión o dirección toma la última decisión y se encarga de los

 Product Backlog: El Product Backlog define todo lo necesario en el producto

Figura 2 Ficha de Producto Backlog utilizada en Scrum

 Estimación De Esfuerzo: La estimación de esfuerzo es un proceso iterativo

 Reunión Para Planear El Sprint: El Sprint Planning meeting consta de dos

 Reunión Diaria De Scrum: Se organizan reuniones de Scrum diarias para

 Sprint Review Meeting: En el último día del sprint, el equipo y el Scrum

Extreme Programming (a veces escrito eXtreme Programming) o programación

 En la fase de Exploración, los clientes escriben las historias en las tarjetas o

 La fase de Planificación de las versiones establece el orden de prioridad de

 La fase de Productionizing requiere más pruebas y verificar el rendimiento

 La fase de Muerte está cercana cuando el cliente ya no tiene ninguna

Figura 4 Pasos del Proceso de Extreme Programming

Hay diferentes papeles en XP para cada tarea y propósito durante el proceso y su