miércoles, 4 de octubre de 2023

INGENIERIA DEL PROCESO SOFTWARE

Tema 2: Desarrollo de software ágil

Metodologías Ágiles: Valores y Principios

MANIFIESTO ÁGIL

Toda metodología ágil así como su aplicación debe cumplirlo. Consta de 4

valores y 12 principios

Valores

Individuals and interactions over processes and tools (personas e interacciones por
encima de procesos y herramientas).

Son esenciales para los equipos de alto rendimiento. Si se gestionan

personas como componentes y no se trata a personas como individuos se reduce
la motivación, se baja la productividad y la gente buena se va. Se logra aumentando
la comunicación.

El comportamiento de los miembros del equipo debe centrarse en el respeto,

la transparencia, la con anza y el compromiso con el equipo y sus objetivos.

El con icto positivo consiste en generar una lista de problemas en la

organización, enfrentarse a ellos y eliminarlos sistemáticamente en orden de
prioridad. El n es crear un comportamiento productivo, mejorar el proceso, innovar
y alinear el equipo hacia un objetivo común al que se compromete.

Working software over comprehensive documentation (Software funcional por

encima de su documentación).

Si el software no funciona los documentos no sirven de nada. Solo se debe

realizar la documentación interna necesaria, y la externa toda la que pida el cliente.
Si el Software funciona el producto está terminado.

Customer collaboration over contract negotiation (colaboración del cliente por

encima de negociación por contrato).

1
fi
fl
fi
 El cliente debe proporcionar comentarios sobre el software que funciona a
intervalos regulares. Un representante del cliente (product owner) trabaja mano a
mano con el equipo de desarrollo.

Responding to change over following a plan (responder al cambia por encima de

seguir un plan).

Más del 60% de los requisitos de producto o de proyecto cambian durante el

desarrollo de software. Los clientes no saben lo que desean hasta que ven el
software que funciona. Por tanto si el proyecto no es capaz de adaptarse a los
cambios fracasa. El Desarrollo Adaptativo consiste en satisfacer los requisitos del
cliente y adquirir un valor comercial.

12 Principios

1. La prioridad principal es satisfacer al cliente mediante tempranas y continuas

entregas de software utilizable

2. Dar la bienvenida a los cambios. Los procesos ágiles aplican los cambios para
que el cliente sea competitivo.

3. Entregar el software desarrollado frecuentemente con el menor intervalo posible

entre una entrega y la siguiente.

4. La gente de negocios y los desarrolladores trabajan juntos a través dude un

proyecto.

5. Construir proyecto empujados por motivaciones personales. Dar el entorno que

necesitan las personas y con ar en ellos.

6. El diálogo cara a cara es el método más e ciente y efectivo para comunicar

información dentro de un equipo de desarrollo.

7. Desarrollar software es la primera medida de progreso.

8. Los procesos ágiles promueven un desarrollo llevadero. Los patrocinadores,

desarrolladores y usuarios son capaces de mantener una paz constante.

9. La atención continua a la calidad técnica y al buen diseño incrementa la

agilidad.

10. La simplicidad es esencial.

11. Las mejores arquitecturas, requisitos y diseños surgen de la propia organización

del equipo.

2
fi
fi
 12. En intervalos regulares, el equipo re exiona en cómo llegar a ser más efectivo,
sincronizar y ajustar su comportamiento.

PRÁCTICAS ÁGILES

Sobre desarrollo software

- Pequeñas y frecuentes versiones: ciclo de vida increméntale y evolutivo. Al nal
de cada ciclo se valida el producto por parte del cliente.
- Plani cación conjunta: recopilación informal de requisitos (se pregunta al cliente
lo que quiere). Estimación inicial de los requisitos recopilados. Priorización de los
requisitos. Selección de los requisitos más importantes para formar versiones
parciales pero completa funcionalmente (constituyen una entrega). Se revisa
después de cada versión.
- Diseño sencillo: desarrollar la solución más sencilla que cumpla las
especi caciones, solo de los requisitos actuales, es mejor no predecir
necesidades futuras.
- Claridad: utilizar símiles o metáforas que ayuden a entender la arquitectura
básica del sistema.
- Accesibilidad del cliente: siempre disponible para clari car y validar los
requisitos.

