Metodologías Ágiles

INSTITUTO POLITCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERA Y

CIENCIAS SOCIALES Y ADMINISTRATIVAS
UNIDAD DE APRENDIZAJE:
Metodologa de la Investigacin Interdisciplinaria
SECUENCIA: 4NM71
PROFESOR(A): Lic. Miguel ngel Rojas Lpez Portillo
NOMBRE DEL TRABAJO DE INVESTIGACIN:
PANORAMA SOBRE METODOLOGAS DE DESARROLLO DE SOFTWARE GILES
INTEGRANTES DEL EQUIPO:
Bedolla Perez Felix Sahed
Espinoza Trujano Luis Enrique
Martnez Mrquez Oscar Fernando
Moncada Jasso Iram
Padilla Santana Carlo Gilmar
NDICE
INTRODUCCIN ............................................................................................................... 8
CAPTULO I MARCO METODOLGICO ........................................................................... 9
1.1 PLANTEAMIENTO DEL PROBLEMA ............................................................... 9
1.2 OBJETIVOS.................................................................................................... 10
1.3 TCNICAS E INSTRUMENTOS DE MEDICIN ............................................ 11
1.4 UNIVERSO Y MUESTRA ............................................................................... 11
1.5 JUSTIFICACIN ............................................................................................. 11
1.6 HIPTESIS..................................................................................................... 12
CAPTULO II MARCO TERICO ..................................................................................... 13
2.1 UN RECORRIDO SOBRE EL CONTEXTO HISTRICO ................................ 13
2.2 MANIFIESTO PARA EL DESARROLLO GIL DE SOFTWARE ..................... 16
2.3 LOS PRINCIPIOS GILES ............................................................................. 17
2.4 EL PARADIGMA GIL .................................................................................... 19
CAPTULO III. METODOLOGA SCRUM ......................................................................... 22
3.1 CONCEPTO ................................................................................................... 22
3.2 REGLAS ......................................................................................................... 23
3.3 ROLES ........................................................................................................... 24
3.4 ARTEFACTOS................................................................................................ 27
3.5 EVENTOS O ACTIVIDADES .......................................................................... 31
3.6 FUNCIONAMIENTO ....................................................................................... 33
3.7 TIPOS DE PROYECTO Y ORGANIZACIONES DONDE SE USA .................. 34
3.8 CERTIFICACIONES ....................................................................................... 36
3.9 BENEFICIOS Y DESVENTAJAS .................................................................... 38
CAPTULO IV. METODOLOGAS CRYSTAL ................................................................... 39
4.1 CONCEPTO ................................................................................................... 39
4.2 ROLES DE LOS PARTICIPANTES ................................................................ 40
4.3 MATERIALES Y MTODOS ........................................................................... 41
4.4 FUNCIONAMIENTO ....................................................................................... 41
4.5 APLICABILIDAD A PROYECTOS................................................................... 42
4.7 PRINCIPALES VENTAJAS Y DESVENTAJAS ............................................... 42
4.8 CONCLUSIN DE LA METODOLOGA ......................................................... 43
CAPTULO V EXTREME PROGRAMMING ..................................................................... 43
5.1 CONCEPTO ................................................................................................... 43
5.2 REGLAS ......................................................................................................... 43

5.2.1 REGLAS DE PLANIFICACIN ......................................................... 44
5.2.2 REGLAS PARA EL DISEO ............................................................ 44
5.2.3 REGLAS PARA EL DESARROLLO.................................................. 45
5.2.4 REGLAS PARA LAS PRUEBAS ...................................................... 45
5.3 VALORES DE LA PROGRAMACIN EXTREMA ........................................... 45
5.4 PRCTICAS DE LA PROGRAMACIN EXTREMA ........................................ 45
5.5 ROLES DE LA PROGRAMACIN EXTREMA ................................................ 48
5.6 ARTEFACTOS................................................................................................ 50
5.7 FUNCIONAMIENTO ....................................................................................... 50
5.8 TIPOS DE PROYECTO Y ORGANIZACIONES DONDE SE USA .................. 52
CAPTULO VI. KANBAN .................................................................................................. 54
6.1 CONCEPTO ................................................................................................... 54
6.2 FUNCIONES................................................................................................... 55
CONCLUSIONES............................................................................................................. 57
GLOSARIO ...................................................................................................................... 60
FUENTES DE CONSULTA .............................................................................................. 63
NDICE DESCRIPTIVO
Captulo I Marco Metodolgico
Presentamos los principales objetivos de nuestra investigacin, as como aquello
que nos motiva a realizar esta investigacin.
Captulo II Marco Terico
Las metodologas giles de desarrollo de software son un conjunto de marcos de
trabajo que empezaron a popularizarse en la dcada de los 90S, a inicios del siglo
XXI se escribi el manifiesto gil que contiene los principales valores y prcticas
giles como alternativa a las metodologas tradicionales.
Captulo III Metodologa Scrum
Scrum se ha posicionado como una de las metodologas giles de desarrollo de
software ms populares en los ltimos aos, ya sea por su nivel de eficiencia,
versatilidad y adaptabilidad. En este captulo se describirn sus principios,
ideologa y funcionamiento los cuales nos brindaran un mejor entendimiento de
cmo este popular marco de trabajo expone la doctrina Agile.
Captulo IV Metodologas Crystal
Crystal es una familia de metodologas de desarrollo gil que consta de muchas
variedades, las cuales dependen de varios factores como el tamao del proyecto,
su complejidad, tolerancia a fallos, etc. En este captulo nos enfocamos en su
derivado Clear para describir el funcionamiento de las dems.
Captulo V Extreme Programming
Extreme Programming (Programacin Extrema) es una disciplina de desarrollo del
software centrada en desarrollar las relaciones interpersonales a travs de
valores, los cuales van de la mano de ciertas reglas estructuradas de
metodologas previamente definidas para alcanzar una meta en comn el cual es
reducir el costo de cambio en los proyectos.
Captulo VI Kanban
Kanban es un mtodo para la mejora de procesos industriales. No fue sino hasta

que, a David Anderson, en 2010, se le ocurri mejorar los procesos de
construccin de software. Este captulo explica cmo se aplica al desarrollo de
software.
RESUMEN
Captulo III. SCRUM
Una de las metodologas giles para el desarrollo de software ms populares es
SCRUM, debido a que es muy organizada y muy aplicable en las organizaciones
que necesitan llevar un mejor control sobre su programacin de tiempos de
entrega y la calidad con la que los productos son llevados a los interesados en los
proyectos.
En este captulo encontraremos mucha terminologa especializada que se
detallar en el mismo. Mucha de la cual se refiere a los roles de los participantes
del proyecto; a los periodos de entrega de resultados; lo que se piensa hacer para
la siguiente entrega; los interesados en el desarrollo de la aplicacin; al progreso
con el que se cuenta hasta el momento, entre muchos otros. A pesar de contar
con mucha terminologa (lo cual puede parecer desalentador), animamos al lector
a que la conozca pues existen varias certificaciones que mejorarn su desarrollo
profesional.
Captulo IV. Crystal Clear
Al referirnos a metodologas de desarrollo Crystal, tenemos que hablar de una
serie de herramientas de desarrollo que se adaptan de acuerdo al tamao del
equipo. Por motivos de extensin, hemos decidido limitarnos a hablar de aquella
variedad de Crystal que engloba a los equipos de pocas personas: Crystal Clear,
no obstante, muchas de las caractersticas aplican para todas las dems. A
diferencia de SCRUM, se centra ms en el desarrollo y tiene menos nfasis en la
asignacin de roles.
Captulo V. Extreme Programming
En este captulo se explicarn las caractersticas y principios fundamentales que
basan a una de las metodologas menos complejas en cuanto a tamaos de
equipo y estructura organizacional. Esto se debe a que su paradigma es centrado
6
en las personas, no en el desarrollo o en el proyecto en s mismo; pero todo esto

lo describiremos mejor en el captulo.
Captulo VI. Kanban
Kanban surgi como una herramienta para mejorar los procesos industriales en
tiempos donde era vasta la demanda de productos terminados. Cuando el auge
del desarrollo de las aplicaciones tuvo su apogeo, tambin se gener la necesidad
de obtener una mejora de los procesos de desarrollo de aplicaciones en varias de
las metodologas existentes. Fue entonces cuando a alguien se le ocurri adaptar
la metodologa Kanban de procesos industriales, a la informtica. Durante el
transcurso del captulo mencionaremos a quin se le atribuye este hecho y por
qu se diferencia tanto de las metodologas anteriormente descritas.
INTRODUCCIN
Una computadora es para m la herramienta ms sorprendente que hayamos ideado. Es
el equivalente a una bicicleta para nuestras mentes-Steve Jobs
El trmino metodologa segn la Real Academia Espaola es un es un vocablo

generado a partir de tres palabras de origen griego: met (ms all), ods
(camino) y logos (estudio). La comprensin por extensin nos induce a
aceptar que la metodologa es una serie de procedimientos para alcanzar un fin
especfico.
En el presente documento indagaremos en cada una de las metodologas giles
de desarrollo de sistemas, empezando en el captulo II, estableceremos el
contexto histrico que influy en el origen de las metodologas giles, despus,
presentamos los 12 principios del manifiesto gil, que es un documento escrito por
un grupo de desarrolladores y cuyo objetivo es presentar los valores principales
para el proceso de creacin de software.
A travs de investigacin bibliogrfica de fuentes confiables, presentamos al lector
un breve, pero conciso contexto de las metodologas giles (Scrum, Crystal,
Extreme Programming y Kanban) en el desarrollo del software actual (al momento
de la revisin: mayo del 2016).
De cada una de estas metodologas presentaremos los siguientes puntos:
Concepto.
Reglas.
Roles.
Artefactos.
Eventos o Actividades.
Funcionamiento.
Tipos de proyecto y organizaciones donde se usan.
Certificaciones.
Ventajas y desventajas.
CAPTULO I MARCO METODOLGICO

1.1 PLANTEAMIENTO DEL PROBLEMA
Los profesionales que en la actualidad se dedican a la industria de las Tecnologas
de la Informacin deben tomar en cuenta la necesidad de estar apegados a las
tendencias actuales orientadas por las tecnologas y prcticas demandadas por la
industria en general. El portal DataCenter seala que un profesional que tiene
competencias como las que se demandan su valor en el mercado sube un 10% o
ms segn el ndice de Remuneracin de Habilidades de TI y Certificaciones del
Foote Partners LLC (Search Data Center, 2016).
Y aunque lo importante y esencial debera ser la excelencia en el conocimiento
tcnico para la creacin de software, se requiere que un profesional cultive otro
tipo de habilidades que permitan potencializar la colaboracin en equipo y agregue
a su vez valor al negocio. Jeffrey Hammond, vicepresidente y analista para el
desarrollo de aplicaciones de Forrested Research Inc. apunta: "los empresarios
de hoy en da la mayora de los cuales no son negocios de software
tradicionales quieren ese algo extra de los desarrolladores que aporte valor a la
organizacin" (Search Data Center, 2016).
Es necesario transformar un negocio que se valga de proyectos de TI de manera
organizacional de la mano de un nuevo paradigma. Jos Luis Noriega, director
comercial de BBVA seala: hay que dejar que se asiente un nuevo sistema IT,
formar a los equipos y obtener rendimiento de la inversin. Lo disruptivo hoy es
conseguir transformar una compaa, de arriba abajo, en una mquina de
gestionar las continuas alteraciones que ocurren en el contexto de negocio, no en
el de IT, y de actuar ante ellas con agilidad, de mano del nuevo paradigma de las
Metodologas giles (Centro de Innovacin BBVA, 2016). Y este paradigma ha
ido subiendo posiciones entre las tendencias de gestin de proyectos.
Por lo tanto ante la necesidad de un profesional por actualizarse en las tendencias
y conocimientos actuales, por adquirir capacidades que aporten valor a la
organizacin, y ante el surgimiento de este nuevo paradigma en la industria de las
9
Tecnologas de la Informacin, es conveniente comprender el surgimiento y

