metodologia xp

Ing. Manuel Alcántara Ramírez

Programación Extrema

Como surge XP

Creado por Kent Beck

En el proyecto C3 en Chrysler

Kent dirigió el proyecto

Durante el proceso nació esta nueva metodología: eXtreme

Programming (XP)

C3 concluyó exitosamente en 1997

3 UNTECS - Manuel Alcántara R.

¿Qué es XP?

Es una metodología ágil que se caracteriza por:

Estar diseñada para entornos dinámicos.

Es Flexible.

Es Predecible.

Para equipos pequeños (máximo 10 programadores).

Orientada fuertemente hacia la codificación.

Énfasis en la comunicación informal, verbal.

De bajo riesgo


Comparación Ciclos de vida

Tradicionales con el de XP

UNTECS - Manuel Alcántara R. 5

Características de XP Metodología creada a base de prueba y error.

Considera 4 valores que pueden mejorar cualquier proyecto de software: Simplicidad,

Comunicación,

Realimentación,

Coraje.

Expresada en forma de 12 prácticas (algunas ya existentes desde hace años), que se soportan las unas a las otras y conforman un conjunto completo.


Simplicidad

“Hacer que el sistema funcione lo mas simple posible”

“Mantener el sistema en la condición mas simple posible”.

En relación al proceso y la codificación, el principio es hacerlo

simple que pueda funcionar,

Es mejor hacer algo simple hoy, que hacerlo más complicado hoy y

probablemente nunca usarlo.


Comunicación

El cliente es parte del equipo de desarrollo.

Comunicación constante entre el equipo de gestión y el

equipo de desarrollo.

Comunicación constante entre desarrolladores.

XP hace casi imposible la falta de comunicación.


Retroalimentación Retroalimentación concreta y frecuente del cliente, del equipo y

de los usuarios finales da una mayor oportunidad de dirigir el

esfuerzo.

Testeo continuo a través de todo el proceso

Testeo como herramienta de especificación y desarrollo

Testeo como garantía de integridad del código frente a

cambios.

Velocidad, pero además calidad


Coraje Se requiere coraje para comunicarse con los demás

cuando eso podría exponer la propia ignorancia.

Se requiere coraje para mantener el sistema simple, dejando para mañana las decisiones de mañana.

Se requiere coraje para confiar en que la retroalimentación durante el camino es mejor que tratar de adivinar todo con anticipación.

Es difícil ser valeroso.

Se requiere coraje para enfrentar la reacción frente a los cambios


Proceso de desarrollo de software con XP


Proceso de Desarrollo de Software con XP

Prototipo

arquitectónico

Planificación de

entregas Iteración

Tests de

aceptación

Pequeñas

entregas

Historias de

usuario

Metáfora de

sistema

Prototipo

requerimientos

Estimación

incierta Estimación

confiable

Plan de entregas Versión mas

reciente

Aprobación del

cliente

Escenarios de testeo

Historias nuevas

Velocidad del proyecto

Próxima

iteración

bugs




Iteración


Iteración

Próxima

iteración

Planificación de

iteración Desarrollo

Versión mas

reciente

Velocidad de

proyecto

Plan de

iteración

Plan de entregas

Bugs

Historias de

usuario

Tests de

aceptación

fallados

Funcionalidades

nuevas

Corrección de bugs

Día a día

Historias nuevas,

Velocidad de proyecto

Aprender y

comunicar


Desarrollo


Desarrollo

Corrección de

bugs

Reunión de

pie

Manejo colectivo del

software

Próxima tarea o test de

aceptación fallido

Plan de iteración

Día a día

tareas

Tests de

aceptación

fallados

Tests de unidad

pasados al 100%

Test de

aceptación

aprobado

Tareas sin terminar

Demasiado por

hacer

Nueva

funcionalidad

Aprender y

comunicar

Programación en pares

Reconstrucción de código


Manejo colectivo del código

Próxima tarea o

test de

aceptación

