A propósito de programación extrema XP (eXtreme Programming)

Partes: 1, 2

1. RESUMEN

Xp forma parte del conjunto de métodos ágiles que centran sus prioridades en las personas, no en los procesos, en la actualidad Xp se proyecta a ser un modelo de desarrollo común, sencillo y adaptable a las características cambiantes y exigentes de empresas y clientes, es por ello que en este documento se presentan en forma resumida las características principales, las actividades, las prácticas, el ciclo de vida, los artefactos y las críticas a esta metodología recopiladas en el transcurso de la investigación.

2. INTRODUCCIÓN

Los métodos ágiles surgen como una inflexión en un momento o contexto definido, en donde se hace necesario una renovación metodológica que busca satisfacer la necesidad de realizar los proyectos de una forma más rápida sin disminuir la calidad del mismo pero sí reducir documentación, pasos, procesos y tiempo. Indistintamente en el año 2001 firman para Xp en el manifiesto ágil Kent Beck, Ward Cinningham, Martin Fowler, James Grenning, Ron Jeffries, Brian Marick, y Robert C. Matin, poco después y hasta hoy surge un gran número de libros y escritos que describen los pasos para aplicar esta metodología.

3. PROGRAMACIÓN EXTREMA XP (eXtreme Programming)

Metodología ágil basada en cuatro principios: simplicidad, comunicación, retroalimentación y valor. Además, orientada por pruebas y refactorización, se diseña e implementan las pruebas antes de programar la funcionalidad, el programador crea sus propios tests de unidad.

Este método es típicamente atribuido a Kent Beck, Ron Jeffries y Ward Cinningham. El objetivo de Xp son grupos pequeños y medianos de construcción de software en donde los requisitos aún son muy ambiguos, cambian rápidamente o son de alto riesgo. Xp busca la satisfacción del cliente tratando de mantener durante todo el tiempo su confianza en el producto. Además, sugiere que el lugar de trabajo sea una sala amplia, si es posible sin divisiones (en el centro los programadores, en la periferia los equipos individuales). Una ventaja del espacio abierto es el incremento en la comunicación y el proporcionar una agenda dinámica en el entorno de cada proyecto.

4. Actividades de Xp

4.1. Codificar

Es necesario codificar y plasmar nuestras ideas a través del código. En programación, el código expresa la interpretación del problema, así podemos utilizar el código para comunicar, para hacer comunes las ideas, y por tanto para aprender y mejorar.

4.2. Hacer pruebas

Las características del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas dan la oportunidad de saber si lo implementado es lo que en realidad se tenía en mente. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema, entonces habremos acabado por completo.

4.3. Escuchar

[5] nos menciona en una frase, "Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio software ¿para qué nos querrían?".

Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la información. Tenemos que escuchar a nuestros clientes cuáles son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fácil y difícil de obtener, y la realimentación entre ambos nos ayudan a todos a entender los problemas.

4.4. Diseñar

El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, lo apropiado es dividirla en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes.

Resumiendo las actividades de Xp: Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para poder codificar, probar y escuchar indefinidamente.

Partes: 1, 2

Página siguiente