DESCRIPCIÓN DE LAS METODOLOGÍAS ÁGILES

PARA EL DESARROLLO DE SOFTWARE

INFORME TÉCNICO

Autor: MSc. Fredy Humberto Vera Rivera.

Departamento de Sistemas e Informática.

(Maddison, 1983) Define metodología como un conjunto de filosofías, fases,

procedimientos, reglas, técnicas, herramientas, documentación y aspectos de formación
para los desarrolladores de sistemas de información. Por lo tanto, una metodología es un
conjunto de componentes que especifican:

- Cómo se debe dividir un proyecto en etapas.

- Qué tareas se llevan a cabo en cada etapa.
- Qué salidas se producen y cuándo se deben producir.
- Qué restricciones se aplican.
- Qué herramientas se van a utilizar.
- Cómo se gestiona y controla un proyecto.

Las metodologías tradicionales usadas para el desarrollo de software son:

 Cascada
 Prototipado o espiral.
 Proceso unificado de desarrollo – RUP
 Métodologias ágiles: Scrum, XP, Lean, DSDM.

1. METODOLOGÍAS ÁGILES PARA EL DESARROLLO DE

SOFTWARE

Son métodos de ingeniería del software basados en el desarrollo iterativo e incremental.

Los requerimientos y soluciones evolucionan mediante la colaboración de grupos auto
organizados y multidisciplinarios. Se centran en la minimización de los riesgos y control
del cambio. Se desarrolla en iteraciones, en cada iteración se obtiene un prototipo
funcional del sistema.

El manifiesto ágil. (Cunningham, Medinilla, Giné, & Gómez, 2001)

En marzo de 2001 diecisiete críticos de los modelos de mejora del desarrollo de software
basados en procesos, convocados por Kent Beck, quien había publicado un par de años
antes Extreme Programming Explained, se reunieron en Salt Lake City para tratar sobre
técnicas y procesos para desarrollar software. En la reunión surgió el término “Métodos
Ágiles” para definir a los métodos que estaban surgiendo como alternativa a las
metodologías formales (CMMI, SPICE) a las que consideraban excesivamente “pesadas”
y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas
previas al desarrollo. Los integrantes de la reunión resumieron los principios sobre los que
se basan los métodos alternativos en cuatro postulados, lo que ha quedado denominado
como Manifiesto Ágil.

Tabla 1. El manifiesto ágil

Valores En vez de
Individuos e iteraciones Proceso y herramientas
Software funcionando Documentación extensiva
Colaboración con el cliente Negociación contractual
Respuesta ante el cambio Seguir un plan.
Fuente: autor

1.1. Principios del Manifiesto Ágil

Tras los cuatro valores descritos, los firmantes redactaron los siguientes, como los
principios que de ellos se derivan:

- La principal prioridad es satisfacer al cliente a través de la entrega temprana y

continua de software de valor.
- Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los
procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
- Entregar con frecuencia software que funcione, en periodos de un par de semanas
hasta un par de meses, con preferencia en los periodos breves.
- Las personas del negocio y los desarrolladores deben trabajar juntos de forma
cotidiana a través del proyecto.
- Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y
el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
- La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de
un equipo de desarrollo es mediante la conversación cara a cara.
- El software que funciona es la principal medida del progreso.
- Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores,
desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
- La atención continua a la excelencia técnica enaltece la agilidad.
- La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es
esencial.
- Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-
organizan.
- En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y
ajusta su conducta en consecuencia.
Teniendo en cuenta estos principios se han formulado varias metodologías ágiles de
desarrollo entre las cuales se encuentran: XP – Programación extrema, Scrum, DSMD -
Dynamic Systems Development Method, FDD - Feature-Driven Development, siendo
estas las más utilizadas en la actualidad. A continuación se realiza una descripción breve
de cada una de estas metodologías.

1.2. PROGRAMACIÓN EXTREMA – XP

Esta metodología fue formulada por Kent Beck. Define un proceso iterativo e incremental
con pruebas unitarias continuas y entregas frecuentes. El cliente o un representante del
cliente son integrados al equipo de desarrollo. Recomienda que el desarrollo de las
funciones del producto sea realizado por dos personas en el mismo puesto (programación
por pares). Antes de incorporar nueva funcionalidad, se deben corregir todos los defectos
encontrados. Constantemente, se llevan a cabo pruebas de regresión a fin de detectar los
posibles errores. (Beck, 1999)

1.2.1. Características de programación extrema - XP

 Hace más énfasis en la adaptabilidad que en la previsibilidad.

 Los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e
incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a
los cambios de requisitos en cualquier punto de la vida del proyecto es una
aproximación mejor y más realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los
requisitos. (Beck & Fowler, Planning Extreme Programming, 2001)
 En lugar de tratar de luchar por impedir el cambio lo asume y busca una forma de
trabajo que se adapte fácilmente a estas circunstancias.
 Se orienta a lograr un equipo de trabajo en donde se involucre el cliente y
continuamente se estén presentando versiones funcionales, pero con el mínimo de
código necesario y lo más simple.
 El diseño se realiza sobre la marcha, haciendo solo lo necesario para cada etapa y
luego modificándolo en las siguientes. No es necesario hacer una documentación
para el diseño, la filosofía de la XP reza que no hay mejor documentación que el
mismo código. (Beck & Fowler, Planning Extreme Programming, 2001)
 El equipo de Extreme Programming mantiene el sistema integrado y funcionando
