c


 


 c 



   



   


 ! "# #$%
&

'()*

Ä
  El desarrollo de software ágil disciplinado se realiza de una forma
El desarrollo de Software representa varios obstáculos; por lo cual colaborativa mediante una organización de los equipos propia
se desarrollaron varios tipos de metodologías para hacer esta tarea dentro de un marco de trabajo efectivo que produce software de
más sencilla. Entre estos tenemos los métodos Iterativos y alta calidad con un coste efectivo y en el tiempo apropiado que
Evolutivos; los cuales se centran en el control del proceso cumple con las necesidades cambiantes de las personas
mediante una planificación estricta, en cambio las metodologías involucradas en el negocio.
ágiles nacen como respuesta a los problemas que puedan
ocasionar estas metodologías y se basa retrasar las decisiones y la 

 

planificación adaptativa. En febrero de 2001, tras una reunión celebrada en Utah-EEUU,
nace el término .ágil aplicado al desarrollo de software. En esta
-
 
 reunión participan un grupo de 17 expertos de la industria del
Software, Metodologías Ágiles, RUP, XP, SCRUM, Cristal Clear. software Su objetivo fue definir los principios que deberían
permitir a los equipos desarrollar software rápidamente y
respondiendo a los cambios que puedan surgir a lo largo del
 
Ä

El software juega un papel significativo en la vida de las personas.
Se puede usar tanto en una aplicación en un ordenador personal
como en un robot industrial.
Desde que se empezó con el desarrollo de software han ido
surgiendo numerosos métodos, paradigmas y modelos de proceso
para manejar los esfuerzos complejos del desarrollo. Algunos de
los métodos de desarrollo se han convertido en métodos
orientados a documentación o con la expectativa de que los


desarrolladores sigan ciertos procesos. A estos métodos se les
suele conocer como métodos tradicionales o pesados.
El desarrollo de software ha estado plagado de problemas.
Afortunadamente, al mismo tiempo se están haciendo
continuamente innovaciones en técnicas de programación para
entregar software de calidad que cumpla los requisitos de los
clientes dentro del presupuesto y la planificación.
Probablemente el cambio más notable en los últimos años en el
proceso de software ha sido la aparición de la palabra ágil. Se
habla de métodos de software ágiles, de cómo introducir agilidad
en un equipo de desarrollo.
Este nuevo movimiento creció de los esfuerzos de varias personas
que trataban con procesos software en los 90.
proyecto.
Tras esta reunión se creó The Agile Alliance, una organización,
sin ánimo de lucro, dedicada a promover los conceptos
relacionados con el desarrollo ágil de software. El punto de
partida fue el Manifiesto Ágil, un documento que resume la
filosofía ágil.
  
Según el Manifiesto se valora:
· Al individuo y las interacciones del equipo de desarrollo sobre el
proceso y las herramientas. La gente es el principal factor de éxito
de un proyecto software. Es más importante construir un buen
equipo que construir el entorno.
· Desarrollar software que funciona más que conseguir una buena
documentación. La regla a seguir es no producir documentos a
menos que sean necesarios. Estos documentos deben ser cortos y
centrarse en lo fundamental.
· La colaboración con el cliente más que la negociación de un
contrato. Se propone que exista una interacción constante entre el
cliente y el equipo de desarrollo.
· Responder a los cambios más que seguir estrictamente un plan.
La planificación no debe ser estricta sino flexible y abierta.

Los valores anteriores inspiran los doce principios del manifiesto.

La reproducción digital o impresa de la totalidad o parte de este
trabajo para uso personal o en el aula se otorgan sin costo siempre
que los ejemplares no sean fabricados o distribuidos para el beneficio
o ventaja comercial y que las copias tengan este aviso y la cita
completa en la primera página. m Para copiar de otra manera, o volver
a publicar en los servidores o redistribuir en las listas, se requiere una
autorización previa y / o un pago.
R
L, 28-08, 2010, La Paz, olivia.
Derechos de autor 2010.
Son características que diferencian un proceso ágil de uno
tradicional. Los dos primeros principios son generales y resumen
gran parte del espíritu ágil. El resto tienen que ver con el proceso
a seguir y con el equipo de desarrollo, en cuanto metas a seguir y
organización del mismo. Los principios son:
I. La prioridad es satisfacer al cliente mediante tempranas y
continuas entregas de software que le aporte un valor.
II. ar la bienvenida a los cambios. Se capturan los cambios   

 
para que el cliente tenga una ventaja competitiva.

