Metodologías agiles

Requerimientos de software

Integrantes:
-Benjamín Ignacio Díaz Freire

P á g i n a 1 | 15
Introducción

P á g i n a 2 | 15
Contenido

P á g i n a 3 | 15
Contenido
APRENDIZAJE ESPERADO DE LA SEMANA................................................................6
Ideas clave..............................................................................................6
1. Enfoque interactivo e incremental dentro de un equipo de desarrollo según
metodología ágil
7
1.1 Beneficios....................................................................................................................................7
1.2 Restricciones...............................................................................................................................9
1.3 Recomendaciones.......................................................................................................................9
2. Metodologías ágiles de programación......................................................10
2.1 Metodología XP (Extreme Programming).................................................................................10
2.1.1 Proceso..............................................................................................................................11
2.1.2 Roles en el proceso............................................................................................................11
2.1.3 Herramientas esenciales....................................................................................................12
2.2 Metodología Scrum...................................................................................................................14
2.2.1 Proceso..............................................................................................................................15
2.2.2 Roles..................................................................................................................................16
2.2.3 Herramientas esenciales....................................................................................................16
Conclusiones...........................................................................................17
Bibliografía.............................................................................................17
Enlaces y material multimedia.........................................................................17

P á g i n a 4 | 15
Enfoque interactivo e incremental dentro de un equipo
de desarrollo según metodología ágil
Según la página Proyectos Ágiles,
destinada a la aplicación de
contenidos de proyectos agiles, el
desarrollo interactivo e incremental se
planifica en diversos bloques
temporales, llamados iteraciones. En el
caso de Scrum, estas iteraciones
pueden ser de un mes natural o hasta
de dos semanas, si así se necesita.
Dichas iteraciones se pueden
considerar como mini proyectos, ya que
en todas las iteraciones se repite un proceso similar de trabajo, que proporciona un
resultado completo sobre un producto final. Con esto, el cliente obtiene un
beneficio de un proyecto incremental. Para ello, cada requisito se debe
completar en una única iteración. El equipo de desarrollo debe realizar todas las
tareas necesarias para completarlo (incluyendo pruebas y documentación) y que
esté preparado para ser entregado al cliente con el mínimo esfuerzo necesario.
De esta manera, no se deja para el final del proyecto ninguna actividad
arriesgada relacionada con la entrega de requisitos. Un aspecto fundamental para
guiar el desarrollo iterativo e incremental es la priorización de los objetivos y
requisitos en función del valor que aportan al cliente.

1.1Beneficios
Se puede gestionar las expectativas del cliente (requisitos desarrollados,
velocidad de desarrollo, calidad) de manera regular y puede tomar decisiones en
cada iteración. Esto es especialmente interesante cuando:

- El cliente no sabe exactamente qué es lo que necesita, lo va sabiendo

conforme observa cuáles son los resultados del proyecto.
- El equipo necesita saber si lo que ha entendido es lo que el cliente espera.
- El cliente necesita hacer cambios a corto plazo (nuevos requisitos o a cambios
en los ya realizados) porque:
o Cambios en las condiciones del mercado, ya sea por un cambio de
necesidades, por un nuevo producto que ha lanzado la
competencia, urgencias, etcétera.
o La reacción y aceptación del mercado respecto al uso de los
primeros resultados del proyecto.
o Cualquier cambio en el entorno (recursos u otros) que pueda
incluso finalizar el proyecto, manteniendo como mínimo los
resultados alcanzados hasta ese momento.

P á g i n a 5 | 15
El cliente puede comenzar el proyecto con requisitos de alto nivel, quizás no del todo
completos, de manera que se vayan refinando en sucesivas iteraciones. Sólo es
necesario conocer con más detalle los requisitos de las primeras iteraciones, los que
más valor aportan. No es necesario realizar una recolección completa y
detallada de todos los requisitos antes de empezar el desarrollo del proyecto. El
cliente puede obtener resultados importantes y usables ya desde las primeras
iteraciones.

Se puede gestionar de manera natural

los cambios que van apareciendo
durante el proyecto. La finalización de
cada iteración es el lugar natural
donde el cliente puede proporcionar
su feedback tras examinar el
resultado obtenido (ver control
empírico y demostración). Con esta
información, ya es posible planificar
los cambios
necesarios para alinearse con las expectativas del cliente desde las primeras
iteraciones, de manera que al finalizar el proyecto el cliente obtenga los
objetivos esperados. El cliente como máximo puede perder los recursos
dedicados a una iteración, no los de todo el proyecto. La finalización de cada
iteración es el lugar natural donde el equipo puede decidir cómo mejorar su
proceso de trabajo, en función de la experiencia obtenida. Con esta información,
ya es posible planificar los cambios necesarios para aumentar la productividad y
calidad desde las primeras iteraciones (ver retrospectiva).

Permite conocer el progreso real del proyecto desde las primeras iteraciones y
extrapolar si su finalización es viable en la fecha prevista. El cliente puede decidir re-
priorizar los requisitos del proyecto, añadir nuevos equipos, cancelarlo, etcétera.