todo el tiempo. Los programadores escriben todo el código de la producción de
dos en dos, y todos trabajan juntos todo el tiempo. Se codifican en un estilo
coherente, de modo que todos puedan entender y mejorar todo el código según
sea necesario.
 1.2.2. Roles

Un rol se define como una persona, grupo de personas o entidad involucrada en el

desarrollo del sistema. En la tabla se describen los roles de XP. (Letelier & Penadés,
2006).

Tabla 2. Roles de XP.

ROL DESCRIPCIÓN
Programador Es el encargado de la implementación del sistema y escribir las pruebas
unitarias. La comunicación entre los miembros del equipo de desarrollo
y los demás miembros es fundamental.
Cliente Se encarga de escribir y validar las historias de usuario y las pruebas
funcionales para validar su implementación. También define la prioridad
a las historias de usuario y decide cuales se implementan en cada
iteración, enfocado en aportar mayor valor al negocio.
Encargado de Pruebas (Tester) Ayuda al cliente a escribir las pruebas funcionales, ejecuta estas
pruebas, define y difunde los resultados al equipo de desarrollo, es el
responsable de las herramientas de soporte para las pruebas.
Encargado de seguimiento Proporciona realimentación al equipo en el proceso XP. Se encarga de
(Tracker) verificar el grado de acierto en las estimaciones realizadas y el tiempo
real dedicado, comunicando los resultados para mejorar futuras
estimaciones. También realiza el seguimiento del proceso de cada
iteración y evalúa si los objetivos son alcanzables con las restricciones
de tiempo y recursos presentes. Determina los cambios a realizar para
poder lograr los objetivos de la iteración.
Entrenador (Coach) Es el responsable del proceso global. Debe conocer muy bien el
proceso XP para proveer guías a los miembros del equipo de forma que
apliquen las prácticas XP y se siga el proceso correctamente.
Consultor Es un miembro externo al equipo con un conocimiento específico en
algún tema necesario para el proyecto. Guía al equipo para resolver un
problema específico.
Gestor (Big boss) Es el vínculo entre el cliente y los programadores, ayuda a que el equipo
trabaje efectivamente creando las condiciones adecuadas. Su labor
esencial es la coordinación-
Fuente: autor

1.2.3. Artefactos

Historias de usuario:

Es la técnica usada para especificar los requisitos del software, tanto funcionales como no
funcionales. Consisten en tarjetas de papel donde el cliente describe brevemente las
características del sistema. Se da un tratamiento dinámico y flexible, en cualquier
momento se pueden romper, reemplazar o modificar por otras más específicas o
generales. Cada historia de usuario debe ser lo suficiente comprensible y delimitada para
que los programadores puedan implementarla en unas semanas. (Letelier & Penadés,
2006)
La información que debe contener una historia de usuario definida por (Beck, Extreme
Programming Explained: Embrace Change, 2000) presenta un ejemplo de ficha en la cual
pueden reconocerse los siguientes contenidos: fecha, tipo de actividad (nueva, corrección,
mejora), prueba funcional, número de historia, prioridad técnica y del cliente, referencia a
otra historia previa, riesgo, estimación técnica, descripción, notas y una lista de
seguimiento con la fecha, estado cosas por terminar y comentarios. A continuación se
presenta una tabla con la información que debe contener una historia de usuario:

Tabla 3. Historias de usuario

Historia de Usuario
Fecha: Tipo: (Nueva, corrección, mejora)
Número: Usuario:
Nombre historia:
Prioridad: Iteración asignada:
Programador Responsable:

Descripción:

Observaciones:

Fuente: autor

1.2.4. Prácticas fundamentales de XP

En la figura aparecen las practicas básicas que se deben llevar a cabo en un proceso de
desarrollo de software con XP (Jeffries, 2014), las cuales se explican a continuación.

Todo el equipo (Whole Team) de un proyecto se sientan juntos, trabajan en el mismo

lugar y cerca el uno del otro, el equipo debe incluir un representante del negocio, el
Cliente, el cual forma parte fundamental del equipo.
Fuente: (Jeffries, 2014)

Planificación del Juego:

El equipo de XP utiliza una forma simple de planificación y seguimiento del proyecto. Se

centran en el valor del negocio, el equipo produce el software en una serie de pequeños
lanzamientos totalmente integrados que pasan las pruebas que el cliente haya definido.
La planificación en el desarrollo de software aborda dos cuestiones clave: la predicción de
lo que va a llevarse a cabo en la fecha prevista, y la determinación de qué hacer a
continuación; en XP frente a estas dos preguntas se realiza:

Planificación de lanzamiento, es una práctica donde el cliente presenta las características

deseadas a los programadores, los programadores estiman la dificultad; el cliente
presenta un plan para el proyecto, definiendo prioridades y el orden del desarrollo.

Planificación de la iteración, es una práctica que el equipo realiza cada dos semanas para
definir las tareas a realizar y las funcionalidades a implementar, teniendo en cuenta las
características deseadas por el cliente y sus prioridades. Al finalizar la iteración se obtiene
una versión visible para el cliente que puede probar.

El equipo XP mantiene el sistema integrado y funcionando todo el tiempo. Con cada

iteración se añaden funcionalidades de valor para el negocio, logrando una integración
continua, el sistema está funcionando todo el tiempo. Los programadores escriben el
código de dos en dos (programación en pares), uno se encarga de escribir el código y el
otro realiza la prueba unitaria y funcional del código creado, se siguen estándares de
codificación siguiendo un estilo coherente; con el fin de que todos puedan leer, entender y
mejorar el código de todos.

