Grado en Ingeniería Informática.

2º Curso
CursoAcadémico 2022-23

Área de Lenguajes y Sistemas Informáticos

Universidad de Burgos

INGENIERÍADEL SOFTWARE
UNIDAD DOCENTE 1. TEMA 2. PARTE 2

Metodologías ágiles.
SCRUM y XP
 Metodologías ágiles
 Introducción
 Método de desarrollo adaptativo.
 Las personas y las interacciones por encima de las
herramientas.
 Colaboración con el cliente.
 Respuesta ante el cambio.

restricted
1. SCRUM
 Método de desarrollo basado en el trabajo
colaborativo entre equipos.
 Se puede aplicar a cualquier tipo de trabajo en
equipo.
 Involucrarse con el cliente, el mercado y la
tecnología a través de pequeñas acciones para
desarrollar productos competitivos.
 ROLES

 Dentro de la metodología Scrum encontramos

cuatro roles fundamentales:
 Product Owner: Encargado de determinar las
prioridades y representante de la empresa.
 Scrum Master: Ayuda al equipo a comprender
y seguir la teoría de Scrum.
 Equipo de desarrollo: Grupo de trabajo que
lleva a cabo el producto encargado.
 Stakeholders: Aquellos con interés en el
producto.
 PRODUCT OWNER

 Comunicación del objetivo del proyecto.

 Definir elementos del Backlog del producto y las

prioridades.

 Verificar que el producto es comprensible para el

equipo de trabajo.
 SCRUM MASTER

 Maximizar el valor de cada entrega en cada

sprint.

 Eliminar cualquier aspecto que impida llevar a

cabo la metodología.

 Asegurar que cada evento de la metodología sea

productivo, positivo y dentro de la planificación.
SCRUM
 PRODUCT BACKLOG

 Conjunto de tareas, funcionalidades y

requerimientos del proyecto.
 MODIFICAR → Cualquier miembro del equipo.
 ASIGNAR PRIORIDADES → Product Owner.
 PRODUCT BACKLOG

 Etapas del producto backlog →DEEP:

 Detailed Appropriately: Definición de
requisitos del producto.
 Emergent: Definición de su evolución y
adaptación a las demandas del cliente y
decisiones del Product Owner.
 Estimated: Valor asignado al proyecto según
el esfuerzo que requiere.
 Prioritized: Todos los elementos deben tener
prioridades.
 SPRINT BACKLOG

 Tareas a realizar y asignación a personas que las

llevan a cabo.
 Asignación de tiempo y un coste que requerirá
cada tarea.
 Cada sprint realiza las acciones detalladas y va
probando el producto final.
 Debe repetirse hasta entregar todos los elementos
del Backlog.
 No debe haber tiempos sin productividad entre
sprints.
 SPRINT REVIEW

 Es la fase final del sprint.

 Su fin es dar transparencia al equipo y al cliente
final.
 Se revisa el trabajo realizado.
 Es importante obtener feedback sobre el
desarrollo.
 El Product Owner explica los ítems del Product
Backlog finalizados.
 El equipo muestra el incremento realizado.
 Review del proyecto general, costes y tiempo y
detalle de pasos a seguir.
 SPRINT PLANNING MEETING

 Reunión en la que el Product Owner prioriza las

tareas del Product Backlog.
 Determinar el objetivo del sprint siguiente y
asignación de tiempos.
 BENEFICIOS DE SCRUM

 Calidad del producto obtenido

 Control y reducción del riesgo.
 Satisfacción del cliente.
 Flexibilidad y adaptación.
 Equipo involucrado.
 Vista clara del progreso obtenido.
 Métricas del proyecto en costes, tiempo y
eficiencia.
 2. Programación extrema
 Se denomina con las siglas XP.
 Se trata del proceso ágil más destacado de desarrollo
software.
 Se centra en la ADAPTABILIDAD.
 Modificación de requisitos → INEVITABLE.
 Programación humanizada.
 Importancia al trabajo en equipo.
 Retroalimentación cliente – equipo de desarrollo.

restricted
 2. Programación extrema
 Pretende que los costes no crezcan exponencialmente
debido a los cambios en el tiempo, como sí ocurría en las
metodologías tradicionales.

restricted
 2. Programación extrema
 Valores
 Comunicación entre los que trabajan en el proyecto.
 Simplicidad, utilizando siempre la solución más
sencilla.
 Retroalimentación continua del usuario.
 Valentía del programador para modificar aspectos que
funcionan bien, para mejorarlas.

restricted
 2. Programación extrema
 Doce prácticas fundamentales.
 Diseño simple.
 Refactorización.
 Test.
 Estándares de codificación.
 Propiedad colectiva del código.
 Programación por parejas.
 Integración continua.
 40 horas semanales.
 Metáfora del negocio.
 Cliente in situ.
 Entregas frecuentes.
 Planificación incremental.

restricted
 2. Programación extrema
 Diseño simple
 Cuanto más sencillo sea el diseño, más fácil de
