Programación extrema para niños

La Programación Extrema (conocida como XP, por sus siglas en inglés eXtreme Programming) es una forma especial de desarrollar programas de computadora. Fue creada por Kent Beck, quien escribió el primer libro sobre este tema en 1999.

A diferencia de otras maneras más antiguas de crear programas, la Programación Extrema se enfoca mucho en la capacidad de adaptarse a los cambios. Sus creadores piensan que es normal que los requisitos de un proyecto cambien mientras se está trabajando en él. Creen que es mejor poder ajustarse a esos cambios en cualquier momento, en lugar de intentar planear todo al principio y luego esforzarse por no cambiar nada.

Podemos ver la Programación Extrema como una forma de usar las mejores ideas para desarrollar programas, aplicándolas de manera flexible durante todo el tiempo que dura la creación del software.

Historia de la Programación Extrema

La Programación Extrema fue desarrollada por Kent Beck mientras trabajaba en un proyecto de nóminas para una empresa de automóviles. Beck se convirtió en el líder de ese proyecto en 1996 y empezó a mejorar la forma en que se desarrollaba el software. Escribió un libro sobre esta nueva metodología en 1999.

Muchas de las ideas de la Programación Extrema ya existían antes. Lo que hace esta metodología es llevar esas "mejores prácticas" a un nivel más intenso. Por ejemplo, la idea de "escribir las pruebas antes de escribir el código" ya se usaba en proyectos importantes como el Programa Mercury de la NASA en los años 60. En esos proyectos, se creaban los documentos de prueba al mismo tiempo que se desarrollaba el software. La XP lleva esto al extremo, creando pruebas automáticas para validar incluso las partes más pequeñas del código.

¿Cómo Nació la XP?

Dos cosas importantes influyeron en el desarrollo de software en los años 90:

• Por un lado, la programación orientada a objetos se volvió muy popular. Esta es una forma de organizar el código de manera diferente.
• Por otro lado, el crecimiento de Internet hizo que fuera muy importante crear programas rápidamente para que las empresas pudieran competir.

Los requisitos de los proyectos cambiaban muy rápido, lo que hacía que los métodos tradicionales de desarrollo de software fueran difíciles de usar.

El proyecto de nóminas de Chrysler, donde trabajaba Kent Beck, buscaba la mejor manera de usar nuevas tecnologías. Beck fue contratado para mejorar el sistema, pero notó problemas en el proceso de desarrollo. Aprovechó la oportunidad para proponer e implementar cambios, basándose en su trabajo con Ward Cunningham. Beck cuenta que les pidió al equipo que llevaran al máximo las cosas que él consideraba esenciales y que dejaran de lado todo lo demás.

Beck invitó a Ron Jeffries al proyecto para ayudar a desarrollar y mejorar estos métodos. Jeffries se convirtió en el "entrenador" para que el equipo adoptara estas prácticas.

La información sobre la Programación Extrema se compartió con el mundo a través de la primera wiki, la WikiWikiWeb de Cunningham. Muchas personas contribuyeron y expandieron las ideas, lo que llevó a la creación de otras metodologías similares, como el desarrollo ágil de software.

Beck también editó una serie de libros sobre XP, empezando por su propio libro Extreme Programming Explained en 1999, lo que ayudó a que sus ideas llegaran a mucha más gente.

Valores Clave de la Programación Extrema

La Programación Extrema se basa en cinco valores importantes: simplicidad, comunicación, retroalimentación, coraje y respeto.

Simplicidad

La simplicidad es fundamental. Se busca que el diseño del programa sea lo más sencillo posible para que sea más fácil de desarrollar y mantener. Un código complicado puede volverse aún más difícil de entender con el tiempo.

Para mantener la simplicidad, es necesario "refactorizar" el código. Esto significa reorganizarlo y limpiarlo sin cambiar lo que hace, para que siga siendo simple a medida que crece.

También se aplica la simplicidad en la documentación. El código debe tener los comentarios justos, y se busca que el propio código se entienda por sí mismo. Esto se logra eligiendo nombres claros para las variables, funciones y clases.

Cuando se trabaja con simplicidad, junto con la idea de que todos pueden modificar cualquier parte del código y la programación en parejas, se logra que todo el equipo conozca mejor el sistema completo a medida que el proyecto avanza.

Comunicación

La comunicación es muy importante y se da de varias maneras. Para los programadores, un código simple comunica mejor. Si el código es complejo, hay que esforzarse para que sea fácil de leer. El código que se entiende por sí mismo es más confiable que los comentarios, ya que los comentarios pueden quedar desactualizados. Solo se debe comentar lo que no va a cambiar, como el propósito de una clase.

Las pruebas unitarias también son una forma de comunicación, porque muestran cómo se usan las diferentes partes del programa. Los programadores se comunican constantemente gracias a la programación en parejas.

La comunicación con el cliente es constante, ya que el cliente es parte del equipo de desarrollo. El cliente decide qué características son más importantes y siempre debe estar disponible para resolver dudas.

Retroalimentación (Feedback)

Como el cliente está integrado en el proyecto, su opinión sobre cómo va el trabajo se conoce al instante.

