Manual de La Metodología Ágil XP

METODOLOGÍA XP (EXTREME
PROGRAMING)
Estudiante: ESTRADA MONGE, Franklin Edix
Docente: RAMIREX MEDRANO, Percy
Asignatura: METODOLOGÍAS ÁGILES DE DESARROLLO DE
SOFTWARE
Semestre: VII
Año: 2020
FRANKLIN ESTRADA MONGE 1

Índice:
I. ¿Qué es?
II. Origen
III. Definiciones
IV. Objetivos
V. Fases de implementación
VI. Ventajas y desventajas
VII. Cuando usar
VIII. Caso de uso

I. ¿Qué es?
Es una metodología ágil centrada en potenciar las relaciones interpersonales como
clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo,
preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen
clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo
de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios.
II. Origen
Podríamos decir que XP nace oficialmente en aproximados de marzo de 1996 en
un proyecto desarrollado por Kent Beck en DaimlerChrysler, después de haber
trabajado varios años con Ward Cunningham en busca de una nueva aproximación
al problema del desarrollo de software que hiciera las cosas más simples de lo que
nos tenían acostumbrados los métodos existentes. Para muchos, XP no es más que
sentido común. Kent definió cuatro grandes tareas a realizar en el desarrollo de todo
proyecto: planificación, diseño, desarrollo y pruebas; teniendo siempre presente las
cuatro características básicas que debe reunir un programador XP: simplicidad en
el desarrollo, comunicación entre las partes implicadas, realimentación para poder
reutilizar y coraje.
Kent Beck ingeniero de software
estadounidense, uno de los creadores de las
metodologías de desarrollo de software de
programación extrema (eXtreme
Programming o XP) y el desarrollo guiado por
pruebas (Test-Driven Development o TDD),
también llamados metodología ágil

III. Definiciones
Valores XP
XP define un conjunto de valores que establecen el fundamento para todo trabajo
realizado como parte de XP. Cada uno de estos valores se usa como un motor para
actividades, acciones y tareas específicas de XP.
Proceso XP
La programación extrema usa un enfoque orientado a objetos como paradigma
preferido de desarrollo, y engloba un conjunto de reglas y prácticas que ocurren en
el contexto de cuatro actividades estructurales: planeación, diseño, codificación y
pruebas.

Roles De La Metodología XP
En (Erlijman Piwen & Goyen Fros, 2001) La Propuesta original de Beck incluye los
siguientes roles:
PROGRAMADOR: Es el responsable de implementar las historias de usuario por el
cliente. Además, estima el tiempo de desarrollo de cada historia de usuario para
que el cliente pueda asignarle prioridad dentro de la iteración. Cada iteración
incorpora nueva funcionalidad de acuerdo con las prioridades establecidas por el
cliente. El Programador también es responsable de diseñar y ejecutar los test de
unidad del código que ha implementado o modificado.
CLIENTE: Determina la funcionalidad que se pretende en cada iteración y define
las prioridades de implementación según el valor de negocio que aporta cada
historia. El Cliente también es responsable de diseñar y ejecutar los test de
aceptación.
ENCARGADO DE PRUEBAS (TESTER): Es el Encargado de ejecutar las pruebas
regularmente, difunde los resultados dentro del equipo y es también el responsable
de las herramientas de soporte para pruebas.

