01-Metodologias-de-desarrollo-agil-MDS-23267.pdf

Clase de metodologías de software

1. Metodologías de Desarrollo de Software
NRC23267
Departamento de Ciencias de la Computación
Ing. Carlos Andrés Pillajo, Msc.
[email protected]

2. 01 Metodologías de Desarrollo
Ágil
Unidad 2: Metodologías de Desarrollo de Software
2

3. Contenidos
3
Introducción
Métodos ágiles
Principios de los métodos ágiles
Desarrollo rápido dirigido por un plan y desarrollo ágil
(SCRUM)

4. Introducción
Unidad 2
4

5. Objetivo de la clase
•Comprender los orígenes e historia
de los métodos ágiles.
•Identificar los principios y valores de
las metodologías ágiles.
•Comparar el desarrollo ágil con el
desarrollo tradicional.
•Introducir SCRUM como marco ágil
representativo.
•Aplicar conceptos mediante
ejercicios prácticos.
5

6. Video introductoriohttps://youtu.be/Smf2BKwiBmM?si=
qtblsLJVlAwRtSdJ
6

7. Introducción e Historia
•Orígen:
7
Problema inicial:
Desarrollo tradicional rígido
Cambios costosos
Año 2001:
Se publica el Manifesto Ágil en
Utha (EE.UU)
17 autores: “Alianza Ágil”
(Kent Beck, Martin Fowler, etc.)

8. Manifesto Ágil
Individuos e
interacciones,
sobre procesos y
herramientas.
Software
funcionando, sobre
documentación
extensiva.
Colaboración con
el cliente, sobre
negociación
contractual.
Responder al
cambio, sobre
seguir un plan
rígido.
8
Cuatro valores fundamentales
Estamos descubriendo formas mejores de desarrollar
software, por medio de hacerlo y de dar ayuda a otros
para que lo hagan.

9. Individuos e interacciones sobre procesos y
herramientas.
Las personas que desarrollan el software, y quienes usan el mismo, son el centro del éxito.
Las interacciones (comunicación, colaboración, retroalimentación) son más importantes
que los procedimientos rígidos.
Ejemplo:
•En vez de enfocarse exclusivamente en seguir un flujo de trabajo en JIRA, el equipo realiza reuniones diarias
efectivas (Daily Scrum) donde detectan problemas rápidamente.
Riesgo si se ignora:
•Equipos dependientes de procesos automáticos, pero sin comunicación humana efectiva → aumenta la
cantidad de malentendidos, bloqueos y retrabajos.
9

10. Software funcionando sobre
documentación extensiva
El objetivo principal es entregar software que funcione y genere valor, no producir
documentos innecesarios o excesivos.
La documentación es importante, pero debe ser suficiente y útil.
Ejemplo:
•En lugar de generar cientos de páginas de especificaciones estáticas, se trabaja con historias de usuario y
criterios de aceptación que guían el desarrollo real.
Riesgo si se ignora:
•Proyectos con documentación perfecta, pero sin entregar software funcional durante meses o años.
10

11. Colaboración con el cliente sobre
negociación contractual
El cliente es parte activa del proceso; no es solo quien firma el contrato al inicio.
La colaboración continua permite que el producto evolucione según las necesidades reales
del negocio.
Ejemplo:
•En cada Sprint Review, el cliente revisa las funcionalidades entregadas, da su feedback, y puede cambiar
prioridades para el siguiente sprint.
Riesgo si se ignora:
•Desarrollar lo que dice el contrato inicial, sin importar si las necesidades reales cambiaron → producto obsoleto
o inútil al entregarse.
11

12. Responder al cambio sobre seguir un plan
rígido
En entornos de alta incertidumbre, los cambios son inevitables.
El plan inicial sirve de guía, pero no es una camisa de fuerza.
Ejemplo:
•Si aparece una nueva regulación legal a mitad del desarrollo, el equipo adapta su
backlog y prioriza los cambios necesarios en el próximo sprint.
Riesgo si se ignora:
•Resistirse a los cambios, obligando al equipo a cumplir un plan desactualizado →
pérdida de competitividad.
12

13. ¿Cuál de los 4 valores considera
que es más difícil de aplicar en
organizaciones tradicionales y por
qué?
13

14. Métodos Ágiles
Unidad 2
14