comprender y mantener.
 Sin código duplicado.
 Supera las pruebas.
 Sin sintaxis complejas.
 Menor número de clases y métodos.

restricted
 2. Programación extrema
 Refactorización
 Evitar el deterioro progresivo del código.
 Cuando hacemos un cambio, realizarlo sin deteriorar el
código, reescribiendo las partes necesarias.
 El código conserva la claridad y sencillez del original.
 Usar comentarios.
 Importante para cumplir con la gráfica de costes.

restricted
 2. Programación extrema
 Test
 Pilar fundamental de la metodología.
 Aplicar test en cada cambio.
 Automatizar los test siempre que sea posible.
 Se establecen antes de realizar el código que se va a
testear.
 Prevenir errores antes de que aparezcan.
 El objetivo no es cumplir funcionalidades, sino pasar
test.
 Usuario final ayuda a elaborar los test.
 Test de aceptación, unitario y de integridad.

restricted
 2. Programación extrema
 Estándares de codificación
 Nomenclaturas propias de codificación.
 Ayuda a entender mejor el código.

restricted
 2. Programación extrema
 Propiedad colectiva del código.
 Eliminar la propiedad individual del código.
 Cualquier miembro del equipo tiene derecho y
obligación de modificar el código.

restricted
 2. Programación extrema
 Programación por parejas.
 Dos personas delante del mismo monitor y teclado.
 Intercambiar roles táctico y estratégico.
 Nivel equivalente de ambos.

restricted
 2. Programación extrema
 Integración contínua.
 Integrar cada parte independientemente de que no estén
todas desarrolladas.
 Pruebas de integración van detectando errores de cada
parte.
 Integrar cada parte lo antes posible.

restricted
 2. Programación extrema
 40 horas semanales.
 Trabajar más horas de lo debido es contraproducente.
 Terminar la semana cansado, no desmotivado.
 Dos semanas de horas extras = El proyecto no va bien.

restricted
 2. Programación extrema
 Metáfora del negocio
 Mismo vocabulario, con mismo significado, entre el
usuario final y los programadores.

restricted
 2. Programación extrema
 Cliente in situ
 Cliente forma parte del equipo de desarrollo y se
encuentra en el mismo lugar.
 Se agiliza el tiempo de respuesta.
 Hablar cara a cara.

restricted
 2. Programación extrema
 Entregas frecuentes
 Versiones pequeñas del sistema, sin la funcionalidad
completa.
 El usuario puede familiarizarse.
 El equipo de desarrollo puede ejecutar pruebas de
integridad.
 Nuevas versiones lo más pequeñas posible, pero que
aporten valor.

restricted
 2. Programación extrema
 Planificación incremental
 La planificación no es perfecta.
 Varía en función de las necesidades del negocio.
 Se revisa continuamente.

restricted
 2. Programación extrema
 CICLO DE VIDA
 Fase de exploración: Historias de usuario, metáfora de
negocio.
 Fase de planificación: Estudiar las historias y su coste
de implementación.
 Fase de iteración: Dividir historias de usuario en tareas.
 Fase de producción: Primera versión productiva,
continuar con iteraciones.
 Fase de mantenimiento: Nuevas historias de usuario.
 Fase de muerte: Final del software.

restricted
 2. Programación extrema
 Roles
 En la programación extrema encontramos diferentes
roles:
 Programador
 Cliente
 Encargado de pruebas
 Líder técnico
 Consultor
 Project manager

restricted
 2. Programación extrema
 Programador
 Escribe pruebas unitarias.
 Produce el código.

restricted
 2. Programación extrema
 Cliente
 Diseña pruebas de aceptación.
 Aporta la dimensión de negocio al equipo de desarrollo.
 Representa a usuarios finales.
 Siempre disponible para consultas.

restricted
 2. Programación extrema
 Encargado de pruebas
 Ejecuta pruebas de aceptación
 Ayuda a crear pruebas de aceptación.
 Difunde los resultados.
 Automatiza las pruebas.
 Seguimiento de los errores.

restricted
 2. Programación extrema
 Líder técnico
 Lidera el proceso global.
 Garantiza que se sigue la metodología de programación
extrema, la cual domina.
 Ayuda a los miembros del equipo a aplicarla.

restricted
 2. Programación extrema
 Consultor
 No es parte del equipo.
 Tiene conocimientos de un área concreta.
 Resuelve problemas puntuales.

restricted
 2. Programación extrema
 Project Manager
 Máximo responsable del proyecto.
 Enlace con los clientes.
 Garantizar las condiciones para el trabajo.

restricted
 3. Programación extrema vs SCRUM
 Diferencias:

 SCRUM→ entregas cada 2 a 4 semanas.

 XP→ 1 a 3 semanas.

 SCRUM→ tareas completadas no pueden modificarse.

 XP → tareas completadas pueden modificarse.

 SCRUM → se puede modificar el orden de las tareas.

 XP → se sigue el orden establecido por el cliente.

 SCRUM → trabajo individual.

 XP → trabajo en parejas.

restricted