III. Entregar frecuentemente software que funcione desde un par
de semanas a un par de meses, con el menor intervalo de tiempo
posible entre entregas.
IV. La gente del negocio y los desarrolladores deben trabajar
juntos a lo largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. arles
el entorno y el apoyo que necesitan y confiar en ellos para
conseguir finalizar el trabajo.
VI. El diálogo cara a cara es el método más eficiente y efectivo
para comunicar información dentro de un equipo de desarrollo.
VII. El software que funciona es la medida principal de progreso.
VIII. Los procesos ágiles promueven un desarrollo sostenible. Los
promotores, desarrolladores y usuarios deberían ser capaces de
mantener una paz constante.
IX. La atención continua a la calidad técnica y al buen diseño
mejora la agilidad.
X. La simplicidad es esencial.
XI. Las mejores arquitecturas, requisitos y diseños surgen de los
equipos organizados por sí mismos.
XII. En intervalos regulares, el equipo reflexiona respecto a cómo


llegar a ser más efectivo, y según esto ajusta su comportamiento.
El desarrollo ágil elige hacer las cosas en 
con una planificación mínima, más que planificaciones a largo
plazo. Las iteraciones son estructuras de tiempo pequeñas
(conocidas como timeboxes) que típicamente duran de 1 a 4
semanas. De cada iteración se ocupa un equipo realizando un
ciclo de desarrollo completo, incluyendo planificación, análisis de
requisitos, diseño, codificación, pruebas unitarias y pruebas de
aceptación. Esto ayuda a minimizar el riesgo general, y permite al
proyecto adaptarse a los cambios rápidamente. La documentación
se produce a medida que es requerida por los agentes
involucrados. Una iteración puede no añadir suficiente
funcionalidad para garantizar una liberación del producto al
mercado, pero el objetivo es tener una versión disponible (con
errores mínimos) al final de cada iteración. Se requerirán
múltiples iteraciones para liberar un producto o nuevas
características.

 
2.2.1 El Equipo
  


 

 La composición del equipo es normalmente multidisciplinar y de
organización propia sin consideración de cualquier jerarquía
La Tabla 1 recoge esquemáticamente las principales diferencias
corporativa existente o los roles corporativos de los miembros de
de las metodologías ágiles con respecto a las tradicionales
los equipos. Los miembros de los equipos normalmente toman
(Iterativas y Evolutivas). Estas diferencias que afectan no sólo al
responsabilidades de tareas que consigan la funcionalidad de una
proceso en sí, sino también al contexto del equipo y a su
iteración. Deciden ellos mismos cómo realizarán las tareas
organización.
durante una iteración.


  



 



2.2.2 Comunicación Cara a Cara



 
 


 


 Los métodos ágiles enfatizan la comunicación cara a cara sobre
Basadas en heurísticas Basadas en normas y los documentos escritos. La mayoría de los equipos ágiles se
provenientes de prácticas de estándares seguidos por el encuentran localizados en una única ubicación abierta para
producción de código.m entorno de desarrollo facilitar esta comunicación. El tamaño del equipo es normalmente
Especialmente preparados Cierta resistencia a los pequeño (5-9 personas) para ayudar a hacer la comunicación y la
para cambios durante el cambios colaboración más fácil. Los esfuerzos de desarrollos largos deben
proyecto ser repartidos entre múltiples equipos trabajando hacia un objetivo
Impuestas internamente (por Impuestas externamente común o partes diferentes de un esfuerzo. Esto puede requerir
el equipo) también una coordinación de prioridades a través de los equipos.
Proceso menos controlado, Proceso más controlado, con
con pocos principios numerosas políticas/normas. La mayoría de las metodologías ágiles incluyen una comunicación
No existe contrato tradicional Existe un contrato prefijado cara a cara rutinaria, diaria y formal entre los miembros del
o al menos es bastante equipo. Esto incluye específicamente al representante del cliente y
flexible a cualquier persona involucrada en el negocio como observadores.
El cliente es parte del equipo El cliente interactúa con el En una breve sesión, los miembros del equipo informan al resto
de desarrollo equipo mediante reuniones de lo que hicieron el día anterior, lo que van a hacer hoy y cuáles
Grupos pequeños (<10 ) y Grupos grandes y son sus principales obstáculos. Esta comunicación cara a cara
trabajando en el mismo sitio posiblemente distribuidos permanente previene problemas que se puedan esconder.
Pocos artefactos Más artefactos
Pocos roles Más roles 2.2.3 Comunicación Constante con el Cliente
Menos énfasis en la La arquitectura del software es No importa qué disciplinas de desarrollo se requieran, cada
arquitectura del software esencial y se expresa mediante equipo ágil contendrá un representante del cliente. Esta persona es
modelos designada por las personas involucradas en el negocio para actuar
en su nombre y hacer un compromiso personal de estar disponible 



 