Diseño Simple:

El equipo de XP comparte una visión común y simple de lo que el sistema va a ser.

Construyen el software bajo un diseño simple pero adecuado para la funcionalidad actual
del sistema. No hay movimiento perdido y el software está siempre listo para lo que viene.
El diseño en XP no es una cosa de solo una vez, o algo por adelantado, es una cosa de
todo el tiempo. Se realiza un diseño en la planificación de cada iteración, se participan en
sesiones rápidas y revisiones de diseño a través de la refactorización, en el transcurso de
todo el proyecto. En un proceso iterativo e incremental como XP el buen diseño es
esencial y se lleva a cabo a lo largo de todo el proceso de desarrollo.

Programación por Pares:

Todo el software de producción en XP está construido por dos programadores, sentado el

uno al lado del otro en la misma máquina. Esta práctica garantiza que todo el código de
producción es revisado por al menos otro programador, y se traduce en un mejor diseño,
en un mejor código y en una mejor prueba. Este estilo de programación permite compartir
el conocimiento a todo el equipo. Al cambiar los pares, todo el mundo tiene los beneficios
de los conocimientos especializados de los demás. Los programadores aprenden, sus
habilidades mejoran, se vuelven más valiosos para el equipo y para la empresa.

1.2.5. El proceso de desarrollo

Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar

basado en la habilidad del equipo para medir la funcionalidad que puede entregar a través
del tiempo. El ciclo de desarrollo consiste fundamentalmente en los siguientes pasos
(Jeffries, 2014)

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, XP sugiere 40
horas de trabajo, 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 (Beck, Extreme Programming

Explained: Embrace Change, 2000): Exploración, Planificación de la Entrega (Release),
Iteraciones, Producción, Mantenimiento y Muerte del Proyecto. Estas fases se pueden
apreciar en la figura 1.
Figura 1 Fases de XP

Planificación Muerte del

Exploración Iteraciones Producción Mantenimiento
entrega Proyecto

A continuación se detalla brevemente cada una de estas fases. Aunque estas fases no
siguen un orden estricto secuencial, en el gráfico se presenta de esta forma para dar un
mejor entendimiento a esta metodología.

Fase I: Exploración:

En esta fase, los clientes plantean las historias de usuario que son de interés para la
primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con
las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba la
tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un
prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo
del tamaño y familiaridad que tengan los programadores con la tecnología.

Fase II: Planificación de la Entrega

En esta fase el cliente establece la prioridad de cada historia de usuario, los

programadores realizan una estimación 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 debería obtenerse en no más de tres meses. Esta
fase dura unos pocos días.

Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen

los programadores utilizando como medida el punto. Un punto, equivale a una semana
ideal de programación. Las historias generalmente valen de 1 a 3 puntos. Por otra parte,
el equipo de desarrollo mantiene un registro de la "velocidad" de desarrollo, establecida
en puntos por iteración, basándose principalmente en la suma de puntos
correspondientes a las historias de usuario que fueron terminadas en la última iteración.

La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad del

proyecto es utilizada para establecer cuántas historias se pueden implementar antes de
una fecha determinada o cuánto tiempo tomará implementar un conjunto de historias. Al
planificar por tiempo, se multiplica el número de iteraciones por la velocidad del proyecto,
determinándose cuántos puntos se pueden completar. Al planificar según alcance del
sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la
velocidad del proyecto, obteniendo el número de iteraciones necesarias para su
implementación.

Fase III: Iteraciones

Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de
Entrega está compuesto por iteraciones de no más de tres semanas. En la primera
iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada
durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la
creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el
cliente quien decide qué historias se implementarán en cada iteración (para maximizar el
valor de negocio). Al final de la última iteración el sistema estará listo para entrar en
producción.

Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la
Iteración son: historias de usuario no abordadas, velocidad del proyecto, pruebas de
aceptación no superadas en la iteración anterior y tareas no terminadas en la iteración
anterior. Todo el trabajo de la iteración es expresado en tareas de programación, cada
una de ellas es asignada a un programador como responsable, pero llevadas a cabo por
parejas de programadores. Wake en (Wake,2002) proporciona algunas guías útiles para
realizar la planificación de la entrega y de cada iteración.

Fase IV: Producción

La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes

de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar
decisiones sobre la inclusión de nuevas características a la versión actual, debido a
cambios durante esta fase.

Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana. Las
ideas que han sido propuestas y las sugerencias son documentadas para su posterior
implementación (por ejemplo, durante la fase de mantenimiento).

Fase V: Mantenimiento

Mientras la primera versión se encuentra en producción, 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 después de la puesta del sistema en producción. 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 más 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. Se genera la documentación final del sistema y no se realizan
más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema
no genera los beneficios esperados por el cliente o cuando no hay presupuesto para
mantenerlo.
 1.3. SCRUM

Scrum es un proceso de desarrollo de software donde se aplican un conjunto de buenas

prácticas para trabajar colaborativamente en equipo y obtener el mejor resultado posible
de un proyecto. Se realizan entregas parciales y regulares del producto final, priorizadas
por el beneficio que aportan al receptor del proyecto. Esta especialmente indicada para
proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los
requisitos son cambiantes o poco definidos, donde la innovación, la competividad, la
flexibilidad y la productividad son fundamentales. (Proyectos agiles ORG, 2014)

1.3.1. Características:

A continuación se detallan las principales características de Scrum. Esta metodología es

la de mayor popularidad y uso actualmente en el desarrollo de software, también se ha
aplicado en otros entornos diferente al desarrollo de software con buenos resultados.

 Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y
trabaja de forma similar al director de proyecto, el ProductOwner, que representa a
los stakeholders (clientes externos o internos), y el Team que incluye a los
desarrolladores.
 Se desarrolla por etapas denominadas Sprint, aquí se trata de un periodo entre 15
y 30 días, durante el cual se crea un incremento de software potencialmente
entregable (utilizable).
 El conjunto de características que forma parte de cada sprint viene del Product
Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el
trabajo a realizar.
 Los elementos del Product Backlog que forman parte del sprint se determinan
durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner
identifica los elementos del Product Backlog que quiere ver implementados y los
hace del conocimiento del equipo.
 El equipo determina la cantidad de ese trabajo que puede comprometerse a
completar durante el siguiente sprint.
 Los clientes pueden cambiar de idea sobre lo que quieren y necesitan, y que los
desafíos impredecibles no pueden ser fácilmente enfrentados de una forma
predictiva y planificada.
 Acepta que el problema no puede ser completamente entendido o definido, y se
concentra en maximizar la capacidad del equipo de entregar rápidamente y
responder a requisitos emergentes. (Schwaber & Beedle, 2001)
 1.3.2. Roles

Al aplicar la metodoliga Scrum, no hay jefe de proyecto estas responsabilidades se

dividen entre el cliente, el scrum master y el equipo de desarrollo. En la tabla 4 se pueden
apreciar los roles involucrados en un proceso de desarrollo.

Tabla 4. Roles de Scrum

ROL DESCRIPCIÓN
Cliente (Product Owner) Puede ser interno o externo a la organización. Es el representante de
todas las personas interesadas en los resultados del proyecto, actúa
como interlocutor ante el equipo con autoridad para tomar decisiones.
Define los objetivos del producto o proyecto, dirige los resultados del
proyecto. Da prioridad a los requisitos, es el propietario de la
planificación del proyecto. Establece el calendario de entrega en
conjunto con el Scrum Master.
Al iniciar cada iteración evalúa las prioridades, re planifica el proyecto en
función de los requisitos que dan más valor al proyecto.
Debe estar disponible durante el curso de la iteración para responder a
las preguntas que puedan aparecer.
Revisa y evalúa los requisitos completados al finalizar una iteración.
Scrum Master (Facilitador) Es el encargado de liderar al equipo.
Se encarga que todo el equipo siga las reglas y el proceso de scrum.
Se asegura que la lista de requisitos esté priorizada antes de iniciar
cada iteración.
Facilita las reuniones del proceso de scrum de manera que sean
productivas y se consigan sus objetivos.
Se encarga de quitar todos los impedimentos que el equipo tenga para
poder conseguir el objetivo de cada iteración y poder finalizar el
proyecto con éxito.
Protege y aisla al equipo de interrupciones externas durante la ejecución
de la iteración, pudiendo mantener su productividad y el compromiso
que adquirió en la iteración.
Asegura que los requisitos se desarrollen con calidad.
Equipo Grupo de personas que de manera conjunta desarrollan el producto del
proyecto. El tamaño del equipo puede estar entre 5 y 9 personas. Por
encima de 9 la comunicación y colaboración entre todos los miembros
se hace más difícil y se forman subgrupos.
Comparten la responsabilidad del trabajo que realizan en cada iteración
y en el proyecto.
El equipo es autogestionado, selecciona los requerimientos que se
pueden completar en una iteración, realizando al cliente las preguntas
necesarias.
Identifican todas las tareas necesarias para completar cada requisito,
estima el esfuerzo necesario para terminar cada tarea y cada miembro
se asigna las tareas a desarrollar.
Trabaja de manera conjunta para conseguir los objetivos de la iteración.
El equipo es multidisciplinar, cada especialista lidera el trabajo en su
área y el resto colaboran si es necesario para poder completar un
requisito.
Al finalizar la iteración muestra al cliente los requisitos completados,
hace una retrospectiva para mejorar de forma continua su manera de
trabajar.
Debe depender lo mínimo de personas externas al equipo, de manera
que el compromiso que se adquiera en cada iteración se pueda cumplir.
Los miembros del equipos deben dedicarse al proyecto tiempo
completo, deben trabajar en la misma localización física, para mantener
un comunicación constante entre ellos con el fin de trabajar y resolver
problemas en conjunto evitando otros canales de comunicación que
 causen pérdida de tiempo.
El equipo debe ser estable durante la duración del proyecto, sus
miembros deben cambiar lo mínimo posible.

1.3.3. El proceso de desarrollo

El proceso de desarrollo de Scrum es iterativo e incremental, en cada iteración se realiza

una parte fundamental del sistema que se está desarrollando, el equipo de desarrollo
realiza reuniones periódicas (diarias) y cortas para discutir los asuntos del proyecto. Al
finalizar cada iteración se realiza la entrega al cliente, éste verifica la parte del producto
entregado, realiza pruebas y sugiere los cambios necesarios a realizar. Despues de
realizar los ajustes la parte del producto realizado entra a producción y se planea la
siguiente entrega, redefiniendo los requerimientos y los alcances de la siguiente iteración.

En la figura 2 se puede apreciar un gráfico tomado de (Proyectos agiles ORG, 2014).

Figura 2. El proceso de Scrum