Creación de

unidad de testeo Programación en

pares

100% de

unidades de

testeo pasados

Pares

Unidad de

testeo fallida

Mover Gente

Se necesita ayuda Cambio de

par

Unidad de

testeo aprobada

Código

simple Código

complejo

Reconstrucción

despiadada

Ejecutar

todas las

unidades

de testeo

Test de

aceptación

aprobado

Ejecutar test

de aceptación

fallados




Resumen de prácticas

Proceso de planificación

Entregas pequeñas

Metáfora del sistema

Diseño simple

Testeo

Reconstrucción


Propiedad colectiva

Integración continua

Semana de 40 horas

Cliente siempre disponible

Estándares de codificación


Interacción entre las Prácticas


Roles en XP

Programador (Programmer)

Responsable de decisiones técnicas

Responsable de construir el sistema

Sin distinción entre analistas, diseñadores o codificadores

En XP, los programadores diseñan, programan y realizan las pruebas


Roles en XP

Jefe de Proyecto (Manager)

Organiza y guía las reuniones

Asegura condiciones adecuadas para el proyecto

Cliente (Customer)

Es parte del equipo

Determina qué construir y cuándo

Establece las pruebas funcionales


Roles en XP

Encargado de Pruebas (Tester)

Ayuda al cliente con las pruebas funcionales

Se asegura de que las pruebas funcionales se superen

Rastreador (Tracker)

Hace el seguimiento del proyecto.

Observa sin molestar.

Conserva datos históricos.


Roles en XP

Entrenador (Coach)

Responsable del proceso

Tiende a estar en un segundo plano a medida que el equipo madura


Artefactos esenciales en XP

Historias del Usuario

Tareas de Ingeniería

Pruebas de Aceptación

Pruebas Unitarias y de Integración

Plan de la Entrega

Código


Captura de Requisitos en XP

Se usan Historias del Usuario (User-

Stories)

Establecen los requisitos del cliente

Trozos de funcionalidad que aportan valor

Se les asignan tareas de programación con un nº de

horas de desarrollo.

Las establece el cliente.

Son la base para las pruebas funcionales.


Historias (Relatos) de Usuario Una Historia de usuario es un relato acerca de qué problema debe resolver el

sistema.

Cada relato se escribe en una tarjeta y representa una parte de la funcionalidad que es coherente para el cliente.

Son escritos por el cliente o usuario, con la ayuda de los desarrolladores, para permitir estimar los tiempos y asignar prioridades.

Los clientes ayudan a asegurar que la mayoría de la funcionalidad deseada para el sistema esté cubierta con las historias.

Constan de 3 ó 4 líneas escritas por el cliente en un lenguaje no técnico sin hacer mucho hincapié en los detalles.

No se debe hablar ni de posibles algoritmos para su implementación.

No se debe considerar los diseños de base de datos, etc.


Ejemplo de Historia de Usuario

Historia de Usuario

Número: 1 Nombre: Enviar artículo

Usuario: Autor

Modificación de Historia Número: Iteración Asignada: 2

Prioridad en Negocio: Alta

(Alta / Media / Baja) Puntos Estimados:

Riesgo en Desarrollo:

(Alto / Medio / Bajo) : Alto Puntos Reales:

Descripción:

Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un e-mail al autor de contacto con un usuario y clave para que el autor pueda posteriormente acceder al artículo.

Spike para Historia de Usuario


Tarea de Ingeniería

Tarea

Número tarea: Número historia:

Nombre tarea:

Tipo de tarea :

Desarrollo / Corrección / Mejora / Otra Puntos estimados:

Fecha inicio: Fecha fin:

Programador responsable:

Descripción:

Prueba de Aceptación

Caso de Prueba

Número Caso de Prueba: Número Historia de Usuario:

Nombre Caso de Prueba:

Descripción:

Condiciones de ejecución:

Entradas:

Resultado esperado:

Evaluación:

Prácticas XP

• El juego de la

planificación