para los desarrolladores para responder preguntas. Al final de
cada iteración, las personas involucradas en el negocio y el
representante del cliente revisan el progreso y reevalúan las
prioridades con vistas a optimizar el retorno de la inversión y
asegurando la alineación con las necesidades del cliente y los
objetivos de la compañía.
2.2.3 Menos ocumentación (solo la necesaria)
Los métodos ágiles enfatizan software operativo como la medida
principal del progreso. Combinado con la preferencia de
comunicación cara a cara, los métodos ágiles normalmente
producen menos documentación escrita que otros métodos.
Su impulsor es Jim Highsmith. Sus principales características son:
iterativo, orientado a los componentes software más que a las
tareas y tolerante a los cambios. El ciclo de vida que propone
tiene tres fases esenciales: especulación, colaboración y
aprendizaje. En la primera de ellas se inicia el proyecto y se
planifican las características del software; en la segunda
desarrollan las características y finalmente en la tercera se revisa
su calidad, y se entrega al cliente. La revisión de los componentes
sirve para aprender de los errores y volver a iniciar el ciclo de
desarrollo.




 Define un proceso iterativo que consta de 5 pasos. Las iteraciones


 son cortas (hasta 2 semanas). Se centra en las fases de diseño e
Aunque los creadores e impulsores de las metodologías ágiles implementación del sistema partiendo de una lista de
más populares han suscrito el manifiesto ágil y coinciden con los características que debe reunir el software. Sus impulsores son
principios enunciados anteriormente, cada metodología tiene Jeff De Luca y Peter Coad.
características propias y hace hincapié en algunos aspectos más
específicos. A continuación se resumen otras metodologías ágiles.


Ä
Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle.
Define un marco para la gestión de proyectos, que se ha utilizado
con éxito durante los últimos 10 años.
Está especialmente indicada para proyectos con un rápido cambio
de requisitos. Sus principales características se pueden resumir en
dos. El desarrollo de software se realiza mediante iteraciones,
denominadas sprints, con una duración de 30 días. El resultado de

 
 

Definida por Bob Charette.s a partir de su experiencia en
proyectos con la industria japonesa del automóvil en los años 80 y
utilizada en numerosos proyectos de telecomunicaciones en
Europa. En LD, los cambios se consideran riesgos, pero si se
manejan adecuadamente se pueden convertir en oportunidades
que mejoren la productividad del cliente. Su principal
característica es introducir un mecanismo para implementar
dichos cambios.

Ä
- (Ä-)
cada sprint es un incremento ejecutable que se muestra al cliente. RUP es un proceso para el desarrollo de un proyecto de software
La segunda característica importante son las reuniones a lo largo que define claramente quien, cómo, cuándo y qué debe hacerse en
proyecto, entre ellas destaca la reunión diaria de 15 minutos del el proyecto. Como 3 características esenciales está dirigido por los
equipo de desarrollo para coordinación e integración. Casos de Uso: que orientan el proyecto a la importancia para el
usuario y lo que este quiere, está centrado en la arquitectura: que





 relaciona la toma de decisiones que indican cómo tiene que ser