Fuente: (Proyectos agiles ORG, 2014)

El proceso inicia con la lista de requerimientos priorizada en conjunto por el cliente y

scrum master, que actúa como el plan del proyecto. En esta lista el cliente prioriza los
objetivos balanceando el valor que aportan al producto con respecto a su costo y se
dividen en iteraciones y entregas. A continuación se detallan las fases más importantes
de scrum.

Planificación de la iteración

Esta planificación se divide en dos partes con una duración no mayor a 4 horas. En la
primera parte el cliente presenta al equipo la lista de requisitos priorizada del producto o
proyecto, pone nombre a la meta de la iteración y propone los requisitos más prioritarios a
desarrollar en ella. El equipo examina la lista, pregunta al cliente las dudas que surgen y
selecciona los requisitos más prioritarios que se compromete a completar en la iteración,
de manera que sean entregados si el cliente los solicita.

La segunda parte de la reunión el equipo planifica la iteración, el equipo organiza su

trabajo, define las tareas necesarias para poder completar cada requisito, creando la lista
de tareas de la iteración, realiza una estimación conjunta del esfuerzo necesario para
realizar cada tarea y cada miembro del equipo se asigna las tareas que puede realizar.

Sprint (Iteración)

En scrum un proyecto se ejecuta en iteraciones de duración máxima de un mes. Cada

iteración debe proporcionar un resultado completo, un incremento de producto que sea
susceptible de ser entregado con el mínimo esfuerzo cuando el cliente lo solicite. Cada
día el equipo realiza una reunión de sincronización, donde cada miembro inspecciona el
trabajo de los otros para poder hacer las adaptaciones necesarias, comentar y aclarar las
dificultades e impedimentos con que se encuentra. El scrum master se encarga de que el
equipo pueda cumplir con su compromiso y de que no se disminuya su productividad.
Elimina los obstáculos que el equipo no puede resolver por sí mismo. Protege al equipo
de interrupciones externas que puedan afectar su compromiso o su productividad. Se
deben completar primero los requisitos que dan mayor valor al cliente. No se pueden
cambiar los requisitos de la iteración en curso, esto garantiza que el cliente cumpla con su
responsabilidad de conocer qué es lo más prioritario a desarrollar antes de iniciar la
iteración.

La iteración puede ser interrumpida en situaciones muy especiales por parte del cliente o
por el equipo de desarrollo. Por ejemplo cuando el contexto del problema ha cambiado
enormemente y no es posible esperar hasta el final de la iteración para aplicar los
cambios, o si el equipo encuentra que es imposible cumplir con el compromiso adquirido.
En este caso se da por terminada la iteración y se dará inicio a otra mediante una reunión
de planificación de la iteración.

Reunión diaria de sincronización

El objetivo de esta reunión es facilitar la transferencia de información y la colaboración

entre los miembros del equipo para aumentar su productividad. Cada miembro del equipo
inspecciona el trabajo que está realizando (dependencia entre tareas, progreso hacia el
objetivo de la iteración, obstáculos que pueden impedir el objetivo) para finalizar la
reunión poder hacer los cambios necesarios que permitan cumplir con el compromiso
adquirido para la iteración. Cada equipo debe responder las siguientes preguntas:

¿Qué ha hecho desde la última reunión de sincronización? ¿Puede hacer todo lo que
tenía planeado? ¿Cuál fue el problema?

¿Qué voy a hacer a partir de este momento?

Artefactos

DYNAMIC SYSTEMS DEVELOPMENT METHOD - DSDM.

Su impulsor es Jim Highsmith. Define el marco para desarrollar un proceso de producción

de software. Nace en 1994 con el objetivo de crear una metodología RAD (Rapid
aplication development) unificada. DSDM consiste en 3 fases: fase del pre-proyecto, fase
del ciclo de vida del proyecto, y fase del post-proyecto. La fase del ciclo de vida del
proyecto se subdivide en 5 etapas: estudio de viabilidad, estudio de la empresa, iteración
del modelo funcional, diseño e iteración de la estructura, e implementación.
(Abrahamsson, Salo, Ronkainen, & Warsta, 2002)

Características:

 Es iterativo e incremental, orientado a los componentes software más que a las

tareas y tolerante a los cambios.
 Equipos de trabajo entre 2 y 6 persona.
 Pueden existir múltiples equipos de desarrollo.
 Puede ser usada en sistemas grandes, si el sistema puede ser dividido en
componentes.
 El equipo de desarrollo y el usuario trabajan juntos.
 Debe existir realimentación a todas las fases del proceso de desarrollo.

Roles

El proceso de desarrollo

Artefactos

CRYSTAL
Desarrolladas por Alistair Cockburn. Es un conjunto de metodologías caracterizadas por
estar centradas en las personas que componen el equipo y la reducción al máximo del
número de artefactos producidos. El desarrollo de software se considera un juego
cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de
desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus
habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas
políticas dependerán del tamaño del equipo, estableciéndose una clasificación por
colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).
Los colores mancan la complejidad de la metodologia y del proyecto a abordar, cuando
más crítico es un sistema, más rigor requiere. En la figura se puede apreciar una forma
tabular elaborada por Cockburn usada para identificar el rango de complejidad al cual se
aplica una metodología. En el eje Y se muestra la evaluación de las pérdidas que puede
ocasionar la falla de un sistema: C: Pérdida de confort o comodidad, D: pérdida discreta
de dinero, D: pérdida considerable de dinero y E: pérdida de vidas. En el eje x aparecen el
número de personas involucradas en un proyecto.

