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 cambios se integran en el código base varias veces por día. Todos los casos de prueba se deben pasar antes y después de la integración, se dispone de una máquina para la integración y se realizan test funcionales en donde participa el cliente.

• Semana laboral de 40 horas (40-Hour Week)

Cada Trabajador trabaja no más de 40 Horas por semana. Si fuera necesario hacer horas extra, esto no debería hacerse dos semanas consecutivas. Sin héroes, esto hace que se reduzca la rotación del personal y mejora la calidad del producto.

• Cliente en el Sitio (OnSiteCustomer)

El equipo de desarrollo tiene acceso todo el tiempo al cliente, el cual esta disponible para responder preguntas, fijar prioridades, etc. Esto no siempre se consigue; Un cliente muy Junior no sirve y un cliente muy Sénior no es disponible. "Lo ideal es un cliente Analista".

• Estándares de Codificación (Coding Standard)

...