Permite mitigar desde el inicio los riesgos del proyecto. Desde la primera iteración el
equipo tiene que gestionar los problemas que pueden aparecer en una entrega
del proyecto. Al hacer patentes estos riesgos, es posible iniciar su mitigación de
manera anticipada.

Permite gestionar la complejidad del proyecto:

- En una iteración, sólo se trabaja en los requisitos que aportan más valor en
ese momento.
- Se puede dividir la complejidad para que cada parte sea resuelta
en diferentes iteraciones.
Dado que cada iteración debe dar como resultado requisitos terminados, se
minimiza el número de errores que se producen en el desarrollo y se aumentar
la calidad.

P á g i n a 6 | 15
1.2Restricciones
La disponibilidad del cliente debe ser alta durante todo el proyecto, dado que
participa de manera continua:

- El inicio de una iteración, el cliente ha de detallar (o haber detallado

previamente) los requisitos que se van a desarrollar.
- En la finalización de cada iteración, el cliente ha de revisar los requisitos
desarrollados.
La relación con el cliente ha de estar basada en los principios de colaboración y
ganar/ganar, más que tratarse de una relación contractual en la cual cada parte
únicamente defiende su beneficio a corto plazo.

Cada iteración debe dar como resultado requisitos terminados, de manera de

que el resultado sea realmente útil para el cliente y no deje tareas pendientes
para futuras iteraciones o para la finalización del proyecto.

Cada iteración ha de aportar un valor al cliente, entregar unos resultados

cerrados que sean susceptibles de ser utilizados por él.

Es necesario disponer de técnicas y herramientas que permitan hacer cambios

fácilmente en el producto, de manera que pueda crecer en cada iteración de
manera incremental sin hacer un gran esfuerzo adicional, manteniendo su
complejidad minimizada y su calidad.

1.3Recomendaciones
Utilizar iteraciones cortas, de dos a cuatro semanas, incrementa la productividad del
proyecto, dado que el equipo trabaja de forma más eficiente cuando tiene
objetivos a corto plazo. Asimismo, con iteraciones cortas, la precisión de las
estimaciones aumenta. El tamaño depende de:

- Los condicionantes del proyecto.

- La necesidad de obtener feedback más o menos rápido.
- Que no se degrade la relación trabajo útil o la gestión operativa (por
ejemplo, reuniones, actividades necesarias que no producen valor directo,
etcétera).

Utilizar iteraciones regulares, de manera que todas sean un timebox de la

misma duración. Esto permite que:

- El equipo aprenda a calcular la velocidad de desarrollo y la cantidad de

trabajo que puede hacer en una iteración, sin tener que hacer
extrapolaciones si las iteraciones no fuesen regulares.
- El cliente pueda proyectar cuántas iteraciones se necesita para tener cada
entrega, en función de la velocidad de desarrollo del equipo (el trabajo
que pudo completar en iteraciones anteriores del mismo tamaño) y tomar
decisiones al respecto.

P á g i n a 7 | 15
 - Permite gestionar y sincronizar de manera sencilla las necesidades del
proyecto con respecto a las de otros proyectos (integración con el trabajo
realizado por otros equipos, compartición de personas que son difíciles de
asignar a un único equipo).
- Las iteraciones, coincidiendo con meses naturales, permiten sincronizar el
trabajo del equipo con el de otros departamentos y con el resto de la
organización (por ejemplo, la organización puede tener medidas de
resultados y objetivos a nivel trimestral o cuatrimestral).

2. Metodologías ágiles de programación

2.1Metodología XP (Extreme Programming)
Es un enfoque de los procesos de ingeniería de software que tiene como objetivo
potenciar las relaciones interpersonales durante el desarrollo del software. Se
preocupa por el aprendizaje de los programadores, siendo muy importante la
retroalimentación continua entre el cliente y el equipo de desarrollo del
proyecto. Se utiliza principalmente para proyectos con requerimientos que son
cambiantes. Su metodología se encuentra descrita en el siguiente diagrama:

P á g i n a 8 | 15
2.1.1 Proceso
El proceso de la metodología XP sigue 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 uno

2.1.2 Roles en el proceso

En el proceso de la metodología XP, se identifican los siguientes roles y sus tareas:

Programadores: definen tareas a partir de las historias, escriben las pruebas unitarias
y producen el código del sistema (se requieren como mínimo 2 programadores).

Tester: ayuda en la elaboración de pruebas funcionales y apoya al cliente a

definir las historias de usuario.

Tracker: presenta una retroalimentación al equipo del proyecto, establece

prioridades, explica las historias, tiene autoridad para decidir cuestiones relativas a
las historias.

Coach: siendo el experto en XP, es el responsable del proceso global.

Cliente: escribe las historias de usuario, el proceso de negocio.

Gestor: planifica las reuniones, estable el vínculo entre los clientes y los
programadores, siendo el principal encargado del proceso de XP.

Consultor: es un miembro externo del equipo quien provee conocimientos

específicos para la elaboración del sistema.

P á g i n a 9 | 15
2.1.3 Herramientas esenciales
Historias de usuarios

Tareas de ingeniería