desarrollo de las Metodologas giles, as como entender las bases de las
prcticas ms importantes como lo son Scrum, Extreme Programming, Crystal, y
Kanban, segn el portal Search Data Center.
1.2 OBJETIVOS
Objetivo general
Conocer con fines exploratorios las principales metodologas (segn Jos Cans
en su artculo Metodologas giles en el Desarrollo de Software 2003) giles de
desarrollo de software, sus beneficios, desventajas, as como conocer el por qu
fueron diseadas.
Objetivos especficos
1. Conocer qu significa el trmino metodologas giles de desarrollo de
software, segn la Real Academia Espaola.
2. Explicar qu es el manifiesto gil y los principios que estipula para trabajar
con las metodologas giles.
3. Describir algunas metodologas giles populares (segn Patricio Letelier en
su artculo su artculo Metodologas giles en el Desarrollo de Software
2003), mencionando sus caractersticas y mtodos con los que operan.
4. Describir las ventajas y desventajas que conlleva la utilizacin de cada una
de ellas.
5. Lograr que el lector sepa elegir entre la metodologa ms conveniente para
desarrollar un determinado proyecto, segn los instrumentos y artefactos
con los que cuenta actualmente, as como los requerimientos (como lo
expone Daniel Jimnez en su artculo Test de metodologas giles, Qu
metodologa es mejor: Scrum, Kanban o Scrumban? encontrado en el portal
http://www.genbetadev.com)
6. Hacer una comparacin con la forma tradicional de desarrollo de software
con estas metodologas (Justo como lo hace Elena Gordillo Polo Consultora
de TI en su blog https://inventtatte.com/metodologia-tradicional-vs-agil/)
7. Explorar el contexto histrico en el que surgieron las metodologas giles.
10
1.3 TCNICAS E INSTRUMENTOS DE MEDICIN

La presente investigacin no usar tcnicas e instrumentos de medicin debido a
que pretendemos indagar a nivel documental.
1.4 UNIVERSO Y MUESTRA
Debido a que nuestra investigacin se enfoca a una bsqueda documental, no
tendremos universo y muestra.
1.5 JUSTIFICACIN
Las metodologas giles de desarrollo de software como Scrum, Kanban, Extreme
Programming y Crystal, segn el portal Search Data Center, han impactado en la
manera en que se construyen los sistemas de informacin en los ltimos aos.
Inclusive en la Encuesta de Salarios ms actual del portal Gur Software del 2015
la certificacin de Scrum Master se ponder como una de las mejores pagadas por
encima de certificaciones como la de Seguridad, SAP, Java, UML, Linux, Android,
entre otras.
As mismo enfocaremos nuestra investigacin no slo a los aspectos tcnicos de
cada metodologa, tambin pretende describir los valores esenciales, mismos que
aportan el valor organizacional, que segn Jeffrey Hammon, necesitan las
empresas. Aunado a esto el portal Search Data Center seala que un profesional
con nociones sobre las tendencias actuales tiene una mejor remuneracin
econmica.
Nuestra indagacin acercar los contenidos investigados a nuestros compaeros
de clase, promoviendo una nueva visin en la creacin y gestin de proyectos, as
se divulgarn los nuevos marcos de trabajo motivando a nuestra comunidad a
ahondar ms en estos temas.
Hemos optado por descubrir la esencia de las metodologas giles debido a la
importancia que representa dentro de nuestra formacin profesional, as como
representa iniciar por vez primera una investigacin cientfica formal.
11
El alcance de nuestra investigacin se limita a fines exploratorios. Pretende ser

una gua introductoria a las metodologas giles para los compaeros de nuestra
carrera.
1.6 HIPTESIS
Esta investigacin no tendr hiptesis debido a su enfoque documental, pero se
plantean las siguientes preguntas de investigacin a modo de gua conceptual
para este proyecto de investigacin:
Cul es la importancia de las metodologas giles de desarrollo de
software?
Qu metodologas son las ms utilizadas en las empresas de desarrollo
de software ms grandes del mundo (como Facebook o twitter)?
Cmo funcionan las metodologas giles de desarrollo de software (scrum,
xp, crystal y kanban)?
Qu ventajas y desventajas existen al usar las metodologas giles de
desarrollo de software?
Qu roles existen en cada una de las metodologas giles desarrollo de
software (scrum, xp, crystal y kanban) y cul es su funcin?
Qu certificaciones se ofrecen en el mercado para las metodologas giles
de desarrollo de software?
Qu artefactos utiliza cada metodologa gil de desarrollo (scrum, xp,
crystal y kanban) y como se usan en el proceso de creacin de software?
En qu se basa la ideologa gil de desarrollo de software?
Qu beneficios nos ofrecen las metodologas giles con respecto a las
metodologas tradicionales de desarrollo de software?
En qu tipo de proyectos se pueden utilizar las metodologas giles de
desarrollo (scrum, xp, crystal y kanban)?
12
CAPTULO II MARCO TERICO

2.1 UN RECORRIDO SOBRE EL CONTEXTO HISTRICO
Es importante realizar un seguimiento sobre los hechos ocurridos anteriores a
algn tema, recurrir al anlisis histrico permite visualizar el presente como una
sucesin de hechos encadenados iniciados en el tiempo pasado, y a travs de
ellos podemos establecer relaciones causales que permitan inferir la importancia
que tienen para el presente.
Es pertinente rescatar aquellos sucesos de mayor relevancia tanto en los hechos
pasados que dieron pie a las Metodologas giles, como un contexto histrico del
devenir mundial y de la produccin de tecnologa de software.
A continuacin, realizar una lnea de tiempo, primero voy a resaltar los aspectos
que considero como antecedentes directos del desarrollo de las Metodologas
giles:
En 1939 Walter Shewhart populariza el uso de los ciclos cortos de
planificacin en proyectos.
En 1948 Taiichi Ohno implement por vez primera el uso de Kanban en
los sistemas de fabricacin de Toyota.
En 1950 Se desarrolla el Jet hipersnico X-15 mediante un ciclo de
desarrollo iterativo.
En 1951 William Deming
propuso el primer mtodo incremental IIDD
Iterative and Incremental Design and Development.

En 1969 se crea el PMI (Project Manager Institute).
En 1970 se define por vez primera el modelo en cascada.
En 1975 Bill Gates fund Microsoft.
En 1976 Steve Jobs fund Apple.
En 1978 Ohno public el libro The Toyota Production System.
En 1985 Tom Gilb public Evolutionary
Delivery
versus
the
Waterfall
Model.
En 1988 se populariza el trmino de Lean Manufacturing.
13
En 1995 nace el marco de trabajo Scrum como modelo para desarrollo de

software, Jim Coplien y L. Constantine crean la forma Pair Programming.
En 1996 Kent Beck desarroll el modelo Extreme Programming.
En 1997 Jeff de Luca invent el Feature Driven Development
En 1998 T. Cockburn cre las metodologas crystal.
En el 2001 se adopt el
nombre de metodologas giles y se cre el
manifiesto gil.
En el 2002 Kent Beck desarroll el Test Driven Development, mientras J.
Grenning cre el Planning Poker, y se fund la Scrum Alliance.
Aunque la primera fecha est en los inicios del siglo XX, la actividad se intensifica
ms en los aos 70S y 90S.
Pero qu ocurra en ese periodo de tiempo? A continuacin, menciono hechos
importantes, as como detalles culturales en el acontecer mundial en el siglo XX:
1911 F. Taylor public The Principles of Scientific Management.
1914 Primera Guerra Mundial
1914 Revolucin Bolchevique en Rusia. EU era el primer pas industrial del
mundo pues tena empresas que se dedicaban a la siderurgia, petrleo y
combustibles, as como automviles, y empez a recibir personas que
emigraban.
1929 Cada de la bolsa de valores en EU, y puesta en marcha del New
Deal, el mercado internacional cae por las medidas adoptadas.
1931 se empez a producir el automvil modelo T de Henry Ford.
1939 Segunda Guerra Mundial
1945 EU se convirti en el principal productor de alimentos, automviles,
electrodomsticos, centros comerciales, entre muchos otros; pronto
impuls los derechos civiles, la exploracin espacial, educacin y asistencia
mdica. Existieron cambios importantes como que los pases
occidentales adoptaron polticas de crecimiento econmico, modernizacin
y pleno empleo a travs del intervencionismo estatal.
1947 entr el Plan Marshall para reconstruir Europa. Inicia la Guerra Fra
entre EEUU y la URSS.
14
1950 creacin de la CECA, rumbo a la Unin Europea. En Europa creca la

demanda de automviles, en Francia se inaugura el primer tren aos ms
tarde.
1956 Ludwing Von Bertalanffy public la Teora General de los Sistemas.
1960 surga la corriente
existencialista en obras de Sartre, Camus,
Beauvoir, el teatro absurdo: era una visin del mundo que implicaba una
idea
negativa de la condicin humana que sealaba que el hombre

apareca forzado a vivir en un mundo carente de valores y sentido.
El existencialismo ingls se ocup de cuestiones del lenguaje,
lgica,
mtodo,
relacin
entre
significado
proposicin
filosfica. Literatura como Camino de Servidumbre de Hayek, La

sociedad abierta y sus enemigos de Popper, Los Orgenes del
totalitarismo de Arendt, proponan ideas sobre articular una sociedad justa:
la idea del individuo como sujeto de la poltica y de la historia, pluralismo
poltico, etc. Francis Bacon pint figuras
como expresin de soledad
distorsionadas,
claustrofbicas,
y el desamparo del hombre.
1964 juegos olmpicos en Japn, marcaba el inicio de la potencia mundial,

ya se gestaban industrias como Toyota, Honda, Sony, Panasonic, Nissan,
Nintendo.
1966 revolucin cultural en China.
1969 llegada del hombre a la Luna. En Europa, despus que, en EU, se
popularizaron los
ordenadores, computadores personales, instrumentos
de aplicacin,
satlites. Para el inicio de la siguiente dcada Europa
ya era una
sociedad construida bajo los estndares de EU, pero con altos
niveles de desarrollo, bienestar social, desarrollo y empleo.

Aos 80S EU figuraba a la cabeza de la revolucin tecnolgica asociada a
los ordenadores y
las ms
la tecnologa digital, as como sus universidades eran
prestigiosas como centros de investigacin.
1990 Reunificacin de Alemania, cada del Muro de Berln.

1991 disolucin de la URSS.
1996 B. Clinton como presidente de EU, el pas ya gozaba de una
hegemona mundial, bienestar econmico, hipermodernidad, la cultura era
uno de los ncleos del siglo XX, adems de ser un enorme mercado de
innovacin tecnolgica y de consumo de masas.
15
2001 cada de las torres gemelas.

2008 crisis econmica internacional.
A grandes rasgos es posible ir equiparando las dos lneas del tiempo antes
mencionadas, por lo que podemos ver que las Metodologa giles empezaron a
surgir en los aos 90'S, justo en un momento del escenario mundial donde el
capitalismo ganaba terreno de la mano de EU tras la cada de la URSS y el
aumento de su hegemona, pero tambin en un momento en que podra parecer
que
las
ideas
del
existencialismo
filosfico
maduraban
despus
de
aproximadamente 30 aos, impactando en el nuevo terreno frtil en el que

comenzaba a desarrollarse la tecnologa emergente a travs de organizaciones
lderes como Microsoft o Apple; ya para inicio del siglo XXI el manifiesto gil
describe una serie de principios para desarrollar software que poco tenan que ver
con cuestiones tcnicas, pues se enfocan ms en valores humanos y prcticos.
2.2 MANIFIESTO PARA EL DESARROLLO GIL DE SOFTWARE
Apenas en el 2001 un grupo de desarrolladores y autores, escribieron un
documento llamado Manifiesto para el desarrollo gil de software con el objetivo
de brindar un contexto sobre los valores principales que aportan ms beneficios al
proceso donde se crea software, mejor conocido como el manifiesto gil. Como
bien es sealado por Stellman & Greene Agile is also a mindset, because the right
mindset can make a big difference in how effectively a team uses the practices.
(Stellman & Greene, 2015:22)
Este documento expresa las ideas que conviene preferir para un desarrollo gil,
como valorar ms a los individuos y sus interacciones, sobre los procesos y
herramientas; valorar ms software funcionando qu documentacin extensa,
valorar ms la colaboracin con el cliente que una negociacin sobre el contrato, y
valorar ms el responder al cambio, que seguir un plan predefinido. No quiere
decir que las segundas opciones no sean importantes, lo son, pero se prefiere la
primera alternativa.
Uno de los clichs ms comunes que se tiene es creer que el manifiesto est
contra los procesos, herramientas, documentacin, negociacin de contrato y la
16
planeacin; sin embargo, esto es una idea falsa. El manifiesto indica que estas
ideas aportan menor valor al proceso de desarrollo que las que presenta como
ideas prioritarias. Se intenta provocar una catarsis donde las organizaciones
puedan identificarse con una u otra idea, al ver las que promociona el movimiento
gil como indispensables para que un proyecto adquiera valor. Aunque theres no
single recipe that results in perfect software every time. Agile teams recognize this.
Instead, they have ideas and ground rules that help to guide teams to make the
right choices and avoid problemsor deal with those problems when they
inevitably happen. (Ibd, 52)
2.3 LOS PRINCIPIOS GILES
El manifiesto gil define 12 principios giles que se deben llevar a cabo en un
proceso gil.
1.- La principal prioridad es la satisfaccin del cliente bajo una entrega temprana
de valor en el software. Este principio es normalmente ignorado en las dems
formas de llevar a cabo procesos de creacin de software. Es importante recordar
que el cliente quiere valor a su organizacin, no una documentacin tcnica o
ideas poco digeridas, mientras ms temprano se inicie a desarrollar ms pronto se
podrn satisfacer las necesidades del cliente. Se menciona que This first principle
includes three distinct and important ideas: releasing software early, delivering
value continuously, and satisfying the customer. (Ibd., 55)
2.- Bienvenidos los cambios en los requerimientos, incluso cuando ya se est en la
fase de desarrollo. Los procesos giles se acoplan a la dinmica de los
requerimientos, y se debe tener en cuenta que estos son muy variables al inicio,
durante y al final del proyecto. Los clientes estn compitiendo en un mercado
dinmico, por lo tanto, deben adaptarse rpidamente ante estos cambios, aunque
no quiere decir que todos los cambios son gratuitos o no conllevan esfuerzo.
3.- Liberar software funcionando en un periodo de 2 semanas hasta dos meses,
prefiriendo el menor tiempo posible. Esto permite una entrega al cliente en una
etapa temprana en la que podr probar el software y brindar una retroalimentacin
17
temprana al equipo de desarrollo para indicarle si est entregando valor, o si debe

cambiar la estrategia que estaba siguiendo.
4.- Las personas del negocio y los desarrolladores deben colaborar juntos para
obtener un buen proyecto. Se entiende por las personas del negocio a aquellos
otros colaboradores importantes dentro de la organizacin, adems del cliente
directo, que pueden brindar informacin que aporte valor al proyecto.
5.- Construir proyectos con personas motivadas. Este principio enfatiza la
necesidad de un ambiente propicio para hacer un buen trabajo profesional, las
personas no son recursos, y el desarrollo de software no es manufactura
industrial. Los equipos de trabajo necesitan ser motivados, y confiar en ellos.
6.- La comunicacin ms eficiente es la conversacin cara a cara. Aqu se enfatiza
la importancia de la comunicacin entre todos los implicados del proyecto, debido
a que esto no se ha tomado en cuenta, y ante los avances tecnolgicos muchas
veces se prefiere, por ejemplo, enviar correos electrnicos, o bien mensajes de
texto creando una brecha comunicacional, que en la prctica lleva a malos
entendidos y confusiones.
7.- Software funcionando es la principal medida de progreso. El cliente es la
primera persona interesada en que el software como producto final est
funcionando y aportando valor, por ello es importante que sea la medida de
progreso del proyecto. Muchas veces, en proyectos no giles, se confa el
progreso en el cumplimiento de un diagrama de Gantt, o un cronograma, es decir
de documentos propios de una planeacin temprana, sin embargo, la dinmica de
los requerimientos hace que estas tcnicas, cuyo campo es la manufactura,
proporcionen datos equivocados. Es posible llevar la mitad de eventos de un
cronograma, y decir que se lleva 50% de avance, pero el software realmente no
funciona ni aporta valor a la organizacin.
8.- Un proceso gil promueve un desarrollo sustentable. Los implicados del
proyecto deben ser capaces de encontrar un equilibrio colaborativo, equipos auto
organizados, y colaborativos.
18
9.- La agilidad es promovida por la excelencia tcnica y buenos diseos. La

excelencia tcnica es necesaria para establecer un verdadero proceso gil de
creacin de software.
10.- La simplicidad es esencial, el arte de maximizar el trabajo no hecho. No
programar no significa que el proyecto carezca de errores, si algo no es esencial
en el producto no se hace, esto debido a que muchos equipos de desarrollo
tienden a dilatar los requerimientos, as como aumentar el trabajo y esfuerzo para
algo que al final no entregar valor a la organizacin.
11.- Las mejores arquitecturas, toma de requerimientos y diseos emergen de
grupos auto organizados. En las metodologas no giles el analista escribe los
requerimientos, los arquitectos realizan la arquitectura del sistema, ambos
comunicados al equipo de desarrollo por medio de documentos y minutas, por lo
general esta brecha de comunicacin termina generando confusiones.
12.- En intervalos regulares de tiempo un equipo refleja cmo es ms efectivo.
Este es quiz el principio ms importante sobre la agilidad, esta idea de reflejar el
grado de colaboracin y esfuerzo en un periodo corto de tiempo permite tomar
consciencia de aquello que estn haciendo bien, y aquello que estn haciendo mal
para mejorarlo.
En general cualquier desarrollo gil debe cumplir con estos principios, as como
las tcnicas que se usan y herramientas estn enfocadas hacia ellos, Agile is
unique in the history of software engineering. Its unlike the waves of silver bullet
methodologies over the years, which promised to solve your teams software
problems through a combination of magic practices, brilliant software tools, and,
not infrequently, large invoices from consulting companies. (Ibd, 81)
2.4 EL PARADIGMA GIL
La forma tradicional de realizar proyectos es primero establecer el conjunto de
requerimientos que se debe cumplir, este conjunto se realiza una sola vez en la
planeacin, y es invariable. El responsable del proyecto asume las siguientes
fases de la planeacin extensa a partir de los requerimientos, estiman que tan
19
largo ser el proceso, y crean el plan del proyecto para predecir la fecha en que
terminarn el proyecto, esa fecha es comunicada al cliente quin agenda una cita
para la entrega. En una reunin acuerdan los requerimientos con el cliente, y la
segunda reunin es para la entrega del proyecto. El plan que se realiza, valga la
redundancia, en la planeacin no cambia, y maneja el comportamiento durante el
tiempo que dura el desarrollo del producto hasta la entrega; pero la experiencia en
el desarrollo muestra que esta forma de trabajo no es aplicable, pues los
requerimientos siempre cambian, y al cambiar estropean la gran planificacin a
largo plazo que se realiz a partir de ellos; esto lleva a la entrega tarda de
proyectos que no son totalmente funcionales.
El paradigma para la conduccin de proyectos giles es totalmente diferente,
asume por principio que los requerimientos no son nunca fijos, y que cualquier
toma inicial de requerimientos ser solo el punto de inicio para nuevos. Se asume
una fecha en la que se deber liberar una versin temprana del producto, para
obtener una retroalimentacin y as poder ir definiendo aquellos factores que no
fueron previstos anteriormente. Los requerimientos se priorizan en orden de
importancia y se trabajan aquellos que se cree que podrn desarrollarse en el
perodo de tiempo acordado. Como cada perodo de tiempo se deber entregar
una versin, permitir que se vayan cubriendo poco a poco los requerimientos
reales del cliente, que pueden ser aquellos que se previeron en la planificacin, o
no necesariamente. La retrospectiva que brinde la entrega temprana permitir que
esto sea posible.
Podemos clasificar dos tipos de metodologas por un lado las tradicionales que
se basan en los conceptos bsicos de la administracin de proyectos, por lo
general industriales, y las metodologas giles basadas en una forma evolutiva de
lograr soluciones.
En resumen, las metodologas tradicionales:
Se basan en un modelo de prediccin donde se define en una etapa
temprana el proceso del proyecto.
Se detalla al inicio todas las especificaciones del proyecto.
Se debe mencionar al principio el costo y esfuerzo.
20
Es posible detallar cada parte del proceso desde la primera planificacin.

Mientras las metodologas giles:
Casi nunca es posible detallar todas las etapas del proceso.
Es un proceso emprico, al inicio no se puede determinar el costo y
esfuerzo del proyecto en general.
Al inicio es imposible especificar cada parte del proceso que conforma al
proyecto.
Apenas en el ao 2007 se tena que 90% de los equipos que usaron las
metodologas giles incrementaron su productividad, 85% redujeron los defectos
del software que desarrollaron, 83% aceleraron el tiempo en entregar valor, y el
66% redujeron los costos del proyecto.
(Figura 1.4 disponible en Becoming Agile, pg. 12)

Otros beneficios de adoptar la agilidad en los equipos de desarrollo de software
son las siguientes:
Manejo oportuno de tiempos que evita la entrega tarda de proyectos que
no funcionan.
Creacin de proyectos con una mayor calidad en el software.
Construccin de cdigos
entendibles.
La agilidad se enfoca en satisfacer las necesidades del cliente y su

organizacin.
La agilidad permite una auto gestin del tiempo de trabajo del equipo.
21
Por lo tanto, hemos desglosado las generalidades de los valores que persiguen las
Metodologas giles en el desarrollo de Software, dado que su uso est
aumentando cada vez ms es para nosotros interesante ahondar al respecto, de
forma que describiremos las metodologas ms populares en los siguientes
captulos.
CAPTULO III. METODOLOGA SCRUM

3.1 CONCEPTO
Scrum es una metodologa gil de desarrollo, que permite desarrollar software de
manera incremental, de alto valor en entornos donde los requerimientos no estn
bien establecidos y donde se requiere de rapidez, as como flexibilidad en los
resultados obtenidos.
Scrum tambin es considerado un framework o marco de trabajo, es decir, nos
aporta un conjunto de herramientas que nos permiten realizar un proceso iterativo
e incremental para la gestin y desarrollo de software.
Scrum es un marco de trabajo por el cual las personas pueden acometer
problemas complejos adaptativos, a la vez que entregar productos del mximo
valor posible productiva y creativamente (Schwaber, 2013, p.4).
Scrum es un modelo de desarrollo gil caracterizado por:
Adoptar una estrategia de desarrollo incremental, en lugar de la
planificacin y ejecucin completa del producto.
Basar la calidad del resultado ms en el conocimiento tcito de las
personas en equipos auto organizados, que en la calidad de los procesos
empleados.
Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una
tras otra en un ciclo secuencial o de cascada. (Palacio, 2014, p. 16).
Cabe sealar que SCRUM no es una serie de pasos metdicos establecidos que
garantizan el xito de proyecto, ms bien, es una serie de herramientas que se
22
basan en valores, principios y prcticas giles que garanticen una mejor

organizacin del trabajo y una comunicacin ms acertada con el cliente.
Scrum is not a standardized process where you methodically follow a series of
sequential steps that are guaranteed to produce, on time and on budget, a highquality product that delights customers. Instead, Scrum is a framework for
organizing and managing work (Kenneth, 2013, p.13).
3.2 REGLAS
Este conjunto de herramientas o modelo de trabajo funciona bajo un esquema de
reglas bien definidas donde cada una de estas tiene una funcin especfica para el
xito del proyecto.
Las reglas de SCRUM se dividen en 3 secciones: roles, eventos y artefactos
donde la interaccin entre estos componentes conforma el funcionamiento del
modelo SCRUM.
Las reglas de Scrum relacionan los eventos, roles y artefactos, gobernando las
relaciones e interacciones entre ellos (Schwaber, 2013, p.4).
(Figura 1.5 Reglas o Prcticas Scrum disponible en Essential Scrum, pg. 14)
23
3.3 ROLES
Los roles en Scrum son las funciones que desempean cada uno de los
involucrados en el proyecto, de estos tenemos 2 principales categoras.
Roles Cerdo: los cuales estn involucrados directamente en el proceso Scrum.
(Comprometidos)
Roles Gallina: los cuales en realidad no forman parte del proceso Scrum, pero
estn involucrados en el mbito del proyecto. (Implicados)
Dentro de los roles cerdo existen 3 principales roles: el Product Owner el Scrum
Master y el Equipo de desarrollo los cuales son los responsables del proyecto,
que en su conjunto reciben el nombre de Scrum Team.
(Figura 1.6 Scrum Team disponible en Essential Scrum, pg. 15)

Este equipo es auto organizado y multifuncional segn lo menciona Schwaber.
Los equipos auto organizados eligen la mejor forma de llevar a cabo su trabajo y
no son dirigidos por personas externas al equipo. Los equipos multifuncionales
tienen todas las competencias necesarias para llevar a cabo el trabajo sin
depender de otras personas que no son parte del equipo. El modelo de equipo en
Scrum est diseado para optimizar la flexibilidad, la creatividad y la
productividad. (Schwaber, 2013, p.6).
Adems, este equipo entrega productos de forma gil, es decir, siguiendo los
principios del manifiesto gil de forma iterativa e incremental y as obteniendo una
retroalimentacin constante.
24
Las entregas incrementales de producto Terminado aseguran que siempre

estar disponible una versin potencialmente til y funcional del producto (Ibdem,
2013, p.6).
El Product Owner o dueo del producto es el encargado de tomar las
decisiones del proyecto desde la perspectiva del negocio, es decir, es el
encargado de dirigir al Scrum Team en la direccin que el cliente desea. Es el
enlace de comunicacin entre el cliente y el Scrum Team, el cual traduce las
necesidades de este en historias de usuario, las prioriza y las coloca en el
Product Backlog, artefactos que sern detallados posteriormente.
El Dueo de Producto es el responsable de maximizar el valor del producto y del
trabajo del Equipo de Desarrollo. (Ibdem, 2013, p.6).
Es importante sealar que el dueo del producto es una sola persona y es la nica
que puede cambiar la lista del producto, el representa los deseos de los clientes
y las opiniones del Scrum Team, pero para que funcione este modelo todos deben
respetar sus decisiones y cualquier cambio en la lista de producto o
requerimientos deber ser por medio de esta persona.
El equipo de desarrollo es un grupo de 5 a 9 personas integrado por expertos
en informtica tales como analistas de sistemas, programadores, testers,
administradores de bases de datos, etc. Los cuales son responsables por el
diseo, construccin y pruebas del producto deseado.
Los Equipos de Desarrollo son estructurados y empoderados por la organizacin
para organizar y gestionar su propio trabajo. La sinergia resultante optimiza la
eficiencia y efectividad del Equipo de Desarrollo (Ibdem, 2013, p.7).
Ellos se auto gestionan para lograr de la mejor manera los objetivos determinados
por el Product Owner, adems en Scrum no se identifican ttulos para cada
integrante de este equipo, todos son desarrolladores independientemente del
trabajo que realice.
25
Para proyectos grandes donde se requiere de un gran nmero de personas, en

lugar de tener un Scrum Team con todos los integrantes, normalmente se divide
en varios Scrum Teams para que el nmero de personas no vare y as se realice
el trabajo de la manera ms eficiente posible.
El tamao ptimo del Equipo de Desarrollo es lo suficientemente pequeo como
para permanecer gil y lo suficientemente grande como para completar una
cantidad de trabajo significativa. Tener menos de tres miembros en el Equipo de
Desarrollo reduce la interaccin y resulta en ganancias de productividad ms
pequeas y tener ms de nueve miembros en el equipo requiere demasiada
coordinacin. Los Equipos de Desarrollo grandes generan demasiada complejidad
como para que pueda gestionarse mediante un proceso emprico. (Ibdem, 2013,
p.7).
El Scrum Master es el encargado de hacer que todos los involucrados estn
apegados a los principios, valores y prcticas de Scrum. Su principal funcin es el
coaching y el liderazgo manteniendo una sinergia en todo el equipo, es decir,
mantiene al equipo centrado en los objetivos y elimina cualquier impedimento
organizacional que se presente, adems mantiene la armona y motivacin entre
los integrantes del Scrum Team.
Este personaje siempre est reflejando el rumbo del equipo, podemos considerar
que es el espejo del equipo. Adems, es un facilitador que organiza las
reuniones diarias, proporciona los elementos para realizar los artefactos y eventos,
y no permite que alguien externo al Scrum Team interrumpa el trabajo del equipo.
The Scrum Master does whatever it takes to make the Scrum Team successful,
such as removing organizational impediments, facilitating meetings, acting as a
gatekeeper so no one unnecessary interrupts the team's work. (Sutherland, 2012,
p.12).
El Scrum Master es un lder que est a disposicin del Scrum Team ayudando a
personas externas al equipo a entender las interacciones del equipo y el
funcionamiento de Scrum, a adoptar este modelo y planificar la implementacin
26
Scrum en la organizacin. Adems, ayuda al equipo mismo a ejecutar tcnicas

para gestionar el trabajo de manera efectiva.
En los roles gallina se encuentran 2 principales roles, los usuarios y los
stakeholders. Estos no son parte del proceso Scrum, sin embargo, se deben
tener en cuenta ya que estn afectados por el proyecto y forman parte de la
comunicacin cliente-desarrollador.
Los usuarios son las personas finales en el proceso, aquellos que utilizaran el
software, de ah su importancia para saber a quin va dirigida la solucin
informtica.
Los stakeholders son los clientes, proveedores y altos mandos que hacen
posible el proyecto. Para ellos el proyecto producir un beneficio por lo que
participan en las revisiones del sprint.
3.4 ARTEFACTOS
Los artefactos Scrum son objetos de valor que representan el trabajo del equipo,
estos son de diversas formas los cuales de una manera transparente permiten el
entendimiento, inspeccin y adaptacin del proceso Scrum por parte del Scrum
Team.
El primer artefacto recibe el nombre de Product Backlog, lista de producto o
Pila de producto la cual es una lista ordenada o priorizada de los requerimientos
conocidos o todo lo que podra ser necesario en el producto. Esta sigue la filosofa
de Scrum: Hacer el trabajo de ms valor primero. Adems, esta lista es realizada
por el Product Owner, el cual es el responsable de determinar la secuencia del
trabajo y determinar qu caractersticas se incluyen en la lista siendo el nico que
puede hacer modificaciones en la misma, pero con la retroalimentacin y
colaboracin del Scrum Team y de los Stakeholders.
Cabe mencionar que esta lista no es fija, ya que puede estarse modificando
(refactorizando), agregando nuevas tareas o defectos que se necesitan reparar
siendo meramente dinmica y revisada por el product owner cada que las
27
condiciones del negocio cambian. Entre los factores que se consideran para
ponderar y priorizar los elementos de la lista se encuentran valor, costo,
conocimiento y riesgo los cuales determinan qu caracterstica estar hasta arriba
de este artefacto y cuales hasta abajo. Cada una de estos elementos tiene el
nombre de historias de usuario las cuales se refieren a funcionalidades
entregables, no a trabajos internos del tipo diseo de la base de datos.
(Figura 1.7 Product Backlog disponible en Essential Scrum, pg. 19)

El Sprint Backlog es una lista de tems provenientes del Product Backlog, los
cuales van a ser implementados en el sprint, es decir, es la seleccin de las
caractersticas convertidas en actividades de la lista general que se van a realizar
en el incremento. Otra forma de visualizarlo sera como los objetivos
seleccionados a cumplir durante el sprint. Estos tems son la descomposicin de
las historias de usuario seleccionadas del Product Backlog convirtindolas en
actividades, siendo esta seleccin de tems una tarea del Scrum Team completo.
En esta lista cada tem est asignado a un miembro del equipo indicando cuanto
tiempo y esfuerzo se prev para terminarla. Adems, al ser una descomposicin
en unidades pequeas de las historias de usuario se puede monitorear el avance
diario e identificar las problemticas que puedan surgir.
28
Esta lista sirve como comunicacin visual del equipo pues en ella se observa el
progreso de cada persona en cada una de las tareas asignadas, pudiendo ser
modificada nicamente por el Scrum Team durante el Sprint.
La Lista de Pendientes del Sprint es el conjunto de elementos de la Lista de
Producto seleccionados para el Sprint, ms un plan para entregar el Incremento
de producto y conseguir el Objetivo del Sprint. La Lista de Pendientes del Sprint es
una prediccin hecha por el Equipo de Desarrollo acerca de qu funcionalidad
formar parte del prximo Incremento y del trabajo necesario para entregar esa
funcionalidad en un Incremento Terminado (Schwaber, 2013, p.16).
(Figura 1.9 Sprint Backlog disponible en Essential Scrum, pg. 22)

El Burn down Chart es una grfica que muestra la cantidad de tems del
Product Backlog pendientes al comienzo de cada Sprint. Con esto es mucho ms
fcil visualizar el progreso del proyecto, monitoreando la velocidad y capacidad de
trabajo.
Es una grfica descendente o burn down ya que al inicio del proyecto estn
pendientes todos los requerimientos y conforme se avanza disminuyen hasta que
29
se completan, siendo una recta el progreso lineal e ideal y una curva el progreso
real del proyecto.
(Figura 2.0 Burn Down Chart disponible en The Scrum Handbook, pg.35)
El incremento es la parte del producto final terminada, o los tems del Product
Backlog realizados en el Sprint, este incremento debe tener las cualidades de
estar completamente terminado, es decir, que es completamente operativa, est
probado y en condiciones de ser entregadas al cliente.
El Incremento es la suma de todos los elementos de la Lista de Producto
completados durante un Sprint y el valor de los incrementos de todos los Sprints
anteriores. Al final de un Sprint, el nuevo Incremento debe estar Terminado, lo
cual significa que est en condiciones de ser utilizado y que cumple la Definicin
de Terminado del Equipo Scrum. El incremento debe estar en condiciones de
utilizarse sin importar si el Dueo de Producto decide liberarlo o no. (bidem,
2013, p.17).
30
3.5 EVENTOS O ACTIVIDADES

Los eventos son bloques de tiempo definido, es decir, tienen una duracin
mxima. Con esto se evitan reuniones innecesarias que entorpezcan el trabajo del
equipo. Todos los eventos suceden dentro del sprint, y una vez que este comience
no puede alargarse o acortarse. Cabe mencionar que todos los eventos estn
diseados para lograr la inspeccin y la adaptacin del proyecto, por lo que la falta
de alguno de estos mermar la calidad del producto y la oportunidad de mejora.
El Sprint es un ciclo iterativo de duracin definida, aproximadamente de un mes
de duracin el cual no puede ser alargado se termine el incremento o no. En este
evento se desarrolla una funcionalidad del producto para producir nuevos
incrementos funcionales, en el suceden todos los dems eventos Scrum, los
cuales hacen que el producto sea diseado, codificado y probado haciendo que el
mismo evolucione.
El Grooming es la actividad en la cual se definen, estiman y priorizan los tems
del product backlog. En si la realizacin del mismo, como se puede apreciar en la
siguiente imagen.
(Figura 2.1 Grooming disponible en Essential Scrum, pg. 19)

Despus sigue el Sprint Planning en donde se planifica el trabajo a realizar
durante el Sprint, este plan es creado por el Scrum Team completo. Este evento
tiene una duracin mxima de 8hrs y es el Scrum Master quien se encarga de que
el evento se ejecute de manera eficaz y en tiempo.
31
La Reunin de Planificacin de Sprint responde a las siguientes preguntas:

Qu puede entregarse en el Incremento resultante del Sprint que
comienza?
Cmo se conseguir hacer el trabajo necesario para entregar el
Incremento? (Ibdem, 2013, p.10).
En este evento se define el Sprint Goal que es la meta que puede ser
alcanzada durante el Sprint, este debe estar en mente durante todo el evento para
que se trabaje hacia la misma direccin. Adems, en este evento se crea el
Sprint backlog que se explic con anterioridad.
El Daily Scrum es una reunin diaria de 15 minutos de duracin

aproximadamente, en la cual se discute el estado del proyecto. En este el equipo
de desarrollo sincroniza sus actividades y crea un plan para las siguientes
actividades del da. Por otra parte, se inspecciona el trabajo ya hecho desde el
ltimo daily scrum y se hace una proyeccin de lo que se podra lograr para el
prximo.
El Scrum Diario se realiza a la misma hora y en el mismo lugar todos los das
para reducir la complejidad. Durante la reunin, cada miembro del Equipo de
Desarrollo explica:
Qu hice ayer que ayud al Equipo de Desarrollo a lograr el Objetivo del
Sprint?
Qu har hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del
Sprint?
Veo algn impedimento que evite que el Equipo de Desarrollo o yo
logremos el Objetivo del Sprint? (Ibdem, 2013, p.12).
En el Sprint Execution se realizan todas las tareas asignadas en el Sprint
Backlog necesarias para lograr los objetivos y las caractersticas del producto
terminadas, este se realiza justo despus de que el Scrum Team est de acuerdo
con el contenido especificado en el Sprint Planning.
32
Estas tareas no tienen un orden especfico, y el development team puede

realizarlas como ellos deseen auto organizndose y gestionando para la
realizacin de las mismas siempre y cuando se terminen a tiempo y logren los
objetivos marcados.
El Sprint Review se enfoca en hacer el anlisis e inspeccin del incremento
generado, haciendo adaptaciones al Product Backlog si es necesario. En este
evento se hace una revisin de lo que se aadi al producto, y participan tanto el
Scrum Team completo como los stakeholders.
En este evento se discuten las cosas que podran hacerse para optimizar el valor
del producto, sin embargo, es una reunin informal donde el principal objetivo es
facilitar la retroalimentacin de informacin y fomentar la colaboracin.
The goal of this activity is to inspect and adapt the product that is being built.
(Kenneth, 2013, p.)
Por ltimo, est el Sprint Retrospective donde los integrantes del Scrum Team
dejan sus impresiones del sprint recin terminado justo despus de hacer el sprint
review y antes de hacer el prximo sprint planning. La principal meta de esta
reunin es la mejora continua de proceso. Al igual que el daily scrum, esta reunin
tiene un tiempo definido de 4 horas.
En esta reunin se discute que fue lo que pas durante el sprint, que funcion y
que no, para llegar a acuerdos los cuales resaltan los cambios y adaptaciones que
se deben realizar.
3.6 FUNCIONAMIENTO
El proceso Scrum se basa en el sprint, donde suceden todas las actividades. Este
inicia con el grooming, donde se define el product backlog para el caso del primer
sprint y se adapta para los dems sprints priorizando y ordenando las
caractersticas del producto, despus se realiza el sprint planning donde se
definen qu caractersticas del product backlog se harn en el sprint, se
descomponen en tareas cuantificadas y se ordenan en el sprint backlog estimando
33
el tiempo en que se tardar en hacer cada tarea y proponiendo estrategias para su

correcta realizacin.
Una vez definido qu y quienes harn el trabajo se procede con la ejecucin del
sprint que bsicamente es la parte de desarrollo del producto, en esta parte
suceden reuniones diarias para tener una retroalimentacin del trabajo y se
monitorea el progreso de las tareas que se estn realizando y las ya realizadas.
Despus del tiempo definido para el sprint sucede el sprint review donde se hace
un recuento de lo que se ha hecho y se obtiene el incremento creado en el sprint,
para posteriormente iniciar el Sprint retrospective, donde se analiza lo que se ha
hecho bien y lo que se ha hecho mal, para as proponer acuerdos y adaptaciones
que aseguren la calidad del producto.
Al final se repite el proceso, de ah que se diga que es cclico e iterativo hasta que
se completen todos los sprints definidos, o bien, hasta que el producto est en el
punto que el cliente lo acepte.
(Figura 2.2 Scrum Process disponible en Essential Scrum, pg. 17)

3.7 TIPOS DE PROYECTO Y ORGANIZACIONES DONDE SE USA
El uso de la metodologa Scrum est indicado para proyectos en entornos
complejos, donde se necesita obtener resultados pronto, donde los requisitos son
34
cambiantes o poco definidos, donde la innovacin, la competitividad, la flexibilidad

y la productividad son fundamentales.
La cultura de la empresa proveedora del proyecto debe estar alineada con la
filosofa de una gestin gil de proyectos como Scrum. Debe fomentar:
El trabajo en equipo y la colaboracin entre todas las personas implicadas
en un proyecto.
Equipos autogestionados a los que se ha delegado la responsabilidad y
autoridad para hacer su trabajo, en contraposicin a la direccin y control
de personas que ejercera un jefe de proyecto tradicional (en lugar del jefe
de proyecto existe la figura del Facilitador).
La creatividad del equipo.
La transparencia y la mejora continua, tanto del contexto de la organizacin
y del proyecto y como de las herramientas del equipo (Loayza Salazar,
2010, p.55).
Muchas empresas de renombre han hecho uso de la metodologa Scrum para
desarrollar sus productos, en la siguiente tabla observamos ejemplos de
organizaciones que usan o han usado Scrum.
Sectores
Ejemplos de empresas que utilizan Scrum
Media y Telcos
BBC,
BellSouth,
Motorola,
Nokia,
British
Telecom,
DoubleYou,
Palm,
Qualcomm,
Schibsted,
Sony/Ericsson, Telefnica I+D, TeleAtlas, Verizon

Software, Hardware
Adobe, Autentia, Biko2, Central Desktop, Citrix,

Gailn, IBM, Intel, Microfocus, Microsoft, Novell,
OpenView
Labs,
Plain
Concepts,
Primavera,
Proyectalis, Softhouse, Valtech, VersionOne.

Internet
Amazon, Google, mySpace, Yahoo
ERP
SAP
35
Banca e Inversin
Bank of America, Barclays Global Investors, Key

Bank, Merrill Lynch
Sanidad y Salud
Patientkeeper, Philips Medical
Defensa y Aeroespacial
Boeing, General Dynamics, Lockheed Martin
Juegos
Blizzard,
High
Moon
Studios,
Crytek,
Ubisoft,
Electronic Arts
Otros
3M, Bose, GE, UOC, Ferrari

Tabla. Casos de xito usando Scrum (dem, 2010, p.62).
3.8 CERTIFICACIONES
Por lo menos existen 7 opciones en el mercado para obtener la certificacin en

desarrollo usando la metodologa Scrum y cada una de estas ofrecen enfoques
diferentes y otras ofrecen un panorama mundial.
1. Scrum Alliance
Uno de los sitios ms antiguos y respetados que brinda varias certificaciones,
aunque en los mercados hispanoparlantes la ms conocida es la de Scrum
Master.
Scrum Master Certificado (CSM)
Propietario de producto (CPO)
Desarrollador Scrum (CSD)
A su vez, se ofrecen dos certificaciones para aquellos que requieran

especializarse en Scrum y Agile:
Profesional certificado (CSD)
Coach de Scrum (CSC)
2. Organizacin Scrum (Scrum.org)

Ken Schwaber fue uno de los fundadores de Scrum Alliance que luego decidi
apartarse y seguir su camino. Varios de sus exmenes estn abiertos al pblico
sin necesidad de tomar sus cursos y ofrecen un nivel de dificultad alto.
36
Scrum Master profesional 1 y 2 (PSM I, PSM II)
Propietario de producto profesional 1 y 2(PSPO I, PSPO II)
Desarrollador profesional 1 (PSD I)
3. PMI-ACP (pmi.org)
El conocido Instituto de gestin de proyectos, el cual finalmente adems de su
clsico programa de cursos y certificaciones relacionadas a metodologas
tradicionales, comenz a ofrecer la certificacin de Practicante gil luego de llevar
adelante un perodo de prueba durante 2011. Ellos cuentan con una comunidad de
prctica de gil y recomiendan decenas de libros para la preparacin del examen
(muchos de los cuales son los mismos que sugiere ScrumAlliance) y tambin hay
ediciones especficas que se centran en la preparacin del examen.
4. NetObjectives
Ofrecen certificacin de Scrum Master, Propietario del producto y varios cursos
sobre Lean y gil. A diferencia con las instituciones anteriores, tambin brindan los
exmenes de SAFe (Scaled Agile Framework), lo cual es un marco de trabajo
Scrum orientado a compaas de gran porte.
5. ICAgile
Est especializado en ofrecer material consistente y principalmente de calidad
para universidades y organizaciones. Tienen 3 niveles de certificacin, las que
evalan el conocimiento adquirido, pero tambin la experiencia del participante.
Cuentan con un modelo que apoya a Universidades y empresas que deseen
albergar cursos estndares sobre todos los aspectos de gil (no solamente
Scrum).
Es una excelente opcin para Facultades u otras organizaciones similares que
requieran ensear los distintos tpicos de forma unificada.
6. Academia de gil distribuido, SAFe (scaledagileacademy.com)
Ofrece certificaciones para empresas de gran porte mediante una versin de
Scrum adaptada. A grandes rasgos, el marco de trabajo consiste en sincronizar
diferentes pilas de producto a varios niveles y la aparicin de nuevos roles, as
como la extensin de los roles clsicos.
37
El modelo ofrece consistencia para las compaas que emplean actualmente

metodologas tradicionales y desean moverse hacia Scrum.
Consultor SAFe (SAFe program Consultant)
Agilista (SAFe program Agilist)
Practitioner (SAFe program Practitioner)
En SAFe la empresa simplemente seguir prcticas, sin impulsar un cambio de

corporativo real, con las consecuencias que ello puede traer.
7. Probador (tester) certificado gil (Instituto internacional de calidad de
software, agile-tester.org)
Es una organizacin de origen alemn que cuenta con un curso de 5 das
centrado en la especializacin de testers para un entorno gil. Ellos creen que
no puede ser simplemente enseado y tiene que ser demostrado con prcticas. Es
por ello que el curso ocupa plenamente 5 das donde se evalan no solamente las
herramientas, sino que tambin las interacciones entre las personas. Al momento
tienen alrededor de 2000 personas certificadas, lo cual es un nmero bajo
comparado con otras organizaciones, pero una excelente opcin si se piensa que
ataca un nicho especfico de mercado (Bhler, E, 2014).
3.9 BENEFICIOS Y DESVENTAJAS
Como toda metodologa, Scrum no es sinnimo de perfeccin, si bien nos ofrece
muchos beneficios para el desarrollo de proyectos, existen tambin desventajas al
usar esta metodologa; y tiene que ver con la buena ejecucin de cada tarea, as
como con el conocimiento o experiencia que se tenga al usar esta metodologa.
Ventajas de Scrum:
Gestin regular de las expectativas del cliente: el cliente establece sus

expectativas indicando el valor que le aporta cada requisito del proyecto y
cuando espera que est completado.
Flexibilidad y adaptacin: de manera regular el cliente redirige el proyecto

en funcin de sus nuevas prioridades, de los cambios en el mercado, de los
38
requisitos completados que le permiten entender mejor el producto, de la

velocidad real de desarrollo, etc.
Retorno de inversin (ROI): de manera regular, el cliente maximiza el ROI

del proyecto. Cuando el beneficio pendiente de obtener es menor que el
coste de desarrollo, el cliente puede finalizar el proyecto.
Mitigacin de riesgos: desde la primera iteracin el equipo tiene que

gestionar los problemas que pueden aparecer en una entrega del proyecto.
Al hacer patentes estos riesgos, es posible iniciar su mitigacin de manera
anticipada.
Productividad y calidad: de manera regular el equipo va mejorando y

simplificando su forma de trabajar.
Alineamiento entre cliente y equipo: los resultados y esfuerzos del proyecto

se miden en forma de objetivos y requisitos entregados al negocio. Todos
los participantes en el proyecto conocen cul es el objetivo a conseguir. El
producto se enriquece con las aportaciones de todos.
Equipo motivado: las personas estn ms motivadas cuando pueden usar

su creatividad para resolver problemas y cuando pueden decidir organizar
su trabajo.
Desventajas Scrum:
Requiere delegar responsabilidades al equipo, incluso permite fallar si es
necesario.
Es una metodologa que difiere del resto, y esto causa cierta resistencia en
su aplicacin para algunas personas (Loayza Salazar, 2010, p.55).
CAPTULO IV. METODOLOGAS CRYSTAL

4.1 CONCEPTO
Crystal es una familia de metodologas con un cdigo gentico en comn, uno
que enfatiza entregas frecuentes, comunicacin cercana y mejora reflectiva. No
hay una sola metodologa Crystal, sino varias para distintos tipos de proyectos.
Cada proyecto u organizacin usa el cdigo gentico para generar nuevos
miembros de la familia. (Cockburn, 2004, p. 4).
39
El nombre Crystal viene de mi caracterizacin de proyectos que implican

dos dimensiones, tamao y criticalidad, que coinciden con el de los
minerales, color y dureza [...] Proyectos ms grandes, requieren de ms
coordinacin y comunicacin, representados con colores gradualmente ms
oscuros (Claro, Amarillo, Naranja, Rojo, y as sucesivamente). Proyectos
para sistemas que pueden causar ms dao, necesitan dureza aadida en
la metodologa, ms validacin y reglas de verificacin (bidem, p. 4).
Para ilustrar su forma de trabajo, se tomar como ejemplo una de las variedades
que nos ofrece Crystal: Crystal Clear.
Los equipos que trabajan con Crystal Clear tienen el paradigma de trabajar en
equipo su intencin es darle menos peso al trabajo de documentacin, pues
creen que lo importante es darle al usuario la solucin que pide, y no confundirlo
con documentacin usualmente trabajan con ideas plasmadas en un pizarrn,
donde asientan los requerimientos del usuario y el diseo de la solucin
entregable. Ellos estriban en desarrollar una mente comunitaria. Se sientan al
inicio y entienden el problema que quieren resolver, trabajan en el tratamiento que
le brindarn y comienzan a trabajar (bidem, pp. 19, 20).
4.2 ROLES DE LOS PARTICIPANTES
Patrocinador
Usuario experto
Diseador principal
40
Diseador- programador
Experto en negocios
Coordinador
Probador (Tester)
Escritor de documentacin (Writer)
4.3 MATERIALES Y MTODOS
Lpiz
Plumones o pintarrones
Libretas o papel
Pizarrn
Computadoras personales
Prototipos
Lluvia de ideas
Reuniones grupales
Autocrtica
Valores de equipo
Conexiones con el usuario
Desarrollo incremental iterativo
Casos de uso
Entregables
Pruebas
4.4 FUNCIONAMIENTO
A grandes rasgos, existe un proceso bien definido para trabajar con esta
metodologa:
1. Obtencin de requerimientos del o los usuarios interesados (Los cuales
pueden ser los ejecutivos patrocinadores).
2. Definicin de infraestructura y requerimientos tecnolgicos.
3. Elaborar un plan de entrega (la frecuencia con la que se entregarn los
prototipos).
41
a. En cada entrega se deben discutir el propsito de las pantallas y su

secuencia.
b. Tambin se deben realizar las pruebas necesarias al sistema, como
pruebas de regresin o unitarias, en pequeas reuniones referentes
al diseo.
4. Entregar una versin de prueba a las dos semanas, misma que el usuario
revisar y servir como base para reforzar los requerimientos y hacer ajustes
en errores descubiertos para las siguientes iteraciones.
4.5 APLICABILIDAD A PROYECTOS
Computadoras centrales (mainframes), sistemas de arquitectura cliente servidor,
sistemas basados en red (con bases de datos centrales o distribuidas). Puede ser
moldeado para sistemas en tiempo real con reglas adicionales para planear y
verificar los problemas de sincronizacin del sistema. No est destinado para
sistemas a prueba de fallos, ya que le falta reseas duras de arquitectura para
tolerancia a fallos y recuperacin (Cockburn, 2004, pp. 19, 20).
4.6 CERTIFICACIONES
CMMI Agile / Lean Development and CMMI
4.7 PRINCIPALES VENTAJAS Y DESVENTAJAS
Ventajas
Gran tolerancia a la notacin del cdigo fuente generado (siempre y cuando

el equipo est de acuerdo).
Las entregas acordadas son a corto plazo, por lo general de uno a tres
meses.
Est diseada para el cambio.

Reduccin de costos.
Planificacin ms transparente para los clientes.
Retroalimentacin activa con los clientes.
42
Desventajas
Las pruebas de regresin y programacin en pares tienen poca tolerancia.
El tamao del equipo debe ser de 2 8 personas nicamente.
Delimita el alcance del proyecto con el cliente.
4.8 CONCLUSIN DE LA METODOLOGA
La familia de metodologas de desarrollo Crystal es una buena alternativa para
agilizar el proceso de construccin de software cuando se quiere trabajar en un
equipo mediano, pues existe mucha comunicacin interna con los colaboradores
del proyecto, y externa con los interesados en su desarrollo; tambin es una
metodologa muy flexible y orientada a los resultados, dado que no es muy forzoso
terminar con cientos de pginas de documentacin para tener el software
construido.
CAPTULO V EXTREME PROGRAMMING

5.1 CONCEPTO
La Programacin Extrema es una metodologa gil centrada en desarrollar las
relaciones interpersonales como clave del xito del desarrollo del software,
promoviendo ciertos valores, entre ellos, el trabajo en equipo, desarrollar el
aprendizaje de los desarrolladores y creando un clima de trabajo ptimo (Beck,
Kent,1999).
5.2 REGLAS
Una de las caractersticas de eXtreme Programming es que muchos de, s no
todos, sus ingredientes son de sobra conocidos dentro de la rama de la ingeniera
del software desde hace tiempo, incluso desde sus comienzos. Para que exista
una regla, debe de existir una persona del proyecto que la cumpla, un objeto o
artefacto que la verifique y un evento que la contenga, as identificamos los roles,
eventos y artefactos de la programacin extrema.
43
Segn Joskowicz (2008), podemos englobar estos elementos desde la perspectiva

del desarrollo de la programacin extrema:
Reglas para la Planificacin
Reglas para el Diseo
Reglas para el Desarrollo
Reglas para las Pruebas
5.2.1 REGLAS DE PLANIFICACIN
En planificacin es esencial seguir la regla que nos indica que la comunicacin
activa entre el cliente, desarrolladores y coordinadores o gerentes, es el punto de
inicio del proyecto, aqu el proyecto debe de cumplir las siguientes caractersticas
(Frowler, 2001):
Planes simples sin complejidad
Planes realizados por el equipo sin agentes externos
Los planes no son predicciones a futuro son estimaciones que son
susceptibles a cambios
Para lograr el cometido el proyecto recopila historias de usuario, una vez
obtenidas los programadores estiman el trabajo requerido para cumplir las
historias, utilizando la evaluacin de riesgos de la metodologa espiral, se detecta
las historias que sean un obstculo para la entrega, se utilizan (spikes) para
determinar riesgos para generar una toma de decisiones. A continuacin, se
genera una reunin de planificacin con los integrantes del equipo para generar el
plan de entrega (Release Plan), a partir de este plan se genera un plan de
iteraciones para entregas del producto y reuniones diarias para coordinar los
esfuerzos.
5.2.2 REGLAS PARA EL DISEO
La Programacin Extrema hace especial nfasis en diseo simples y claros, el
equipo los puede desarrollar siguiendo el siguiente valor que es la sencillez en
conjunto de buenas prcticas que son la recodificacin y las metforas.
44
5.2.3 REGLAS PARA EL DESARROLLO

La principal regla que sigue la programacin extrema en el desarrollo del proyecto
es que todo el trabajo debe ser una gran propiedad colectiva con reglas
estndares aceptadas por todo el equipo, las principales prcticas que siguen esta
regla son: programacin en parejas, programacin dirigida por pruebas,
integraciones permanentes.
5.2.4 REGLAS PARA LAS PRUEBAS
En el aspecto de pruebas, Beck (1999) nos explica que todo mdulo del sistema
debe de liberarse a travs de pruebas unitarias, deteccin de errores y aprobando
las pruebas de aceptacin.
5.3 VALORES DE LA PROGRAMACIN EXTREMA
Para garantizar el xito de un proyecto de Programacin Extrema, el equipo debe
poner en prctica estos valores:
Comunicacin:
La
XP
ayuda
mediante
sus prcticas
a la
comunicacin entre los integrantes del grupo de trabajo.

Sencillez: Los programas deben de ser sencillos y tener la
funcionalidad requerida en los documentos de requisitos
Retroalimentacin: Las pruebas que se realizan al proyecto
mantienen informados al equipo de desarrollo sobre el grado de
fiabilidad del sistema.
Valenta: Es necesario asumir retos, afrontar los problemas, siempre
mejorar algo que ya funciona.
5.4 PRCTICAS DE LA PROGRAMACIN EXTREMA
El principal objetivo de la programacin extrema es disminuir la mtica curva
exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el
diseo evolutivo funcione. XP apuesta por un crecimiento lento del costo del
cambio y con un comportamiento asinttico, de acuerdo con (Joskowicz,2008)
existen las siguientes prcticas en la programacin extrema.
La Planificacin
45
En esta fase de la programacin extrema, el cliente establece la prioridad de cada

historia de usuario, de acuerdo con el valor que aporta para el negocio. Los
programadores estiman el esfuerzo asociado a cada historia de usuario. Se
ordenan las historias de usuario segn prioridad y esfuerzo, y se define el
contenido de la entrega y/o iteracin, apostando por enfrentar lo de ms valor y
riesgo cuanto antes. Esta prctica se realiza durante la planificacin de la entrega,
en la planificacin de cada iteracin y cuando sea necesario reconducir el
proyecto.
Entregas pequeas
La idea es producir rpidamente versiones del sistema que sean operativas,
aunque obviamente no cuenten con toda la funcionalidad pretendida para el
sistema, pero s que constituyan un resultado de valor para el negocio. Una
entrega no debera tardar ms 3 meses.
Metfora
Una metfora es una historia compartida que describe cmo debera funcionar el
sistema. Fowler (2001), explica que la prctica de la metfora consiste en formar
un conjunto de nombres que acten como vocabulario para hablar sobre el
dominio del problema. Este conjunto de nombres ayuda a la nomenclatura de
clases y mtodos del sistema.
Diseo simple
Kent Beck (1999) asegura que en cualquier momento el diseo adecuado para el
software es aquel que: supera con xito todas las pruebas, no tiene lgica
duplicada, refleja claramente la intencin de implementacin de los programadores
y tiene el menor nmero posible de clases y mtodos.
Pruebas
La produccin de cdigo est dirigida por las pruebas unitarias. Las pruebas
unitarias son establecidas antes de escribir el cdigo y son ejecutadas
constantemente ante cada modificacin del sistema. Los clientes escriben las
pruebas funcionales para cada historia de usuario que deba validarse.
46
Refactorizacin (Refactoring)
La Refactorizacin es una tcnica de anlisis que permite al equipo de
programacin extrema replantear el orden de los mdulos lgicos y fsicos del
sistema tal y como seala (Robert Martin, 2002) que el diseo del sistema de
software es una cosa viviente por lo que se puede imponer todo en un inicio, pero
en el transcurso del tiempo este diseo evoluciona conforme cambia la
funcionalidad del sistema. Para mantener un diseo apropiado, es necesario
realizar actividades de cuidado continuo durante el ciclo de vida del proyecto.
Programacin en parejas
La programacin en parejas es una de las principales fortalezas de XP, los puntos
a favor de esta tcnica es una mejor deteccin de errores y por consiguiente las
mtricas de calidad del sistema aumentan, segn Cockburn y Williams (2000), el
conocimiento no se reserva a un solo grupo de programadores sino que todos
los miembros del equipo pueden modificar y reparar el cdigo del sistema en
parejas. En los estudios realizados por Cockburn y Williams el tiempo promedio
para que el equipo trabaje en parejas con un rendimiento considerable vara de 3
a 4 meses.
Propiedad colectiva del cdigo
Cualquier programador puede cambiar cualquier parte del cdigo en cualquier
momento. Esta prctica motiva a todos a contribuir con nuevas ideas en todos los
segmentos del sistema, evitando a la vez que algn programador sea
imprescindible para realizar cambios en alguna porcin de cdigo.
Integracin continua
Cada pieza de cdigo 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 da.
Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo
cdigo sea incorporado definitivamente.
40 horas por semana
Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas extras
en dos semanas seguidas. Si esto ocurre, probablemente est ocurriendo un
47
problema que debe corregirse. El trabajo extra desmotiva al equipo. Los proyectos
que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser
entregados con retraso. En lugar de esto se puede realizar el juego de la
planificacin para cambiar el mbito del proyecto o la fecha de entrega.
Cliente in-situ
El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Gran
parte del xito del proyecto XP se debe a que es el cliente quien conduce
constantemente el trabajo hacia lo que aportar mayor valor de negocio y los
programadores pueden resolver de manera inmediata cualquier duda asociada. La
comunicacin oral es ms efectiva que la escrita, ya que esta ltima toma mucho
tiempo en generarse y puede tener ms riesgo de ser mal interpretada.
Estndares de programacin
XP enfatiza la comunicacin de los programadores a travs del cdigo, con lo cual
es indispensable que se sigan ciertos estndares de programacin (del equipo, de
la organizacin u otros estndares reconocidos para los lenguajes de
programacin utilizados). Los estndares de programacin mantienen el cdigo
legible para los miembros del equipo, facilitando los cambios.
5.5 ROLES DE LA PROGRAMACIN EXTREMA
Segn Newkirk (2001) existen siete roles en un equipo de programacin extrema a
saber:
Programador
El programador escribe las pruebas unitarias y produce el cdigo del sistema.
Debe existir una comunicacin y coordinacin adecuada entre los programadores
y otros miembros del equipo.
Cliente
El cliente escribe las historias de usuario y las pruebas funcionales para validar su
implementacin. Adems, asigna la prioridad a las historias de usuario y decide
48
cules se implementan en cada iteracin centrndose en aportar mayor valor al

negocio.
Uno de los ideales es que el cliente es slo uno dentro del proyecto, pero puede
corresponder a un interlocutor que est representando a varias personas que se
vern afectadas por el sistema (Beck,1999).
Encargado de pruebas (Tester)
El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales.
Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es
responsable de las herramientas de soporte para pruebas.
Encargado de seguimiento (Tracker)
El encargado de seguimiento proporciona realimentacin al equipo en el proceso
XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones
realizadas y el tiempo real dedicado, comunicando los resultados para mejorar
futuras estimaciones. Tambin realiza el seguimiento del progreso de cada
iteracin y evala si los objetivos son alcanzables con las restricciones de tiempo y
recursos presentes (Newkirk,2001).
Entrenador (Coach)
Es responsable del proceso global. Es necesario que conozca a fondo el proceso
XP para proveer guas a los miembros del equipo de forma que se apliquen las
prcticas XP y se siga el proceso correctamente (Beck,1999).
Consultor
Es un miembro externo del equipo con un conocimiento especfico en algn tema
necesario para el proyecto. Gua al equipo para resolver un problema especfico.
Gestor (Big Boss)
Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje
efectivamente creando las condiciones adecuadas. Su labor esencial es de
coordinacin.
49
5.6 ARTEFACTOS
Los artefactos de la programacin extrema, que dicho en otras palabras son
herramientas del equipo de desarrollo, son las siguientes: historias de usuario y
tarjetas CRC (Beck,1999).
Historias de usuario
Las historias de usuario representan una breve descripcin del comportamiento
del sistema deseado por el usuario, sin trminos tcnicos, se realiza una historia
de usuario por cada funcin del sistema, se emplean para realizar estimaciones
del tiempo y para el lanzamiento de las funciones, reemplazan un gran nmero de
documentos de requisitos y emplean pruebas de sistema para su verificacin.
Tarjetas CRC (CLASE- RESPONSABILIDAD-COLABORADOR)
Una clase es cualquier persona, cosa, evento, concepto, pantalla o reporte

(Jacobson,2001). Las responsabilidades de una clase son las cosas que conoce y
las que realiza, sus atributos y mtodos. Los colaboradores de una clase son las
dems clases con las que trabaja en conjunto para llevar a cabo sus
responsabilidades.
5.7 FUNCIONAMIENTO
Un proyecto XP tiene xito cuando el cliente selecciona los objetivos del sistema a
implementar basado en la habilidad del equipo para medir la funcionalidad que
puede entregar a travs del tiempo.
El ciclo de desarrollo consiste en los siguientes pasos:
1. El cliente define un objetivo a desarrollar del sistema.
2.
El programador estima el esfuerzo necesario para su

implementacin.
3. El cliente selecciona qu construir, de acuerdo con sus prioridades y

las restricciones de tiempo.
4. El programador construye el objetivo.
5. Vuelve al paso 1.
El ciclo de vida ideal de XP consiste de seis fases [Beck, 1999]:
1. Exploracin
2. Planificacin de la Entrega (Release)
50
3. Iteraciones
4. Produccin
5. Mantenimiento
6. Muerte del Proyecto.
Fase I: Exploracin
En esta fase, los clientes plantean a grandes rasgos las historias de usuario que
son de inters para la primera entrega del producto. Al mismo tiempo el equipo de
desarrollo se familiariza con las herramientas, tecnologas y prcticas que se
utilizarn en el proyecto.
Fase II: Planificacin de la Entrega
Cuando se realiza la planificacin de la entrega, el cliente a travs de reuniones
con programadores, establece la prioridad de cada historia de usuario, y
correspondientemente, los programadores y/o analistas realizan una estimacin
del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el
contenido de la primera entrega y se determina un cronograma en conjunto con el
cliente. Una entrega debera obtenerse en no ms de tres meses. El desarrollo de
esta fase se realiza en pocos das generalmente de dos a tres das.
Fase III: Iteraciones
Todo programa construido bajo programacin extrema se construye a travs de
iteraciones, una iteracin es un ciclo de desarrollo de la programacin extrema. En
la primera iteracin se puede intentar establecer una arquitectura del sistema (por
arquitectura del sistema entendemos todo mdulo lgico o fsico del sistema y la
forma de comunicacin entre ellos) que pueda ser utilizada durante el resto del
proyecto. Esto se logra escogiendo las historias que generen la creacin de los
mdulos, sin embargo, esto no siempre es posible ya que es el cliente quien
decide qu historias se implementarn en cada iteracin (para maximizar el valor
de negocio). Al final de la ltima iteracin el sistema estar listo para entrar en
produccin.
Fase IV: Produccin
51
En la fase de produccin el sistema requiere de pruebas adicionales y revisiones

de rendimiento antes de que sea trasladado al entorno del cliente. Al mismo
tiempo, se deben tomar decisiones sobre la inclusin de nuevas caractersticas a
la versin actual, debido a cambios durante esta fase.
Es posible que el tiempo que toma cada iteracin se reduzca, de tres a una
semana.
Fase V: Mantenimiento
Mientras la primera versin se encuentra en produccin, el proyecto XP debe
mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas
iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De
esta forma, la velocidad de desarrollo puede bajar despus de la puesta del
sistema en produccin. La fase de mantenimiento puede requerir nuevo personal
dentro del equipo y cambios en su estructura.
Fase VI: Muerte del Proyecto
Es cuando el cliente no tiene ms historias para ser incluidas en el sistema. Esto
requiere que se satisfagan las necesidades del cliente en otros aspectos como
rendimiento y confiabilidad del sistema.
En la muerte del proyecto generamos la documentacin final del sistema y no se
realizan ms cambios en la arquitectura. La muerte del proyecto tambin ocurre
cuando el sistema no genera los beneficios esperados por el cliente o cuando no
hay presupuesto para mantenerlo (Beck,1999).
5.8 TIPOS DE PROYECTO Y ORGANIZACIONES DONDE SE USA
Por lo general cada metodologa tiene un entorno donde es aplicable, ninguna
metodologa soluciona todo tipo de proyectos, la programacin extrema se
recomienda para proyectos medianos y en el que los requerimientos no se puedan
obtener hasta una vez iniciado el proyecto, aun as, diversos estudios incluidos en
(Nord, 2004) aseguran que la programacin extrema puede ser utilizado en
conjunto con otras metodologas del software.
Si bien no hay un consenso en el nmero mximo de desarrolladores, todos
parecen coincidir en nmeros no mayores a 20. Sus propias prcticas as lo
52
requieren, ya que, por ejemplo, mantener las Stand-up meeting con ms de 20

personas parece poco razonable.
El entorno fsico en el que se realizan los desarrollos deben ser adecuados a la
metodologa. Escritorios amplios, con un ordenador y dos sillas, mesas redondas
para trabajo en equipo, ambientes que permitan la permanente comunicacin y
colaboracin, son algunos de los requerimientos de infraestructura para poder
implementar esta metodologa. La participacin e involucramiento del cliente en el
proceso es fundamental. El cliente debe conocer y aprobar la metodologa, y
destinar los recursos necesarios. De otra manera, el proyecto no podr ser llevado
a cabo. Finalmente, los participantes del equipo de desarrollo deben estar
compenetrados con el proyecto y su metodologa. Deben aceptar compartir sus
cdigos y ser responsables por el cdigo que escribieron otros.
5.9 CERTIFICACIONES
En contraparte con la metodologa Scrum , la programacin extrema no cuenta
con certificaciones reconocidas por el autor y/o similares , la mayora de las
certificaciones citadas son creadas por institutos , escuelas o empresas para
ofrecer al estudiante un marco de trabajo de la programacin extrema , es
necesario aclarar que las certificaciones son para reforzar el currculum vitae del
ingeniero en sistemas, la programacin extrema lleva un camino de 15 aos de
conocimiento basado en la experiencia de un campo dinmico como es la
ingeniera del software , por esta razn se desarrollan workshops(talleres), donde
un grupo de expertos es el encargado de ofrecer experiencias sobre un tema en
especial,
en
este
caso
sobre
la
programacin
extrema,
en
Mxico,
desgraciadamente son muy pocas las organizaciones que ofrecen este tipo de
talleres , adems este tipo de organizaciones estn centralizadas en las grandes
metrpolis del pas, existe actualmente una asociacin llamada Mxico First que
se encarga de proveer acuerdos entre empresas de capacitacin con
profesionistas en los trminos de descuentos, al momento de la investigacin no
exista alguna certificacin enfocada en programacin extrema, el presente listado
son de empresas extranjeras que ofrecen talleres para profesionistas que aspiren
a dominar la programacin extrema.
53
Industrial logic
Industrial Logic es una empresa americana que ofrece talleres a profesionistas TI
(Tecnologas de la Informacin) en metodologas giles, actualmente ofrecen una
capacitacin de 4 das sobre programacin extrema.
CAPTULO VI. KANBAN

6.1 CONCEPTO
Kanban no es una metodologa de desarrollo de software o un enfoque para la
administracin de proyectos. Se requiere de un proceso ya establecido para que
Kanban pueda ser aplicado para cambiar incrementalmente el proceso
subyacente David Anderson, Kanban (Stellman, Greene, 2015, p. 315).
Kanban es un mtodo para mejora de procesos usado por equipos giles. Los
equipos que usan Kanban comienzan por entender la manera en la que
construyen software actualmente, y hacen mejoras a ello con el tiempo. Como
Scrum y XP, Kanban requiere de una mentalidad. Especficamente, requiere de la
mentalidad magra. (dem).
Andrew Stellman y Jennifer Greene tambin nos mencionan en su obra que
cuando los equipos emplean Kanban, se enfocan en eliminar los desperdicios de
sus procesos justo como lo haran en un proceso industrial.
Los autores tambin reconocen que este mtodo comenz a aplicarse como
metodologa de desarrollo de software cuando fue adaptado por David Anderson
en su libro The Kanban Method, en el cual se estipula que el enfoque de Kanban
se orienta a ayudar a un equipo de trabajo a mejorar sus procesos de construccin
de software, a diferencia de SCRUM, cuyo enfoque se centra en la gestin de
proyectos, o XP, en donde se busca tener un desarrollo de software ptimo, con
buenas prcticas de programacin.
54
Kanban no es un mtodo para la gestin de proyectos, pero ciertamente esto no

significa que Kanban no es para los Administradores de Proyectos. De hecho,
David Anderson public una serie de publicaciones de blog que explican
exactamente cmo los administradores de proyectos encajan en Kanban y ofrece
una clase de Gestin de Proyectos con Kanban (Stellman, Greene, 2015, p. 321).
Segn los autores, los roles estn definidos por metodologas existentes como
SCRUM o XP. Kanban sencillamente ayuda en la mejora de los procesos.
Para Stellman y Greene (2015) los principios fundamentales de Kanban son:
1. Comenzar por lo que haces ahora.
2. Acordar en perseguir un cambio incremental y evolutivo.
3. Inicialmente, respetar las reglas actuales, responsabilidad y ttulos de trabajo.
Despus se deben adoptar las siguientes prcticas base:
Visualizar.
Limitar el trabajo en progreso (WIP).
Administrar el flujo.
Hacer explcitamente las polticas de proceso.
Implementar ciclos de retroalimentacin.
Mejorar la colaboracin, evolucionar experimentalmente (usando modelos y
el mtodo cientfico).
6.2 FUNCIONES
Kanban no es una metodologa, o marco de trabajo gil. Si bien Scrum se enfoca
a la gestin de proyectos a travs de varias tcnicas que modifican los
comportamientos organizacionales del equipo, mientras XP se enfoca a las
prcticas y ambientes de programacin, Kanban se enfoca ms que nada a
establecer una mentalidad diferente. Nace como un pensamiento dirigido a la
manufactura para eliminar los derroches dentro de un proceso industrial.
55
Dentro de la industria del software, Kanban a travs de los principios antes

mencionados, se enfoca principalmente a mejorar la forma de construir software a
travs de una toma de consciencia del proceso que se lleva a cabo para realizar
esto.
Cmo iniciar?
Si bien Kanban no dicta una forma de iniciar un proyecto, lo que hace es empezar
por reconocer cmo se est iniciando el proyecto, llevando a poner a lpiz y papel
las actividades que en ese momento se estn realizando, quin las est haciendo,
y cmo se estn realizando.
Esto acelera esta toma de consciencia, ya que as se puede ir visualizando cmo
est trabajando un equipo de desarrollo para crear un producto de software, y a su
vez ser posible ver cmo funciona el marco de trabajo adoptado, as como los
hbitos de colaboracin que de l surgen para entonces poder establecer polticas
o reglas que permitan medir estos comportamientos y guiarlos hacia una mejor
inclusin.
As mismo esto promueve los ciclos de retroalimentacin, al poder ver el flujo de
actividades es notorio poder ejercer una visin ms crtica del proceso, y poder
enfocarse a eliminar los derroches de tiempo, esfuerzo y material, y reconocer un
sistema organizacional enfocado al desarrollo del software.
Lejos de ser un monitor de quin contrata al equipo de desarrollo sirve como
instrumento para que sea el propio equipo quien se conozca y pueda tomar
decisiones que lo lleven a una mejora continua real.
El instrumento ms usado son los tableros de kanban que consisten en una tabla
con columnas que representan las etapas del proceso, en l se colocan tarjetas
que representan las tareas a realizar, conforme cada tarea vaya avanzando, se
debe actualizar en el tablero, de modo que as se visualizar el avance del
proyecto.
56
Kanban puede combinarse por ejemplo con Scrum, una vez que se tenga el
backlog de actividades del Sprint, esas tareas ya ponderadas pueden ser llevadas
al tablero para visualizar el flujo de trabajo del equipo a travs del tiempo.
6.3 CERTIFICACIONES
Una organizacin que ofrece certificaciones es Lean Agile Prosperity Management
Value Inova.
Kanban Methodologist Certificado
Kanban Leader Certificado
Certificaciones Kanban [en lnea], Valueinnova LLC, [Fecha de consulta:

20/04/2016]
CONCLUSIONES
Ideas principales (Felix):
IDEAS PRINCIPALES:
*Alta colaboracin con el cliente
*Alta Respuesta al Cambio
*Conocimiento construido por el equipo
*Enfocado a la sencillez de la construccin de los programas.
57
*La planificacin es adaptable a los imprevistos del proyecto

*Enfocadas a reducir el costo innecesario de los proyectos.
Conclusiones de Carlo:
Las metodologas giles (MA) se basan principalmente en valores
humanos
Las MA ponen al descubierto el flujo de trabajo e informacin de una
organizacin
Las MA no son metodologas que aumentan el ritmo de entrega de
productos
Las MA se basan en ciclos cortos de planificacin, desarrollo,
retrospectivas.
Para su funcionamiento necesitan la participacin del cliente u
organizacin.
Scrum es un marco de trabajo orientado a la gestin del proyecto
Scrum prioriza en entregar valor constante
Scrum hace hincapi en la comunicacin efectiva en el equipo.
Las metodologas Crystal y XP se enfocan a la parte tcnica como lo
es la programacin.
Kanban se adapta de maravilla a las MA porque permite visualizar el
ritmo del proceso de trabajo, as como el grado de integracin en el
equipo.
Las MA muestran que la creacin de tecnologa como lo es el
software requiere de un alto grado de colaboracin y comunicacin
entre los miembros del equipo que desarrollan.
Conclusiones (Iram):
Se basan en los principios agile
Son basadas en la comunicacin constante
Siempre hay retroalimentacin, (Se monitorea el trabajo)
Equipos de trabajo auto organizados
Crean productos funcionales desde el inicio
Son una forma mucho ms organizada, eficiente y controlada de realizar
productos intangibles
se basan en correccin de errores y reajuste continuo del camino a llegar
58
crean productos con mucho ms valor y ms apegados a las necesidades

del cliente
Su popularidad se origina por el dinamismo, la velocidad y eficiencia del
trabajo
Surgen como necesidad de ver progreso a corto tiempo en el trabajo a
realizar
Ideas principales (Enrique):
Observamos que estas metodologas se complementan entre s.
Hacer nfasis en que esto no solo es teora, sino que como ya vimos en el
contenido del documento existen diversas empresas de prestigio que han
usado con xito estas metodologas.
Cada metodologa puede usarse no solo para el desarrollo de software sino
tambin la mejora en procesos.
Conclusiones generales
Las metodologas giles de desarrollo surgieron como necesidad de ver resultados
a corto plazo y reducir costos en cuanto a construccin de software. Su piedra
angular de funcionamiento radica en seguir una serie de valores y principios de
trabajo en equipo que fueron definidos en el manifiesto gil, mismo que fue
seguido por el advenimiento de las metodologas que hemos expuesto en este
trabajo, as como muchas otras.
Una palabra clave del modus operandi en la mayora de metodologas, un comn
denominador, es el hecho de que siempre se trabaja en equipo y existe casi
siempre una comunicacin estrecha con quienes lo conforman. Asimismo, debe
notarse que la conexin con el cliente y mantener bien definidos sus
requerimientos, es la clave para crear productos funcionales y de valor que lo
dejen satisfecho con el producto final, mediante entregas en periodos definidos
que le muestren los avances de desarrollo. Cada metodologa tiene sus
particularidades y su enfoque: SCRUM se orienta al trabajo por objetivos, XP opta
por trabajar manteniendo un enfoque al cdigo fuente al igual que Crystal, Kanban
es reconocido por conocer y mejorar los procesos actuales de construccin, con
esto podemos concluir que estas metodologas nos brindan una manera ms
eficiente y organizada de realizar proyectos de software, que al ser un producto
59
intangible requieren una estructuracin ms organizada del proceso de

construccin del producto adems de una cercana y apego a las necesidades de
los clientes. Al final el nico que decide qu paradigma seguir -- dejarse guiar por
el trabajo colaborativo y comunicativo o seguir una serie de reglas inflexibles -- es
el mismo equipo de trabajo que toma decisiones con base en los resultados y
rendimiento que les brinda todo el universo de metodologas de desarrollo. Es
decir, estas metodologas son una gua y marco de trabajo que son escalables y
adaptables a la infinidad de tipos de proyectos que existen en la industria de las
tecnologas de la informacin. De ah su importancia como instrumento de trabajo
y que toda persona relacionada con el rea de las tecnologas de la informacin
(en especial la administracin de proyectos) debe tener presente como
herramienta eficiente para crear productos informticos de valor y con un alto
grado de calidad.
GLOSARIO
Backlog: Lista priorizada de caractersticas donde se plasman las actividades
ms importantes.
60
Coaching: Mtodo que consiste en acompaar, instruir y entrenar a una persona

o a un grupo de ellas, con el objetivo de conseguir cumplir metas o desarrollar
habilidades especficas.
Cliente: Elemento principal en un proyecto de programacin extrema, es aquel
que inicia las historias de usuarios y por ende el proyecto.
CMMI: Capability Maturity Model Integration o Integracin de modelos de madurez
de capacidades. Es un modelo para la mejora y evaluacin de procesos para el
desarrollo, mantenimiento y operacin de sistemas de software.
Criticalidad: La calidad, estado o grado de ser de alta importancia.
Casos de uso: Los casos de uso se crean para refinar un conjunto de requisitos
de acuerdo con una funcin o tarea. Los casos de uso definen qu harn los
usuarios o funciones en la solucin y un proceso empresarial define cmo
realizarn esas funciones.
Diagrama de Gantt: Es una popular herramienta grfica cuyo objetivo es mostrar
el tiempo de dedicacin previsto para diferentes tareas o actividades a lo largo de
un tiempo total determinado.
Existencialismo: Corriente filosfica europea que considera que la cuestin
fundamental en el ser es la existencia, en cuanto existencia humana, y no la
esencia, y que respecto al conocimiento es ms importante la vivencia subjetiva
que la objetividad.
Estndares de Codificacin: En Programacin Extrema es un conjunto de reglas
para la programacin y documentacin del sistema.
Encargado de Seguimiento: En programacin extrema, es el encargado de dar
retroalimentacin al equipo, verifica el grado de acierto de las iteraciones.
Framework: un conjunto estandarizado de conceptos, prcticas y criterios para
enfocar un tipo de problemtica particular que sirve como referencia, para
enfrentar y resolver nuevos problemas de ndole similar.
Failover: La conmutacin por error, o failover, es un modo de funcionamiento de
respaldo en el que las funciones de un componente de sistema son asumidas por
componentes del sistema secundario cuando el componente principal no est
disponible ya sea debido a una falla o por el tiempo de inactividad programado.
Grooming: actividad en la cual se definen, estiman y priorizan los tems del
backlog.
61
Historia de Usuario: Artefacto de identificacin de requerimientos utilizado en la

fase inicial de programacin extrema.
Iteracin: Ciclo de produccin de software ms pequeo en un proyecto de
programacin extrema.
Iterativo: Trmino que indica una accin repetitiva.
Lean Manufacturing: Es un modelo de gestin enfocado a la creacin de flujo
para poder entregar el mximo valor para los clientes, utilizando para ello los
mnimos recursos necesarios: es decir ajustados.
Metfora: En Programacin Extrema, es el concepto global del sistema a
implementar.
Mainframe: Computadora grande, poderosa y costosa utilizada principalmente en
empresas que necesitan procesar gran cantidad de datos o soportar gran cantidad
de usuarios.
Planning Poker: Es una tcnica para calcular una estimacin basada en el
consenso, en su mayora utilizada para estimar el esfuerzo o el tamao relativo de
las tareas de desarrollo de software.
PMI: El Project Management Institute (PMI) es una organizacin internacional sin
fines de lucro que asocia a profesionales relacionados con la Gestin de
Proyectos.
Plan de Entrega: Cronograma acordado entre clientes y equipo de desarrollo, en
el que se fija una fecha para la liberacin del sistema.
Plan de Iteraciones: Cronograma de actividades para que el equipo de desarrollo
libere una caracterstica del sistema.
Scrum Alliance: Organizacin que desarrolla y difunde marcos de Scrum para
trasladar al sector TIC la forma de trabajo gil, iterativo e incremental
Teora General de los Sistemas: Es el estudio interdisciplinario de los sistemas,
en general, con el propsito de dilucidar los principios que pueden ser aplicados a
todo tipo de sistemas en todos los niveles anidados en todos los campos de la
investigacin.
The Principles of Scientific Management: Es una monografa publicada por
Frederick Winslow Taylor en 1911, la cual orden los principios de la
administracin cientfica, es un texto trascendental de la organizacin moderna y
teora de la decisin que ha motivado a estudiantes y administradores acerca de la
tcnica administrativa.
62
Stakeholders: Personas involucradas en un proyecto o en una empresa.

Tester:
Persona
encargada
de
realizar
pruebas,
revisar
estndares
normatividades en el software.
WIP: Del ingls Work In Progress, es un material que se ha ingresado al proceso
de produccin, pero an no es un producto terminado.
FUENTES DE CONSULTA
Stellman, A. & Greene, J. (2015). Learning Agile. United States of America,

California: O'Reilly Media, Inc.
63
Cockburn, A. (2004). Crystal Clear: A human powered Methodology for small

teams including The Seven Properties of Effective Software Projects. Humans and
Technology.
Satpathy, T. (2016). Una gua para el CONOCIMIENTO DE SCRUM GUA SBOK.
Editorial Scrum Study.
Davies, R. & Sedley, L. (2013). Agile Coaching. EUA: Pragmatic Bookshelf.
Smith & Sidky. (2013). Becoming Agile in an imperfect world, EUA: Editorial
Manning.
Stellman & Greene. (2015). Learning Agile: Understanding SCRUM, XP, LEAN,
and KANBAN. EUA: Editorial OReilly.
Fusi, J. (2013). Breve Historia del mundo contemporneo. Espaa: Editorial
Galaxia Gutenberg.
Rubin, K. (2013). Essential Scrum: A practical guide to the most popular agile
process. EUA: Editorial Pearson.
Sutherland, J. (2012). The Scrum Handbook. EUA: Editorial Scrum Inc.
Schwaber & Sutherland. (2013). La gua de Scrum. Traduccin al espaol. EUA:
Editorial Scrum Inc.
Kniberg, H. (2007). Scrum y XP desde las trincheras: Como hacemos Scrum.
Traduccin al espaol. EUA.
Palacio, J. (2014). Gestin de Proyectos Scrum Manager. Argentina: Editorial
Creative Commons.
Loayza Salazar, D. (2010). Mtodo para eleccin de una metodologa gil hbrida
en una MYPE desarrolladora de software, caso prctico: eleccin de SCRUM y XP
en la empresa AQSOFT. Licenciatura. Universidad Nacional Mayo de San Marcos.
64
Bhler, E (2014). 7 lugares donde obtener tu certificacin Agile/Scrum.

Recuperado
de:
https://agilib.org/2014/02/05/7-lugares-donde-obtener-tu-
certificacion-agilescrum/
Beck, K. (2000). Extreme programming eXplained. Reading, MA: Editorial AddisonWesley.
Cockbun, A. & Williams, L. (2000). The Costs and Benefits of Pair Programming.
Humans and Technology Technical Report.
Fowler,
M.
(2001).
Is
Design
Dead?
Recuperado
de:
www.martinfowler.com/articles/designDead.html
Jacobson, I. (1994). Object-Oriented Software Engineering. Editorial AddisonWesley.

Newkirk, J. & Martin R. (2001). Extreme Programming in Practice. Editorial
Addison-Wesley.
Cobb, C. (2016). What kind of projects are the best to use extreme programming?
Recuperado de: https://www.quora.com/What-kind-of-projects-are-the-best-to-useextreme-programming/answer/Chuck-Cobb3?__snids__=1623331793&__nsrc__=1&__filter__=all.
Fernndez, J. (2016). Introduccin a las metodologas giles Otras formas de
analizar
y
desarrollar.
Recuperado
de:
https://www.exabyteinformatica.com/uoc/Informatica/Tecnicas_avanzadas_de_ing
enieria_de_software/Tecnicas_avanzadas_de_ingenieria_de_software_(Modulo_3
).pdf
Rumpe, B. & Schrder, A. (2002). Quantitative Survey on Extreme Programming
Projects. Munich University of Technology: Software & Systems Engineering,
Search Data Center, 2016, "Encuesta de VersionOne muestra cmo est el
desarrollo
gil
en
2015",
recuperado
de
http://searchdatacenter.techtarget.com/es/foto-articulo/4500252735/Encuesta-de65
VersionOne-muestra-como-esta-el-desarrollo-agil-en-2015/5/Que-tal-popular-esel-proceso-Scrum
Centro de Innovacin BBVA, 2016, "Tendencias tecnolgicas en 2016",
recuperado
de
http://www.centrodeinnovacionbbva.com/noticias/tendencias-
tecnologicas-en-2016#sthash.sqj4gCgl.dpuf
Search Data Center, 2016, "Habilidades del desarrollador de software para el
futuro
programador
de
ensueo",
recuperado
de
http://searchdatacenter.techtarget.com/es/cronica/Habilidades-del-desarrolladorde-software-para-el-futuro-programador-de-ensueno
Gur
Software,
2015,
"Estudio
de
Salarios
del
2015",
recuperado
de
http://sg.com.mx/revista/50/estudio-salarios-sg-2015#.VzscEN9ysf4
TABLERO DEL EQUIPO
CARLO
-Captulo 2
IRAM
KIKE
FERNANDO
FELIX
-Realizacin
-Capturo V
66
Marco Terico
-Capitulo 6
Kanban
(complemento)
-Realice el
acomodo del
documento
-Complete el
ndice
-Complemente
el Captulo 1
Marco
Metodolgico
-Glosario
de la portada y Programacin
los objetivos
Extrema,
particulares
modificada
-Captulo IV
Metodologas
Crystal
-Captulo VI
Kanban
-Glosario de
XP
-referencias
XP
-Realic
descripcin de
Captulos IV y
VI en el ndice
descriptivo
-Actualizacin
de referencias
bibliogrficas
de Cap. IV y
VI
-Glosario
67

Metodologías Ágiles

Cargado por

Copyright:

Formatos disponibles

Metodologías Ágiles

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

Metodologías Ágiles

Cargado por

Copyright:

Formatos disponibles

INSTITUTO POLITCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERA Y

5.2 REGLAS ......................................................................................................... 43

Kanban es un mtodo para la mejora de procesos industriales. No fue sino hasta

en las personas, no en el desarrollo o en el proyecto en s mismo; pero todo esto

El trmino metodologa segn la Real Academia Espaola es un es un vocablo

CAPTULO I MARCO METODOLGICO

Tecnologas de la Informacin, es conveniente comprender el surgimiento y

1.3 TCNICAS E INSTRUMENTOS DE MEDICIN

El alcance de nuestra investigacin se limita a fines exploratorios. Pretende ser

CAPTULO II MARCO TERICO

propuso el primer mtodo incremental IIDD

Iterative and Incremental Design and Development.

En 1995 nace el marco de trabajo Scrum como modelo para desarrollo de

nombre de metodologas giles y se cre el

1950 creacin de la CECA, rumbo a la Unin Europea. En Europa creca la

existencialista en obras de Sartre, Camus,

negativa de la condicin humana que sealaba que el hombre

filosfica. Literatura como Camino de Servidumbre de Hayek, La

y el desamparo del hombre.

1964 juegos olmpicos en Japn, marcaba el inicio de la potencia mundial,

ordenadores, computadores personales, instrumentos

satlites. Para el inicio de la siguiente dcada Europa

sociedad construida bajo los estndares de EU, pero con altos

niveles de desarrollo, bienestar social, desarrollo y empleo.

la tecnologa digital, as como sus universidades eran

prestigiosas como centros de investigacin.

1990 Reunificacin de Alemania, cada del Muro de Berln.

2001 cada de las torres gemelas.

aproximadamente 30 aos, impactando en el nuevo terreno frtil en el que

temprana al equipo de desarrollo para indicarle si est entregando valor, o si debe

9.- La agilidad es promovida por la excelencia tcnica y buenos diseos. La

Es posible detallar cada parte del proceso desde la primera planificacin.

(Figura 1.4 disponible en Becoming Agile, pg. 12)

La agilidad se enfoca en satisfacer las necesidades del cliente y su

CAPTULO III. METODOLOGA SCRUM

basan en valores, principios y prcticas giles que garanticen una mejor

(Figura 1.6 Scrum Team disponible en Essential Scrum, pg. 15)

Las entregas incrementales de producto Terminado aseguran que siempre

Para proyectos grandes donde se requiere de un gran nmero de personas, en

Scrum en la organizacin. Adems, ayuda al equipo mismo a ejecutar tcnicas

(Figura 1.7 Product Backlog disponible en Essential Scrum, pg. 19)

(Figura 1.9 Sprint Backlog disponible en Essential Scrum, pg. 22)

3.5 EVENTOS O ACTIVIDADES

(Figura 2.1 Grooming disponible en Essential Scrum, pg. 19)

La Reunin de Planificacin de Sprint responde a las siguientes preguntas:

El Daily Scrum es una reunin diaria de 15 minutos de duracin

Estas tareas no tienen un orden especfico, y el development team puede

el tiempo en que se tardar en hacer cada tarea y proponiendo estrategias para su

(Figura 2.2 Scrum Process disponible en Essential Scrum, pg. 17)

cambiantes o poco definidos, donde la innovacin, la competitividad, la flexibilidad

Ejemplos de empresas que utilizan Scrum

Sony/Ericsson, Telefnica I+D, TeleAtlas, Verizon

Adobe, Autentia, Biko2, Central Desktop, Citrix,

Proyectalis, Softhouse, Valtech, VersionOne.

Amazon, Google, mySpace, Yahoo

Bank of America, Barclays Global Investors, Key

Patientkeeper, Philips Medical

Boeing, General Dynamics, Lockheed Martin