Métodos ágiles de programación

Sesión 3. Metodologías Ágiles en el Desarrollo de

Software

Martínez Ortiz RamsésGarcía Vázquez José Fernando

Metodologías Ágiles en el Desarrollo de

Software

¿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.

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

¿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.

Elementos clave

• Poca documentación

• Simplicidad

• Análisis como una actividad constante

• Diseño evolutivo

• Integraciones

• Testeos diarios

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.

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.

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.

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.

El Manifiesto Ágil

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

Métodos ágilesvs

Metodologías Tradicionales

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

Agile Project Management

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

• 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

• 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

Fases

Crystal Methods

• 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

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

• 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

Dynamic Sytems Development Method.

• 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

Fases

• 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

• 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

Scrum

• 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

• 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

Fases

Extreme Programming

• 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

• 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

• 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

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.

• 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.