Prcticas de la Programacin

Extrema
Las prcticas sugeridas por la programacin extrema son el resultado de la
experimentacin de muchos equipos de desarrollo. Es posible que no todas
las prcticas sean las ms convenientes para nuestro equipo, lo importante
es implementar aqullas que nos permitan seguir los principios XP y ser
productivos. Veamos algunas de las prcticas sugeridas para cada etapa de
desarrollo:

Planificacin

Se obtienen requerimientos en forma de historias de usuario

Una historia de usuario no es ms que una breve frase que describe
alguna funcionalidad o caracterstica del sistema, que luego debe ser
implementada por el equipo de desarrollo.

Se planifica para desarrollar en pequeos incrementos

Al planificar para pequeos incrementos, minimizamos los riesgos
asociados a costos, tiempos, errores en los programas y dems.

Las iteraciones deben ser cortas, alrededor de dos semanas

La iteracin es la unidad bsica de desarrollo en un proyecto XP. En cada
iteracin se deben implementar un pequeo grupo de historias de usuario,
preferiblemente puntuales e independientes. Adems, la duracin de las
iteraciones se debe tratar de mantener constante lo largo del proyecto.

Se debe hacer una planificacin al inicio de cada iteracin

Al inicio de cada iteracin debemos evaluar el resultado de la iteracin
anterior. Fueron todas las historias implementadas correctamente?
Surgieron problemas inesperados durante el desarrollo? Necesitamos
ajustar algn procedimiento o tcnica?

Luego de tomar estos puntos en consideracin podremos planificar el trabajo

a realizarse en la siguiente iteracin. En esta planificacin debemos definir
las historias de usuario a implementarse y dividirlas en tareas ms
pequeas. Luego, cada miembro del equipo se puede hacer responsable por
la realizacin de una o ms tareas.

Administracin

Se trabaja en un espacio abierto y fluido

Un espacio abierto, donde dos o ms compaeros puedan reunirse a
discutir ideas, programar juntos, o hacer diagramas en el tablero, puede
potenciar enormemente la comunicacin dentro del equipo.

Se designa un paso sostenible para el desarrollo

En cada iteracin se deben especificar la cantidad de historias de usuario a
realizar tomando en cuenta los costos de cada historia. Es importante
asignar una cantidad razonable y no tratar de abarcar ms de la cuenta,
ya que esto slo lleva a horas de sobretiempo, trabajos mal hechos y un
equipo descontento.

La velocidad y el tiempo siempre deben ser medidos

Para poder establecer un paso sostenible, es de suma importancia conocer
el tiempo real que le toma al equipo llevar a cabo las tareas. Tambin
debemos conocer la cantidad real de historias de usuario que el equipo
puede implementar por iteracin. Entre ms exactos sean estos datos,
mejores estimados podremos hacer al planificar.

Todos los das se debe hacer una pequea reunin

Se recomienda hacer una reunin breve y puntual cada maana, donde los
miembros del equipo puedan comentar sobre cualquier cambio que se ha
dado o compartir informacin que sea relevante para los dems.

Mover a la gente constantemente

Al mover a la gente y fomentar la interaccin dentro del equipo, nos
aseguramos que el conocimiento sea distribuido y adems evitamos los
cuellos de botella.

Hacer ajustes cuando sean necesarios

Si algo no est funcionando, hay que arreglarlo. Por ejemplo, se puede
empezar siguiendo las recomendaciones XP, pero no se debe dudar en
hacer cambios cuando sea necesario.

Diseo

Disear para la simplicidad

El diseo del sistema siempre debe cumplir con los principios KISS (Keep It
Simple, Stupid) y TUBE (Testable, Understandable, Browsable,
Explainable). Testable: El sistema debe poder comprobarse mediante
pruebas automatizadas y unit testing. Understandable: El diseo debe ser
fcil de entender para el equipo. Browsable: A la hora de encontrar algo
(una variable, una clase, etc.), el sistema debe facilitarlo. Explainable:
Debe ser fcil explicarle el sistema a una persona nueva que llegue al
equipo.

Utilizar metforas del sistema

Es til generar metforas que expliquen caractersticas del sistema
comparndolo con conceptos sencillos. Por ejemplo, un sistema que utilice
colas se puede comparar con una cafetera con una sola fila.

Utilzar tarjetas CRC (Clase, Responsabilidad, Colaboracin)

Las tarjetas CRC son la principal herramienta de modelado para XP. En una
sesin CRC, cada tarjeta representa un objeto. La clase del objeto se
puede escribir arriba, las responsabilidades a la izquierda y las clases con
las que colabora a la derecha. Esta tcnica permite que todo el equipo
pueda contribuir en el diseo, y fomenta el pensamiento orientado a
objetos.