Sobre código.
- Estandarización: el código desarrollado debe ser entendido por todo el equipo
- Repositorio común: el código pertenece al equipo y es compartido.
- Revisión continua: el código se revisa continuamente para mejorar su estructura.
- Integración continua: el repositorio común contiene las últimas versiones del
código.

Sobre pruebas
- Test unitario: automático y exhaustivo. Tiene que ser previo a la creación del
código y se deben superar toda los tests para que un módulo de código se
considere válido.
- Test de aceptación: garantiza que el sistema proporciona la funcionalidad
requerida. Mide que el proyecto progresa adecuadamente.

3
fi
fi
fl
fi
fi
Sobre la forma de trabajo
- Programación en parejas: colaboración entre miembros del equipo.
- No hacer horas extras.
- Áreas de trabajo abiertas y comunes
- Roles: los miembros del equipo tienen distintos roles según su responsabilidad-

METODOLOGÍAS ÁGILES

Extreme Programming (XP)

Filosofía y prácticas:
- Historias de Usuario.
- Equipos de 5 a 10 personas. Propiedad
colectiva del programa, la programación es en parejas
- Los espacios de trabajo son abiertos. Las semanas son de 40 horas.
- El cliente está presente durante el proceso (o un representante).
- Diseño y arquitectura incremental. Diseños sencillos.
- Pequeñas entregas y versiones
- Pruebas: pruebas unitarias, integración continua.
- Desarrollo: siguiendo los estándares de programación y en iteraciones cortas.
Roles:
- Programador
- Cliente
- Encargado de pruebas
- Tracker
- Entrenador
- Consultor
- Jefe del proyecto

4
 Scrum

Dentro del equipo hay un Product Owner que representa al cliente y un

Scrum Master. El equipo se reúne para plani car los sprints y organizarlo de manera
que cada sprint dura de 2 a 4 semanas, durante las cuales hay reuniones diarias. Al
nalizar cada sprint se evalúa y se pone en retrospectiva y se presenta un producto
funcional.

Lean Software Development

Surge del sistema de producción de Toyota. Está basado en un conjunto de

principios económicos y matemáticos que describen el ujo de información del
product dentro de la empresa. Proporciona un amplio framework económico y de
desarrollo. Sus principios son la calidad, el bajo coste y la velocidad:

1. Eliminar el gasto

2. Incrementar el aprendizaje

3. Postergar las decisiones: no tomar decisiones si no es sobre seguro.

4. Entregar lo antes posible.

5. Fortalecer el equipo.

6. Incorporar integración.

7. Perspectiva amplia, ver todo el proyecto en conjunto.

Cadena de valor de la entrega de software:

Entender las necesidades del cliente > Formular los requisitos de la solución >
Trabajar en el desarrollo de la solución > Construir y probar la solución > Entrega al
cliente.

Kanban

Es una forma de plani car y gestionar el trabajo software que se base en la

idea de que el trabajo en curso (WIP, Work InProgress) debería limitarse, y solo
deberíamos empezar algo nuevo cuando un bloque de trabajo anterior haya sido
entregado o haya pasado a otra función posterior de la cadena.

El Kanban implica que se genera una señal visual para indicar que hay
nuevos bloques de trabajo que pueden ser comenzados porque el trabajo en curso
actual no alcanza el máximo acordado.

5
fi
fi
fi
fl
Características:
- Visualizar bloques de trabajo y el ujo de trabajo.
- Gestión y abordar las unidades de valor limitando el trabajo en curso para que
sea sostenible y detectando los cuellos de botella.
- Medior y optimizar el ujo de trabajo.
- Mecanismo soporte donde añadir y quitar trabajo
- No establece roles.

Test-Driven Development (TDD)

Desarrollo Software orientado a pruebas. El test se escribe antes que el

código fuente. Los ciclos son muy cortos.

Características del proceso de desarrollo:

- Mantener un juego exhaustivo de pruebas del programador.
- Todo código que pasa a producción tiene sus pruebas asociadas.
- Escribir las pruebas primero, las pruebas determinan el código que hay que
escribir.