ENCARGADO DE SEGUIMIENTO (TRACKER): Una de las tareas más importante
del tracker, consiste en seguir la evolución de las estimaciones realizadas por los
programadores y compararlas con el tiempo real de desarrollo. De esta forma,
puede brindar información estadística en lo que refiere a la calidad de las
estimaciones para que puedan ser mejoradas.
ENTRENADOR (COACH): Es Responsable del proceso en general. Se encarga de
iniciar y de guiar a las personas del equipo en poner en marcha cada una de las
prácticas de la metodología XP.
CONSULTOR: Es un Miembro externo del equipo con un conocimiento específico
en algún tema necesario para el proyecto. Guía al equipo para resolver un problema
específico.
GESTOR (BIG BOSS): Es el vínculo entre el cliente y programadores. Experto en
tecnología y labores de gestión. Construye el plantel del equipo, obtiene los recursos
necesarios y maneja los problemas que se generan. Administra a su vez las
reuniones (planes de iteración, agenda de compromisos, etc). Su labor fundamental
es de coordinación.
IV. Objetivos
• Establecer las mejores prácticas de Ingeniería de Software en los
desarrollos de proyectos.
• Mejorar la productividad de los proyectos.
• La Satisfacción del cliente.
• Potenciar el trabajo en grupo.
• Minimizar el riesgo actuando sobre las variables del proyecto: costo,
tiempo, calidad, alcance.
V. Faces de implementación
1.Presentación:
1.1 Herramientas empleadas:
Se definen que herramientas que se van a utilizar en el proyecto.
1.2 Descripción del negocio:
Se describe de forma específicamente el negocio, se puede hacer un
breve análisis de la empresa.
1.3 Descripción de cliente y usuario:
Se describe a los usuarios y al cliente.
2.Planeación:
2.1 Historias de usuario:
• Escritas por el usuario.
• Terminología del cliente.
• Bajo nivel de detalle.
• Sirve de base para estimar los tiempos de implementación.
• No deben ser menos de 20 ni más de 80.
2.2 Velocidad del proyecto:
• Numero de historias de usuario o tareas de programación realizadas
por iteración.
• Sirve de ayuda para estimar la cantidad de historias de usuario a
implementar en una determinada iteración.
• Ejemplo:
2.3 División de iteraciones:

• El proyecto se divide en varias iteraciones
• La duración de una iteración varia entre una y tres semanas
2.4 Estrategias pequeñas:

• Entregas funcionales del proyecto frecuentemente
2.5 Plantear entregas:
• Reunión al inicio del proyecto
• Cuales historias de usuario serán implementadas para cada entrega
• Grado de relevancia para historia de usuario
• Se aproxima el tiempo para la realización de cada iteración
2.6 Reunión inicial de iteración:
• Las historias son traducidas a tareas al comienza de cada iteración

• Se estiman los tiempos para la realización de las tareas en días ideales
2.7 Reunion matinal:
• La realización de una reunión al comenzar el día laboral
• Esta reunion se realizará en el sitio de trabajo del equipo
• Evitar discuciones largas
2.8 Mover personal:
• Cada persona en un equipo debe conocer mucho del codigo de cada
sección del proyecto
• Rotar los programadores en parte del desarrollo
2.9 Modificar XP cuando sea necesario:
• Corrija las reglas de XP cuando estas fallen
• Las reglas solo se cambian cuando el equipo lo aprueba en conjunto
3.Diseño:
3.1 Simplicidad:
• El diseño debe ser sencillo
• Solo se crearan diagramas utiles
3.2 Metáfora del sistema:
• Plasmar la arquitectura del sistema en una “Historia”
• Convención de los nombres para los objetos del sistema
3.3 Tarjetas CRC
• Su principal utilidad es dejar el enfoque procedimental y entar al
modelo orientado a objetos
• Todo el grupo participa en su elaboración
3.4 Spike solution (Solución rápida)
• Se trata de una prueba que se hace para redolver un problema técnico
o e diseño
• Es un programa muy simple que explora una solución potencial
3.5 No adicione funcionabilidad antes de tiempo
• El adicionar funcionabilidades que no se han acordado para la
iteración conlleva una perdida de tiempo que es inaceptable.
3.6 Refactorización
• Diseño como tarea pendiente