Al hacer ciclos de trabajo muy cortos y mostrar resultados con frecuencia, se evita tener que rehacer partes del programa que no cumplen con lo que se esperaba. Esto ayuda a los programadores a enfocarse en lo más importante.

Imagina los problemas de tener ciclos de trabajo muy largos. Meses de esfuerzo podrían perderse por cambios en lo que el cliente quiere o por malentendidos. El código también da retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre la "salud" del código. Ejecutar estas pruebas a menudo permite descubrir errores causados por cambios recientes.

Coraje o Valentía

Muchas prácticas de XP requieren valentía. Una de ellas es diseñar y programar pensando en el presente, no en el futuro lejano. Esto evita que el equipo se quede atascado en un diseño demasiado complejo. La valentía permite a los desarrolladores sentirse cómodos al reorganizar su código cuando sea necesario. Esto significa revisar el sistema y modificarlo para que los cambios futuros sean más fáciles de implementar.

Otro ejemplo de valentía es saber cuándo eliminar código: tener el valor de quitar código antiguo que ya no sirve, sin importar cuánto esfuerzo se invirtió en crearlo. Además, valentía significa persistencia: un programador puede estar sin avanzar en un problema difícil por un día entero, y luego resolverlo rápidamente al día siguiente, solo si es persistente.

Respeto

El respeto se muestra de varias maneras. Los miembros del equipo se respetan entre sí, porque los programadores no pueden hacer cambios que hagan que las pruebas dejen de funcionar o que retrasen el trabajo de sus compañeros. Los miembros respetan su propio trabajo porque siempre buscan la alta calidad en el producto y el mejor diseño posible a través de la refactorización del código. Los miembros del equipo respetan el trabajo de los demás al no menospreciar a nadie, lo que mejora la confianza en el equipo y aumenta su ritmo de trabajo.

Características Principales de la XP

Las características más importantes de este método son:

• Desarrollo iterativo e incremental: Se hacen pequeñas mejoras, una tras otra, en ciclos cortos.
• Pruebas unitarias continuas: Se realizan pruebas automáticas y se repiten con frecuencia, incluyendo las pruebas de regresión (para asegurar que los cambios no dañaron lo que ya funcionaba). Se recomienda escribir la prueba antes de escribir el código. Hay herramientas como JUnit (para Java) o NUnit (para .NET) que ayudan con esto.
• Programación en parejas: Se sugiere que dos personas trabajen juntas en la misma computadora para desarrollar el código. Aunque parezca que se pierde productividad, la calidad del código es mayor porque se revisa y discute mientras se escribe.
• Integración frecuente con el cliente: Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo para que la comunicación sea constante.
• Corrección de todos los errores: Se deben corregir todos los errores antes de añadir nuevas funciones. Se hacen entregas frecuentes del programa funcionando.
• Refactorización del código: Esto es reescribir partes del código para que sea más fácil de leer y mantener, sin cambiar lo que hace. Las pruebas aseguran que no se introduzcan nuevos errores al refactorizar.
• Propiedad del código compartida: En lugar de que cada grupo sea responsable de una parte del programa, este método promueve que todo el equipo pueda corregir y mejorar cualquier parte del proyecto. Las pruebas frecuentes aseguran que los posibles errores se detecten.
• Simplicidad en el código: Es la mejor manera de que las cosas funcionen. Cuando todo funciona de forma simple, se puede añadir más funcionalidad si es necesario. La Programación Extrema cree que es más fácil hacer algo simple y luego cambiarlo si se necesita, que hacer algo complicado que quizás nunca se use.

La simplicidad y la comunicación se complementan muy bien. Con más comunicación, es más fácil saber qué hacer y qué no. Cuanto más simple es el sistema, menos hay que comunicar sobre él, lo que lleva a una comunicación más completa.

Roles en un Equipo XP

Programador

Es quien escribe el código del sistema. Es el corazón del equipo.

Desarrollador de Pruebas (Test Developer)

Crea el código para las pruebas unitarias del sistema. Es un rol muy importante.

Cliente

Escribe las "historias de usuario" (descripciones de lo que el programa debe hacer) y las pruebas para verificar que se implementaron correctamente. Decide qué características son prioritarias y cuáles se harán en cada etapa, buscando siempre el mayor valor para el negocio.

Probador (Tester)

Interpreta lo que el cliente pide y ayuda al equipo a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, comparte los resultados con el equipo y es responsable de las herramientas de prueba.

Rastreador (Tracker)

Se encarga de dar seguimiento al proyecto. Proporciona información al equipo sobre cómo van las cosas. Debe comparar las estimaciones de tiempo con el tiempo real que se tardó, para ayudar a mejorar las futuras estimaciones.

Entrenador (Coach)

Es responsable de todo el proceso. Guía a los miembros del equipo para que sigan las prácticas de XP correctamente.

Consultor

Es una persona externa al equipo con conocimientos específicos en algún tema que el proyecto necesita. Ayuda al equipo a resolver un problema particular. También investiga según los requisitos.

Gestor (Big Boss)

Es el "dueño" del proyecto y el enlace entre los clientes y los programadores. Su trabajo principal es la coordinación.

Para Saber Más

• Historias de usuario
• Informática
• Programación
• Programación en pareja
• Manifiesto ágil

Véase también

En inglés: Software development Facts for Kids