Niveles de aplicación:

1. Iteración o Funcional: El usuario especi ca pruebas antes que las

funcionalidades sean implementadas. Una vez que el código está escrito la
prueba sirve como criterio de aceptación.

2. Micro-iteraciones: Guiado por pruebas unitarias escritas por el programador.

Pasos:
- Rápidamente agregar una prueba.
- Ejecutar todas las pruebas y comprobar que solo la nueva falla.
- Hacer un pequeño cambio.
- Ejecutar todas las pruebas y comprobar que pasan satisfactoriamente.
- Refactorizar para eliminar duplicados.

6
fl
fl
fi
 Scrum
Bases: exibilidad, adaptabilidad y productividad

Es un método de gestión para procesos de desarrollo de sistemas. No

propone ninguna técnica de desarrollo de software en particular. De ne como ha de
trabajar un equipo para producir trabajo de calidad en un entorno cambiante.

Características
- Ayuda a las personas, equipos y organizaciones a generar valor a través de
soluciones adaptables para problemas complejos.
- Es simple y deliberadamente incompleto, de niendo solo las partes necesarias.
- Permite emplear diversos procesos, técnicas y métodos.
- Emplea un enfoque iterativo e incremental para optimizar la previsibilidad y
controlar el riesgo.
- Involucra a grupos de personas que colectivamente tienen todas las habilidades
y experiencia para hacer el trabajo y compartir o adquirir tales habilidades según
sea necesario.

Valores personales
- Apertura
- Enfoque
- Coraje
- Respeto
- Compromiso
Equipos
- Multidisciplinar
- Pequeño: de 5 a 10 personas
- Auto-organizado: los miembros del equipo se organizan entre ellos.
- Auto-gestionado: el proyecto lo gestionan los propios miembros del equipo.

7
fl
fi
fi
 ROLES

Roles del proyecto

- Stakeholders: usurarios nales, cliente, etc. Gerentes
- Equipo Scrum: miembros del equipo.
Roles del equipo Scrum

Scrum prescribe 3 roles para sus equipos

- Product Owner: consolida las necesidades de los usuarios, stakeholders y otras
partes interesadas para crear una visión única y priorízala de los requisitos del
sistema. De ne las características del producto, decide fechas de entregarles y
contenidos del mismo. Su función es priorizar las características de acuerdo al
valor del mercado y si es necesario ajustar funcionalidades y prioridades en cada
iteración.

Su responsabilidad es tener una visión del producto, entregas y sprint,

respetar las estimaciones del equipo y mantener la comunicación. También de los
bene cios del producto y su coste.
- Scrum master: representa a la gestión del proyecto. Es el propietario de la
implementación del método. Es el líder del equipo pero no es jefe del proyecto y
no toma decisiones.

Es el responsable de promover los valores y prácticas de Scrum. Se asegura

