Programación extrema
La
programación extrema es un ciclo de vida de software de desarrollo ágil y
orientado a objetos que fue propuesto por Kent Beck en el año 1999 y buscaba la
creación de software de una forma más rápida y de mejor calidad.
La
programación extrema funciona de una forma diferente que los ciclos de vida
convencionales. Los primeros ciclos de vida de software, como el modelo de
cascada, buscaban hacer un gran análisis para conseguir requerimientos y usar
estos para guiar a los programadores por las etapas de diseño y desarrollo,
buscando solamente controlar los cambios en los requerimientos a medida que se
avanza; por otro lado, la programación extrema busca eliminar los
requerimientos y adaptarse a los cambios que pida el cliente durante cualquier
etapa del ciclo de desarrollo, ya que, se afirma que adaptarse a los cambios
que pida el cliente durante el proceso es una forma un poco más realista de
desarrollar que pretender definir todo al inicio y solo controlar los cambios.
La programación
extrema se puede graficar de la siguiente manera:
.png)
Planificación
Durante la
etapa de planificación se crean las denominadas “historias de usuario”, las
cuales son hechas por el cliente donde el mismo define las prioridades y
explica las diferentes historias para que la entienda el equipo de
programadores, luego, los programadores comienzan a decidir cuál es la forma
más la forma más óptima de resolver el caso en las fechas propuestas, pensando
en el cliente (¿Qué se debe hacer?, ¿En que fecha se necesita?...) y en ellos
mismos (¿Cómo organizar el trabajo en equipo?, ¿Cuánto lleva implementar esta
característica?...), de esta forma, se crean pequeñas versiones para resolver
los problemas, las cuales deben ser lo más pequeñas posibles y con los
requisitos más importantes para el cliente (todas estas versiones deben tener
sentido como un todo).
Diseño
En esta
etapa se crean diseños simples que pasen todas las pruebas creadas para ellos
en la planificación, deben tener pocas clases y métodos, sin lógica duplicada y
deben manifestar claramente lo importante para que los programadores creen una
buena codificación en el siguiente paso.
Codificación
Una de las
acciones principales de esta etapa es la “Recodificación”, la cual consta de
simplificar el código echo anteriormente sin que este pierda funcionalidad,
cabe destacar que esto solo debe hacerse si el sistema lo pide, no en base a
simples especulaciones. Toda esta etapa debe realizarse en parejas y cada
pareja frente a un computador trabajando en conjunto siguiendo todas un mismo
estándar de codificación, la idea es que uno de ellos codifique pensando en la
mejor forma de hacerlo mientras que el otro piensa más estratégicamente cosas
como: “¿Funcionará de esta forma?” o “¿Fallará alguna prueba de esta forma?” y
siempre tomando en cuenta que cualquiera de los dos puede implementar nuevas
ideas o codificaciones, el código no es propiedad de uno solamente. Luego,
todas las parejas de trabajo deben de reunir sus códigos y realizar pruebas del
sistema en su totalidad al menos una vez al día. Es importante que el cliente
este presente durante este proceso, ya que, se necesita para que los
programadores resuelvan dudas o aclaren aspectos del sistema de forma rápida.
Evaluación
En la última
etapa se le realizan pruebas a cada uno de los aspectos del sistema, los
programadores crean pruebas para probar el funcionamiento y el cliente realiza
pruebas funcionales, si todas las pruebas de aceptación dan un buen resultado
el sistema pasa a ser implementado, lo cual nos da como resultado un programa
de muy buena calidad y que es capaz de adaptarse a diferentes cambios con el
tiempo.
Ventajas
-Buen
cumplimiento de los plazos.
-Programación
más sencilla.
-Constante
proceso de pruebas.
-Buena
calidad del trabajo.
-El cliente
posee el control con respecto a sus prioridades.
-Clientes
satisfechos.
-Perfecto
cuando los requerimientos cambian constantemente.
-Funciona
muy bien para proyectos pequeños.
Desventajas
-En
proyectos más grandes, o de mayor valor, no es recomendable.
-Se necesita
tener un entorno que permita la implementación constante de pruebas.
-Es
preferible que los programadores estén en un mismo lugar y en un ambiente
físico adecuado para poder reunirse y agruparse a pares.
-Débil en
diseño y documentación, por lo cual no debe usarse cuando la seguridad es
primordial.
-Mayor
consumo de tiempo y recursos por la programación a pares.
-El exceso
de pruebas retrasa el desarrollo.
-Es solo
orientada a objetos.
-No es tan
eficiente si el cliente no está en todo momento disponible.
Conclusión
Desde mi
punto de vista, la programación extrema me parece muy interesante, porque me
doy cuenta que se preocupa de aspectos como la moral del equipo y la
simplicidad de código para los programadores sin dejar para nada de lado la calidad
y la satisfacción para el cliente. Aunque este ciclo de vida no sea muy
aplicable a proyectos más grande, no cabe duda de que da muy buenos resultados
a los demás proyectos y es una forma muy agradable y rápida para desarrollar
sistemas de buena calidad.
Autor: Edwards Sepúlveda