P á g i n a 10 | 15
Pruebas de aceptación

Pruebas Unitarias y de Aceptación

Plan de Entrega

P á g i n a 11 | 15
Código

2.2Metodología Scrum
Según Roger Pressman (2010), la metodología Scrum es un método de desarrollo
ágil de software concebido por Jeff Sutherland y su equipo de desarrollo a
principios de la década de 1990. Los principios Scrum son congruentes con el
manifiesto ágil y se utilizan para guiar actividades de desarrollo dentro de un
proceso de análisis que incorpora las siguientes actividades estructurales:
requerimientos, análisis, diseño, evolución y entrega. Dentro de cada actividad
estructural, las tareas del trabajo ocurren con un patrón del proceso llamado
sprint. El trabajo realizado dentro de un sprint (el número de éstos que requiere
cada actividad estructural variará en función de la complejidad y tamaño del
producto) se adapta al problema en cuestión y se define y con frecuencia se
modifica en tiempo real por parte del equipo Scrum.

P á g i n a 12 | 15
2.2.1 Proceso
Product backlog: conjunto de requisitos denominados historias descritos en un
lenguaje no técnico y priorizados por valor de negocio o, lo que es lo mismo, por
retorno de inversión considerando su beneficio y coste. Los requisitos y prioridades
se revisan y ajustan durante el curso del proyecto a intervalos regulares.

Sprint planning: reunión durante la cual el product owner presenta las historias del
backlog por orden de prioridad. El equipo determina la cantidad de historias que
puede comprometerse a completar en ese sprint para, en una segunda parte de
la reunión, decidir y organizar cómo lo va a conseguir.

Sprint: iteración de duración prefijada durante la cual el equipo trabaja para

convertir las historias del product backlog a las que se ha comprometido, en una
nueva versión del software totalmente operativo.

Sprint backlog: lista de las tareas necesarias para llevar a cabo las historias del sprint.

Daily sprint meeting: reunión diaria de cómo máximo 15 minutos, en la que el

equipo se sincroniza para trabajar de forma coordinada. Cada miembro comenta
que hizo el día anterior, que hará hoy y si hay impedimentos.

Demo y retrospectiva: reunión que se celebra al final del sprint y en la que el

equipo presenta las historias conseguidas mediante una demonstración del
producto. Posteriormente, en la retrospectiva, el equipo analiza qué se hizo bien,
qué procesos serían mejorables y discute acerca de cómo perfeccionarlos.

P á g i n a 13 | 15
2.2.2 Roles
Scrum master: lidera al equipo para cumplir las reglas y procesos de la
metodología. Trabaja con el propietario del producto.

Product owner (cliente): representante de los cliente. Se focaliza en la parte del

negocio y es responsable del ROI (entregar un valor superior a la inversión).

Scrum team: grupo de profesionales con conocimientos técnicos necesarios

para que desarrollen el proyecto de manera conjunta llevando a cabo las
historias a las que se comprometieron al inicio de cada sprint.

2.2.3 Herramientas esenciales

Sprint: nombre que recibe cada iteración de desarrollo. Es el núcleo central
que genera el avance por tiempos prefijados (time boxing).

Product backlog: es una lista ordenada de todo lo que podría ser necesario para el
producto y la única fuente de requerimientos para cualquier cambio a realizarse.
Contiene todas las características, funcionalidades, requerimientos, mejoras y
correcciones del producto, y otros atributos como descripción, ordenación y
estimación. Evoluciona a medida que el producto y el entorno en el que será
usado también lo hacen.

Incremento: resultado final de cada sprint.

Sprint backlog: Es la recopilación de ítems del product backlog, negociados entre el

propietario de producto y el Scrum team en la ceremonia de planificación,
reunión que se realiza al comienzo del sprint, y que el Scrum team se compromete
a construir durante el sprint en curso.

P á g i n a 14 | 15
Conclusiones
Como pudimos ver en las materias de esta semana, existen distintas
metodologías que se aplican al concepto de metodologías ágiles. Hemos visto los
distintos beneficios, restricciones y recomendaciones del enfoque interactivo e
incremental de metodologías ágiles. Las metodologías ágiles tratadas en esta
materia comparten varias características: ambas constan de sus respectivos
procesos, roles y herramientas, teniendo como objetivo primordial facilitar el
proceso de desarrollo de software.

Bibliografía
 Pressman, Roger (2010). Ingeniería de software. Un enfoque
práctico. Séptima edición. Editorial McGraw-Hill, España.
 http://davidrtmetodosagiles.blogspot.com/2017/02/comparativa-entre-xp-y-
scrum.html
 https://proyectosagiles.org/
 https://www.cerem.es/blog/cultura-agil-que-es-y-como-aplicarlo-en-la-
organizacion
 https://www.crehana.com/blog/transformacion-cultural/cultura-agil/
 https://www.computerweekly.com/es/definicion/Desarrollo-de-software-agil-
o-Agile
 https://www.redhat.com/es/devops/what-is-agile-methodology
 https://www.evaluandosoftware.com/desarrollo-software-agil/

P á g i n a 15 | 15