Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Curso de Desarrollo Ágil PDF
Curso de Desarrollo Ágil PDF
GIL
El presente documento est bajo la licencia Creative Commons Reconocimiento-No comercial-Compartir Igual versin
2.5 Espaa.
Usted es libre de:
- copiar, distribuir y comunicar pblicamente la obra
- hacer obras derivadas
Al reutilizar o distribuir la obra, tiene que dejar bien claro los trminos de la licencia de esta obra.
Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor
Nada en esta licencia menoscaba o restringe los derechos morales del autor.
Esto es un resumen legible por humanos del texto legal (la licencia completa) disponible en
http://creativecommons.org/licenses/by-nc-sa/2.5/es/
El presente documento cumple con las condiciones de accesibilidad del formato PDF (Portable Document Format).
Se trata de un documento estructurado y etiquetado, provisto de alternativas a todo elemento no textual, marcado de
idioma y orden de lectura adecuado.
Para ampliar informacin sobre la construccin de documentos PDF accesibles puede consultar la gua disponible en la
seccin Accesibilidad > Formacin > Manuales y Guas de la pgina http://www.inteco.es.
Las distintas normas ISO mencionadas han sido desarrolladas por la International
Organization for Standardization
Todas las dems marcas registradas que se mencionan, usan o citan en el presente curso
son propiedad de los respectivos titulares.
INTECO cita estas marcas porque se consideran referentes en los temas que se tratan,
buscando nicamente fines puramente divulgativos. En ningn momento INTECO busca con
su mencin el uso interesado de estas marcas ni manifestar cualquier participacin y/o
autora de las mismas.
Nada de lo contenido en este documento debe ser entendido como concesin, por
implicacin o de otra forma, y cualquier licencia o derecho para las Marcas Registradas
deben tener una autorizacin escrita de los terceros propietarios de la marca.
El carcter de todos los cursos editados por INTECO es nicamente formativo, buscando en
todo momento facilitar a los lectores la comprensin, adaptacin y divulgacin de las
disciplinas, metodologas, estndares y normas presentes en el mbito de la calidad del
software.
1. ESCENARIO DE APERTURA 7
2. INTRODUCCIN 8
4. DESARROLLO GIL 20
4.1. El Manifiesto gil 21
4.1.1. Manifiesto para el desarrollo de software gil 22
4.1.2. Principios detrs del manifiesto gil 24
4.2. Caractersticas 25
4.3. Comparacin con otros mtodos 27
4.3.1. Comparacin con otros mtodos de desarrollo iterativos 27
4.3.2. Comparacin con el modelo en cascada 28
4.3.3. Comparacin con codificacin cowboy 28
4.4. Idoneidad de los mtodos giles 29
4.5. Empezar a usar un mtodo gil 30
4.6. Escenario 31
5. MTODOS GILES 33
5.1. Gestin de proyectos 33
5.2. Extreme Programming (XP) 34
5.2.1. Elementos de la metodologa 34
6. PRCTICAS GILES 53
6.1. Test Driven Development (TDD) 53
6.1.1. Ciclo de desarrollo orientado a pruebas 54
6.1.2. Ventajas 55
6.1.3. Inconvenientes 55
6.2. Integracin continua 56
6.2.1. Prcticas recomendadas 56
6.2.2. Ventajas 57
6.2.3. Inconvenientes 58
6.3. Pair programming 58
6.3.1. Ventajas 59
6.3.2. Inconvenientes 60
9. ESCENARIO DE CLAUSURA 66
10. ENLACES 67
COMPASS S.A. es una empresa de desarrollo de software que en los ltimos aos ha ido
adquiriendo un nmero de pequeas empresas.
En parte de las empresas que ahora forman parte de COMPASS se estaba usando un
modelo en cascada como modelo de desarrollo, pero se ha observado que con este modelo
haba muchas cosas que fallaban.
El software juega un papel significativo en la vida de las personas. Se puede usar tanto en
una aplicacin en un ordenador personal como parte embebida de un robot industrial.
Desde que se empez con el desarrollo de software han ido surgiendo numerosos mtodos,
paradigmas y modelos de proceso para manejar los esfuerzos complejos del desarrollo.
Algunos de los mtodos de desarrollo se han convertido en mtodos orientados a
documentacin o con la expectativa de que los desarrolladores sigan ciertos procesos. A
estos mtodos se les suele conocer como mtodos tradicionales o pesados.
Este nuevo movimiento creci de los esfuerzos de varias personas que trataban con
procesos software en los 90. La mayora de las ideas no eran nuevas, es ms, mucha gente
crea que se haba construido software exitoso de esta forma desde haca tiempo. Haba, sin
embargo, una vista de que esas ideas se haban contenido y no se haban tratado de forma
suficientemente seria, particularmente por la gente interesada en procesos de software.
Para apoyar al desarrollo de proyectos por medio de este modelo se han creado distintos
frameworks o entornos de trabajo, como puede ser el Rational Unified Process. El desarrollo
incremental e iterativo es tambin una parte esencial de un tipo de programacin conocido
como Extreme Programming y los dems frameworks de desarrollo rpido de software, que
se irn viendo a lo largo del curso.
Los dos trminos se pusieron en prctica a mediados de los 90s. Los autores del Proceso
Unificado (UP) y el proceso unificado Rational (RUP) seleccionaron el trmino desarrollo
iterativo e iteraciones para hacer referencia de forma general a cualquier combinacin de
desarrollo incremental e iterativo. La mayora de las personas que dicen desarrollo iterativo
quieren decir que hacen ambos desarrollo incremental e iterativo.
La idea bsica
VERSIN
El sistema
Iteracin de 3 PARA LOS
crece de forma
semanas CLIENTES
incremental
El inicio identifica el alcance del proyecto, los riesgos y los requisitos (funcionales y
no funcionales) a un alto nivel en suficiente detalle para que se pueda estimar el
trabajo.
La elaboracin entrega una arquitectura de trabajo que mitiga los riesgos altos y
cumple los requisitos no funcionales.
Cada una de las fases puede dividirse en una o ms iteraciones, que se agrupan en funcin
de tiempo ms que de caracterstica. Los arquitectos y analistas trabajan una iteracin por
delante de los desarrolladores y tcnicos de pruebas.
Entre las debilidades que se han encontrado en este tipo de modelos aparecen las que se
mencionan a continuacin:
El mtodo RAD tiene una lista de tareas y una estructura de desglose de trabajo diseada
para la rapidez. El mtodo comprende el desarrollo iterativo, la construccin de prototipos y
el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el
desarrollo rpido de aplicaciones tiende a englobar tambin la usabilidad, utilidad y rapidez
de ejecucin.
DISEO DE
USUARIO
CONSTRUCCIN
RPIDA
TRANSICIN
El desarrollo rpido de aplicaciones fue una respuesta a los procesos no giles de desarrollo
desarrollados en los 70 y 80, tales como el mtodo de anlisis y diseo de sistemas
estructurados y otros modelos en cascada. Un problema con las metodologas previas era
que llevaba mucho tiempo la construccin de las aplicaciones y esto poda llevar a la
situacin de que los requisitos podan haber cambiado antes de que se completara el
sistema, resultando en un sistema inadecuado o incluso no usable. Otro problema era la
suposicin de que una fase de anlisis de requisitos metdica sola identificara todos los
requisitos crticos. Un evidencia amplia avala el hecho de que esto se da rara vez, incluso
para proyectos con profesionales de alta experiencia a todos los niveles.
Empezando con las ideas de Brian Gallagher, Alex Balchin, Barry Boehm y Scott Shultz,
James Martin desarroll el enfoque de desarrollo rpido de aplicaciones durante los 80 en
IBM y lo formaliz finalmente en 1991, con la publicacin del libro, Desarrollo rpido de
aplicaciones.
RAD requiere el uso interactivo de tcnicas estructuradas y prototipos para definir los
requisitos de usuario y disear el sistema final. Usando tcnicas estructuradas, el
desarrollador primero construye modelos de datos y modelos de procesos de negocio
preliminares de los requisitos. Los prototipos ayudan entonces al analista y los usuarios a
verificar tales requisitos y a refinar formalmente los modelos de datos y procesos. El ciclo de
modelos resulta a la larga en una combinacin de requisitos de negocio y una declaracin
de diseo tcnico para ser usado en la construccin de nuevos sistemas.
Ventajas
Las principales ventajas que puede aportar este tipo de desarrollo son las siguientes:
Velocidad de desarrollo
Calidad: segn lo definido por el RAD, es el grado al cual un uso entregado resuelve
las necesidades de usuarios as como el grado al cual un sistema entregado tiene
costes de mantenimiento bajos. El RAD aumenta la calidad con la implicacin del
usuario en las etapas del anlisis y del diseo.
Las ventajas que puede aadir sobre el seguimiento de un mtodo en cascada, por ejemplo,
es que en el mtodo en cascada hay un largo periodo de tiempo hasta que el cliente puede
ver cualquier resultado. El desarrollo puede llevar tanto tiempo que el negocio del cliente
haya cambiado sustancialmente en el momento en el que el software est listo para usar.
Con este tipo de mtodos no hay visibilidad del producto hasta que el proceso no est
finalizado al 100%, que es cuando se entrega el software.
Caractersticas reducidas.
Escalabilidad reducida.
Una de las crticas principales que suele generar este tipo de desarrollo es que, ya que el
desarrollo rpido de aplicaciones es un proceso iterativo e incremental, puede conducir a
una sucesin de prototipos que nunca culmine en una aplicacin de produccin satisfactoria.
Tales fallos pueden ser evitados si las herramientas de desarrollo de la aplicacin son
robustas, flexibles y colocadas para el uso correcto.
RUP fue originalmente desarrollado por Rational Software, y ahora disponible desde IBM. El
producto incluye una base de conocimiento con artefactos de ejemplo y descripciones
detalladas para muchos tipos diferentes de actividades.
El fallo de los proyectos es causado por una combinacin de varios sntomas, aunque cada
proyecto falla de una forma nica. La salida de su estudio fue un sistema de mejores
prcticas del software al que llamaron RUP.
El proceso fue diseado con las mismas tcnicas con las que el quipo sola disear
software; tena un modelo orientado a objetos subyacente, usando UML (Unified Modeling
Language)
Tareas (cmo): una tarea describe una unidad de trabajo asignada a un rol que
proporciona un resultado significante.
Las cuatro fases en las que divide el ciclo de vida del proyecto son:
Modelaje de negocio
Requisitos
Anlisis y diseo
Implementacin
Pruebas
Despliegue
Gestin de proyectos
Entorno
Certificacin
Existe un examen de certificacin IBM Certified Solution Designer Rational Unified Process
7.0. Este examen prueba tanto contenido relacionado con el contenido de RUP como
relacionado con los elementos de estructura del proceso.
Es una certificacin a nivel personal. El examen tiene una duracin de 75 minutos y son 52
preguntas. Hay que conseguir un 62% para aprobar.
Un enfoque de negocio que alinea el desarrollo con las necesidades de los clientes y
los objetivos de la compaa
Hasta hace poco el proceso de desarrollo llevaba asociado un marcado nfasis en el control
del proceso mediante una rigurosa definicin de roles, actividades y artefactos, incluyendo
modelado y documentacin detallada. Este esquema tradicional para abordar el desarrollo
del software ha demostrado ser efectivo y necesario en proyectos de gran tamao (respecto
a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el
proceso. Sin embargo, este enfoque no resulta ser el ms adecuado para muchos de los
proyectos actuales donde el entorno del sistema es muy cambiante y en donde se exige
reducir drsticamente los tiempos de desarrollo manteniendo una alta calidad. Ante las
dificultades para utilizar metodologas tradicionales con estas restricciones de tiempo y
flexibilidad, muchos equipos de desarrollo se resignan a prescindir del buen hacer de la
ingeniera del software, asumiendo el riesgo que ello conlleva. En este escenario, las
metodologas giles emergen como una posible respuesta para llenar ese vaco
metodolgico. Por estar especialmente orientadas para proyectos pequeos, las
metodologas giles constituyen una solucin a medida para ese entorno, aportando una
elevada simplificacin que a pesar de ello no renuncia a las prcticas esenciales para
asegurar la calidad del producto.
Las metodologas giles son sin duda uno de los temas recientes en la ingeniera de
software que estn acaparando gran inters. Prueba de ello es que se estn haciendo un
espacio destacado en la mayora de conferencias y talleres celebrados en los ltimos aos.
En la comunidad de la ingeniera del software, se est viviendo con intensidad un debate
abierto entre los partidarios de las metodologas tradicionales y aquellos que apoyan las
ideas surgidas del Manifiesto gil.
Entre los mtodos giles tempranos destacan Scrum, Crystal Clear, Extreme Programming,
Adaptative Software Development, Feature Driven Development and Dynamic Systems
El Manifiesto gil
Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos
desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo
del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que se genera
en cada una de las actividades desarrolladas.
Tras esta reunin se cre La Alianza gil, una organizacin sin nimo de lucro, dedicada a
promover los conceptos relacionados con el desarrollo gil de software y ayudar a las
organizaciones para que adopten dichos conceptos. El punto de partida fue el Manifiesto
gil, documento que resume la filosofa gil.
El Manifiesto para el desarrollo de software gil trata de poner en duda la situacin del
momento respecto al desarrollo de software, ya que fue creado para contrarrestar los
mtodos pesados orientados a procesos y a documentacin e intenta sugerir nuevos
enfoques de desarrollo de software.
Este valor tambin quiere abandonar el uso de procesos estrictos. Sin embargo, los
procesos pueden ser beneficiales hasta cierto punto, por lo que se debera evitar un
abandono total de los mismos.
De acuerdo con la Alianza gil, los documentos que contienen requisitos, anlisis o
diseo pueden ser muy tiles para guiar el trabajo de los desarrolladores y ayudan a
predecir el futuro. Pero cdigo que funciona, que ha sido probado y depurado revela
informacin sobre el equipo de desarrollo, el proceso de desarrollo y la naturaleza de
los problemas a solucionar. La Alianza gil afirma que la ejecucin de un programa
es la nica medida fiable de la velocidad y las deficiencias del equipo y vislumbra lo
que el equipo debera construir en realidad. En ocasiones los mtodos giles
aparecen menos orientados a planes que lo que de verdad son. Los documentos y
planes se usan en mtodos giles hasta cierto punto.
Este valor enfatiza las relaciones cercanas entre el equipo de desarrollo de software
y el cliente. El supuesto bsico detrs de este valor es la satisfaccin del cliente en
general, que es el driver principal en el desarrollo de software gil.
La colaboracin y dedicacin del cliente son crticas para todos los proyectos de
desarrollo de software.
En cada una de las cuatro afirmaciones lo que quieren resaltar es que aunque los elementos
de la parte de la derecha de la comparacin tienen valor, ellos valoran ms los elementos de
la izquierda.
Los cambios en los requisitos son bienvenidos, incluso tarde, en el desarrollo. Los
procesos giles aprovechan los cambios como ventaja competitiva del cliente.
Entregar software que funcione con frecuencia, desde un par de semanas hasta un
par de meses, con preferencia de escalas de tiempo cortas (con el menor intervalo
de tiempo posible).
Caractersticas
El desarrollo gil elige hacer las cosas en incrementos pequeos con una planificacin
mnima, ms que planificaciones a largo plazo. Las iteraciones son estructuras de tiempo
pequeas (conocidas como timeboxes) que tpicamente duran de 1 a 4 semanas. De cada
iteracin se ocupa un equipo realizando un ciclo de desarrollo completo, incluyendo
planificacin, anlisis de requisitos, diseo, codificacin, pruebas unitarias y pruebas de
aceptacin. Esto ayuda a minimizar el riesgo general, y permite al proyecto adaptarse a los
cambios rpidamente. La documentacin se produce a medida que es requerida por los
agentes involucrados. Una iteracin puede no aadir suficiente funcionalidad para garantizar
una liberacin del producto al mercado, pero el objetivo es tener una versin disponible (con
errores mnimos) al final de cada iteracin. Se requerirn mltiples iteraciones para liberar
un producto o nuevas caractersticas.
MTODOS ITERATIVOS
Y EVOLUTIVOS
MTODOS
GILES
Los mtodos giles enfatizan la comunicacin cara a cara sobre los documentos escritos.
La mayora de los equipos giles se encuentran localizados en una nica ubicacin abierta
para facilitar esta comunicacin. El tamao del equipo es normalmente pequeo (5-9
personas) para ayudar a hacer la comunicacin y la colaboracin ms fcil. Los esfuerzos
de desarrollos largos deben ser repartidos entre mltiples equipos trabajando hacia un
objetivo comn o partes diferentes de un esfuerzo. Esto puede requerir tambin una
coordinacin de prioridades a travs de los equipos.
La mayora de las metodologas giles incluyen una comunicacin cara a cara rutinaria,
diaria y formal entre los miembros del equipo. Esto incluye especficamente al representante
del cliente y a cualquier persona involucrada en el negocio como observadores. En una
breve sesin, los miembros del equipo informan al resto de lo que hicieron el da anterior, lo
que van a hacer hoy y cules son sus principales obstculos. Esta comunicacin cara a cara
permanente previene problemas que se puedan esconder.
Los mtodos giles enfatizan software operativo como la medida principal del progreso.
Combinado con la preferencia de comunicacin cara a cara, los mtodos giles
normalmente producen menos documentacin escrita que otros mtodos.
Los mtodos adaptativos se centran en la adaptacin rpida a los cambios. Cuando las
necesidades de un proyecto cambian, un equipo adaptativo cambia tambin. Un equipo
adaptativo tendr dificultades para describir lo que pasar en el futuro. Cuanto ms lejana
sea una fecha, ms vago ser un mtodo adaptativo en cuanto a saber qu pasar en esa
fecha. Un equipo adaptativo puede informar exactamente de las tareas que se realizarn la
semana que viene, pero slo las caractersticas planificadas para el prximo mes. Cuando
se pregunta por una versin de dentro de seis meses, un equipo adaptativo slo podr ser
capaz de reportar la declaracin de la misin de las versiones o una declaracin de la
relacin valor coste esperada.
Los mtodos giles tienen mucho en comn con las tcnicas de RAD (desarrollo rpido de
aplicaciones).
En este aspecto, las crticas giles afirman que estas caractersticas no tienen lugar en el
contexto del proyecto global, concluyendo que, si el sponsor del proyecto est preocupado
por contemplar ciertos objetivos con un periodo de tiempo o un presupuesto definido, las
metodologas giles no son apropiadas. Los partidarios del desarrollo gil responden que las
adaptaciones de Scrum (mtodo de desarrollo gil que se explicar en apartados sucesivos)
muestran cmo los mtodos giles estn incrementando la produccin y mejora continua de
un plan estratgico.
Algunos equipos giles usan el modelo en cascada a pequea escala, repitiendo el ciclo de
cascada entero en cada iteracin. Otros equipos, los ms notables los equipos de XP,
trabajan en actividades simultneamente.
Como con todos los mtodos de desarrollo, las habilidades y la experiencia de los usuarios
determinan el grado de xito.
No hay mucho consenso en qu tipo de proyectos de software son los ms adecuados para
las metodologas giles. Muchas organizaciones grandes tienen dificultades en salvar el
espacio entre un mtodo ms tradicional como el de cascada y uno gil.
El desarrollo gil ha sido ampliamente documentado como que funciona bien para equipos
pequeos localizados en un mismo sitio (<10 desarrolladores).
Algunas cosas que pueden afectar negativamente al xito de un proyecto gil son:
Barry Boehm y Richard Turner sugieren que se pueden usar un anlisis de riesgos para
elegir entre mtodos adaptativos (giles) y predictivos (orientados a planes).
Baja criticidad
Desarrolladores seniors
Alta criticidad
Desarrolladores juniors
El uso de un mtodo gil no es para todo el mundo. Hay un nmero de aspectos que hay
que tener en mente si se decide seguir este camino. Por otro lado, estas metodologas se
consideran ampliamente aplicables.
Para alguien nuevo en mtodos giles, la pregunta es por dnde empezar. Como con
cualquier nueva tecnologa o proceso, es necesario hacer nuestra propia evaluacin de ello.
Esto permite ver cmo encaja en un entorno.
El primer paso es encontrar proyectos adecuados para probar los mtodos giles. Debido a
que los mtodos giles estn fundamentalmente orientados a las personas, es esencial que
se empiece con un equipo que quiera probar y trabajar de forma gil.
Es valioso tambin tener clientes (aquellos que necesitan el software) que quieran trabajar
de forma colaborativa. Si los clientes no colaboran, no se vern las ventajas completas de
un proceso adaptativo.
Mucha gente afirma que los mtodos giles no se pueden usar en proyectos grandes. Se ha
tenido xito con proyectos giles con unas 100 personas y mltiples continentes. A pesar de
ello, se podra empezar con algo ms pequeo. Los proyectos ms grandes son
indudablemente ms complicados, as que es mejor aprender con proyectos de tamao ms
manejable.
Quizs una de las cosas ms importantes que se pueden hacer es encontrar a alguien con
experiencia en mtodos giles para ayudar. Y una vez que se haya encontrado un buen
mentor, seguir su consejo.
Escenario
Potencialmente, casi todos los mtodos giles son adecuados para la adaptacin. La
conveniencia de situacin puede considerarse como una caracterstica de distincin entre
los mtodos giles y los mtodos tradicionales, que son mucho ms rgidos y preceptivos.
La implicacin prctica es que los mtodos giles permiten a los equipos de proyecto
adaptar las prcticas de trabajo de acuerdo con las necesidades del proyecto individual. Las
prcticas son actividades y productos concretos que son parte del marco de trabajo del
mtodo. En un nivel ms extremo, la filosofa detrs del mtodo, que consiste en un nmero
de principios, podra ser adaptada.
Gestin de proyectos
Los mtodos giles suelen cubrir la gestin de proyectos. Algunos mtodos se suplementan
con guas en gestin de proyectos. PRINCE2 se ha propuesto como un sistema de gestin
de proyectos complementario y adecuado.
XP es una metodologa gil centrada en potenciar las relaciones interpersonales como clave
para el xito en el desarrollo de software, promoviendo el trabajo en equipo, preocupndose
por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se
basa en la realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin
fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje
para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con
requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. A Kent Beck
se le considera el padre de XP.
Los principios y prcticas son de sentido comn pero llevadas al extremo, de ah proviene su
nombre.
Elementos de la metodologa
Las historias de usuario: son la tcnica utilizada para especificar los requisitos del
software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente
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 cules se implementan en cada iteracin centrndose en apoyar
mayor valor al negocio.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se
debe presionar al programador a realizar ms trabajo que el estimado, ya que se perder
calidad en el software o no se cumplirn los plazos. De la misma forma el cliente tiene la
obligacin de manejar el mbito de entrega del producto, para asegurarse de que el sistema
tenga el mayor valor de negocio posible.
Prcticas
La principal suposicin que se realiza en XP es la posibilidad de disminuir la mtica curva
exponencial del coste del cambio a lo largo del proyecto, lo suficiente para que el diseo
evolutivo funcione. Esto se consigue gracias a las tecnologas disponibles para ayudar en el
desarrollo de software y a la aplicacin disciplinada de las siguientes prcticas:
Diseo simple. Se debe disear la solucin ms simple que pueda funcionar y ser
implementada en un momento determinado del proyecto.
Pruebas. La produccin de cdigo est dirigida por las pruebas unitarias. stas son
establecidas por el cliente antes de escribirse el cdigo y son ejecutadas
constantemente ante cada modificacin del sistema.
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. Esta prctica se desarrollar con ms profundidad en apartados
sucesivos.
Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para el
equipo. ste es uno de los principales factores de xito del proyecto XP. El cliente
conduce constantemente el trabajo hacia lo que aportar mayor valor al negocio y los
Principios
Los principios bsicos de la programacin extrema son: simplicidad, comunicacin,
retroalimentacin y coraje.
Coraje o valenta: para los gerentes la programacin en parejas puede ser difcil de
aceptar, parece como si la productividad se fuese a reducir a la mitad ya que slo la
mitad de los programadores est escribiendo cdigo. Hay que ser valiente para
confiar en que la programacin por parejas beneficia la calidad del cdigo sin
repercutir negativamente en la productividad. La simplicidad es uno de los principios
ms difciles de adoptar. Se requiere coraje para implementar las caractersticas que
el cliente quiere ahora sin caer en la tentacin de optar por un enfoque ms flexible
que permite futuras modificaciones. No se debe emprender el desarrollo de grandes
marcos de trabajo mientras el cliente espera. En ese tiempo el cliente no recibe
noticias sobre los avances del proyecto y el equipo de desarrollo no recibe
retroalimentacin para saber si va en la direccin correcta. La forma de construir
Actividades
XP describe cuatro actividades que se llevan a cabo dentro del proceso de desarrollo de
software.
Codificar
Los defensores de XP argumentan que el nico producto realmente importante del proceso
de desarrollo de sistemas es el cdigo (un concepto al que dan una definicin ms amplia
que la que pueden dar otros). Sin el cdigo no se tiene nada. La codificacin puede ser
dibujar diagramas que generarn cdigo, hacer scripts de sistemas basados en web o
codificar un programa que ha de ser compilado.
Probar
Nadie puede estar seguro de algo si no lo ha probado. Las pruebas no es una necesidad
primaria percibida por el cliente. Mucho software se libera sin unas pruebas adecuadas y
funciona. En el desarrollo de software, XP dice que esto significa que uno no puede estar
seguro de que una funcin funciona si no la prueba. Esto sugiere la necesidad de definir de
lo que uno puede no estar seguro.
No puedes estar seguro de si lo que has codificado es lo que queras significar. Para
probar esta incertidumbre, XP usa pruebas unitarias. Son pruebas automatizadas
que prueban el cdigo. El programador intentar escribir todas las pruebas en las
No puedes estar seguro de si lo que queras significar era lo que deberas. Para
probar esta incertidumbre, XP usa pruebas de aceptacin basadas en los requisitos
dados por el cliente.
Escuchar
Los programadores no saben necesariamente todo sobre el lado del negocio del sistema
bajo desarrollo. La funcin del sistema est determinada por el lado del negocio. Para que
los programadores encuentren cual debe ser la funcionalidad del sistema, deben escuchar
las necesidades de los clientes. Tambin tienen que intentar entender el problema del
negocio y dar a los clientes retroalimentacin sobre el problema, para mejorar el propio
entendimiento del cliente sobre el problema.
Disear
Desde el punto de vista de la simplicidad, uno podra decir que el desarrollo de sistemas no
necesita ms que codificar, probar y escuchar. Si estas actividades se desarrollan bien, el
resultado debera ser un sistema que funcionase. En la prctica, esto no ocurre. Uno puede
seguir sin disear, pero un momento dado se va a atascar. El sistema se vuelve muy
complejo y las dependencias dentro del sistema dejan de estar claras. Uno puede evitar esto
creando una estructura de diseo que organice la lgica del diseo. Buenos diseos
evitarn perdidas de dependencias dentro de un sistema; esto significa que cambiar una
parte del sistema no tendr por qu afectar a otras.
Escenario
El gerente de la organizacin se rene con parte del esquipo de desarrollo que est llevando
a cabo el piloto de utilizacin de una mtodo gil, en este caso XP.
Scrum es un proceso gil que se puede usar para gestionar y controlar desarrollos
complejos de software y productos usando prcticas iterativas e incrementales.
Aunque Scrum estaba previsto que fuera para la gestin de proyectos de desarrollo de
software, se puede usar tambin para la ejecucin de equipos de mantenimiento de software
o como un enfoque de gestin de programas.
Historia
En 1986, Hirotaka Takeuchi e Ikujiro Nonaka describieron un enfoque integral que
incrementaba la velocidad y flexibilidad del desarrollo de nuevos productos comerciales.
Compararon este nuevo enfoque integral, en el que las fases se solapan fuertemente y el
proceso entero es llevado a cabo por un equipo multifuncional a travs de las diferentes
fases, al rugby, donde todo el equipo trata de ganar distancia como una unidad y pasando el
baln una y otra vez.
En 1991, DeGrace y Stahl hicieron referencia a este enfoque como Scrum, un trmino de
rugby mencionado en el artculo de Takeuchi y Nonaka. A principios de los 90, Ken
Schwaber us un enfoque que gui a Scrum a su compaa, Mtodos de Desarrollo
Avanzados. Al mismo tiempo, Jeff Sutherland desarroll un enfoque similar en Easel
Corporation y fue la primera vez que se llam Scrum. En 1995 Sutherland y Schwaber
presentaron de forma conjunta un artculo describiendo Scrum en OOPSLA 95 en Austin, su
primera aparicin pblica. Schwaber y Sutherland colaboraron durante los siguientes aos
para unir los artculos, sus experiencias y las mejores prcticas de la industria en lo que
ahora se conoce como Scrum. En 2001, Schwaber se asoci con Mike Beedle para poner
en limpio el mtodo en el libro Agile Software Development with Scrum.
Caractersticas
Scrum es un esqueleto de proceso que incluye un conjunto de prcticas y roles predefinidos.
Los roles principales en Scrum son el ScrumMaster que mantiene los procesos y trabaja
Una de las mayores ventajas de Scrum es que es muy fcil de entender y requiere poco
esfuerzo para comenzar a usarse.
Una parte muy importante de Scrum son las reuniones que se realizan durante cada una de
las iteraciones. Hay distintos tipos:
Scrum diario: cada da durante la iteracin, tiene lugar una reunin de estado del
proyecto. A esta reunin se le domina Scrum
24 h
30 das
Versin
Backlog del Backlog de la
Iteracin incrementada
producto iteracin
del software
Figura 11. Flujo de proceso de SCRUM
Prcticas
A continuacin se enumeran algunas de las prcticas de Scrum:
Viabilidad
Implementacin
Iteracin de
modelo
funcional
Iteracin de
diseo y
construccin
Figura 12. Ciclo de desarrollo de DSDM
DSDM fue desarrollado en Reino Unido en los 90 por el DSDM Consortium, una asociacin
de vendedores y expertos en el campo de la ingeniera creado con el objetivo de desarrollar
y promover conjuntamente un marco de trabajo RAD independiente combinando sus
propias experiencias. El DSDM Consortium es una organizacin sin nimo de lucro que
tiene la propiedad y se encarga de la administracin del marco de trabajo DSDM. La primera
versin se complet en Enero de 1995 y se public en Febrero de 1995.
El enfoque DSDM
En DSDM hay nueve procesos subyacentes que consisten en cuatro fundamentos y cinco
puntos de partida.
Se le deben otorgar poderes al equipo del proyecto para tomar decisiones que son
importantes para el progreso del proyecto, sin tener que esperar a aprobaciones de
ms alto nivel.
Se debera hacer una lnea base del alcance y los requisitos a alto nivel antes de que
el proyecto empiece
Las pruebas se llevan a cabo a lo largo de todo el ciclo de vida del proyecto.
Supuestos adicionales:
Cada paso del desarrollo slo ha completarse hasta que empiece el siguiente paso.
Esto permite que la nueva iteracin del proyecto comience sin retrasos innecesarios.
Los cambios en el diseo pueden coincidir con los cambios en la demanda de los
usuarios finales ya que cada iteracin del sistema es incremental.
El equipo ha de estar formado por miembros habilidosos que formen una unin
estable. Un tema importante es el otorgamiento de poderes al equipo del proyecto.
Esto quiere decir que el equipo tiene que poseer el poder de tomar decisiones
importantes relacionadas con el proyecto sin tener que escribir propuestas formales
a la alta gerencia, lo que puede llevar mucho tiempo. Para que el equipo del proyecto
pueda ejecutar un proyecto con xito, necesitan tambin la tecnologa correcta para
llevar a cabo el proyecto. Esto implica un entorno de desarrollo, herramientas de
gestin de proyectos, etc.
RUP es probablemente el mtodo que ms tiene en comn con DSDM ya que tambin es
una forma dinmica de desarrollo de sistemas de informacin. De nuevo el enfoque iterativo
se usa en este mtodo de desarrollo.
Como XP y RUP hay muchos otros mtodos de desarrollo que muestran similitudes con
DSDM, pero DSDM se diferencia de ellos en una serie de cosas. Primero est el hecho de
Crystal Clear
Crystal Clear es un miembro de la familia de metodologas Crystal como describe Alistair
Cockburn y se considera un ejemplo de metodologa gil.
Crystal Clear cuenta con las siguientes propiedades (las tres primeras son requeridas):
Mejora reflexiva
Seguridad personal
Disciplinas
Filosofas
AUP se basa en las siguientes filosofas:
Son varias las prcticas que se utilizan en el desarrollo rpido. Aunque algunas de ellas se
consideran metodologas en s mismas, son simplemente prcticas usadas en diferentes
metodologas.
Integracin continua
Pair programming
El desarrollo orientado a pruebas (TDD) es una tcnica de desarrollo de software que usa
iteraciones de desarrollo cortas basadas en casos de prueba escritos previamente que
definen las mejoras deseadas o nuevas funcionalidades. Cada iteracin produce el cdigo
necesario para pasar la prueba de la iteracin. Finalmente, el programador o equipo
refactoriza el cdigo para acomodar los cambios. Un concepto clave de TDD es que las
pruebas se escriben antes de que se escriba el cdigo para que ste cumpla con las
pruebas. Hay que tener en cuenta que TDD es un mtodo de diseo de software, no slo un
mtodo de pruebas.
TDD est relacionado con los primeros conceptos de pruebas de programacin de Extreme
Programming, en 1999, pero ms recientemente se est creando un inters general mayor
en s mismo.
TDD requiere que los desarrolladores creen pruebas unitarias automatizadas para definir los
requisitos del cdigo antes de escribir el cdigo en s mismo. Las pruebas contienen
afirmaciones que son verdaderas o falsas. El objetivo es escribir cdigo claro que funcione.
Ejecutar las pruebas rpidamente confirma el comportamiento correcto a medida que los
desarrolladores evolucionan y refactorizan el cdigo. Los desarrolladores se ayudan de
herramientas para crear y ejecutar automticamente conjuntos de casos de prueba.
La idea de escribir las pruebas antes que el cdigo tiene dos beneficios principales. Ayuda a
asegurar que la aplicacin se escribe para poder ser probada, ya que los desarrolladores
deben considerar cmo probar la aplicacin desde el principio, en vez de preocuparse por
ello luego. Tambin asegura que se escriben pruebas para cada caracterstica.
2. Ejecutar las pruebas y comprobar que la ltima que se ha aadido falla. Esto valida
que las pruebas estn funcionando correctamente y que las nuevas pruebas no
pasan errneamente, sin la necesidad de cdigo nuevo.
4. Ejecutar las pruebas automatizadas y ver que tienen xito Si todas las pruebas ahora
pasan, el programador puede estar seguro de que el cdigo cumple todos los
requisitos probados. Este es un buen punto para empezar el paso final del ciclo.
Ventajas
Entre las ventajas que se desprenden del uso de esta prctica encontramos las siguientes:
Al escribir primero los casos de prueba, se definen de manera formal los requisitos
que se espera que cumpla la aplicacin. Los casos de prueba sirven como
documentacin del sistema.
Inconvenientes
TDD es difcil de usar en situaciones donde hacen falta todas las pruebas
funcionales para determinar xito o fracaso. Ejemplos de esto son interfaces de
usuario, programas que trabajan con bases de datos, y algunos que dependen de
configuraciones de red especficas.
Las pruebas se han visto histricamente como una posicin ms baja que los
desarrolladores o arquitectos.
La integracin continua es un proceso que permite comprobar continuamente que todos los
cambios que lleva cada uno de los desarrolladores no producen problemas de integracin
con el cdigo del resto del equipo. Los entornos de integracin continua construyen el
software desde el repositorio de fuentes y lo despliegan en un entorno de integracin sobre
el que realizar pruebas. El concepto de integracin continua es que se debe integrar el
desarrollo de una forma incremental y continua.
Cuando se embarca en un cambio, un desarrollador coge una copia del cdigo actual en el
que trabajar. Cuando el cdigo cambiado se sube al repositorio por otros desarrolladores,
esta copia deja de reflejar el cdigo del repositorio. Cuando el desarrollador sube el cdigo
al repositorio debe primero actualizar su cdigo para reflejar los cambios que se han
producido en el repositorio desde que cogi su copia. Cuantos ms cambios haya en el
repositorio, ms trabajo debe hacer el desarrollador antes de subir sus propios cambios.
Pero hay que tener en cuenta que el repositorio se puede convertir en algo tan diferente a la
lnea base del desarrollador que puede caer en lo que se suele llamar, infierno de
integracin, donde el tiempo que usan para integrar es mayor que el tiempo que le han
llevado sus cambios originales. En un caso peor, los cambios que est haciendo el
desarrollador pueden tener que ser descartados y el trabajo se ha de rehacer.
Prcticas recomendadas
La integracin continua en s misma hace referencia a la prctica de la integracin frecuente
del cdigo de uno con el cdigo que se va a liberar. El trmino frecuente es abierto a
interpretacin, pero a menudo se interpreta como muchas veces al da.
Hacer las pruebas propias de la construccin. Esto toca otro aspecto de mejor
prctica, desarrollo orientado a pruebas. Esta es la prctica de escribir una prueba
que demuestre la falta de funcionalidad en el sistema y entonces escribir el cdigo
que hace que esa prueba se pueda pasar. Una vez que el cdigo est construido, se
deben pasar todas las pruebas para confirmar que se comporta como el
desarrollador esperaba que lo hiciera.
Despliegue automtico.
Ventajas
La integracin continua tiene muchas ventajas:
Inconvenientes
Las desventajas que se pueden observar con el uso de esta prctica son las siguientes:
Pair programming
Ventajas
Entre las ventajas que puede ofrecer una prctica como la programacin por pares
encontramos:
Coste reducido del desarrollo: siendo los defectos una parte particularmente cara del
desarrollo de software, especialmente si se encuentran tarde en el proceso de
desarrollo, la gran disminucin de la tasa de defectos debido a la programacin por
pares puede reducir significativamente los costes del desarrollo de software.
Flujo elstico: la programacin por pares conduce a un diferente tipo de flujo que la
programacin individual. Es ms rpido y ms fuerte o elstico a las interrupciones
ya que cuando uno trata la interrupcin el otro puede seguir trabajando.
Inconvenientes
Pero esta tcnica tambin genera una serie de desventajas o factores que pueden afectar
de forma negativa:
Egos y conflictos potenciales: conflictos personales que pueden resultar en que uno
o los dos desarrolladores se sientan incmodos. Las diferencias en el estilo de
codificacin pueden llevar a conflicto.
Hbitos personales molestos: las personas se pueden sentir molestas por otros
miembros del equipo debido a objeciones con algunos de sus hbitos.
Los rumores iniciales y los principios controvertidos de Extreme programming, tales como
programacin por pares e integracin continua, han atrado crticas particulares, como las de
McBreen y Boehm y Turner. Muchas de las crticas, sin embargo, son consideradas por
parte de los partidarios del desarrollo gil como malentendidos del desarrollo gil.
Con frecuencia se usa como medio de sacar dinero al cliente a travs de la falta de
definicin de un entregable.
Requiere encuentros a intervalos frecuentes con un enorme coste para los clientes.
Puede ser muy ineficiente, si los requisitos de un rea de cdigo cambian durante
varias iteraciones, se puede necesitar hacer la misma programacin varias veces.
Mientras que si se tiene que seguir un plan, un rea de cdigo individual se supone
que slo se va a escribir una vez.
Segn la filosofa de desarrollo se pueden clasificar las metodologas en dos grupos. Las
metodologas tradicionales, que se basan en una fuerte planificacin durante todo el
desarrollo, y las metodologas giles, en las que el desarrollo de software es incremental,
cooperativo, sencillo y adaptado.
Metodologas tradicionales
Otra de las caractersticas importantes dentro de este enfoque, son los altos costes al
implementar un cambio y la falta de flexibilidad en proyectos donde el entorno es voltil.
Metodologas giles
Este enfoque nace como respuesta a los problemas que puedan ocasionar las metodologas
tradicionales y se basa en dos aspectos fundamentales, retrasar las decisiones y la
planificacin adaptativa. Basan su fundamento en la adaptabilidad de los procesos de
desarrollo.
En las metodologas tradicionales el principal problema es que nunca se logra planificar bien
el esfuerzo requerido para seguir la metodologa. Pero entonces, si logramos definir
mtricas que apoyen la estimacin de las actividades de desarrollo, muchas prcticas de
metodologas tradicionales podran ser apropiadas. El no poder predecir siempre los
resultados de cada proceso no significa que estemos frente a una disciplina de azar. Lo que
significa es que estamos frente a la necesidad de adaptacin de los procesos de desarrollo
que son llevados por parte de los equipos que desarrollan software.
Tener metodologas diferentes para aplicar de acuerdo con el proyecto que se desarrolle
resulta una idea interesante. Estas metodologas pueden involucrar prcticas tanto de
metodologas giles como de metodologas tradicionales. De esta manera, podramos tener
una metodologa por cada proyecto, la problemtica sera definir cada una de las prcticas,
y en el momento preciso definir parmetros para saber cul usar.
Es importante tener en cuenta que el uso de un mtodo gil no vale para cualquier proyecto.
Sin embargo, una de las principales ventajas de los mtodos giles es su peso inicialmente
ligero y por eso las personas que no estn acostumbradas a seguir procesos encuentran
estas metodologas bastante agradables.
En la tabla que se muestra a continuacin aparece una comparativa entre estos dos grupos
de metodologas.
EL equipo de desarrollo que llev a cabo el piloto obtuvo grandes beneficios con el uso de
XP como modelo de desarrollo.
El gerente de COMPASS felicita a todo el equipo por el buen trabajo realizado y le reporta al
director el resultado exitoso del uso de este mtodo de desarrollo.
Informacin de RUP:http://www-01.ibm.com/software/awdtools/rup/
Ciclo de vida: conjunto de etapas que comprenden todas las actividades, desde el
momento en que surge la idea de crear un nuevo producto software, hasta aquel en
que el producto deja definitivamente de ser utilizado por el ltimo de sus usuarios