Practicas XP

PRÁCTICAS BÁSICAS DE XP

De forma aislada, cualquier práctica individual de Xp tiene poco sentido, pero en conjunto, unas compensan las carencias que las otras puedan tener.

• El juego de la Planificación - (PlanningGame)

El alcance de la siguiente versión está definido por las consideraciones de negocios (prioridad de los módulos, fechas de entrega) y estimaciones técnicas (estimaciones de funciones, consecuencias).

El objetivo del juego es maximizar el valor del software producido, La estrategia es poner en producción las características más importantes lo antes posible, Las Piezas clave son las StoryCards, Los Jugadores son los desarrolladores y el cliente y las Movidas son Exploración, Selección y Actualización.

• Versiones Pequeñas (Short Releases)

Un sistema simple se pone rápidamente en producción. Periódicamente, se producen nuevas versiones agregando en cada iteración aquellas funciones consideradas valiosas para el cliente

• Metáfora del Sistema (Metaphor)

Cada Proyecto es guiado por una historia simple de cómo funciona el sistema en general, reemplaza a la arquitectura y debe estar en lenguaje común, entendible para todos (Cliente y Desarrolladores), esta puede cambiar permanentemente.

• Diseño Simple (Simple Designs)

El sistema se diseña con la máxima simplicidad posible (YAGNY - "No vas a necesitarlo"), Se plasma el diseño en tarjetas CRC (Clase – Responsabilidad- Colaboración), no se implementan características que no son necesarias, con esta técnica, las clases descubiertas durante el análisis pueden ser filtradas para determinar qué clases son realmente necesarias para el sistema.

• Pruebas Continuas (Testing)

Los casos de prueba se escriben antes que el código. Los desarrolladores escriben pruebas unitarias y los clientes especifican pruebas funcionales.

• Refactorización (Refactoring)

Es posible reestructurar el sistema sin cambiar su comportamiento, por ejemplo eliminando código duplicado, simplificando funciones, Mejorando el código constantemente, si el código se está volviendo complicado se debería modificar el diseño y volver a uno más simple. Refactoring (Modificar la forma del código sin cambiar su funcionamiento).

• Programación por parejas (Pair Programming)

El código es escrito por dos personas trabajando en el mismo computador. "Una sola maquina con un teclado y un mouse"

• Posesión Colectiva del Código (CollectiveCodeOwnership)

Nadie es dueño de un módulo. Cualquier programador puede cambiar cualquier parte del sistema en cualquier momento, siempre se utilizan estándares y se excluyen los omentarios, Los test siempre deben funcionar al 100% para realizar integraciones con todo el código permanentemente.

• Integración continua (ContinuousIntegration)

Los

...