Los 5 valores de la programación extrema (XP)

La Programación Extrema “Extreme Programming” (XP) no es un conjunto de reglas a seguir, sino una forma de trabajar en armonía con los valores personales y organizacionales, que tiene su punto de partida en cinco valores fundamentales.

En este artículo, se describen los cinco valores de XP, que son: Comunicación, Simplicidad, Retroalimentación, Coraje y Respeto. Estos valores no son un simple ardid de mercadeo sino que realmente son parte integral de la metodología.

Los valores XP representan un excelente punto de partida para entender los cambios de paradigmas que implica trabajar bajo la filosofía ágil.

Les invitamos a leer y a contarnos, ¿Han aplicado los valores de XP en su trabajo?, ¿Que opinan del resultado?, ¿Cuales ventajas y desventajas han visto?. Les invitamos a dejar sus mensajes y preguntas en la sección de comentarios del artículo.

Presentamos a continuación los 5 valores de XP:

Comunicación

Los valores de Extreme Programming están publicados en el sitio extremeprogramming.org.

En lo referente a la comunicación establece: “Todos son parte del equipo y nos comunicamos cara a cara todos los días. Trabajamos juntos en todo, desde los requerimientos hasta la programación. En equipo crearemos la mejor solución al problema.”

En los métodos tradicionales de desarrollo de software, la comunicación de los requerimientos a los desarrolladores se realiza a través de la documentación, por ejemplo las Especificaciones de Diseño en el Rational Unified Process (RUP).

XP rompe con este esquema, la comunicación se realiza por medio de transferencia de conocimientos en reuniones frecuentes cara a cara entre usuarios y desarrolladores, lo que le da a ambos una visión compartida del sistema.

Por ello, XP favorece diseños simples, colaboración de usuarios con programadores, comunicación verbal frecuente, retroalimentación y construcción rápida del software.

Simplicidad

La simplicidad implica que: “Desarrollaremos lo que sea solicitado y necesario, pero no más que eso. De esa forma, se maximiza el valor de la inversión realizada. Nos dirigiremos a nuestro objetivo a pasos simples y pequeños, mitigando las fallas a medida que ocurran. Crearemos algo de lo cual podamos sentirnos orgullos y que pueda mantenerse en el largo plazo a costos razonables.” (Cita de extremeprogramming).

En XP se comienza desarrollando las soluciones más sencillas necesarias para solucionar los problemas (requerimientos) que se están viendo en ese momento, añadiendo funcionalidad extra más tarde, en la medida en que se obtiene más información de los requerimientos. La diferencia respecto a esquemas tradicionales es que se enfoca en las necesidades de hoy en lugar de las necesidades de mañana, la semana que viene o el mes que viene.

La ventaja es que no se invierte esfuerzo en futuros requerimientos que podrían cambiar o que no se vayan a necesitar.

Asimismo, un diseño y programación simple mejora la calidad de las comunicaciones, pues es más fácil de implementar y entender por todos en el equipo.

Retroalimentación (Feedback)

Según extremeprogramming el valor de la retroalimentación establece: “Nos tomaremos seriamente los compromisos con el usuario establecidos en todas las iteraciones, entregando software en funcionamiento en cada una. Mostraremos al usuario nuestro software frecuentemente y de forma temprana, escuchando cuidadosamente sus observaciones y realizando los cambios que sean necesarios. Adaptaremos nuestros procesos al proyecto y no al contrario”.

Según Wikipedia, La retroalimentación actúa en tres dimensiones:

• Retroalimentación del sistema: Por medio de la ejecución de pruebas unitarias y de integración, los programadores reciben retroalimentación directa del estado del sistema.

• Retroalimentación del cliente (usuario): Las pruebas de aceptación, son diseñadas conjuntamente por el cliente y los analistas de pruebas, obteniendo en conjunto retroalimentación del estado actual del sistema. Esta revisión puede hacerse cada 2 o 3 semanas, permitiendo así que el cliente sea quien guíe el desarrollo del software.

• Retroalimentación del equipo: Cuando el cliente trae nuevos requerimientos, el equipo puede directamente proporcionar la estimación del tiempo que tomará implementarlos.

Bajo este esquema, las fallas de sistema se pueden comunicar fácilmente, pues existen pruebas unitarias que demuestran que el sistema fallará si es puesto en producción. Asimismo, un cliente puede probar el sistema periódicamente, contrastando el funcionamiento con sus requerimientos funcionales o “Historias de usuario”.

