PDF de programación - Extreme Programming

Extreme Programming

(Programación extrema)

Ing. Mauricio Campos

Universidad Tecnológica Nacional
Facultad Regional Buenos Aires

Buenos Aires, Argentina





Julio 2004

[email protected]

“Luego que un proyecto termina sabremos suficiente para hacer un buen plan, pero este ya no es útil”

Es una metodología liviana para equipos
chicos a medianos que afronten
requerimientos vagos o cambiantes.

2 CONCEPTOS GENERALES
El equipo XP incluye desarrolladores,
manager y clientes, todos trabajando
juntos, haciéndose preguntas, negociando
alcances y cronogramas y creando las
pruebas de funcionalidad. El grupo de
programadores es pequeño, generalmente
entre 2 y 12 personas.
El principal objetivo es entregar el
software requerido cuando es requerido.
Para lograrlo la metodología utiliza
herramientas de buenas prácticas de
desarrollo de software.

3 LAS MEJORES PRACTICAS
Metáfora de sistema: Cada proyecto
tiene una metáfora que provee una
convención de nombres fácil de recordar.
Diseño simple: Siempre utiliza el diseño
mas simple posible que cumpla el trabajo.
Pruebas continuas: Los equipos de XP
se enfocan en la validación del software
en todo momento. Los programadores
escriben las pruebas antes que el código.
Re-factoring: Re-factor elimina
cualquier línea de código duplicada
durante la etapa de codificación. Es el
proceso de cambiar el código para
mejorar la estructura mientras evoluciona.
Programación en pareja: El código es
escrito por dos programadores sentados
en una máquina. Esencialmente todo el
código es revisado mientras es escrito.

RESUMEN
Los proyectos de desarrollo de software
están rodeados de riesgos. La capacidad
para lidiar con ellos es esencial para el
éxito. Las dos categorías de
administración de riesgos son:
Anticipación o elasticidad.
Anticipación tiende a identificar y resol-
ver todos los posibles problemas antes de
programar. Esta lógica es aceptada por los
métodos clásico y es muy costosa en
ambientes de constantes cambios.
Por otro lado la elasticidad es la
capacidad de afrontar con éxito los
peligros imprevistos, luego de que se
hayan manifestado. Este es el principal
criterio de Programación extrema (XP)
[Kent Beck].
XP puede ser descripta con tres palabras:
Simplicidad–Comunicación-Feedback

Keywords
XP; extreme programming; desarrollo de
software; proceso de desarrollo liviano.

1 INTRODUCCION
El ambiente instable que rodea a los
proyectos de desarrollo de software hace
imposible el uso de las técnicas clásicas,
como ser “método de cascada”. Los
resultados insatisfactorios y la necesidad
de tener un modo eficiente que guíe el
proceso de desarrollo ha hecho que
personas alrededor del mundo comiencen
a crear técnicas, mas adaptadas a la
realidad. Programación extrema (XP) es
una de ellas.



1

Integración continua: Todos los
cambios son integrados en el código base
por lo menos un vez al día.
Pequeños Releases (lanzamientos):
Comenzar con el conjunto de
funcionalidades útiles mas pequeño.
Agregar continuamente porciones de
funcionalidad en cada lanzamiento.
Semana laboral de 40 horas: Los
programadores se van a casa a tiempo.
Continuas horas extras es considerado un
indicador de que el proceso y/o
cronograma están mal.
Cliente In-situ : Del equipo de
desarrolladores tienen continuo acceso
continuo a un cliente, este debe ser
alguien que vaya a utilizar el sistema.
Codificación estándar: Todos codifican
bajo el mismo estándar Lo ideal sería no
poder identificar, al mirar el código, por
quien fue escrito.
Código colectivo: A nadie le “pertenece”
un módulo. Cualquier desarrollador debe
poder trabajar en cualquier parte del
código base en cualquier momento.

4 DICCIONARIO SINTETICO
Carta: Término genérico para describir a
una tarea o historia.
Entrenador (Coach): Un desarrollador
con experiencia quien enseña y guía a los
otros a través de la metodología XP.
Cliente: Es la persona que dirige los
requerimientos. Es aconsejable que sea un
usuario final o un gerente de producto.
Días/semanas ideales de programación:
Se refieren a cuanto toma (en días o
semanas) completar una tarea si esto es tu
única actividad y no hay distracciones.
Iteración: Unidad de tiempo al cabo de la
cual una versión del software es
internamente lanzada
(Típicamente dura entre 1 a 3 semanas)
Programación en parejas: Dos
desarrolladores sentados juntos en una
máquina y escribiendo el código
operativo.
Lanzamiento: Unidad de tiempo al cabo
de la cual una versión del proyecto será
lanzada al usuario final(pocas iteraciones)

Pizarra de historias: Pizarra en la cual
son desplegadas las tarjetas de historias y
tareas divididas en iteraciones y
lanzamientos.
Historia: Un Caso de uso simplificado
que provee valor agregado al cliente.
Tarea: Tarea del desarrollo que
normalmente solo cumple parcialmente la
funcionalidad de una historia.
Clima de ayer: Modo simple de conocer
cuanto trabajo puede hacerse en una
iteración. Se calcula a partir de cuanto
trabajo se hizo en la ultima iteración.