15. Métodos Ágiles
15
Qué es agilidad en el contexto del
trabajo de la ingeniería de software?
La agilidad se ha convertido en la palabra mágica de hoy para describir un proceso de software moderno.
Un equipo ágil es diestro y capaz de responder de manera apropiada a los cambios.
El cambio es de lo que trata el software en gran medida.
Un equipo ágil reconoce que el software es desarrollado por individuos que trabajan en equipo, y que su
capacidad, su habilidad para colaborar, es el fundamento para el éxito del proyecto.

16. Métodos Ágiles
16
La agilidad puede aplicarse a cualquier proceso de software.
Para lograrlo
Permitir al equipo del proyecto adaptar las tareas y hacerlas directas.
Ejecutar la planeación de manera que entienda la fluidez de un
enfoque ágil de desarrollo.
Eliminar todos los productos del trabajo excepto los má esenciales y
mantener los esbeltos.
Poner énfasis en una estrategia de entrega incremental.

17. Métodos Ágiles
17
La agilidad y el costo del cambio

18. Métodos ágiles
Estos métodos se basan en un
conjunto de principios y valores
que promueven la entrega
continua de software funcional y
de calidad, a través de iteraciones
cortas y un enfoque centrado en
las personas y la comunicación.
18

19. No cometa el error de suponer que la
agilidad le da permiso para
improvisar soluciones. Se requiere de
un proceso, y la disciplina es
esencial.
19
Consejo

20. Principios de los Métodos
Ágiles
Unidad 2
20

21. 12 Principios del Manifiesto Ágil
1.La prioridad más alta es satisfacer al cliente a través de la
entrega pronta y continua de software valioso.
2.Son bienvenidos los requerimientos cambiantes, aun en una
etapa avanzada del desarrollo. Los procesos ágiles dominan el
cambio para provecho de la ventaja competitiva del cliente.
3.Entregar con frecuencia software que funcione, de dos
semanas a un par de meses, de preferencia lo más pronto que
se pueda.
4.Las personas de negocios y los desarrolladores deben trabajar
juntos, a diario y durante todo el proyecto.
21

22. 12 Principios del Manifiesto Ágil
5.Hay que desarrollar los proyectos con individuos motivados.
Debe darse a éstos el ambiente y el apoyo que necesiten, y
confiar en que harán el trabajo.
6.El método más eficiente y eficaz para transmitir información a
los integrantes de un equipo de desarrollo, y entre éstos, es la
conversación cara a cara.
7.La medida principal de avance es el software que funciona.
8.Los procesos ágiles promueven el desarrollo sostenible. Los
patrocinadores, desarrolladores y usuarios deben poder
mantener un ritmo constante en forma indefinida.
22

23. 12 Principios del Manifiesto Ágil
9.La atención continua a la excelencia técnica y el buen diseño
mejora la agilidad.
10.Es esencial la simplicidad: el arte de maximizar la cantidad de
trabajo no realizado.
11.Las mejores arquitecturas, requerimientos y diseños surgen de
los equipos con organización propia.
12.El equipo reflexiona a intervalos regulares sobre cómo ser más
eficaz, para después afinar y ajustar su comportamiento en
consecuencia.
23

24. Desarrollo rápido dirigido por
un plan (RAD)
Unidad 2
24

25. Desarrollo Rápido Dirigido por un Plan
(RAD)
RAD (Rapid Application Development).
Propuesto por James Martin a principios de los años 90.
Surge como respuesta a las limitaciones del modelo en cascada.
Aparece para enfrentar entornos donde los requerimientos cambiaban
frecuentemente y se necesitaban resultados en menor tiempo.
25

26. Desarrollo Rápido Dirigido por un Plan
(RAD)
Metodología
orientada a la
velocidad.
Permite construir
sistemas funcionales
de forma rápida a
través de prototipos.
Iteración continua
con el cliente y
equipos
interdisciplinarios.
Enfocado en rapidez,
reutilización y
participación
intensiva del usuario.
26

27. Fases del modelo RAD
Fase Descripción
1. Recolección de requisitosReuniones intensivas con usuarios y partes
interesadas.
2. Diseño del prototipoDesarrollo de prototipos funcionales rápidos para
validar requerimientos.
3. Construcciónodificación rápida utilizando herramientas
visuales, componentes y reutilización.
4. Pruebas y entregaPruebas funcionales intensivas y despliegue.
27
Nota: las fases no son estrictamente secuenciales.