de que el equipo es completamente funcional y productivo. Es el escudo del equipo
ante interferencias externas. Puede ser un rol de tiempo completo o parcial (puede
actuar como otro miembro del equipo.

Es el encargado de fomentar un entorno donde: el product owner ordena el

trabajo de un problema complejo en el product Backlog. El equipo de Scrum
convierte una selección del trabajo en un incremento de valor durante un Sprint. El
equipo y sus partes interesadas inspeccionan los resultados y realizan los ajustes
necesarios para el próximo Sprint.

El per l del scrum master es de una persona que confíe en el éxito del
proyecto, que tenga autoridad, que conozca perfectamente el entorno del negocio,
del cliente, las necesidades y el objetivo, que tenga las atribuciones su cientes para
tomar las decisiones necesarias durante el desarrollo
- Desarrolladores: su papel es cumplir con el sprint. Realizar estimaciones,
plani car su propio trabajo, tener la autoridad de realizar cualquier cosa
necesaria para conseguir el objetivo. Se compromete con el product owner en las
tareas a realizar y al nal de la iteración le muestran el resultado.

8
fi
fi
fi
fi
fi
fi
fi
 Como equipo responden en sus conjunto. Trabajan de forma cohesionada y
auto-organizada. No hay un gestor que delimita, asigna y coordina las tarea, esto es
una función de los propios miembros del equipo.

Sus responsabilidades son seleccionar el rol objetivo de la iteración.

Determinar los resultados de trabajo. Hacer todo lo necesario para alcanzar el
objetivo de la iteración. Realizar demostraciones del resultado del trabajo ante el
product owner y los stakeholders.

Se respetan las opiniones y aportaciones de todos. Todos conocen la

metodolog a de trabajo con Scrum. El desarrollo es superpuesto, en lugar de una
cosa detrás de otra los equipos Scrum hacen un poco de todo todo el tiempo.

PRIMERA ACTIVIDAD SCRUM

Product Backlog

En el inicio del proceso scrum se organiza una reunión de plani cación de la

que se obtiene el objetivo del producto y el product backlog. La plani cación es
conjunta, sencilla y clara. Los requisitos del producto software se describen en
términos de Historias de Usuario.

La plani cación ágil establece un conjunto expectativas base del proyecto.

Soporta el proceso de toma de decisiones y facilita la comunicación. Entre sus
ventajas reduce riesgos y da un mejor soporte a la toma de decisiones.

Se prioriza la plani caci n como actividad frente al propio plan

• El plan est sujeto a cambios.

• La tarea de plani caci n se realiza a lo largo de todo el proyecto.

• Se plani ca en base a caracter sticas (unidad de valor para el cliente).

• La mejor forma de vencer la incertidumbre es iterando.

Épicas, Features e Historias de Usuario

Épicas

Son visionarias. Proporcionan un valor competitivo de mercado. Su

desarrollo lleva bastante tiempo. Afectan a todo el producto desde un punto de
vista arquitectónico. Implican rediseñar, refactorizar o extender la arquitectura.

Features

Son características del sistemas. Se ha de explicar su bene cio.

9
fi
í
á
fi
fi
fi
ó
ó
í
fi
fi
fi
 Historias de usuario

Representan una forma de describir los requisitos de usuario. Se identi can

por funcionalidad, no por tareas. Indican mediante frases simples lo que tiene que
hacer el sistema desde el punto de vista del usuario. Se centran en describir el qué
y no el cómo. Las tareas son parte de las historias de usuario que no se entregan al
dueño del producto.

Los tres componentes básicos que se utilizan para su elaboración son:

- Tarjetas: donde se describe la historia de usuario.
- Conversaciones: diálogo que representa las acciones que se realizan, la
información intercambiada y cualquier otra referencia que se considere de
utilidad.
- Con rmaciones: criterios de aceptación que se utilizarán para con rmar que la
historia se ha completado.

Campos que las describen:

- Id: tienen un identi cador único.
- Nombre: título de la historia.
- Descripción de la funcionalidad: Como <rol de usuario>, quiero <funci n del
sistema> para poder <valor de negocio>.
- Prioridad: importancia asignada.
- Estimación: esfuerzo estimado.
- Conversaciones sobre la historia: a modo de anotaciones se incluye la
explicación del usuario al desarrollador sobre lo que quiere y los detalles de la
funcionalidad.
- Pruebas: descripci n de las pruebas de aceptaci n. Descripci n a alto nivel de
c mo se demostrar la historia al nal del Sprint. Sirven de documentaci n.

Modelo INVEST

• Independent: Una historia de usuario no deben depender de otras, ya que

compromete la plani caci n.

• Negotiable: Los detalles de una historia de usuario se obtienen de la

conversaci n. El contenido es adaptable.

• Valuable: Una historia de usuario tiene valor para el cliente o el usuario.

10
ó
fi
ó
fi
ó
á
fi
ó
fi
ó
ó
fi
ó
ó
fi
 • Estimable: Es posible determinar el tama o de una historia de usuario, as como
priorizarla respecto a otras.

• Small: El desarrollo de una historia de usuario no debe tener una duraci n no

superior a 1 semana y 2 3 tres personas por US.

• Testable: Una historia de usuario se puede probar.

Las 5 W’s

• Who: qui n hace la acci n

• What: que es lo que se va a hacer

• When: cuando se va a hacer

• Where: en qu parte de la aplicaci n/sistema

• Why: por qu se quiere hacer.

Historias técnicas

Incluyen requisitos no funcionales. No son de valor para el cliente.

Representan trabajo que debe hacerse pero no están relacionadas con ninguna
historia funcional especí ca. Hay que evitarlas integrándolas dentro de historias de
usuario.

Priorización

Inicialmente se crea un listado de historias de usuario y posteriormente se

ordenan. El product owner debe de nir el producto y priorizar las listas de usuario.
El scrum team se encarga de la estimación.

La lista nunca llega a ser completa y de nitiva, si no que es dinámica, se

incorporan constantemente las necesidades del sistema, se rede ne y mantiene
durante todo el ciclo de vida del sistema.

La priorización debe involucrar a todo el equipo. Se prioriza por valor y

riesgo de implementación. El producto debe ser útil desde el principio. Para
realizarla existen una serie de técnicas
- Moscow: se clasi can las historias en 4 categorías.
• M – MUST have this (non-negotiable)

• S – SHOULD have this if at all possible

• C – COULD have this if it does not a ect anything else

11
é
é
é
fi
fi
ó
ó
ó
fi
ñ
ff
fi
fi
í
ó
 • W – WON’T have this time but WOULD like in the future (muy importante)
- Silent Priorization: consta de un preparación y tres rondas
- Preparación: preparar un tablon con las columnas que representan prioridad,
poner todas las historias visibles sobre una super cie
- Ronda 1: Cada persona toma una historia y sin hablar con nadie, la ubica en la
categor a que considere.
- Ronda 2: Cada miembro examina la clasi cación y puede hacer movimientos.
Si hay historias sobre las que no hay acuerdo se retiran.
- Ronda 3: El equipo habla sobre las historias apartadas.
- Dot Voting: es una técnica que utiliza marcas para identi car las historias más
importantes. Cada participante dispone de un número de votos que tiene que
distribuir. El número de votos depende del participante y del número de
elementos a seleccionar.

SPRINT

Es un periodo de tiempo durante el que se desarrolla un incremento de

funcionalidad. El producto es dise ado, codi cado y probado durante el Sprint. En
cada iteración se entrega un producto al cliente. La duración típica es de 2 a 4
semanas y la máxima es de 1 mes.

Durante el sprint no se puede modi car el trabajo que se ha acordado en el

Backlog. Solo es posible cambiar el curso de un sprint si el Scrum Master lo aborta
por una razón concreta.

De nición de DONE : Descripci n formal del estado del Incremento cuando cumple
con las medidas de calidad requeridas para el producto.

Sprint Planning

Se hace una reunión de plani cación de la iteración, en la que se seleccionan

historial de usuario para de nir el working product y construir el sprint backlog y se
de ne el objetivo del sprint.

En la plani cación de la duración del sprint se tiene en cuenta el tiempo que

se compromete el Product Owner a no introducir cambios en el sprint. La
recomendación es experimentar en las primeras iteraciones para lograr un equilibrio
entre las ventajas de trabajar en sprints más largos o más cortos.

12
fi
fi
í
fi
fi
ó
ñ
fi
fi
fi
fi
fi
fi
 En la reunión se seleccionan las historias del product backlog a partir de la
estimación. Se establece cuándo y dónde se van a hacer las daily meetings. Se
establece cuando realizar la revisión y retrospectiva del sprint.

En esta reunión participan el product owner, scrum master y el equipo. El

product owner indica el objetivo del sprint, reprioriza si es necesario las historias de
usuario más importantes del product backlog, establece cu ndo realizar la revisi n
y retrospectiva del sprint. El equipo scrum reestima las historias y las modi ca si
fuera necesario.

ESTIMACIÓN

En cuanto a la estimación. Todos los integrantes deben participar en ella y

entender el problema para cada historia de usuario. La estimación se ha de realizar
considerando que la historia de usuario es la única cosa en la que se va a trabajar,
todo lo necesario para comenzar a desarrollar está listo y no va a haber
interrupciones.

Para de nir la unidad de estimación del SP (Story Points) se debe de nir su

valor. Pueden ser días ideales o esfuerzo.

Un día ideal es un día de 100% de producción de trabajo (1SP= 1 día ideal).

Si la medida elegida es el esfuerzo los SP representan el esfuerzo de desarrollo en
base a su complejidad, di cultad, riesgo. Se elige una historia de usuario de
referencia/medida para estimar. El resto de historias se estiman usando como
referencia de esfuerzo la historia de usuario inicial.

Técnicas de estimación
- T-shirt: es la base del silent priorization pero no es en silencio. Cada tamaño de
camiseta representa unos SP.
- Poker Game: todos los miembros del equipo tienen cartas de estimaci n. El
Scrum master lee la descripci n de la historia de usuario. Todos a la vez
muestran las cartas. Si hay discordancias los votantes explican sus puntos de
vista. Se repite el proceso hasta que converge.

Si la estimaci n es compleja hay que aumentar la realimentaci n: revisi n peri dica

de las estimaciones, Iteraciones cortas. Estimar s lo las actividades cercanas.
Invertir m s esfuerzos de estimaci n en las historias con mayor prioridad.

13
á
ó
fi
fi
ó
ó
ó
á
ó
ó
ó
fi
fi
ó
ó
 Cálculo de la velocidad

La velocidad del sprint se calcula en función de la cantidad de trabajo

realizado y la suma de los SP de las historias que conforman el sprint. Las historias
se seleccionan teniendo en cuenta la velocidad que se desea alcanzar en el sprint.

Existen tres técnicas de cálculo

- El tiempo que hizo ayer: se calcula sprint a sprint la velocidad del equipo. Se
hace la media de la velocidad real de los sprints anteriores. La primera
estimación es la más costosa y con más probabilidad de error. Solo es factible si
los distintos sprints se realizan más o menos de la misma manera y si el equipo
no varía de tamaño y no cambia sus condiciones de trabajo.
- Días-hombre disponibles y productividad diaria: para calcular los días hombres
disponibles hay que tener en cuenta los días laborables del sprint, el número de
miembros del equipo, días a tiempo completo o parcial, bajas y vacaciones. La
productividad diaria (Tiempo trabajo diario sprint= media de horas por día-
Tiempo para otras actividades) se multiplica por los días hombre disponible.
- Días-hombre disponibles y factor de dedicación: el factor de dedicación pondera
cómo de centrado va a estar el equipo. El factor de dedicación por defecto para
equipos nuevos es del 70%.

Burndown chart

Es el grá co de seguimiento del sprint que ayuda a detectar alarmas o

situaciones arriesgadas. La unidad del eje Y suele ser SP y la unidad del eje X es el
tiempo. Hay un burndown estimado y uno real.

Daily planning

Es una reunión diaria de 15 minutos en el mismo lugar y hora siempre. Ayuda

a evitar otras reuniones innecesarias. No es dar un informe al Scrum Master, se
trata de compromisos hacia adelante. Se actualiza diariamente el Sprint Backlog/
Kanban. Cada persona mueve sus tareas las reestima y añade sus tareas no
plani cadas.

BUENAS PRÁCTICAS

Scrum no propone ninguna técnica de desarrollo software particular. Se

recomienda el uso de patrones. Dos niveles de abstracción:

14
fi
fi
 - Patrón de arquitectura software: estrategia que expresa un esquema de
organizaci n estructural esencial para un sistema sw, que consta de
subsistemas, sus responsabilidades e interrelaciones.
- Patrón de diseño software: soluci n general a un problema general que puede
adaptarse a un problema concreto. Evitan la reiteraci n en la b squeda de
soluciones a problemas ya conocidos y solucionados anteriormente.
- MVC (Modelo Vista Controlador): Patr n de arquitectura software. Separa los
datos y la l gica de negocio de una aplicaci n de la interfaz de usuario y la
gesti n de eventos. MVC mejora la reutilizaci n de c digo y separaci n de
conceptos

Reunión de retrospectiva

Se realiza al nalizar cada sprint. Se analiza cómo se ha trabajado. Se echa

un vistazo a lo que funciona y lo que no y se discute que mejorar y se aborda cómo
solucionarlo. Participa todo el equipo.

15
ó
ó
ó
fi
ó
ó
ó
ó
ó
ó
ú
ó