Metodologias Agiles en El Desarrollo de Software
-
Upload
anonymous-qrejys -
Category
Documents
-
view
43 -
download
0
description
Transcript of Metodologias Agiles en El Desarrollo de Software
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS ADMINISTRATIVAS
ANÁLISIS Y DISEÑO DE SISTEMAS
TEMA: METODOLOGÍAS ÁGILES PARA EL DESARROLLO DE
SOTFWARE
INTEGRANTES:
PITA PITA JOSÉ ALEXIS
QUIMI VERA HELLEN RUDY
RODRÍGUEZ BAQUE GUIDO
SALDAÑA TACURI JESSICA PAOLA
TORRES ZAMBRANO GETZIBA ABIGAIL
PROFESOR: HUREL RAÚL
CURSO: 5/58 ISAC
DICIEMBRE-2015
1
INDICE METODOLOGÍAS ÁGILES EN EL DESARROLLO DE SOFTWARE .......................... 3
1. INTRODUCCIÓN ............................................................................................................. 3
2. METODOLOGÍAS ÁGILES ........................................................................................... 3
2.1 El Manifiesto Ágil. ..................................................................................................... 4
2.2 Comparación .............................................................................................................. 5
3. PROGRAMACIÓN EXTREMA (EXTREME PROGRAMMING, XP) ..................... 5
3.1 Roles XP...................................................................................................................... 6
3.2 Proceso XP .................................................................................................................. 6
3.3 Prácticas XP ............................................................................................................... 7
4. SCRUM............................................................................................................................... 8
4.1 Características ........................................................................................................... 9
4.2 Herramientas y Prácticas .......................................................................................... 9
4.3 Reuniones en Scrum ................................................................................................ 12
5. Crystal Methodologies ..................................................................................................... 13
5.1 Crystal Clear ............................................................................................................ 14
5.2 Crystal Orange ......................................................................................................... 14
5.3 Orange Web ............................................................................................................. 15
5.4 Ventajas .................................................................................................................... 15
5.5 Desventajas ............................................................................................................... 15
6. Dynamic Systems Development Method (DSDM) ........................................................ 15
6.1 Características ......................................................................................................... 16
6.2 Desventajas ............................................................................................................... 16
6.3 Ventajas .................................................................................................................... 16
6.4 Roles o funciones ...................................................................................................... 16
7. Adaptive Software Development (ASD) ........................................................................ 17
8. Feature -Driven Development (FDD) ............................................................................ 17
9. Lean Development (LD) .................................................................................................. 17
CONCLUSIONES .................................................................................................................. 17
BIBLIOGRAFIA .................................................................................................................... 18
2
INDICE TABLAS
TABLA 1 DIFERENCIAS ENTRE METODOLOGÍAS ÁGILES Y NO ÁGILES . ¡Error!
Marcador no definido.
INDICE ILUSTRACIONES
Ilustración 1 Las prácticas se refuerzan entre sí ................................................................... 8
Ilustración 2 Estructura central de Scrum ............................................................................ 9
Ilustración 3 Visión general del modelo SCRUM ............................................................... 13
3
METODOLOGÍAS ÁGILES EN EL DESARROLLO DE
SOFTWARE
1. INTRODUCCIÓN
En las dos últimas décadas las notaciones de modelado y posteriormente las herramientas
pretendieron ser las "balas de plata" para el éxito en el desarrollo de software, sin embargo, las
expectativas no fueron satisfechas. Esto se debe en gran parte a que otro importante elemento,
la metodología de desarrollo, había sido postergado. De nada sirven buenas notaciones y
herramientas si no se proveen directivas para su aplicación. Así, esta década ha comenzado con
un creciente interés en metodologías de desarrollo. Hasta hace poco el proceso de desarrollo
llevaba asociada un marcado énfasis en el control del proceso mediante una rigurosa definición
de roles, actividades y artefactos, incluyendo modelado y documentación detallada. Este
esquema “tradicional” para abordar el desarrollo de software ha demostrado ser efectivo y
necesario en proyectos de gran tamaño (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 más
adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy
cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo, pero
manteniendo una alta calidad. Ante las dificultades para utilizar metodologías tradicionales con
estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a
prescindir del “buen hacer” de la ingeniería del software, asumiendo el riesgo que ello conlleva.
En este escenario, las metodologías ágiles emergen como una posible respuesta para llenar ese
vacío metodológico. Por estar especialmente orientadas para proyectos pequeños, las
metodologías ágiles constituyen una solución a medida para ese entorno, aportando una elevada
simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad
del producto.
Las metodologías ágiles son sin duda uno de los temas recientes en ingeniería de software que
están acaparando gran interés. Prueba de ello es que se están haciendo un espacio destacado en
la mayoría de conferencias y workshops celebrados en los últimos años. Es tal su impacto que
actualmente existen 4 conferencias internacionales de alto nivel y específicas sobre el tema.
Además, ya es un área con cabida en prestigiosas revistas internacionales. En la comunidad de
la ingeniería del software, se está viviendo con intensidad un debate abierto entre los partidarios
de las metodologías tradicionales (referidas peyorativamente como “metodologías pesadas”) y
aquellos que apoyan las ideas emanadas del "Manifiesto Ágil". La curiosidad que siente la
mayor parte de ingenieros de software, profesores, e incluso alumnos, sobre las metodologías
ágiles hace prever una fuerte proyección industrial. Por un lado, para muchos equipos de
desarrollo el uso de metodologías tradicionales les resulta muy lejano a su forma de trabajo
actual considerando las dificultades de su introducción e inversión asociada en formación y
herramientas. Por otro, las características de los proyectos para los cuales las metodologías
ágiles han sido especialmente pensadas se ajustan a un amplio rango de proyectos industriales
de desarrollo de software; aquellos en los cuales los equipos de desarrollo son pequeños, con
plazos reducidos, requisitos volátiles, y/o basados en nuevas tecnologías.
2. METODOLOGÍAS ÁGILES
En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término “ágil” aplicado
al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del
software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su
objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar
4
software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.
Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales,
caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de
las actividades desarrolladas.
Tras esta reunión se creó Te Agile Alliance, una organización, sin ánimo de lucro, dedicada a
promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las
organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto
Ágil, un documento que resume la filosofía “ágil”.
2.1 El Manifiesto Á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. Muchas veces se comete el error de construir primero
el entorno y esperar que el equipo se adapte automáticamente. Es mejor crear el equipo y que
éste configure su propio entorno de desarrollo en base a sus necesidades.
Desarrollar software que funciona más que conseguir una buena documentación. La regla a
seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar
una decisión importante”. Estos documentos deben ser cortos y centrarse en lo fundamental.
La colaboración con el cliente más que la negociación de un contrato. Se propone que exista
una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre
ambos será la que marque la marcha del proyecto y asegure su éxito.
Responder a los cambios más que seguir estrictamente un plan. La habilidad de responder a
los cambios que puedan surgir al largo del proyecto (cambios en los requisitos, en la tecnología,
en el equipo, etc.) determina también el éxito o fracaso del mismo. Por lo tanto, la planificación
no debe ser estricta sino flexible y abierta.
Los valores anteriores inspiran los doce principios del manifiesto. Son características que
diferencian un proceso ágil de uno tradicional. Los dos primeros principios son generales y
resumen gran parte del espíritu ágil. El resto tienen que ver con el proceso a seguir y con el
equipo de desarrollo, en cuanto metas a seguir y organización del mismo. Los principios son:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software
que le aporte un valor.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva.
III. Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible entre entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que
necesitan y confiar en ellos para conseguir finalizar el trabajo.
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.
5
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.
2.2 Comparación
La Tabla 1 recoge esquemáticamente las principales diferencias de las metodologías ágiles con
respecto a las tradicionales (“no ágiles”). Estas diferencias que afectan no sólo al proceso en sí,
sino también al contexto del equipo, así como a su organización.
Metodologías Ágiles Metodologías Tradicionales
Basadas en heurísticas provenientes de prácticas de producción de código
Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo
Especialmente preparados para cambios durante el proyecto Cierta resistencia a los cambios
Impuestas internamente (por el equipo) Impuestas externamente
Proceso menos controlado, con pocos
principios
Proceso mucho más controlado, con numerosas políticas/normas
No existe contrato tradicional o al menos es bastante flexible Existe un contrato prefijado
El cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de desarrollo mediante reuniones
Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio Grupos grandes y posiblemente distribuidos
Pocos artefactos Más artefactos
Pocos roles Más roles
Menos énfasis en la arquitectura del software La arquitectura del software es esencial y se expresa mediante modelos
Tabla 1 Diferencias entre metodologías ágiles y no ágiles
3. PROGRAMACIÓN EXTREMA (EXTREME PROGRAMMING,
XP)
XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave
para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por
el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en
realimentación continua entre el cliente y el equipo de desarrollo, comunicación 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 técnico.
6
Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí proviene su
nombre. Kent Beck, el padre de XP, describe la filosofía de XP sin cubrir los detalles técnicos
y de implantación de las prácticas. Posteriormente, otras publicaciones de experiencias se han
encargado de dicha tarea. A continuación, presentaremos las características esenciales de XP
organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prácticas.
3.1 Roles XP
Programador. El programador escribe las pruebas unitarias y produce el código del
sistema.
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.
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 prueba.
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.
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.
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.
Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el equipo
trabaje efectivamente creando las condiciones adecuadas.
3.2 Proceso XP
El ciclo de desarrollo consiste (a grandes rasgos) 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.
El ciclo de vida ideal de XP consiste de seis fases:
Exploración
Planificación de la Entrega (Release)
Iteraciones
Producción
Mantenimiento
Muerte del Proyecto
7
3.3 Prácticas XP
La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curva
exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño
evolutivo funcione. Esto se consigue gracias a las tecnologías disponibles para ayudar en el
desarrollo de software y a la aplicación disciplinada de las siguientes prácticas:
El juego de la planificación.
Hay una comunicación frecuente el cliente y los programadores. El equipo técnico realiza
una estimación del esfuerzo requerido para la implementación de las historias de usuario y los
clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración.
Entregas pequeñas.
Producir rápidamente versiones del sistema que sean operativas, aunque no cuenten con toda la
funcionalidad del sistema. Esta versión ya constituye un resultado de valor para el negocio. Una
entrega no debería tardar más 3 meses.
Metáfora.
El sistema es definido mediante una metáfora o un conjunto de metáforas compartidas por el
cliente y el equipo de desarrollo. Una metáfora es una historia compartida que describe
cómo debería funcionar el sistema (conjunto de nombres que actúen como vocabulario para
hablar sobre el dominio del problema, ayudando a la nomenclatura de clases y métodos del
sistema).
Diseño simple.
Se debe diseñar la solución más simple que pueda funcionar y ser implementada en un momento
determinado del proyecto.
Pruebas.
La producción de código está dirigida por las pruebas unitarias. Éstas son establecidas por el
cliente antes de escribirse el código y son ejecutadas constantemente ante cada modificación
del sistema.
Refactorización (Refactoring).
Es una actividad constante de reestructuración del código con el objetivo de remover
duplicación de código, mejorar su legibilidad, simplificarlo y hacerlo más flexible para facilitar
los posteriores cambios. Se mejora la estructura interna del código sin alterar su
comportamiento externo.
Programación en parejas.
Toda la producción de código debe realizarse con trabajo en parejas de programadores. Esto
conlleva ventajas implícitas (menor tasa de errores, mejor diseño, mayor satisfacción de los
programadores, …).
Propiedad colectiva del código.
Cualquier programador puede cambiar cualquier parte del código en cualquier momento.
Integración continua.
Cada pieza de código es integrada en el sistema una vez que esté lista. Así, el sistema puede
llegar a ser integrado y construido varias veces en un mismo día.
40 horas por semana. Se debe trabaja r un máximo de 40 horas por semana. No se trabajan horas
extras en dos semanas seguidas. Si esto ocurre, probablemente está ocurriendo un problema que
debe corregirse. El trabajo extra desmotiva al equipo.
Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para el equipo. Éste es uno de
los principales factores de éxito del proyecto XP. El cliente conduce constantemente el trabajo
hacia lo que aportará mayor valor de negocio y los programadores pueden resolver de manera
inmediata cualquier duda asociada. La comunicación oral es más efectiva que la escrita.
8
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 Ilustración 1, donde una línea entre dos
prácticas significa que las dos prácticas se refuerzan entre sí. La mayoría de las prácticas
propuestas por XP no son novedosas, sino que en alguna forma ya habían sido propuestas en
ingeniería del software e incluso demostrado su valor en la práctica. El mérito de XP es
integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del
negocio, los valores humanos y el trabajo en equipo.
Ilustración 1 Las prácticas se refuerzan entre sí
4. SCRUM
Scrum es una metodología ágil de desarrollo, aunque surgió como modelo para el desarrollo de
productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y
que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados
sistemas de software.
Es una metodología de desarrollo muy simple, que requiere trabajo duro porque no se basa en
el seguimiento de un plan, sino en la adaptación continua a las
circunstancias de la evolución del proyecto.
9
Scrum es una metodología ágil, y como tal:
Es un modo de desarrollo de carácter adaptable más que predictivo.
Orientado a las personas más que a los procesos.
Emplea la estructura de desarrollo ágil: incremental basada en iteraciones y revisiones.
Se comienza con la visión general del producto, especificando y dando detalle a las
funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden llevarse a cabo
en un periodo de tiempo breve (normalmente de 30 días).
Cada uno de estos periodos de desarrollo es una iteración que finaliza con la producción de un
incremento operativo del producto.
Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución a través de
reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el día anterior y el
previsto para el día siguiente.
Ilustración 2 Estructura central de Scrum
4.1 Características
Equipos autodirigidos
Utiliza reglas para crear un entorno ágil de administración de proyectos
No prescribe prácticas específicas de ingeniería
Los requerimientos se capturan como ítems de la lista Product Backlog.
El producto se construye en una serie de Sprints de un mes de duración.
4.2 Herramientas y Prácticas
Scrum no requiere ni provee prácticas de Ingeniería. En lugar de eso, especifica prácticas y
herramientas de gerencia que se aplican en sus distintas fases para evitar el caos originado por
la complejidad e imposibilidad de realizar predicciones.
Product Backlog List
Es una lista priorizada que define el trabajo que se va a realizar en el proyecto. Cuando un
proyecto comienza es muy difícil tener claro todos los requerimientos sobre el producto. Sin
embargo, suelen surgir los más importantes que casi siempre son más que suficientes para un
Sprint.
El objetivo es asegurar que el producto definido al terminar la lista es el más correcto, útil y
competitivo posible y para esto la lista debe acompañar los cambios en el entorno y el producto.
10
Existe un rol asociado con esta lista y es el de Product Owner. Si alguien quiere realizar
cualquier modificación sobre la lista, por ejemplo: agregar o incrementar la prioridad de sus
elementos tiene que convencer al Product Owner.
Sprints
Un Sprint es el procedimiento de adaptación de las cambiantes variables del entorno
(requerimientos, tiempo, recursos, conocimiento, tecnología). Son ciclos iterativos en los cuales
se desarrolla o mejora una funcionalidad para producir nuevos incrementos. Durante un Sprint
el producto es diseñado, codificado y probado. Y su arquitectura y diseño evolucionan durante
el desarrollo.
El objetivo de un Sprint debe ser expresado en pocas palabras para que sea fácil de recordar y
esté siempre presente en el equipo.
Burn down Chart
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos
en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que
conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto.
Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que
los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje
horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes
de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta
tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos
la pendiente variará o incluso valdrá cero en algunos tramos.
Sprint Backlog
Es el punto de entrada de cada Sprint. Es una lista que tiene los ítems de la Product Backlog
List que van a ser implementados en el siguiente Sprint.
Los ítems son seleccionados por el Scrum Team, el Scrum Master y el Product Owner en la
Sprint Planning Meeting a partir de la priorización de los ítems y los objetivos que se marcaron
para ese Sprint. A partir de los objetivos a cumplir durante el Sprint el Scrum Team determina
que tareas debe desempeñar para cumplir el objetivo. De esto surge el Sprint Backlog.
Stabilization Sprints
En estos Sprints el equipo se concentra en encontrar defectos, no en agregar funcionalidad.
Suelen aplicarse cuando se prepara un producto para el release. Son útiles cuando se están
realizando pruebas beta, se está introduciendo a un equipo en la metodología de Scrum o cuando
la calidad de un producto no alcanza los límites esperados.
No fueron definidos por Scrum, pero han sido recomendados por su utilidad al aplicar esta
metodología.
Scrum of Scrums o MetaScrum
Los equipos de Scrum suelen tener entre 5 y 10 personas, sin embargo, está metodología ha
sido aplicada en proyectos que involucran más de 600 personas. Esto ha sido llevado a cabo
dividiendo a los accionistas en equipos de pequeños de hasta 10 personas aproximadamente. Y
definiendo jerárquicamente personas que pertenecen a dos equipos, es decir, además de su rol
específico dentro de un equipo tienen el rol de enlace en un equipo superior.
11
Roles y responsabilidades
Scrum clasifica a todas las personas que intervienen o tienen interés en el desarrollo del
proyecto en: propietario del producto, equipo, gestor de Scrum (también Scrum Manager o
Scrum Master) y “otros interesados”.
Los tres primeros grupos (propietario, equipo y gestor) son los responsables del proyecto, los
que según la comparación siguiente (y sin connotaciones peyorativas) serían los “cerdos”;
mientras que el resto de interesados serían las gallinas.
Cerdos y gallinas.
Esta metáfora ilustra de forma muy gráfica la diferencia de implicación en el proyecto entre
ambos grupos:
Una gallina y un cerdo paseaban por la carretera.
La gallina dijo al cerdo: “Quieres abrir un restaurante conmigo”.
El cerdo consideró la propuesta y respondió: “Sí, me gustaría. ¿Y cómo lo llamaríamos?”.
La gallina respondió: “Huevos con jamón”.
El cerdo se detuvo, hizo una pausa y contestó:
“Pensándolo mejor, creo que no voy a abrir un restaurante contigo. Yo estaría realmente
comprometido, mientras que tú estarías sólo implicada”.
Roles Cerdo
Los Cerdos son los que están comprometidos con el proyecto y el proceso Scrum; ellos son los
que "ponen el jamón en el plato".
Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de
forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de
usuario, las prioriza, y las coloca en el Product Backlog.
ScrumMaster (o Facilitador)
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos
que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del
equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y
cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se
utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.
Equipo
El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas
con las habilidades transversales necesarias para realizar el trabajo (diseñador, desarrollador,
etc.).
Roles "Gallina"
Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta. Un
aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los
usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente
participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y
planear cada sprint.
12
Usuarios
Es el destinatario final del producto. Como bien lo dice la paradoja, El árbol cae en el bosque
cuando no hay nadie ¿Hace ruido? Aquí la definición sería Si el software no es usado ¿fue
alguna vez escrito?
Stakeholders (Clientes, Proveedores).
Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el
beneficio acordado que lo justifica. Sólo participan directamente durante las revisiones del
sprint.
Managers
Es la gente que establece el ambiente para el desarrollo del producto.
4.3 Reuniones en Scrum
Daily Scrum
Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily
standup". El scrum tiene unas guías específicas:
La reunión comienza puntualmente a su hora. A menudo hay castigos -acordados por el
equipo- para quién llega tarde (por ejemplo: dinero, flexiones, llevar colgando una
gallina de plástico del cuello, etc.)
Todos son bienvenidos, pero solo los "cerdos" pueden hablar.
La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño
del equipo.
Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
Durante la reunión, cada miembro del equipo contesta a tres preguntas:
¿Qué has hecho desde ayer?
¿Qué es lo que estás planeando hacer hoy?
¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del
ScrumMaster recordar estos impedimentos).
Scrum de Scrum
Cada día normalmente después del “Daily Scrum”
Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocándose
especialmente en áreas de solapamiento e integración.
Asiste una persona asignada por cada equipo.
La agenda será la misma como del Daily Scrum, además de las siguientes cuatro preguntas:
¿Qué ha hecho tu equipo desde nuestra última reunión?
¿Qué hará tu equipo antes que nos volvamos a reunir?
¿Hay algo que demora o estorba a tu equipo?
¿Estás a punto de poner algo en el camino del otro equipo?
Reunión de Planificación del Sprint (Sprint Planning Meeting)
Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del Sprint” se lleva
a cabo.
Seleccionar que trabajo se hará
Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomara
hacer el trabajo.
13
Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual
Sprint
Ocho horas como limite
Al final del ciclo Sprint, dos reuniones se llevarán a cabo: la “Reunión de Revisión del Sprint”
y la “Retrospectiva del Sprint”
Reunión de Revisión del Sprint (Sprint Review Meeting)
Revisar el trabajo que fue completado y no completado
Presentar el trabajo completado a los interesados (alias “demo”)
El trabajo incompleto no puede ser demostrado
Cuatro horas como límite
Retrospectiva del Sprint (Sprint Retrospective)
Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los
miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la
retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de
cuatro horas.
Ilustración 3 Visión general del modelo SCRUM
5. Crystal Methodologies
Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar
centradas en las personas que componen el equipo y la reducción al máximo del número de
artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software
se considera un juego cooperativo de invención y comunicación, limitado por los recursos a
utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en
mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas.
Estas políticas 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).
14
Dependiendo de la cantidad de desarrolladores involucrados, el bienestar de los mismos, el
ciclo de vida del desarrollo del proyecto, el presupuesto monetario imprescindible y el
presupuesto de uso opcional Crystal Methodologies es capaz de clasificarse mediante los
siguientes colores que determinan las metodologías incluidas dentro de las metodologías
Crystal:
Crystal Clear
Crystal Yellow
Crystal Orange
Crystal Orange Web
Crystal Red
Crystal Magenta
Crystal Blue
Aunque solamente tres de ellos han sido realmente construidos y son usados en proyectos
empresariales, institucionales etc.
5.1 Crystal Clear
Esta denotación está diseñada para grupos o equipos de desarrollo de uno a seis desarrolladores
que trabajen en una misma oficina u oficinas adyacentes y en donde el proyecto que se lleve a
cabo no sea de gran envergadura o con grandes dificultades para su desarrollo. La misma cuenta
con cuatro roles principales:
Patrocinador o ejecutivo que costee el proyecto
Diseñador-programador líder
Diseñador-programador
Cliente (que estaría la menor parte del tiempo en el desarrollo del proyecto).
Esta caracterizado por tener libertades en cuanto a la modelación de los casos de uso,
calendarios de visitas con el cliente, creación de borradores etc. que atrasarían la entrega de un
producto no complejo, aunque si recomienda la política estándar de entregas incrementales al
cliente, así como las pruebas convenientes del producto.
5.2 Crystal Orange
Puede incluir hasta 40 desarrolladores que sus respectivos locales residan en el mismo edificio
y que estarían trabajando en un proyecto que por momentos puede estar haciéndole perder al
equipo presupuesto de uso opcional. Está diseñado para sistemas de tamaño o complejidad
media. Los roles que participan en esta sección de la metodología son:
Patrocinador o ejecutivo que costee el proyecto
Experto en negocios
Experto en usos técnicos
Analista/diseñador de negocios
Gerente del proyecto
Arquitecto de software
Diseñador líder
Programador líder
15
Otros diseñadores-programadores
Diseñador de interfaz de usuario
“Reuse point”
Escritor de código
Probador
Estos roles están organizados en equipos denotados como: equipo de planificación del sistema,
monitoreo del proyecto, tecnología, infraestructura, y pruebas externas.
El producto debe estar dotado de documentación, liberación de secuencias, calendarios,
reportes de estado del proyecto, documentación de la interfaz de usuario, modelo común de
objetos (diseño de clases, bases de datos etc.), manual de usuario, código fuente, casos de
prueba y código de migración en caso de existir.
5.3 Orange Web
Esta metodología tiene como diferencia de la anterior que está diseñada para proyectos que
estén sometidos a cambios continuos debido a que son usados por el cliente, según su creador
(2003) esta metodología se encuentra en prueba, y presenta alrededor de 50 roles divididos en
ejecutivos, gente de negocios, gerentes, analistas, programadores, y probadores. Comparado
con Crystal Orange presenta menos proyectos debido a que generalmente se dedican a uno solo
con actualización de versiones.
5.4 Ventajas
Son apropiadas para entornos ligeros
Al estar diseñada para el cambio experimenta reducción de costo.
Presenta una planificación más transparente para los clientes.
Se definen en cada iteración cuales son los objetivos de la siguiente.
Permite tener una muy útil realimentación de los usuarios.
5.5 Desventajas
Delimita el alcance del proyecto con el cliente.
6. Dynamic Systems Development Method (DSDM)
El método de desarrollo de sistemas dinámicos (en inglés Dynamic Systems Development
Method o DSDM) Nace en 1994 con el objetivo de crear una metodología RAD unificada y es
un método que provee un framework para el desarrollo ágil de software, apoyado por su
continua implicación del usuario en un desarrollo iterativo y creciente que sea sensible a los
requerimientos cambiantes, para desarrollar un sistema que reúna las necesidades de la empresa
en tiempo y presupuesto.
La metodológica DSDM es caracterizada por su rapidez de desarrollo atendiendo a las
demandas de tecnología de forma eficaz y eficiente previendo que transcurra mucho tiempo y
la tecnología cambie.
Es una metodología ágil situada dentro de las RAD (rapid aplication development), es ideal
para proyectos de sistemas de información cuyos presupuestos y agendas son muy apretadas.
16
6.1 Características
Trabajo en equipo tanto los desarrolladores, los usuarios y los Stakeholders.
El equipo de desarrollo puede tomar sus decisiones sin depender de autorizaciones de
sus superiores.
El desarrollo es iterativo e incremental.
El equipo de desarrollo debe realizar entregas cortas, pero frecuentemente, estas
entregas deben ser funcionales.
Todos los cambios pueden ser reversibles, es decir, debemos tener una línea base y a
partir de ella crear funcionalidad, pero si no tenemos los resultados deseados podemos
regresar a la línea base nuevamente.
La verificación de calidad debe existir a lo largo del proceso de desarrollo y no
solamente en al final del proyecto.
6.2 Desventajas
Ningún sistema es construido a la perfección en el primer intento.
La entrega del proyecto deberá ser a tiempo, respetando presupuesto y asegurando la
calidad.
DSDM solo quiere que se complete la iteración con la funcionalidad suficiente como
para que inicie la siguiente iteración.
DSDM es utilizado en sistemas TI, pero también pudiera ser utilizado para proyectos
en donde se requiera cambio de algún sistema, aunque no sea TI.
La evaluación de riesgo debe estar enfocada en entregar funcionalidad no en el proceso
de desarrollo.
La estimación debe estar basada en funcionalidad del negocio.
6.3 Ventajas
Tiempo
Dinero(presupuesto)
Desarrollo Iterativo
Concesión de requisitos
Participación
6.4 Roles o funciones
Patrocinador ejecutivo (fondos y recursos)
Visionario (inicializa y mantiene)
Embajador de usuario (conocimiento de UF)
Asesor de usuario (ideas diarias UF)
Gerente del proyecto(gestiona)
Coordinador Técnico (diseño y calidad)
Jefe de equipo (mantener)
Escribano (registra decisiones, acuerdos o requisitos)
Roles de Especialistas (Personas Esp. de Apoyo)
17
7. Adaptive Software Development (ASD)
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.
8. Feature -Driven Development (FDD)
Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2
semanas). Se centra en las fases de diseño e implementación del sistema partiendo de una
lista de características que debe reunir el software. Sus impulsores son Jeff De Luca y Peter
Coad.
9. Lean Development (LD)
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.
CONCLUSIONES
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. Sin embargo, hay que
tener presente una serie de inconvenientes y restricciones para su aplicación, tales como:
están dirigidas a equipos pequeños o medianos (Beck sugiere que el tamaño de los equipos se
limite de 3 a 20 como máximo, otros dicen no más de 10 participantes), el entorno físico debe
ser un ambiente que permita la comunicación y colaboración entre todos los miembros del
equipo durante todo el tiempo, cualquier resistencia del cliente o del equipo de desarrollo hacia
las prácticas y principios puede llevar al proceso al fracaso (el clima de trabajo, la colaboración
y la relación contractual son claves), el uso de tecnologías que no tengan un ciclo rápido de
realimentación o que no soporten fácilmente el cambio , etc.
18
BIBLIOGRAFIA Abrahamsson, P., Salo, O., Ronkain en, J., Warsta, J. “Agile software development
methods Review and analysis”. VTT Publications. 2002.
Beck, K. “Extreme Programming Explained. Embrace Change”, Pearson Education,
1999. Traducido al español como: “Una explicación de la programación extrema.
Aceptar el cambio”, Addison Wesley, 2000.
Coad P., Lefebvre E., De Luca J. “Java Modeling In Color With UML: Enterprise
Components and Process”. Prentice Hall. 1999.
Cockbun, A. “Agile Software Development”. Addison-Wesley. 2001.
Fowler, M., Beck, K., Brant, J. “Refactoring: Improving the Design of Existing Code”.
Addison-Wesley. 1999
Highsmith J., Orr K. “Adaptive Software Development: A Collaborative Approach to
Managing Complex Systems”. Dorset House. 2000.
effries, R., Anderson, A., Hendrickson, C. “Extreme Programming Installed”. Addison-
Wesley. 2001
Poppendieck M., Poppendieck T. “Lean Software Development: An Agile Toolkit for
Software Development. Managers”. Addison Wesley. 2003.
Schwaber K., Beedle M., Martin R.C. “Agile Software Development with SCRUM”.
Prentice Hall. 2001.
Stapleton J. “Dsdm Dynamic Systems Development Method: The Method in Practice”.
Addison-Wesley. 1997.
https://procesosdesoftware.wikispaces.com/METODOLOGIA+SCRUM
https://prezi.com/qxjk5edz-nj4/metodologia-agil-dynamic-system-development-
method-dsdm/
http://www.ecured.cu/Crystal