5 PIEDRAS ANGULARES
•

Pruebas – (Unidad de prueba)
♦

Las unidades de pruebas son
escritas antes que el código y son
puestas dentro del mismo
repositorio con el código.
Código sin pruebas no será
aceptado.
Requiere que todo el código pase
todas las unidades de prueba.
Asegurando así que todas las
funcionalidades trabajan bien.

♦

♦

•

•

Doble chequeo – (Programación en
pareja)
♦

Todo el código es escrito por dos
programadores trabajando en la
misma máquina, ellos
constantemente chequean el
código de cada uno y comparten
opiniones.
Esta práctica asegura que todo el
código es revisado, esto resulta en
mejor diseño, mejor prueba, y
mejor código.

♦

Simpleza – (Hacerlo fácil)
♦

Los métodos de diseño y
programación en XP tienden a ser
tan simples y confiables como sea
posible.
“Un diseño simple siempre toma
menos tiempo que uno complejo.
Hazlo de la manera mas simple
que funcione. Mantén las cosas
tan simple como sea posible el
tiempo que sea posible, mediante

♦



2

•

nunca agregar funcionalidades
antes de lo previsto”

♦

Comunicación – (Usuario experto)
Trabaje con un cliente, quien se
♦
convertirá al final del proyecto en
un usuario experto.
El cliente debe ser alguien que
conozca las metas del negocio y
las funcionalidades requeridas del
software.
Durante todas las fases se requiere
comunicación con este cliente,
preferentemente cara a cara en el
lugar.
Funciones principales del cliente:
(cid:131) Escribir las “Historias de

♦

♦

Usuario”.

(cid:131) Asignar las prioridades.
(cid:131) Negociar las “Historias de

Usuario” para que sean
incluidas en los lanzamientos.

(cid:131) Negociar los momentos de
cada pequeño lanzamiento.


6 PASO A PASO
El Nuevo proyecto XP comienza
recolectando las historias de usuario[7] y
llevando a cabo las spike solutions[8.1]
para los puntos que parecen ser riesgosos.
Esto lleva entre 2 y 4 semanas.
Cuando esto se encuentra terminado ya
conoceremos los costos estimados y
conoceremos el perfil del sistema. Luego
estamos listos para crear el
(necesariamente impreciso) cronograma
del proyecto, con el cual todos están de
acuerdo, esto se llama “Plan del
Lanzamiento”[9]. Hasta el primer plan es
suficientemente confiable para tomar las
decisiones, de todos modos el equipo XP
revisa el plan regularmente.
El desarrollo comenzará con una reunión
de plan de iteración [10]. Esta reunión es
una practica mediante la cual el equipo
recibe instrucciones cada par de semanas.
El equipo construye software en
iteraciones bisemanales, entregando un
utilitario funcional al fin de cada
iteración.

Durante el planeamiento de la iteración el
cliente presenta las funcionalidades
deseadas para las próximas dos semanas.
Los programadores las quiebran en tareas
y estiman su costo (a un nivel mas fino de
detalle que en el Plan de Lanzamiento).
Basándose en la cantidad de trabajo
terminado en la anterior iteración, el
equipo acuerda lo que será encarado en la
presente iteración.

7 HISTORIAS DE USUARIOS
Las historias de usuario se utilizan en
reemplazo de grandes documentos de
requerimiento y ellas son escritas por el
cliente (quien trabajará con el equipo de
desarrollo a lo largo de todo el proyecto)
como las cosas que quiere que el sistema
haga para El, en sus propias palabras y sin
terminologías de sintaxis técnica.
Las historias de usuario están en un
formato de aproximadamente tres
oraciones (la tarjeta que se utiliza para
escribirlas también las limita). Ellas solo
deben proveer suficiente detalles para
hacer una razonable estimación de cuanto
tiempo llevará implementar la historia.
Cuando llegue el momento de
implementar la historia, los
desarrolladores irán con los clientes para
recibir una descripción detallada del
requerimiento.
El tiempo ideal de desarrollo (entre 1 y 3
semanas) es estimado por los
desarrolladores y muestra cuanto tiempo
llevaría implementar la historia en caso
de que no hubiese otras tareas ni
distracciones y uno sabe exactamente que
hacer. Mas allá de tres semanas significa
que la historia debe ser quebrada en mas
de una. Menos de una semana significa
que debe ser combinada con otra historia.
El número óptimo para crear un plan de
lanzamiento es entre 100 a 60 historias de
usuario.




3

8 METAFORA
La arquitectura del sistema es construida
para guiar la “Integridad Conceptual” (la
consideración mas importante en el
diseño de sistemas). En cambio de una
arquitectura formal XP utiliza un
conjunto de metáforas. La metáfora es
una simple historia compartida, que
muestra como el sistemas funciona.
Esta historia típicamente abarca un
puñado de clases y paterns que moldean
el esqueleto del sistema en construcción.

El tener la habilidad de adivinar como
algo s