- Resumen
- Programación Extrema
(eXtreme Programming) - Actividades de
Xp - Prácticas
Básicas de XP - Ciclo
de Vida - Actores y
Responsabilidades de Xp - Artefactos
Xp - Críticas a
eXtreme Programming - Bibliografía
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.
Página siguiente |