• Entregas pequeñas

• Metáfora

• Diseño simple

• Pruebas

• Refactoring

• Programación en parejas

• Propiedad colectiva

• Integración continua

• Semana de 40 horas

• Cliente in situ

• Estándares de programación


Escenarios en XP : Exploración

Historias de Usuario

Prioridad Riesgo

Esfuerzo (puntos)

Spikes (Bosquejos)

Definir Historias de Usuario

Elaborar Spikes

Estimar Esfuerzo y Riesgo

?


Escenarios en XP:

Planificación de la Entrega

Historias de Usuario

Primera Iteración

Segunda Iteración

Última Iteración

…

N-ésima Iteración

Historias fuera de la entrega

Velocidad de Proyecto (VP) puntos/semana

Entrega <= 3 meses

2 a 3 semanas


Escenarios en XP : Comenzar Iteración

Historias de la Iteración

Definir y ordenar Tareas de Ingeniería

Tareas de la iteración


Escenarios en XP : Programación

Pruebas de Aceptación de Historias de la iteración

Programación en Parejas

Tareas de Historias de la iteración

Historias de la Iteración

Versión del Producto

Diseño

Refactoring

Programación

Pruebas Unitarias

Integración

Pruebas de Integración



Escenarios en XP : Pruebas de Aceptación


Definir Pruebas de Aceptación

Aplicar Pruebas de Aceptación

Corregir errores Definir nuevas Historias


Entorno y clima de trabajo

Espacio de trabajo XP

Espacio abierto

Mesas centrales

Cubículos en el espacio exterior

Espacio de trabajo

del proyecto C3 de

DaimlerChrysler


Reunión diaria: “Stand-up Meeting”

Todo el equipo

Problemas

Soluciones

De pie en un círculo

Evitar discusiones largas

Sin conversaciones separadas

… Entorno y clima de trabajo Reunión diaria XP


Entorno y clima de trabajo

Gantt de Pared

Obtenida de www.agiletek.com

“Centro del universo del proyecto”

“Punto de reunión para la “Stand-up Meeting”


XP en la práctica (i) Retroalimentación a escala fina: Desarrollo guiado por pruebas Planificación iterativa Cliente como parte del equipo Programación en pares

Proceso continuo: Integración continua Refactorización Liberación pequeña, entregas frecuentes


XP en la práctica (ii)

Entendimiento compartido: Diseño simple

Metáforas del sistema

Propiedad colectiva del código

Estándares de codificación

Bienestar del programador:

Ritmo sostenible (Semanas de 40 horas)


Diseño simple

El diseño debe ser lo más simple posible: no introducir

estructura, ni funcionalidad antes de tiempo.

Se puede añadir complejidad más adelante.

Inconveniente: Vencer la tendencia al “gran diseño previo”


Pruebas automatizadas (i) Todo código que puede fallar debe tener una prueba.

Hacer la prueba aún antes de la implementación.

Inconveniente: Obliga a imponer una forma de trabajar y puede ser necesaria formación/experiencia.

Dos tipos: Prueba de Unidad (o del Programador) y Prueba de Aceptación (o Funcional, o del Cliente).

La Prueba de Aceptación es una prueba formal conducida para determinar si un sistema satisface los criterios de aceptación y permite al cliente determinar si acepta o no el sistema.


Pruebas automatizadas (ii) Para cada lenguaje de programación hay herramientas de Prueba