Coraje

Establece: “Diremos la verdad en nuestros avances y estimados, no documentaremos excusas para el fracaso, pues planificamos para tener éxito. No tendremos miedo a nada pues sabemos que nadie trabaja solo. Nos adaptaremos a los cambios cuando sea que estos ocurran.” (Cita de extremeprogramming).

Algunas prácticas del coraje son:

• Diseñar y programar para hoy y no para mañana, evitando así hacer énfasis en el diseño en detrimento de todo lo demás.

• Refactorizar el código siempre que sea necesario (No tener reservas al respecto).

• Inspeccionar constantemente el código y modificarlo (refactorizar), de tal manera que futuros cambios se puedan implementar más fácilmente (desarrollar rápido para atender las necesidades de hoy pero refactorizar después para facilitar el mantenimiento).

• Desechar componentes o piezas de código cuando sea necesario, sin preocuparse del tiempo invertido (y perdido) en su creación (Es mejor desechar algo que no es útil en lugar de tratar de repararlo).

• Ser persistente en la resolución de problemas.

Respeto

El valor del respeto en XP establece: “Todos en el equipo dan y reciben el respeto que merecen como integrantes del equipo y los aportes de cada integrante son valorados valorados por todos. Todos contribuyen, así sea simplemente con entusiasmo. Los desarrolladores respetan la experticia de los clientes y viceversa. La Gerencia respeta el derecho del equipo de asumir responsabilidad y tener autoridad sobre su trabajo”. (Cita de extremeprogramming).

Respeto es tanto por el trabajo de los demás como por el trabajo de uno mismo, por ejemplo, los desarrolladores nunca deben subir cambios que impidan la compilación de la versión, que hagan fallar pruebas unitarias ya realizadas o que de alguna otra forma retrasen el trabajo de sus pares, esto significa tener respeto por el trabajo (y el tiempo) de los demás.

Asimismo, los desarrolladores respetan su propio trabajo por medio de su compromiso con una alta calidad y buscando el mejor diseño para la solución por medio de la refactorización constante.

En cuanto al trabajo en equipo, nadie debe sentirse poco apreciado o ignorado, todos deben colaborar en esto, tratando con respeto a sus compañeros y mostrando respeto por sus opiniones, esto asegura altos niveles de motivación y lealtad hacia el proyecto.

¿Y qué opinas tú?

¿Qué opinas de los valores de la programación extrema (XP), ¿Los has aplicado?, ¿Tu experiencia ha sido buena o mala?, ¿Por qué?, ¿Cuáles aspectos de los valores adoptarías y cuáles no?, ¿Qué cambiarías?, ¿Cuáles son los principales retos en la implementación del XP?.

¿Buscas más información de metodologías ágiles?

¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de metodologías ágiles?, entonces presiona síguenos en nuestras redes sociales.

        

Lectura recomendada

Proyectos Ágiles con Scrum: Flexibilidad, aprendizaje, innovación y colaboración en contextos complejos 
Autor: Martin Alaimo; Martin Salas.
>> Latinoamérica (amazon.com) 
>> España (amazon.es)
>> Ver reseña


Código Limpio
Autor: Robert C. Martin
>> España(amazon.es)
>> Latinoámerica (amazon.com)



Kanban
Autor: David J Anderson
>> España (amazon.es)
>> Latinoámerica (amazon.com)





Referencias

>> Wikipedia. Extreme programming

>> extremeprogramming.org. The Values of Extreme Programming

>> Sironi,G . The eXtreme Programming Values. Agile Zone (DZone)

Otros artículos

Desarrollo ágil, Scrum y Test Driven Development

>> 5 Preguntas y respuestas sobre el Feature Driven Development (FDD)

>> Test Driven Development (TDD): 9 retos para su implementación y cómo hacerles frente

>> Plantillas Scrum: historias de usuario y criterios de aceptación

>> El “Test Driven Development” (TDD): Desarrollo y pruebas de software bajo Scrum

>> Scrum de Scrum: Desarrollo ágil para grandes proyectos

>> 5 métricas de desempeño para proyectos de desarrollo ágil y Scrum

>> Herramientas de software para gestión de proyectos de desarrollo ágil

>> El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos

>> Los Programas de Certificación del Scrum Alliance

>> Preguntas y respuestas sobre Scrum Alliance

>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?

>> Metodologías de desarrollo ágil