Programación extrema

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:

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