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
Resumen
Dan mayor valor al individuo, a la colaboración con el cliente y al desarrollo incremental del software con iteraciones.
Justificación
Se enfoca en resultados a corto plazos
De existir alguna anomalía o falta se hará las correcciones correspondientes
XP en comparación de las metodologías tradicionales es mas rápida
Los resultados son verificados por el usuario de manera que apruebe el producto.
Introducción
Cuando el entorno del sistema es muy cambiante
Las metodologías ágiles emergen como una posible respuesta
Qué es XP?
Satisfacer al completo las necesidades del cliente
Promueve el trabajo en equipo
Necesidades del cliente para lograr un producto de buena calidad en poco tiempo
Es la adecuada para los proyectos con requisitos imprecisos
XP es una metodología ágil para el desarrollo de software
Diseñada un grupo de programadores pequeño
Valores de XP
Retroalimentación
Llevar y dirigir el proyecto en una dirección correcta
Valentía
Desarrolladores a la par con el cambio
Simplicidad
Soluciones más simples a problemas
Respeto
El equipo debe trabajar como uno
Comunicación
La comunicación cara a cara es la mejor forma de comunicación
Roles XP
Encargado de seguimiento (Tracker)
Proporciona realimentación. Determina cuándo es necesario realizar algún cambio
Entrenador (Coach)
Es responsable del proceso global
Encargado de pruebas (Tester)
Encargado de pruebas ayuda al cliente a escribir las pruebas funcionales.
Consultor
Miembro externo del equipo con un conocimiento específico en algún tema
Cliente
Escribe las historias de usuario y las pruebas funcionales para validar su implementación
Gestor (Big boss)
Es el vínculo entre clientes y programadores
Programador
Produce el código del sistema
Modelo XP
Calidad
Alcance
Tiempo
Tres de ellas podrán ser fijadas arbitrariamente por actores externos al grupo de desarrolladores
Costo
Ciclos de desarrollo cortos (llamados iteraciones)
En cada iteración se realiza un ciclo completo de análisis, diseño, desarrollo y pruebas
Típicamente un proyecto con XP lleva 10 a 15 ciclos o iteraciones
Proceso XP
El ciclo de desarrollo pasos
El programador estima el esfuerzo necesario para su implementación
El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo.
El cliente define el valor de negocio a implementar
El programador construye ese valor de negocio
Vuelve al paso 1
El ciclo de vida de un proyecto XP
Fase III: Iteraciones
Establecer una arquitectura del sistema
Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son:
Velocidad del proyecto
Pruebas de aceptación no superadas en la iteración anterior
Tareas no terminadas en la iteración anterior
Historias de usuario no abordadas
Fase IV: Producción
Requiere de pruebas adicionales y revisiones de rendimiento
Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementación
Fase II: Planificación de la Entrega
Programadores realizan una estimación del esfuerzo
Las estimaciones de esfuerzo
Un punto, equivale a una semana ideal de programación
La planificación se puede realizar basándose en el tiempo o el alcance
El cliente establece la prioridad de cada historia de usuario
Las historias generalmente valen de 1 a 3 puntos
El resultado de esta fase es un Plan de Entregas, o “Release Plan”
Fase V: Mantenimiento
Se requiere de tareas de soporte para el cliente
La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura.
Fase I: Exploración
El equipo de desarrollo se familiariza con las herramientas, tecnologías para el proyecto
La arquitectura del sistema construyendo un prototipo
Plantean a grandes rasgos las historias de usuario que son de interés para la entrega del producto
Fase VI: Muerte del Proyecto
Esto requiere que se satisfagan las necesidades del cliente
Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura
Es cuando el cliente no tiene más historias para ser incluidas en el sistema
Tiene éxito cuando el cliente selecciona el valor de negocio a implementar
Reglas y Prácticas
Diseño
Simplicidad
El diseño más simple posible que funcione
Especial énfasis en los diseños simples y claros
Soluciones “spike”
Los problemas pueden utilizarse pequeños programas de prueba
Recodificación
Consiste en escribir nuevamente parte del código de un programa, sin cambiar su funcionalidad
Metáforas
Es algo que todos entienden, sin necesidad de mayores explicaciones
Desarrollo
Uso de estándares
Promueve la programación basada en estándares
Programación dirigida por las pruebas (“Test-driven programming”)
Se escribe son los test que el sistema debe pasar.
Disponibilidad del cliente
Tener al cliente disponible durante todo el proyecto
El cliente debe proporcionar las historias de usuarios
Programación en pares
Los diseños son mejores y el código más corto
El equipo resuelve problemas en forma más rápida
La cantidad de defectos encontrados en las pruebas es estadísticamente menor.
Las personas aprenden significativamente más, acerca del sistema y acerca de desarrollo de software
El proyecto termina con más personas que conocen los detallas de cada parte del código
La mayoría de los errores se descubren en el momento en que se codifican
Las personas aprenden a trabajar juntas, generando mejor dinámica de grupo
Las personas disfrutan más de su trabajo
Integraciones permanentes
Todos los desarrolladores necesitan trabajar siempre con la “última versión”
Propiedad colectiva del código
El equipo puede contribuir con nuevas ideas que apliquen a cualquier parte del proyecto
Ritmo sostenido
Debe llevarse un ritmo sostenido de trabajo
Planificación
Simplicidad del plan
Las Historias de Usuario
Las historias de usuario es muy dinámico y flexible
La información contenida
Referencia a otra historia previa
Riesgo
Prioridad técnica y del cliente
Estimación técnica
Prueba funcional, número de historia
Descripción
Tipo de actividad (nueva, corrección, mejora)
Notas y una lista de seguimiento con la fecha
Fecha
Estado cosas por terminar y comentarios
Las historias de usuario son la técnica utilizada en XP para especificar los requisitos
Organiza una reunión de planificación
Establecer un plan o cronograma de entregas (“Release Plan”)
Plan de entregas (“Release Plan”)
“Juego de planeamiento” (“Planning game”)
“Planning meeting”
“Planning workshop”
Reunión de planeamiento
Luego de algunas iteraciones es recomendable realizar nuevamente una reunión
Establece qué historias de usuario serán agrupadas
Valúan rápidamente el tiempo de desarrollo de cada una.
Si alguna de ellas tiene “riesgos”
Pequeños programas de prueba (“spikes”)
Plan de iteraciones (“Iteration Plan”)
Cada historia de usuario se traduce en tareas específicas de programación.
Cada historia de usuario se establecen las pruebas de aceptación
Las historias de usuarios seleccionadas para cada entrega son desarrolladas y probadas en un ciclo de iteración
El proyecto comienza recopilando “Historias de usuarios”
sustituyen a los tradicionales “casos de uso”
Reuniones diarias de seguimiento (“Stand-up meeting”)
Mantener la comunicación entre el equipo
Dialogo continuo entre las partes involucradas
Pruebas
Detección y corrección de errores
Cuando se encuentra un error (“bug”), éste debe ser corregido inmediatamente
Pruebas de aceptación
El cliente debe especificar uno o diversos escenarios para comprobar que una historia de usuario
Las pruebas de aceptación son consideradas como “pruebas de caja negra” (“Black box system tests”)
Pruebas unitarias
Todos los módulos deben de pasar las pruebas unitarias antes de ser liberados o publicados
Ventajas y Desventajas
Ventajas
Se consiguen productos más fiables y robustos contra los fallos gracias al diseño de los test
Obtenemos código más simple y más fácil de entender, reduciendo el número de errores
Se atienden las necesidades del usuario con mayor exactitud
se consigue que los desarrolladores apliquen las buenas prácticas que se les ofrecen con la XP
El proceso de integración es continuo, por lo que el esfuerzo final para la integración es nulo
Gracias al “refactoring” es más fácil el modificar los requerimientos del usuario
Se consiguen productos usables con mayor rapidez
Conseguimos tener un equipo de desarrollo más contento y motivado
Desventajas
No se puede aplicar a proyectos de gran escala, que requieran mucho personal
Es más complicado medir los avances del proyecto
Resulta muy complicado planear el proyecto y establecer el costo y la duración del mismo
Altas comisiones en caso de fallar
Conclusiones y Recomendaciones
Conclusiones
Los desarrolladores deben estar involucrados en todas las funcionalidades del proyecto
La programación en parejas ayuda a reducir costo y tiempos y mejorar la calidad del proyecto
Organiza a los integrantes del equipo para trabajar a un mismo ritmo
Los métodos en cascada o espiral son los más adecuados para proyectos
El cliente le da un valor agregado al proyecto
Los desarrolladores y las especificaciones estan claramente determinadas desde el comienzo
Es difícil estimar el costo y duración del proyecto
Recomendaciones
Usar XP en equipos pequeños de desarrollo que no superen a 20
Se debe involucrar al cliente en el desarrollo del proyecto desde el inicio
Para proyectos medianos, y en los que las especificaciones no se puedan obtener hasta luego de comenzado el proyecto
Los desarrolladores deben compartan el código y ser responsables