Fuente: (Highsmith, 2002)

Los grande proyectos requieren más coordinación y comunicación con lo que se les
asignan una metodología Crystal más compleja y completa. El código genético de Crystal
está conformado por:

El modelo económico-operativo: Lleva a las personas de un proyecto a pensar sobre su

trabajo específicamente, su enfoque y de una forma eficaz.

Selección de prioridades: Las prioridades comunes de la familia Crystal son: 1)

Seguridad en los resultados del proyecto, 2) Eficacia en el desarrollo y 3) habitualidad.

Selección de propiedades: Son 7 propiedades, las cuales son: Entrega frecuente,

comunicación intima, mejora reflexiva, seguridad personal, enfoque, acceso fácil a los
usuarios especialistas, ambiente técnico con pruebas automatizadas, administración de la
configuración e integración frecuente.
Selección de principios: Los principios son: utilice metodologías más grandes para
equipos más grandes, utilice metodologías más densas para proyectos más críticos, la
comunicación interactiva, cara a cara es la más eficaz.

Ejemplos de proyectos: Tener referencias de otros proyectos realizados con la

metodología y aprender de ellos.

De acuerdo a lo enunciado, la familia delos métodos Crystal se puede apreciar en la

siguiente figura, las cuales se dividen por código de colores El Crystal Clear es el más
pequeño y ligero. Luego amarillo, naranja, rojo, marron, azul y violeta, en ese orden según
el tamaño del grupo de trabajo.

Fuente: (crystalmethodologies.org, 2013)

Características de las Metodologías Crystal (Abrahamsson, Salo, Ronkainen, &

Warsta, 2002):

 Sugiere un ciclo de desarrollo de 4 meses.

 Hace énfasis en la comunicación.
 Permite la adopción de otros métodos ágiles.
 Permite el manejo de equipos de desarrollo de hasta 50 personas.
 No es bueno para proyectos de sistemas de vida-crítico (sistema cuyo fallo o mal
funcionamiento puede provocar: la muerte o lesiones graves a personas, o pérdida
o daños graves al equipo o daño ambiental).
 Entrega frecuente de código usable a los usuarios
 Mejora reflexiva
 Comunicación osmótica preferiblemente estando en la misma ubicación
 Seguridad personal
 Fácil acceso a los usuarios expertos
 Pruebas automatizadas, gestión de la configuración e integración frecuente.
La más exhaustivamente documentada es Crystal Clear (CC), otro método elaborado en
profundidad es el Naranja, apto para proyectos de duración estimada en 2 años.

Roles:

En crystal clear los roles más comúnmente usados se describen en la siguiente tabla.

ROL DESCRIPCIÓN
Patrocinador Produce la declaración de la misión del proyecto, los compromisos,
consigue los recursos y define la totalidad del proyecto.
Usuario Experto Junto con el experto en negocios produce la lista de actores-objetivos y
el archivo de casos de uso y requerimientos. Debe familiarizarse con el
uso del sistema, definir los modos de operación, información a manejar
y la navegación.
Diseñador – Programador senior Produce la descripción arquitectónica. Debe ser un profesional capaz de
manejar con fluidez, mezclar e inventar procedimientos. Tiene roles de
coordinador, arquitecto, mentor y programador experto.
Diseñador – Programador Produce junto con el diseñador principal, los borradores de pantallas, el
modelo del dominio, las notas y diagramas de diseño realiza el código
fuente, el código de migración, las pruebas y la distribución del sistema.
El desarrollo se realiza diseño y programo. Los programadores son
también diseñadores.
Experto en negocios Junto con el usuario experto produce la lista de actores – objetivos y el
archivo de casos de uso y requerimientos. Debe conocer las reglas y
políticas del negocio.
Coordinador Con la ayuda del equipo, produce el mapa de proyecto, el plan de
entrega, el estado del proyecto, la lista de riesgos, el plan y el estado de
la iteración y la agenda de visualización.
Verificador Produce el Reporte de Bugs. Puede ser un programador en tiempo
parcial, o un equipo de varias personas.

El proceso de desarrollo

Crystal Clear enfatiza el proceso como un conjunto de ciclos anidados. En la mayoría de

los proyectos se perciben siete ciclos: (1) el proyecto, (2) el ciclo de entrega de una
unidad, (3) la iteración (nótese que se requiere múltiples entregas por proyecto pero no
muchas iteraciones por entrega), (4) la semana laboral, (5) el período de integración, de
30 minutos a tres días, (6) el día de trabajo, (7) el episodio de desarrollo de una sección
de código, de pocos minutos a pocas horas. (Reynoso & Kicillof, 2004)

Fuente: (Reynoso & Kicillof, 2004)

Cockburn subraya que interpretar no linealmente un modelo de ciclos es difícil; la mente
se resiste a hacerlo. La figura muestra los ciclos y las actividades conectadas a ellos. Las
letras denotan C:Chartering, p:planeamiento de iteración, s: reunión diaria de pie
(standup), d:desarrollo, c: check-in, i: integración, R: taller de Reflexión, D: Entrega
(Delivery), y W: empaquetado del proyecto (Wrapup).

Artefactos:

Crystal Clear involucra unos veinte productos de trabajo o artefactos. A continuación se

detallan los más importantes. (Reynoso & Kicillof, 2004):

1. Declaración de la misión: Documento de un párrafo a una página, describiendo

