Métodos ágiles del desarrollo de software

1. Métodos ágiles de
programación
Sesión 3. Metodologías Ágiles en el
Desarrollo de Software
Martínez Ortiz Ramsés
García Vázquez José Fernando

2. Metodologías Ágiles en el
Desarrollo de Software

3. ¿Qué son?
• Buscan permitir a los equipos desarrollar software
rápidamente y respondiendo a los cambios que
puedan surgir a lo largo del proyecto.
• Una alternativa a los procesos de desarrollo de
software tradicionales, rígidos y dirigidos por la
documentación generada en cada una de las
actividades desarrolladas.

4. Objetivo general
• Con el objetivo de agilizar y automatizar los procesos
en el desarrollo de software, nos vemos en la
necesidad de implantar Metodologías de Desarrollo
de Software que nos ayuden a entregar un producto
de calidad en tiempo y costo estimados

5. ¿Qué lo hace ágil?
• Incremental. Entregas pequeñas de software con
ciclos rápidos
• Cooperativo. Cliente y desarrolladores trabajan
juntos constantemente con una cercana
comunicación
• Sencillo. El método en sí mismo es simple, fácil de
aprender y modificar
• Esta bien documentado y es adaptable. Permite
realizar cambios de último momento.

6. Elementos clave
• Poca documentación
• Simplicidad
• Análisis como una actividad constante
• Diseño evolutivo
• Integraciones
• Testeos diarios

7. Ventajas
• Rápida respuesta a cambios de requisitos a lo largo
del desarrollo
• Entrega continua y en plazos cortos de software
funcional.
• Trabajo conjunto entre el cliente y el equipo de
desarrollo.
• Minimiza los costos frente a cambios.
• Importancia de la simplicidad, al eliminar el trabajo
innecesario.

8. Ventajas
• Mejora continua de los procesos y el equipo de
desarrollo.
• Evita malentendidos de requerimientos entre el
cliente y el equipo.
• El equipo de desarrollo no malgasta el tiempo y
dinero del cliente desarrollando soluciones
innecesariamente
• Cada componente del producto final ha sido probado
y satisface los requerimientos.

9. Problemas comunes
• Falta de documentación del diseño.
• Problemas derivados de la comunicación oral. Este
tipo de comunicación resulta difícil de preservar
cuando pasa el tiempo y está sujeta a muchas
ambigüedades.
• Falta de calidad. Probar el código de forma constante
no genera productos de calidad, sólo revela falta de
análisis y diseño.

10. Problemas comunes
• Falta de procesos de revisión del código.
• Falta de reusabilidad. La falta de documentación
hacen difícil que pueda reutilizarse el código ágil.
• Restricciones en cuanto a tamaño de los proyectos
abordables.
• Rigidez. Algunos métodos ágiles son muy rígidos:
deben cumplirse muchas reglas de una forma
estricta para garantizar el éxito del proyecto.

11. El Manifiesto Ágil

12. Valores
• Valorar al individuo y las interacciones del equipo
de desarrollo sobre el proceso y las herramientas.
• Desarrollar software que funciona más que
conseguir una buena documentación
• Valorar la colaboración con el cliente más que la
negociación de un contrato
• Responder a los cambios más que seguir
estrictamente un plan

13. Métodos ágiles
vs
Metodologías Tradicionales

14. Metodologías Ágiles Metodologías Tradicionales
Especialmente preparados para cambios
durante el proyecto
Cierta resistencia a los cambios
Proceso menos controlado, con pocos
principios
Proceso mucho más controlado, con
numerosas políticas / normas
Impuestas internamente (por el equipo) Impuestas externamente
El cliente es parte del equipo de
desarrollo
El cliente interactúa con el equipo de
desarrollo mediante reuniones
Grupos pequeños (menos de 10
integrantes)
Grupos grandes y posiblemente
distribuidos
Pocos roles Más roles
Menos énfasis en la arquitectura del
software
La arquitectura del software es esencial
y se expresa mediante modelos

15. Agile Project Management

16. Declaración de Interdependencia
• Incrementar el retorno de la inversión
• Entregar resultados fiables
• Aceptar la incertidumbre y gestionarla a través
iteraciones, anticipación y adaptación
• Animar el desarrollo creativo e innovador
• Incrementar el rendimiento obteniendo mejores
resultados

17. • Previsión. En esta fase se determinan la visión del
producto, los objetivos del proyecto, la comunidad
del proyecto y como el equipo trabajará junto
• Especulación. En esta fase se genera un plan de
entregas basado en las funcionalidades del
producto más que en las actividades.
• Exploración. El objetivo de la fase de exploración
es obtener funcionalidades de la aplicación
probadas y aceptadas.
Fases

18. • Adaptación. En la fase de adaptación se revisan
los resultados liberados, la situación actual y el
rendimiento de la aplicación, y se adapta si es
necesario
• Cierre. Se concluye el proyecto, se aprende de
la experiencia y se celebra. En esta fase lo más
importante es la transferencia de conocimientos y
según Jim, celebrarlo.
Fases