Se trata de un conjunto de metodologías para el desarrollo de construido el sistema y en qué orden, y es iterativo e incremental:
software caracterizadas por estar centradas en las personas que donde divide el proyecto en mini proyectos donde los casos de
componen el equipo y la reducción al máximo del número de uso y la arquitectura cumplen sus objetivos de manera más
artefactos producidos. Han sido desarrolladas por Alistair depurada.
Cockburn. El desarrollo de software se considera un juego
cooperativo de invención y comunicación, limitado por los 3.7.1 Principios del RRP
recursos a utilizar. El equipo de desarrollo es un factor clave, por Como filosofía RUP maneja 6 principios clave:
lo que se deben invertir esfuerzos en mejorar sus habilidades y
destrezas, así como tener políticas de trabajo en equipo definidas.
Estas políticas dependerán del tamaño del equipo, estableciéndose
3.7.1.1
daptación del proceso
El proceso deberá adaptarse a las características propias de la
una clasificación por colores, por ejemplo Crystal Clear (3 a 8
organización. El tamaño del mismo, así como las regulaciones
miembros) y Crystal Orange (25 a 50 miembros).
que lo condicionen, influirán en su diseño específico. También se
deberá tener en cuenta el alcance del proyecto.
 






Define el marco para desarrollar un proceso de producción de 3.7.1.2 alancear prioridades
software. Nace en 1994 con el objetivo de crear una metodología Los requerimientos de los diversos inversores pueden ser
RAD unificada. Sus principales características son: es un proceso
diferentes, contradictorios o disputarse recursos limitados. ebe
iterativo e incremental y el equipo de desarrollo y el usuario encontrarse un balance que satisfaga los deseos de todos.
trabajan juntos. Propone cinco fases: estudio viabilidad, estudio
del negocio, modelado funcional, diseño y construcción, y
finalmente implementación. Las tres últimas son iterativas, 3.7.1.3 Colaboración entre equipos
además de existir realimentación a todas las fases. El desarrollo de software no lo hace una única persona sino
múltiples equipos. Debe haber una comunicación fluida para
coordinar requerimientos, desarrollo, evaluaciones, planes,
resultados, etc.
3.7.1.4 emostrar valor iterativamente 3.7.3 Roles en RRP
Los proyectos se entregan, aunque sea de un modo interno, en 3.7.3.1
nalistas

  

. En cada iteración se analiza la opinión de los · Analista de procesos de negocio.
inversores, la estabilidad y calidad del producto, y se refina la · Diseñador del negocio.
dirección del proyecto así como también los riesgos involucrados. · Analista de sistema.
· Especificador de requisitos.
3.7.1.5 Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables 3.7.3.2 esarrolladores
tales como patrón del software, lenguajes 4GL o esquemas · Arquitecto de software.
(frameworks) por nombrar algunos. Éstos se pueden acompañar · Diseñador
por las representaciones visuales de la arquitectura, por ejemplo · Diseñador de interfaz de usuario
con UML. · Diseñador de cápsulas.
· Diseñador de base de datos.
3.7.1.6 Enfocarse en la calidad · Implementador.
El control de calidad no debe realizarse al final de cada iteración, · Integrador.
sino en

los aspectos de la producción.
3.7.3.3 Gestores
3.7.2 El ciclo de vida de RRP · Jefe de proyecto

· Jefe de control de cambios.
· Jefe de configuración.
· Jefe de pruebas
· Jefe de despliegue
· Ingeniero de procesos
· Revisor de gestión del proyecto
· Gestor de pruebas.

3.7.3.4
poyo
· Documentador técnico
· Administrador de sistema
· Especialista en herramientas
· Desarrollador de cursos
· Artista gráfico

 3.7.3.5 Especialista en pruebas

  

 

  
 
 · Especialista en Pruebas (tester)
 
 
 


 · Analista de pruebas
 · Diseñador de pruebas
RUP divide el proceso en 4 fases, dentro de las cuales se realizan
varias iteraciones en número variable según el proyecto y en las 3.7.3.6 tros roles
que se hace un mayor o menor hincapié en los distintas · Stakeholders.
actividades. · Revisor
· Coordinación de revisiones
3.7.2.1 Inicio · Revisor técnico
Se hace un plan de fases, se identifican los principales casos de · Cualquier rol
uso y se identifican los riesgos. Se define el alcance del proyecto.
  !