el propósito.
2. Estructura del equipo: Lista de equipos y miembros.
3. Metodología: Comprende roles, estructura, proceso, productos de trabajo que
mantienen, métodos de revisión.
4. Secuencia de entrega: Declaración o diagrama de dependencia; muestra el
orden de las entregas y lo que hay en cada una.
5. Cronograma de visualización y entrega: Lista, planilla de hoja de cálculo o
herramienta de gestión de proyectos.
6. Lista de riesgos: Descripción de riesgos por orden descendente de prioridad.
7. Estatus del proyecto: Lista hitos, fecha prevista, fecha efectiva y comentarios.
8. Lista de actores-objetivos: Lista de dos columnas, planilla de hoja de cálculo,
diagrama de caso de uso o similar.
9. Casos de uso anotados: Requerimientos funcionales.
10. Archivo de requerimientos: Colección de información indicando qué se debe
construir, quiénes han de utilizarlo, de qué manera proporciona valor y qué
restricciones afectan al diseño.

ADAPTATIVE SOFTWARE DEVELOPMENT - ASD

Su impulsor es Jim Highsmith. Es iterativo, orientado a los componentes software más

que a las tareas y tolerante a los cambios. El ciclo de vida que propone tres fases
esenciales: especulación, colaboración y aprendizaje. Proporciona un marco para el
desarrollo iterativo de sistemas grandes y complejos. El método fomenta el desarrollo
iterativo e incremental con el uso de prototipos. ASD resalta que las aproximaciones
secuenciales en cascada sólo funcionan en entornos bien conocidos. Pero como los
cambios ocurren frecuentemente en el desarrollo software, es importante usar un método
tolerante a cambios. El primer ciclo de un proyecto ASD suele ser corto, asegurando que
el cliente está involucrado y confirmando la viabilidad del proyecto. Cada ciclo termina con
una revisión en grupo enfocada al cliente. Durante las reuniones de revisión, se estudia la
aplicación funcionando. El resultado de las reuniones son peticiones de cambio
documentadas. (Highsmith, 2002)

Entre las empresas que han requerido consultoría adaptativa se cuentan AS Bank de
Nueva Zelanda, CNET, GlaxoSmithKline, Landmark, Nextel, Nike, Phoenix International
Health, Thoughworks y Microsoft.

Características:

 Es iterativo
 Enfocado en el objetivo del sistema.
 Basado en características.
 Tolerante al cambio
 Mantiene el control de los riesgos

Roles

En la documentación poco se encuentra referencia a roles de ASD, en un estudio

realizado por (Riehle, 2000), en el cual realiza una comparación de las metodologías XP y
ASD, se evidencia el uso de tres roles en ASD. Los cuales se detallan a continuación.

ROL DESCRIPCIÓN
Desarrolladores Dirige y desarrolla el producto, realiza los cambios y pruebas de acuerdo
al cambio de los requerimientos y a la evolución del proyecto.
Cliente Confirma la viabilidad del proyecto. Está involucrado en todo el proceso
de desarrollo. Realiza las pruebas de aseguramiento de la calidad en la
fase de aprendizaje.
Administrador – Gerente Dirige el proceso y la creación del producto software, lo adapta a medida
que cambian los requerimientos.

El proceso de desarrollo (Highsmith, 2002)

El proceso de desarrollo de ASD es guiado por una adaptación continua, una filosofía
diferente y un diferente ciclo de vida, orientado a la aceptación de un cambio continuo
como la norma. En ASD, el ciclo de vida planear – diseñar - construir estático, es
reemplazado por un ciclo de vida Especular – Colaborar - Aprender dinámico. Se trata de
un ciclo de vida dedicado al aprendizaje continuo y orientado al cambio, reevaluando,
mirando hacia un futuro incierto, y la intensa colaboración entre los desarrolladores, la
gerencia y los clientes. (Highsmith, 2002)
Fuente: (Highsmith, 2002)

A continuación se detallan las fases principales de ASD:

Especular: Da espacio para explorar, para hacer clara la conciencia de que no estamos
seguros, para apartarse de los planes sin miedo. Esto no quiere decir que la planificación
es obsoleta, sólo que la planificación es tenue. Esto significa que tenemos que seguir las
iteraciones de entrega cortas y alentamos iteración. Un equipo que "especula" no
abandona la planificación, reconoce la realidad de la incertidumbre. La especulación
reconoce la naturaleza incierta de problemas complejos y fomenta la exploración y la
experimentación. En esta fase se define la misión del proyecto sus objetivos y las
iteraciones a realizar. También se identifican los riesgos y se define la velocidad del
equipo de desarrollo para determinar el tiempo de cada iteración. Una iteración va entre 2
y 8 semanas dependiendo de las características del proyecto, en cada iteración se define
un objetivo y una misión. Los requerimientos de cada iteración se definen con el cliente.
Cada iteración produce un producto tangible por el cliente y entrega características
fundamentales del software, las cuales son probadas por el cliente.

Colaborar: Las aplicaciones complejas no se construyen, evolucionan. Las aplicaciones

complejas requieren que un gran volumen de información que se recoge, analiza y aplica
a la solución. Un volumen grande de información que cualquier individuo puede manejar
por si solo. Aunque siempre hay espacio para mejorar, la mayoría de los desarrolladores
de software son razonablemente competentes en el análisis, programación y pruebas.
Pero en entornos turbulentos están definidas en parte por los altos índices de flujo de
información y diversos requisitos de conocimientos. En este entorno de flujo de alta
información, no es posible que una persona o un grupo pequeño "lo sabe todo," son
primordiales las habilidades de colaboración (la capacidad de trabajar de forma conjunta
para producir resultados, compartir conocimientos, o la toma de decisiones).

