Please enable JavaScript.
Coggle requires JavaScript to display documents.
Metodología Ágil de Desarrollo de Software – XP - Coggle Diagram
Metodología Ágil de Desarrollo de Software – XP
Que es XP
XP es una metodología ágil para el desarrollo de software y consiste básicamente en ajustarse estrictamente a una serie de reglas que se centran en las necesidades del cliente para lograr un producto de buena calidad en poco tiempo, centrada en potenciar las relaciones interpersonales como clave para el éxito deldesarrollo de software.
Valores de XP
Comunicación
Simplicidad
Retroalimentación
Valentía
Respeto
Roles XP
Programador
Cliente
Encargado de pruebas(Tester)
Encargado de seguimiento (Tracker)
Entrenador(Coach)
Consultor
Gestor (Big boss)
Modelo XP
-costo, tiempo, calidad y alcance
-sólo tres de ellas podrán ser fijadas arbitrariamente por actores externos al grupo de desarrolladores (clientes y jefes de proyecto)
-se trata de realizar ciclos de desarrollo cortos (llamados iteraciones), con entregables funcionales al finalizar cada ciclo
-Típicamente un proyecto con XP lleva 10 a 15 ciclos o iteraciones
Proceso XP
Fase I: Exploración
los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto.
Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo
Fase II: Planificación de la Entrega
el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimación del esfuerzo necesario de cada una de ellas
Fase III: Iteraciones
El Plan de Entrega está compuesto por iteraciones de no más de tres semanas.
Esto se logra escogiendo las historias que fuercen la creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración (para maximizar el valor de negocio)
Fase IV: Producción
requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta fase.
Fase V: Mantenimiento
Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones.
Fase VI: Muerte del Proyecto
Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema.
REGLAS Y PRÁCTICAS
Planificación
como un dialogo continuo entre las partes involucradas en el proyecto, incluyendo al cliente, a los programadores y a los coordinadores o gerentes
Las Historias de Usuario
son la técnica utilizada en XP para especificar los requisitos del software
Plan de entregas (“Release Plan”)
El cronograma de entregas establece qué historias de usuario serán agrupadas para conformar una entrega, y el orden de las mismas
Plan de iteraciones (“Iteration Plan”)
Las historias de usuarios seleccionadas para cada entrega son desarrolladas y probadas en un ciclo de iteración, de acuerdo al orden prestablecido.
Reuniones diarias de seguimiento (“Stand-up meeting”)
Diseño
Simplicidad
Un diseño simple se implementa más rápidamente que uno complejo
Soluciones “spike”
Cuando aparecen problemas técnicos, o cuando es difícil de estimar el tiempo para implementar una historia de usuario, pueden utilizarse pequeños programas de prueba (llamados “spike”), para explorar diferentes soluciones
Recodificación
La recodificación (“refactoring”) consiste en escribir nuevamente parte del código de un programa, sin cambiar su funcionalidad, a los efectos de hacerlo más simple, conciso y/o entendible.
Metáforas
Una “metáfora” es algo que todos entienden sin necesidad de mayores explicaciones.
Desarrollo
Disponibilidad del cliente
Uno de los requerimientos de XP es tener al cliente disponible durante todo el proyecto. No solamente como apoyo a los desarrolladores, sino formando parte del grupo.
Uso de estándares
promueve la programación basada en estándares, de manera que sea fácilmente entendible por todo el equipo, y que facilite la recodificación
Programación dirigida por las pruebas (“Test-driven programming”)
En las metodologías tradicionales, la fase de pruebas, incluyendo la definición de los tests, es usualmente realizada sobre el final del proyecto, o sobre el final del desarrollo de cada módulo
Programación en pares
XP propone que se desarrolle en pares de programadores, ambos trabajando juntos en un mismo ordenador.
Integraciones permanentes
Todos los desarrolladores necesitan trabajar siempre con la “última versión”. Realizar cambios o mejoras sobre versiones antiguas causan graves problemas, y retrasan al proyecto
Propiedad colectiva del código
En un proyecto XP, todo el equipo puede contribuir con nuevas ideas que apliquen a cualquier parte del proyecto.
Ritmo sostenido
La metodología XP indica que debe llevarse un ritmo sostenido de trabajo. Anteriormente, ésta práctica se denominaba “Semana de 40 horas” Sin embargo, lo importante no es si se trabajan, 35, 40 o 42 horas por semana.
Pruebas
Pruebas unitarias*
Las pruebas unitarias son una de las piedras angulares de XP. Todos los módulos deben de pasar las pruebas unitarias antes de ser liberados o publicados
Detección y corrección de errores
Cuando se encuentra un error (“bug”), éste debe ser corregido inmediatamente, y se deben tener precauciones para que errores similares no vuelvan a ocurrir.
Pruebas de aceptación
Las pruebas de aceptación son creadas en base a las historias de usuarios, en cada ciclo de la iteración del desarrollo
VENTAJAS Y DESVENTAJAS
Ventajas
Se consiguen productos usables con mayor rapidez
El proceso de integración es continuo, por lo que el esfuerzo final para la integración es nulo. Se consigue integrar todo el trabajo con mucha mayor facilidad.
Se atienden las necesidades del usuario con mayor exactitud. Esto se consigue gracias a las continuas versiones que se ofrecen al usuario
Se consiguen productos más fiables y robustos contra los fallos gracias al diseño de los test de forma previa a la codificación
Obtenemos código más simple y más fácil de entender, reduciendo el número de errores.
Gracias a la filosofía del “pair programming” (programación en parejas), se consigue que los desarrolladores apliquen las buenas prácticas que se les ofrecen con la XP.
Gracias al “refactoring” es más fácil el modificar los requerimientos del usuario.
Conseguimos tener un equipo de desarrollo más contento y motivado. Las razones son, por un lado el que la XP no permite excesos de trabajo (se debe trabajar 40 horas a la semana), y por otro la comunicación entre los miembros del equipo que consigue una mayor integración entre ellos.
Desventajas
Resulta muy complicado planear el proyecto y establecer el costo y la duración del mismo
No se puede aplicar a proyectos de gran escala, que requieran mucho personal, a menos que se las subdivida en proyectos más pequeños.
Es más complicado medir los avances del proyecto, pues es muy complicado el uso de una medida estándar.
Altas comisiones en caso de fallar.