- "#-
3.7.2.2 Elaboración Es una metodología ágil centrada en potenciar las relaciones
Se hace un plan de proyecto, se completan los casos de uso y se interpersonales como clave para el éxito en desarrollo de
eliminan los riesgos. software, promoviendo el trabajo en equipo, preocupándose por el
aprendizaje de los desarrolladores, y propiciando un buen clima
3.7.2.3 Construcción de trabajo. XP se basa en realimentación continua entre el cliente
Se concentra en la elaboración de un producto totalmente y el equipo de desarrollo, comunicación fluida entre todos los
operativo y eficiente y el manual de usuario. participantes, simplicidad en las soluciones implementadas y
coraje para enfrentar los cambios. XP se define como
3.7.2.4 Transición especialmente adecuada para proyectos con requisitos imprecisos
Se Instala el producto en el cliente y se entrena a los usuarios. y muy cambiantes, y donde existe un alto riesgo técnico.
Como consecuencia de esto suelen surgir nuevos requisitos a ser
analizados. Los principios y prácticas son de sentido común pero llevadas al
extremo, de ahí proviene su nombre. Kent Beck, es el padre de
XP.
A continuación las características esenciales de XP organizadas
en los tres apartados siguientes: historias de usuario, roles,
proceso y prácticas.
3.8.1 Las Historias de Rsuario
Son la técnica utilizada para especificar los requisitos del
software. Se trata de tarjetas de papel en las cuales el cliente
describe brevemente las características que el sistema debe
poseer, sean requisitos funcionales o no funcionales. El
tratamiento de las historias de usuario es muy dinámico y flexible.
Cada historia de usuario es lo suficientemente comprensible y
delimitada para que los programadores puedan implementarla en
unas semanas.
3.8.2. Roles XP
Los roles de acuerdo con la propuesta original de Beck son:
3.8.2.1 Programador
El programador escribe las pruebas unitarias y produce el código
del sistema.
3.8.2.2 Cliente
Escribe las historias de usuario y las pruebas funcionales para
validar su implementación. Además, asigna la prioridad a las
historias de usuario y decide cuáles se implementan en cada
iteración centrándose en aportar mayor valor al negocio.
3.8.2.3 Encargado de pruebas (Tester)
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.
3.8.2.4 Encargado de seguimiento (Tracker)
Proporciona realimentación al equipo. Verifica el grado de acierto
entre las estimaciones realizadas y el tiempo real dedicado, para
mejorar futuras estimaciones. Realiza el seguimiento del progreso
de cada iteración.
3.8.2.5 Entrenador (Coach)
Es responsable del proceso global. Debe proveer guías al equipo
de forma que se apliquen las prácticas XP y se siga el proceso
correctamente.
3.8.2.6 Consultor
Es un miembro externo del equipo con un conocimiento
específico en algún tema necesario para el proyecto, en el que
puedan surgir problemas.
3.8.2.7 Gestor (ig boss).
Es el vínculo entre clientes y programadores, ayuda a que el
equipo trabaje efectivamente creando las condiciones adecuadas.
Su labor esencial es de coordinación.
3.8.3. Proceso XP
El ciclo de desarrollo consiste en los siguientes pasos:
1. El cliente define el valor de negocio a implementar.
2. El programador estima el esfuerzo necesario para su
implementación.
3. El cliente selecciona qué construir, de acuerdo con sus
prioridades y las restricciones de tiempo.
4. El programador construye ese valor de negocio.
5. Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el
programador aprenden. No se debe presionar al programador a
realizar más trabajo que el estimado, ya que se perderá calidad en
el software o no se cumplirán los plazos. De la misma forma el
cliente tiene la obligación de manejar el ámbito de entrega del
producto, para asegurarse que el sistema tenga el mayor valor de
negocio posible con cada iteración.
El ciclo de vida ideal de XP consiste de seis fases: Exploración,
Planificación de la Entrega (Release), Iteraciones, Producción,
Mantenimiento y Muerte del Proyecto.
3.8.4. Prácticas XP
La principal suposición que se realiza en XP es la posibilidad de
disminuir el costo del cambio a lo largo del proyecto, lo suficiente
para que el diseño evolutivo funcione. Esto se consigue gracias a
las tecnologías disponibles para ayudar en el desarrollo de
software y a la aplicación disciplinada de las siguientes prácticas.
3.8.4.1 El juego de la planificación
Hay una comunicación frecuente el cliente y los programadores.
El equipo técnico realiza una estimación del esfuerzo requerido
para la implementación de las historias de usuario y los clientes
deciden sobre el ámbito y tiempo de las entregas y de cada
iteración.
3.8.4.2 Entregas pequeñas
Producir rápidamente versiones del sistema que sean operativas,
aunque no cuenten con toda la funcionalidad del sistema. Esta
versión ya constituye un resultado de valor para el negocio. Una
entrega no debería tardar más 3 meses.
3.8.4.3 Metáfora
El sistema es definido mediante una metáfora o un conjunto de
metáforas compartidas por el cliente y el equipo de desarrollo.
Una metáfora es una historia compartida que describe cómo
debería funcionar el sistema.
3.8.4.4 iseño simple
Se debe diseñar la solución más simple que pueda funcionar y ser
implementada en un momento determinado del proyecto.
3.8.4.5 Pruebas
La producción de código está dirigida por las pruebas unitarias.
Éstas son establecidas por el cliente antes de escribirse el código y
son ejecutadas constantemente ante cada modificación del
sistema.
3.8.4.6 Refactorización (Refactoring)
Es una actividad constante de reestructuración del código con el
objetivo de remover duplicación de código, mejorar su
legibilidad, simplificarlo y hacerlo más flexible para facilitar los
posteriores cambios.
3.8.4.7 Programación en parejas
Toda la producción de código debe realizarse con trabajo en
parejas de programadores.
3.8.4.8 Propiedad colectiva del código
Cualquier programador puede cambiar cualquier parte del código
en cualquier momento.
3.8.4.9 Integración continua
Cada pieza de código es integrada en el sistema una vez que esté
lista. Así, el sistema puede llegar a ser integrado y construido
varias veces en un mismo día.
3.8.4.10 40 horas por semana.
Se debe trabajar un máximo de 40 horas por semana. No se
trabajan horas extras en dos semanas seguidas. Si esto ocurre,
probablemente está ocurriendo un problema que debe corregirse.
El trabajo extra desmotiva al equipo.
3.8.4.11 Cliente in-situ
El cliente tiene que estar presente y disponible todo el tiempo para
el equipo. Éste es uno de los principales factores de éxito del
proyecto XP. El cliente conduce constantemente el trabajo hacia
lo que aportará mayor valor de negocio y los programadores
pueden resolver de manera inmediata cualquier duda asociada. La
comunicación oral es más efectiva que la escrita.
3.8.4.12 Estándares de programación.
XP enfatiza que la comunicación de los programadores es a través
del código, con lo cual es indispensable que se sigan ciertos
estándares de programación para mantener el código legible.