Aprender: Es vital para el éxito. Tenemos que probar nuestros conocimientos

constantemente, usando prácticas como retrospectivas de proyectos y grupos enfocados
al cliente. Además, las revisiones se deben hacer después de cada iteración en vez de
esperar hasta el final del proyecto. En esta fase se pretende asegurar la calidad del
producto desarrollados en cada iteración. En la misma se analizan cuatro categorías de
cosas:

 Calidad del resultado de la desde la perspectiva del cliente

 Calidad del resultado de la desde la perspectiva técnica
 El funcionamiento del equipo de desarrollo y las prácticas que este utiliza
 El status del proyecto

Artefactos:

Esta metodología exige poca documentación. En algunas ocasiones se usan las historias
de usuario, o modelos de casos de uso para especificar los requerimientos. En la revisión
de la literatura realizada se encuentra muy poca información de los artefactos usados o
requeridos por ASD.

DESVENTAJAS DEL DESARROLLO ÁGIL.

El instituto de tecnologías de la comunicación del gobierno España en su guía de

metodologías del desarrollo de software proponen una serie de desventajas en general
del desarrollo ágil, las cuales se enuncian a continuación. (INTECO, Instituto Nacional de
Tecnologías de la comunicación, 2009), citando a McBreen y Boehm y Turner.

 Con frecuencia se usa como medio de sacar dinero al cliente a través de la falta
de definición de un entregable.
 Falta de estructura y documentación necesaria.
 Sólo funciona con desarrolladores experimentados.
 Incorpora diseño de software insuficiente.
 Requiere encuentros a intervalos frecuentes con un enorme coste para los
clientes.
 Requiere demasiado cambio cultural para adaptarlo.
 Puede conducir a negociaciones contractuales más difíciles.
 Puede ser muy ineficiente, si los requisitos de un área de código cambian durante
varias iteraciones, se puede necesitar hacer la misma programación varias veces.
Mientras que si se tiene que seguir un plan, un área de código individual se
supone que sólo se va a escribir una vez.
 Imposible desarrollar estimaciones realistas del esfuerzo necesario para
proporcionar un presupuesto, porque al principio del proyecto nadie sabe el
alcance o los requisitos enteros.
 Puede aumentar el riesgo de cambios del alcance, debido a la falta de
documentación de requisitos detallada.
 El desarrollo ágil está orientado a características, los atributos de calidad no
funcionales son difícil de plasmar como historias de usuario.
Referencias:

Abrahamsson, Salo, Ronkainen, & Warsta. (2002). Agile Software Development Methods:
Review and Analysis. VTT Publications.
Abran, A., & Moore, J. W. (2004). Guide to the Software Engineering Body of Knowledge.
IEEE Computer Society.
Beck, K. (1999). Extreme Programming Explained. Embrace Change. Pearson Education.
Beck, K. (2000). Extreme Programming Explained: Embrace Change. Addison Wesley.
Beck, K., & Fowler, M. (2001). Planning Extreme Programming. Addison Wesley.
crystalmethodologies.org. (2013). Crystalmethodologies.org. Recuperado el 25 de 4 de
2014, de http://www.crystalmethodologies.org/
Cunningham, W., Medinilla, A., Giné, A., & Gómez, E. (2001). Manifesto for Agile
Software Development. Recuperado el 14 de agosto de 2010, de
http://agilemanifesto.org/
Henríquez, P., & Organista, J. (2009). Definición y estimación de tipos y niveles de uso
tecnológico: una aproximación a partir de estudiantes de recién ingreso a la
universidad. EDUTEC, Revista electrónica de tecnología educativa.
Hernandez Sampieri, R., Collado, C., & Baptista, P. (2006). Metodología de la
Investigación. Mc. Graw Hill.
Highsmith, J. (2002). Agile Software Development Ecosystems. Addison Wesley.
INTECO, Instituto Nacional de Tecnologías de la comunicación. (2009). Ingeniería del
software: Metodologías y ciclos de vida. España.
Jeffries, R. E. (2014). XProgramming.com An agile Software Development Resource.
Recuperado el 17 de 7 de 2014, de http://xprogramming.com/index.php
Letelier, P., & Penadés, M. C. (2006). Metodologías ágiles para el desarrollo de software:
eXtrema Programing (XP). Técnica Administrativa ISSN 1666-1680 Vol 5 No 26.
Maddison, R. (1983). Information System methodologies. Wiley Henden.
Proyectos agiles ORG. (2014). Proyectos agiles.org. Recuperado el 10 de 7 de 2014, de
http://www.proyectosagiles.org/
Reynoso, C., & Kicillof, N. (Abril de 2004). Métodos heterodoxos en desarrollo de
software. Recuperado el 31 de 7 de 2014, de
http://ima.udg.edu/Docencia/3105200728/SurveyMetAgil.pdf
Riehle, D. (2000). A comparison of the value systems of adaptative software development
an extreme programing: How methodologies may learn from each other.
Recuperado el 31 de 7 de 2014, de
http://mailserver.di.unipi.it/estate/Library/XP/Documents/Papers/R2000.pdf
Schwaber, K., & Beedle, M. (2001). Agile Software Development with Scrum.