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
Valores
Retroalimentación
Valentía
Simplicidad
Respeto
Comunicación
Roles
Encargado de seguimiento (Tracker)
Entrenador (Coach)
Encargado de pruebas (Tester)
Consultor
Cliente
Gestor (Big boss)
Programador
Modelo
Define 4 variables
Calidad
Alcance
Tiempo
Costo
3 fijadas arbitrariamente por
actores externos al grupo de desarrolladores
Variable restante podrá ser establecida por el equipo de desarrollo
Iteraciones
Entregables funcionales
Se divide en
Desarrollo
Pruebas
Diseño
Análisis
Proceso
Ciclo de desarrollo
El cliente selecciona qué construir, de acuerdo con
sus prioridades y las restricciones de tiempo.
El programador construye ese valor de negocio.
El programador estima el esfuerzo necesario para su
implementación.
Vuelve al paso 1.
El cliente define el valor de negocio a implementar.
Fases
Iteraciones
Elementos a tomar en cuenta
Velocidad del proyecto
Pruebas de aceptación no superadas en la iteración anterior
HU no abordadas
Tareas no terminadas en la iteración anterior
Varias iteraciones
no más de 3 semanas
Producción
Se toman decisiones sobre la inclusión de nuevas características
Posible rebaje de tiempo que toma cada iteraciíon
Requiere pruebas adicionales y revisiones de rendimiento
No se realizan más desarrollos funcionales
Planificación de la Entrega (Release)
Planificación basada en tiempo o alcance
Programadores realizan estimación de esfuerzo de las HU
Cliente establece la prioridad de cada historia de usuario
Mantenimiento
Velocidad de desarrollo puede bajar después de la puesta del sistema en producción
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
Puede requerir nuevo personal en el equipo y cambios en su estructura
Exploración
Equipo de desarrollo se familiariza con las herramientas, tecnologías y practicas que se utilizarán en el proyecto
Se prueba la tecnología
Clientes plantean historias de usuario
Exploran posibilidades de arquitectura
Tiempo
Pocas semanas a pocos meses
Muerte del Proyecto
Ocurre cuando el sistema no genera beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo
Documentación final del sistema
Reglas y prácticas
Diseño
Soluciones “spike”
Recodificación
Simplicidad
Metáforas
Desarollo
Programación en pares
Integraciones permanentes
Programación dirigida por las pruebas
Propiedad colectiva del código
Uso de estándares
Ritmo sostenido
Disponibilidad del cliente
Planificación
Historias de usuario
Plan de entregas
Plan de iteraciones
Reuniones diarias de seguimiento
Pruebas
Detección y corrección de errores
Pruebas de aceptación
Pruebas unitarias
Ventajas y desventajas
Ventajas
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.
Se atienden las necesidades del usuario con mayor exactitud. Esto se consigue gracias a las continuas versiones que se ofrecen al usuario.
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.
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.
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. 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
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.
Resulta muy complicado planear el proyecto y establecer el costo y la duración del mismo.
Altas comisiones en caso de fallar.