No aadir funcionalidad antes de tiempo

Es importante desarrollar nicamente lo necesario para completar la
historia de usuario que estamos implementando, y no perder tiempo y
energa desarrollando funcionalidad que probablemente no sea utilizada.
Si algo es realmente necesario, ya habr tiempo ms adelante para
implementarlo cuando las historias de usuario lo requieran.

Resolver dudas mediante cdigo (spike solutions)

Un spike solution es un programa pequeo que intenta solucionar un
problema especfico. Cuando no estemos seguros de cmo resolver un
problema, es recomendable realizar uno o varios spike solutions para
encontrar la mejor alternativa. Los spike solutions son utilizados
nicamente para entender el problema y son descartados ms adelante.

Refinar siempre que sea posible (refactor)

El refinamiento es de suma importancia para mantener el sistema
trabajando en ptimas condiciones. Cuando eliminamos la redundancia,
simplificamos el diseo o eliminamos cdigo problemtico, estamos
refinando.

Desarrollo

El cliente siempre est disponible

En XP se recomienda que el cliente (o al menos un experto que lo
represente) est siempre con el equipo de desarrollo, convirtindose en un
miembro ms del equipo. Junto al equipo de desarrollo, el cliente debe
escribir las historias de usuario, asignar prioridades y tomar decisiones.

Cumplimiento de estndares y convenciones

Desarrollar de acuerdo a los estndares facilita la colaboracin dentro del
equipo y la creacin de componentes reutilizables.

Las pruebas se programan primero

Al progamar las pruebas primero obtenemos una mejor comprensin del
problema y nos aseguramos que no se nos va a olvidar (o nos va a dar
pereza) realizar las pruebas ms adelante.

Programacin en parejas
Dos cabezas piensan (y programan) mejor que una. Adems, la
programacin en pareja permite que el conocimiento se distribuya
correctamente a travs del equipo.

Desarrollar en paralelo pero integrar de manera secuencial

Se desea que los miembros del equipo puedan desarrollar en paralelo,
evitando los retrasos que conlleva el desarrollo en cascada. Sin embargo,
la integracin de los resultados se debe hacer de manera secuencial. De
esta forma nos aseguramos de no introducir bugs silenciosos o romper con
el cdigo de otra persona. Para esta tarea se pueden utilizar sistemas de
manejo de versiones como CVS, Subversion o Git.

Integrar constantemente
Como los programadores estarn desarrollando en paralelo, es probable
que en algn momento se puedan desviar demasiado de la lnea principal
de cdigo (llamada trunk), y luego les sea muy difcil integrar esa
funcionalidad de vuelta. Al integrar constantemente nos ahorramos ese y
otros tipos de problemas.

Fomentar la propiedad colectiva del cdigo

Cuando todo el equipo se siente duea de todo el cdigo, la colaboracin
se hace mucho ms amena y desinteresada. Se desean evitar actitudes
como: "ese error es culpa de X persona, y le corresponde a esa persona
arreglarlo" y en cambio fomentar la cooperacin.

Pruebas

Todo cdigo debe tener su prueba unitaria

Las pruebas unitarias son pruebas que aseguran que un mdulo especfico
de software, aislado del resto del programa, funciona correctamente. Antes
de desarrollar cualquier cdigo se deben escribir las pruebas unitarias del
mismo para asegurarnos que ste funciona como es debido.

Todo cdigo debe pasar todas las pruebas unitarias del sistema
Adems de pasar sus propias pruebas unitarias, antes de integrar nuevo
cdigo debemos asegurarnos que ste no introduce bugs o rompe con
funcionalidad ya existente. Para esto, corremos una prueba automatizada
que verifique las pruebas unitarias de todo el sistema.

Cuando se encuentra un error se deben disear mejores pruebas

Si se encuentra un error en produccin, significa que alguna prueba
unitaria estaba incorrecta o haca falta. Es importante no slo corregir el
error, sino tambin generar las pruebas que eviten que este tipo de
errores sea pasado por alto nuevamente.

Se deben correr pruebas de aceptacin con frecuencia, y los resultados

deben ser publicados en un lugar visible
Las pruebas de aceptacin provienen de las historias de usuario, y nos
indican si una historia ha sido implementada correctamente. Ninguna
historia de usuario puede ser marcada como terminada si no se han
pasado todas sus pruebas de aceptacin. Se recomienda que los
resultados de estas pruebas de aceptacin estn siempre accesibles a
todo el equipo de desarrollo.