• Se conserva el codigo sencillo
• Rehacer secciones de codigo si es necesario
4.Codificación:
4.1 Cliente siempre presente
• El cliente debe de estar disponible en el sitio de trabajo
• El cliente es fundamental para solucionar dudas cara a cara
4.2 El código se escribe siguiendo estándares
• Al escribir el código del programa se deben de seguir estandares de
programación
4.3 Codificar primero la prueba
• Escribir primero la prueba que el código
• El tiempo de escribir una prueba y luego el código del programa para
dicha prueba es menor que solo escribir el código
• Escribir pruebas primero permite identificar los casos especiales que
deberá parar el código
4.4 Toda la producción de código debe ser en hecha en parejas
• Toda la producción de código debe ser en hecha en parejas sentadas
frente a un único computador
• Al trabajar en parejas se tiene un diseño de menor calidad y un código
más organizado
• Al trabajar en parejas se solucionan los problemas más fácilmente
4.5 Solo una pareja hace integración a la vez (Integración secuencial)
• Antes de integrar nuevo código a un proyecto se debe de garantizar
que la última versión halla pasado por todas las pruebas
• Solo se debe hacer una integración a la vez
• Se debe tener claro cuál es la última versión funcional
4.6 Integrantes frecuentes
• Se deben hacer integraciones cada poca hora o en lo posible no tardar
más de un día entre una y otra integración
• Entre más se tarde en encontrar un problema, resultará más costoso
resolverlo
• Integrar frecuentemente evita problemas como el trabajar sobre una
clase obsoleta
4.7 Propiedad colectiva del código

• Se debe procurar rotar a los programadores no solo de compañero,
también de partes del proyecto a desarrollar
4.8 No trabajar horas extra
• No trabajar horas extra
5.Pruebas
5.1 Pruebas unitarias
• Las pruebas deben ser escritas antes que los métodos
• Su implementación y ejecución deben consumir el menor tiempo
posible
5.2 Pruebas de aceptación
• Se deben diseñar las pruebas la aceptación con base en las historias
de usuario
5.3 Cuando se encuentra un error
• Al encontrar un error debe escribirse primero la prueba antes que
corregirlo
VI. Ventajas y Desventajas

Ventajas Desventajas
• Da lugar a una programación • Es recomendable emplearla
sumamente organizada. solo en proyectos a corto plazo.
• Ocasiona eficiencias en el • En caso de fallar, las
proceso de planificación y comisiones son muy altas.
pruebas. • Requiere de un rígido ajuste a
• Cuenta con una tasa de los principios de XP.
errores muy pequeña. • Puede no siempre ser más fácil
• Propicia la satisfacción del que el desarrollo tradicional.
programador.
• Fomenta la comunicación
entre los clientes y los
desarrolladores.
• Facilita los cambios.
• Permite ahorrar mucho
tiempo y dinero.
• Puede ser aplicada a
cualquier lenguaje de
programación.
• El cliente tiene el control
sobre las prioridades.

• Se hacen pruebas continuas
durante el proyecto.
• La XP es mejor utilizada en la
implementación de nuevas
tecnologías.
VII. Cuando usar

XP se define como especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.
VIII. Caso de uso

El caso de uso a explicar es de una tesis adjunto el enlace:
http://repositorio.unprg.edu.pe/bitstream/handle/UNPRG/1948/BC-TES-TMP-
803.pdf?sequence=1&isAllowed=y
Fuente:
http://repositorio.utp.edu.co/dspace/bitstream/handle/11059/794/0053E18cp.pdf
https://iswugaps2extremeprogramming.wordpress.com/2015/09/14/ventajas-y-
desventajas/
https://ingsotfwarekarlacevallos.wordpress.com/2015/05/08/metodologia-de-desarrollo-
agil-xp-y-scrum/
https://repositorio.unan.edu.ni/1365/1/62161.pdf

Manual de La Metodología Ágil XP

Cargado por

Copyright:

Formatos disponibles

Manual de La Metodología Ágil XP

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual de La Metodología Ágil XP

Cargado por

Copyright:

Formatos disponibles

METODOLOGÍA XP (EXTREME

FRANKLIN ESTRADA MONGE 1

FRANKLIN ESTRADA MONGE 2

FRANKLIN ESTRADA MONGE 3

FRANKLIN ESTRADA MONGE 4

FRANKLIN ESTRADA MONGE 5

2.3 División de iteraciones:

2.4 Estrategias pequeñas:

FRANKLIN ESTRADA MONGE 7

FRANKLIN ESTRADA MONGE 8

FRANKLIN ESTRADA MONGE 9

VI. Ventajas y Desventajas

FRANKLIN ESTRADA MONGE 10

VII. Cuando usar

VIII. Caso de uso

FRANKLIN ESTRADA MONGE 11

También podría gustarte