28. Características
clave de RAD
•Prototipado rápido.
•Desarrollo iterativo.
•Alta participación del cliente.
•Uso intensivo de herramientas CASE.
•Reutilización de componentes existentes.
•Equipos pequeños y altamente
capacitados.
28

29. Desarrollo Rápido Dirigido por un Plan
(RAD)
•Ventajas
•Reducción significativa del
tiempo de desarrollo.
•Alta adaptabilidad a cambios.
•Mejora la satisfacción del
usuario por su involucramiento.
•Menor documentación y más
énfasis en productos
funcionales.
•Desventajas
•Requiere usuarios
comprometidos y disponibles.
•Difícil de aplicar en proyectos grandes o críticos.
•Puede haber problemas de
escalabilidad y mantenimiento
si no se gestiona bien la calidad.
•Requiere herramientas
especializadas y equipos con
experiencia.
29

30. Desarrollo Ágil (SCRUM)
Unidad 2
30

31. Desarrollo Ágil
31

32. Desarrollo Ágil
32

33. Desarrollo
Ágil
(SCRUM)
33

34. Desarrollo
Ágil
(SCRUM)
•SCRUM es un marco de
trabajo ágil para el
desarrollo de productos
complejos. No es una
metodología con pasos
rígidos, sino una estructura
ligera y adaptable, basada
en la inspección,
adaptación y transparencia.
34

35. 35

36. SCRUM
•Aunque scrum puede ser de mucha
ayuda, en realidad es un compendio
de buenas prácticas, por lo que no
constituye un método prescriptivo ni
una metodología, como podrían ser
Rational Unified Process (RUP) o
Métrica 3 y, por tanto, no va a decir
qué es lo que hay que hacer en cada
caso, punto por punto.
36

37. Valores SCRUM
CompromisoDe las responsabilidades y la libertad otorgadas a los miembros
del equipo.
CorajeLos miembros del equipo se apoyan entre sí para afrontar retos
complejos.
FocalizaciónEn cada iteración.
AperturaSe fomenta la transparecia y el flujo de información.
RespetoMutuo entre los miembros del equipo.
37

38. Proceso SCRUM
38

39. Roles
39
Product owner
Gestiona todas las
funcionalidades que se han
de cumplir con la
implementación del
sistema.
Scrum Master
Adopta una función de
coaching. Es responsable
de asegurar de que todo el
equipo scrum sigas las
prácticas de scrum.
Equipo de Desarrollo
Serán los que conviertan
las necesidades del
product owner en un
conjunto de nuevas
funcionalidades.

40. Product Backlog (Pila de producto)
El product backlog es responsabilidad del product owner y
constituye la lista priorizada de las historias de usuario o
funcionalidades que ha de cumplir el sistema y se encuentra
escrito en un lenguaje que el cliente puede entender.
40
Está suficientemente detallado
Es algo estimado
Es emergente
Está priorizado

41. Mapa de historias de usuario
41

42. Sprint
•Cada iteración se denomina sprint y constituye una versión
operativa del software que se debe implementar.
•Período de tiempo de duración fija, nunca superior al mes.
Pueden ir de entre una a cuatro semanas.
•Crear un incremento del producto: terminado, utilizable y
potencialmente desplegable.
42
En base a la frecuencia solicitada por el cliente.Factores para
determinar la
duración de un
sprint
En base a las capacidades del equipo de desarrollo.
Si se estima que los cambios por parte del cliente van a ser muy fuertes

43. Sprint dentro del proceso Scrum
43

44. Backlog vs Sprint Backlog
44

45. Reuniones o Ceremonias
•Sprint planning
•Realizada al comienzo de cada sprint y en ella se define lo que se va a implementar en la iteración actual.
•Participan todos los roles de scrum.
•Se obtiene el sprint backlog.
45
•Daily Scrum
•Se realiza de forma diaria a lo largo de todo el proyecto.
•Duración de máximo 15 minutos.
•Cada miembro del equipo explica el trabajo que hizo el día anterior.
•Participa el DevTeam y Scrum Master.
•Sprint review
•Realizada al final de cada sprint.
•Se demuestra el incremento y se obtiene una retroalimentación de los interesados del proyecto.
•Participan todos los roles de scrum y algunos stakeholders.
•Sprint retrospective
•También se realiza al final de cada sprint.
•De carácter eminentemente técnico.
•Participa el DevTeam para analizar su propio trabajo.
•Moderador: Scrum Master.

46. Preguntas
Metodologías de
Desarrollo de Software
46