El mayor beneficio de las prácticas se consigue con su aplicación
conjunta y equilibrada puesto que se apoyan unas en otras. Esto se
ilustra en la Figura 3, donde una línea entre dos prácticas significa
que las dos prácticas se refuerzan entre sí.




No existe una metodología universal para hacer frente con éxito a
cualquier proyecto de desarrollo de software. Toda metodología
debe ser adaptada al contexto del proyecto (recursos técnicos y
humanos, tiempo de desarrollo, tipo de sistema, etc.
Históricamente, las metodologías tradicionales han intentado
abordar la mayor cantidad de situaciones de contexto del
proyecto, exigiendo un esfuerzo considerable para ser adaptadas,
sobre todo en proyectos pequeños y con requisitos muy
cambiantes. Las metodologías ágiles ofrecen una solución casi a
medida para una gran cantidad de proyectos que tienen estas
características. Una de las cualidades más destacables en una
metodología ágil es su sencillez, tanto en su aprendizaje como en
su aplicación, reduciéndose así los costos de implantación en un
equipo de desarrollo. Esto ha llevado hacia un interés creciente en
las metodologías ágiles.
Ä  Ä  

[1] Metodologías Ágiles de Desarrollo de Software, Universidad
Politecnica de Valencia.
[2] Curso de Desarrollo Ágil, INTECO
[3] Fundamentos del RUP, Juan pablo Gomez Gallego