Programacin Extrema

Programación Extrema
El popular proceso de desarrollo puede acelerar la calidad de creación y el impulso de sus
proyectos de redes.
Por Arthur English*
ÀEstá buscando una manera de optimizar la creación del software de redes en su departamento
de Tecnología de la Información? El proceso de desarrollo de peso ligero de programación
extrema podría ser el boleto.
XP ayudó al fabricante de administradores de tráfico IP, Opnix, a reducir el costo de cambio de
curva. Más tarde, en el desarrollo del producto principal del fabricante, el equipo descubrió un
serio gusano en una porción del sistema que había sido escrito varios meses antes. Arreglar el
gusano requirió del rediseño de un componente medular del sistema. El equipo se impuso el reto
y reescribió un 7% completo de su código base en menos de ocho horas, mismo que funcionó
cerca de una línea de código cada minuto y medio por desarrollador. Todas las pruebas de
unidad también corrieron el mismo al final del día, probando que los desarrolladores no habían
roto nada con sus cambios, dice Jiva DeVoe, vicepresidente de desarrollo de software de Opnix.
Conocido por el acrónimo XP antes de que Microsoft comenzara a utilizarlo para Office XP y
Windows XP, la metodología de desarrollo ha causado tanta conmoción como Java, .Net, XML y
los servicios Web. Kent Beck creó XP en 1996 mientras dirigía el proyecto Chrysler
Comprehensive Compensation para reescribir el sistema de nómina del fabricante de autos.
Desde entonces, Beck ha escrito una serie de libros sobre XP para Addison-Wesley, incluyendo
Extreme Programming Explained: Embrace Change.
Las propuestas de XP buscan mejorar la calidad del software, aumentar la productividad y
reducir los costos. "XP ha permitido a nuestra empresa entregar proyectos a tiempo y en
presupuesto, en semanas de 40 horas para clientes en una variedad de entornos de software,
incluyendo C++, Java y hasta Visual Basic", dice Ted Waltman, presidente de la firma de
consultoría IFC.
XP es una evolución, no una revolución, y muchas de sus técnicas han existido por décadas. He
aquí las principales 12 prácticas de XP:
1. La Metáfora guía todo el desarrollo con una simple historia de cómo funciona el sistema
completo. XP estimula historias, que son breves descripciones de una tarea de un sistema en
vez de los más tradicionales diagramas y modelos de Unified Modeling Language. La metáfora
expresa la visión evolutiva del proyecto que define el alcance y propósito del sistema.
2. El Juego de Planeación enmarca la definición de los requerimientos y la planeación del
proyecto. Los usuarios finales definen las características de la aplicación con historias. Los
programadores dan prioridad a las historias y programan lo más importante y difícil para la
siguiente iteración. Solamente los programadores que trabajan en una historia pueden calcular
cuánto tiempo tomará terminar. Tomar las tareas más difíciles primero, es reducir el riesgo global
asociado con el proyecto.
3. Pequeñas Versiones contiene los más valiosos requerimientos de negocios que se utilizan
para construir el sistema. Las versiones deberían ser entregadas cada dos o tres semanas de
manera que los clientes puedan ver y tocar el producto funcionando de manera regular.
4. El Diseño Sencillo desanima a la complejidad. Simple Design se enfoca en proporcionar un
sistema que cubra las necesidades inmediatas del cliente - ni más ni menos. El método
tradicional de construir "ganchos" para una funcionalidad futura lleva a los grandes sistemas a
elementos sustanciales que son inicialmente no utilizados y no probados, y con frecuencia
descartados.
5. La Comprobación es continua. Los programadores escriben pruebas de la unidad para
validar la operación correcta de los módulos antes de escribir el código funcional para el módulo
en desarrollo. Los clientes entonces escriben pruebas de sistema para demostrar que los
requerimientos han sido satisfechos.
6. La Refactorización es el proceso de reestructurar el sistema para eliminar la duplicación,
simplificar el código y agregar flexibilidad sin cambiar la manera en que el código opera. Incluso
si usted no desea comprar XP como un todo, éste es un proceso que debería considerar.
7. Programación por Par implica a dos programadores trabajando juntos para desarrollar y
discutir el código de cada uno de ellos. Este es el aspecto más controversial de XP. Aunque el
pair-programming puede no ser para todo el mundo, la evidencia anecdótica en la lista de correo
de XP ([email protected]) demuestra éxito. Antes de tratar de
implementar esto, su equipo de desarrollo podría querer asistir a un curso de programación de
XP para aprender cómo colaborar al estilo XP.
8. Dominio Colectivo, que permite a cualquier programador cambiar cualquier código en el
sistema en cualquier momento, es similar a la programación de fuente abierta. Este método es
marcadamente diferente a los métodos tradicionales en los que un simple desarrollador posee un
conjunto de códigos. Los proponentes de XP argumentan que mientras más gente trabaje en una
pieza, menos gusanos aparecerán.
Waltman dice que la propiedad de código colectivo juega una parte importante en cubrir las
demandas del usuario para los cambios de sistema. "Los cambios de última hora pueden ser un
esfuerzo de equipo, y no una crisis de carga de trabajo individual asignado", comenta.
9. Integración Continua es una actividad día-a-día. El código es integrado y probado después
de unas cuantas horas o un día como máximo. La integración de un conjunto de cambios al
mismo tiempo simplifica el proceso de integración y deja visible quién es responsable del arreglo
del código cuando las pruebas de integración fallan.
10. Las Semanas Laborales de Cuarenta Horas son altamente propugnadas en los proyectos
XP. Como dice Beck, está bien trabajar tiempo extra cuando se requiere, pero no hay que
hacerlo dos semanas seguidas. Habiendo descansado, los desarrolladores motivados aceleran
la productividad.
11. Cliente en el sitio es una persona designada que trabaja con el equipo y está disponible
para responder preguntas, resolver asuntos y establecer prioridades. El cliente, después de todo,
es el árbitro final de la aceptación del sistema. Este representante del cliente permanece con el
equipo de trabajo durante todo el proyecto.
12. Los Estándares de Codificación o Cifrado son un requerimiento obligatorio -no un
conjunto de lineamientos. Los programadores siguen reglas comunes de manera que todo el
código en el sistema se ve como si hubiera sido escrito por una persona. Se crean normas de
código que funcionen para nuestro equipo y se aplican consistentemente.
XP realmente resplandece en proyectos de entornos de negocios altamente dinámicos en los
que el cambio es la norma. Considere utilizar XP como una forma de mejorar la calidad y reducir
los costos. Aunque usted no pueda comprar la práctica completa de XP, debería considerar la
adaptación de porciones del mismo en combinación con otros métodos que puedan mejorar lo
más importante.
_____