19. Fases

20. Crystal Methods

21. • Los proyectos más grandes suelen necesitar una
mayor coordinación y metodologías más complejas
que no los proyectos más pequeños.
• Cuanto más crítico sea el sistema que queremos
desarrollar, más rigurosidad necesitamos disponer
en el desarrollo del proyecto. Aparecen unos
caracteres (C, D, E y L) e indican las perdidas
potenciales por fallos del sistema, y lo hacen de la
siguiente manera:
Complejidad del proyecto

22. Crystal tiene asignado un color, cuanto más oscura
sea su tonalidad, más compleja es la metodología

23. • C: Indica pérdida de confort debido a un fallo del
sistema.
• D: Indica pérdida de dinero discrecional, es decir
del que podemos disponer, generalmente nuestro.
• E: Indica pérdida de dinero esencial, es decir dinero
que probablemente no es nuestro y no podemos
disponer de el libremente.
• L: De Life en ingles, vida. Indica la pérdida de vidas
por el fallo del sistema.
Complejidad del proyecto

24. Dynamic Sytems
Development Method.

25. • La idea fundamental de DSDM se basa en que en
vez de fijar las funcionalidades de un producto y
después el tiempo y el coste, fijar primero el
tiempo y el coste y con esto fijado, determinar
las funcionalidades que se pueden implementar en
el producto.
Objetivo

26. Fases

27. • Estudio de viabilidad. En esta fase se estudia la
idoneidad de utilizar DSDM en el proyecto que nos
ocupa y por tanto, se decide si utilizarlo o no.
• Estudio de negocio. Esta es la fase en que las
características principales del negocio y la
tecnología, son evaluados
• Modelo funcional de las iteraciones. Se realizan
las tareas tanto de análisis como de
codificación y se construyen prototipos.
Fases

28. • Iteraciones de diseño y construcción. Estas son las
fases en las que principalmente se construye el
sistema. El resultado final es un sistema probado,
que como al menos satisface los mínimos
requisitos establecidos.
• Implementación. En esta fase se pasa del entorno
de desarrollo al entorno de producción. Se da
formación a los usuarios y finalmente se abre el
sistema para que lo utilicen
Fases

29. Scrum

30. • Planificación del Sprint. En esta fase se define el
Product Backlog si todavía no ha sido definido, el
cual consiste en una lista priorizada de requisitos
del sistema y es un documento vivo, que puede
ser continuamente actualizado.
• Seguimiento del Sprint. A lo largo de esta fase se
llevan a cabo breves reuniones diarias, para ver el
avance de las tareas y el trabajo que esta previsto
para la jornada.
Fases

31. • Revisión del Sprint. Una vez finalizado el Sprint se
realiza un análisis y revisión del incremento
generado. En esta reunión se presentan los
resultados finales y se recomienda siempre
tener preparada una demo.
Fases

32. Fases

33. Extreme Programming

34. • Fase de Exploración. En esta fase los usuarios
escriben las tarjetas de historia que ellos quieren
que sean incluidas en la primera versión. Cada una
de las tarjetas de historia describen una
funcionalidad que será añadida al programa.
• Fase de planificación. En esta fase se establece la
prioridad de las diferentes historias y se acuerda el
contenido de la primera entrega del proyecto.
Fases

35. • Fase de iteraciones. Esta fase incluye la
realización de diferentes fases antes de liberar
la primera versión del producto.
• Fase de producción. En esta fase se llevan a cabo
un conjunto de pruebas extras, de rendimiento y
funcionamiento que son necesarias antes de
poder entregar el producto al cliente
Fases

36. • Fase de mantenimiento. Una vez se ha liberada la
primera versión a los usuarios, el proyecto se debe
mantener en el entorno de producción siempre y
cuando aún hayan iteraciones en fase de
producción.
• Fase de cierre del proyecto. Es la fase en que los
clientes ya no tienen más historias que deban ser
implementadas. La documentación del proyecto se
realiza en esta fase, ya que ni la arquitectura, ni el
diseño, ni el código sufrirán cambio alguno
Fases

37. Sistema Recomendado
• Se recomienda el uso de una metodología ágil
como la Extreme Programming, ya que por el
tiempo que se tiene para realizar el software,
una documentación extensa y exhaustiva no
es una opción para comenzar, por lo que en la
primera fase de esta metodología, se
escogerán las funcionalidades que se incluirán
en la primera versión del software.

38. • Después se procederá a desarrollar las
iteraciones del software, realizando las
pruebas necesarias para su implementación
en los 3 meses. Si aún quedan peticiones del
cliente, se le dará el mantenimiento para
adaptar el software, terminando el trato en el
momento en que se cumplan todos los
requisitos y entregando una documentación
de todo el sistema.