de Unidad que permiten automatizar la ejecución de las mismas, como JUnit para Java. (ver http://www.xprogramming.com/software.htm)

Frecuentemente una Prueba de Unidad es mejor que un comentario para ayudar a entender por qué una determinada función es necesaria, para demostrar cómo es llamada una función y cuales son los resultados esperados, y para documentar defectos en versiones previas del programa que queremos asegurarnos de que no vuelvan.


http://www.xprogramming.com/software.htm

Integración continua Todos los cambios deben ser integrados a la base del

código al menos diariamente.

Las pruebas deben correr al 100% antes y después de la integración.

Cada nueva versión debe tener la mínima funcionalidad extra que tiene sentido.

Encaja con “release early, release often”

Ventajas: tener realimentación de los usuarios y ofrecer pronto nueva funcionalidad (+éxito).



La Programación en Pares requiere que dos desarrolladores participen en un proyecto en una misma estación de trabajo.

Cada miembro lleva a cabo la acción que el otro no está haciendo en ese momento: Mientras uno redacta Pruebas de Unidad el otro piensa acerca de la clase que satisfará a dicha prueba, por ejemplo.

Los estudios demuestran que, tras aprender Habilidades Personales dos programadores son más que doblemente productivos que uno sólo para una tarea determinada.


http://www.programacionextrema.org/cgi-bin/wiki.pl?PruebasUnidad

http://www.programacionextrema.org/cgi-bin/wiki.pl?HabilidadesPersonales

Refactorización (i)

Es una técnica disciplinada de reestructurar cualquier código existente, alterando su estructura interna sin modificar su comportamiento externo.

¿Si su software fuera un edificio, se parecería mas a uno de la izquierda o de la derecha?


Refactorización (ii)

Si un programa funciona pero está mal diseñado, pronto surgirán problemas a la hora de actualizarlo. Los problemas más comunes pueden ser catalogados como “olor de código” (ya que la acumulación de los mismos provocan que el código apeste).

Existen listas de refactorizaciones. Ejemplo:

Add Parameter

A method needs more information from its caller.

Add a parameter for an object that can pass on this information.


Últimas ideas… El método de desarrollo empleado por la programación extrema y el que suele

llevarse a cabo en la generación de Software Libre tienen grandes parecidos.

Hay algunas prácticas de la programación extrema que no se usan de manera mayoritaria (pruebas de unidad y de aceptación, metáfora y refactorización) y que son muy interesantes y provechosas.

XP y bases de datos: cuidar que tanto BDs relacionales como orientadas al objeto sean flexibles, de manera de migrar fácilmente los datos en caso de cambios.

En cuanto al lanzamiento de cada mini-versión, usar una estación de integración que permite a los desarrolladores observar quién y cuándo se está realizando, manteniendo estabilidad en el sistema.


Referencias http://www.extremeprogramming.org/

http://www.programacionextrema.org/

http://www.jera.com/techinfo/xpfaq.html

http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap

http://clabs.org/caseforxp.htm

http://ootips.org/xp.html

http://www.bobjectsinc.com/cstug/xpslides/

http://www.xp123.com/

http://c2.com/cgi/wiki?XpGlossary


http://www.extremeprogramming.org/

http://www.programacionextrema.org/

http://www.jera.com/techinfo/xpfaq.html


http://clabs.org/caseforxp.htm

http://ootips.org/xp.html

http://www.bobjectsinc.com/cstug/xpslides/

http://www.xp123.com/

http://c2.com/cgi/wiki?XpGlossary

Conclusiones

Apostolado de metodologías exitosas

Aporte de la experiencia práctica a los modelos teóricos

Enfoque de conjunto de prácticas como rompecabezas

Tecnología en expansión

Importancia de revisitar las metodologías desde la

experiencia práctica


Referencias K. Beck, “Embracing change with Extreme Programing”, Computer, Vol. 32, No. 5 Oct.

1999, pp 70-77

L. Williams, R. Kessler, W. Cunningham and R. Jeffries, “Strenghthening the Case for Pair Programing”, IEEE Software, Vol. 17, No. 4 Jul/Aug 2000, pp 19-25

R. Martin, “Extreme Programing Development through dialog”, IEEE Software, Vol. 17, No. 4 Jul/Aug 2000, pp 12-13

C3 Team, “Chrysler goes to “Extremes”, Distributed Computing, Oct 1998, pp 24-28

http://www.xprogramming.com

http://www.extremeprogramming.org



Documents

metodologia xp