Please enable JavaScript.

Coggle requires JavaScript to display documents.

Metodologia XP - Coggle Diagram

- - - - Las Historias de Usuario
        
        Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales.
      - 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”)
        
        El objetivo de tener reuniones diarias es mantener la comunicación entre el equipo, y compartir problemas y soluciones
  - - - Simplicidad
        
        Un diseño simple se implementa más
        rápidamente que uno complejo
      - Soluciones “spike”
        
        pueden utilizarse pequeños programas de prueba (llamados “spike”), para explorar diferentes soluciones
      - Recodificación
        
        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
        
        es algo que todos entienden,
        sin necesidad de mayores explicaciones. sugiere utilizar este concepto como una manera sencilla de explicar el propósito del proyecto
  - - - Uno de los requerimientos de XP es tener al
        cliente disponible durante todo el proyecto
    - - 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
    - - propone un modelo inverso, en el que, lo primero que se escribe son los test que el sistema debe pasar. Luego, el desarrollo debe ser el mínimo necesario para pasar las pruebas previamente definidas.
    - - propone que se desarrolle en pares de programadores, ambos trabajando juntos en un mismo ordenador
    - - Todos los desarrolladores necesitan trabajar
        siempre con la “última versión”
    - - todo el equipo puede contribuir con nuevas ideas que apliquen a cualquier parte del proyecto
    - - que se desea establecer con esta práctica es el de planificar el trabajo de manera de mantener un ritmo constante y razonable, sin sobrecargar al equipo.
  - - - Todos los módulos deben de pasar las pruebas unitarias antes de ser liberados o publicados. Las pruebas deben ser definidas antes de realizar el código (“Test-driven programming”).
    - - Cuando se encuentra un error (“bug”), éste
        debe ser corregido inmediatamente,
    - - Las pruebas de aceptación son creadas en base a las historias de usuarios, en cada ciclo de la iteración del desarrollo.
- - - - El valor de la variable restante podrá
        ser establecido por el equipo de desarrollo
- - - - En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto.
    - - En esta fase 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
    - - Esta fase incluye varias iteraciones sobre el sistema
        antes de ser entregado. El Plan de Entrega está compuesto por iteraciones de no más de tres semanas
    - - La fase de 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.
    - - el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones
    - - Es cuando el cliente no tiene más historias para ser
        incluidas en el sistema
        
        La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.