Seguramente has escuchado sobre “Ritmo sostenido” o “Trabajo de 40 horas por semana” o quizás no has escuchado sobre ninguno de estos términos si es así entonces será más fácil darte a conocer extreme programing sino, si has escuchado sobre esta metodología seguramente la consideras como “el lado oscuro” de la  agilidad. ¿Por qué? Todos aquellos que ya conocen sobre la metodología se toparon con esta práctica en el cual los equipos debían llevar un trabajo sostenido, es decir una manera de trabajar sin perder la concentración y cumplir con los tiempos de entrega. Debido a esto, se consideró que la mejor manera de llevar a cabo con los objetivos era que los equipos de trabajo debían estar sentados frente a un computador más de 8 horas al día, cuando la realidad es otra.

Extreme programing como metodología ágil no considera que se deba llevar a cabo 40, 35 o 42 horas por semana por el contrario la idea de llevar un ritmo sostenido es que los equipos encuentren la mejor manera de llevar a cabo su trabajo sin producirles estrés o agotamiento, y esto se logra bajo una buena planificación de trabajo. Si el proyecto se retrasa, nada garantiza que trabajar horas extras dé resultados satisfactorios quizás puedas realizar una entrega puntual de un producto que pueda funcionar pero, ¿qué pasa con tu equipo de trabajo? Si recordamos los valores del manifesto agile, debemos mencionar que le damos más valor a los individuos que a los procesos ya que son las personas quienes se encargaran de realizar el producto, y cuando un individuo trabaja horas extra éste se ve desmotivado, agotado y estresado y el único resultado que tendrás es un producto de mala calidad, funcional sí, pero no de calidad y probablemente menos gente en tu equipo.

Entonces, ¿Qué es Extreme Programing? Déjame contarte que no es “Programación Extrema” es decir, no es sentarte más de 8 horas al día y “echar código sin parar” ¡no! Extreme programming es una metodología ágil basada en los principios del manifesto agile, cuyo único propósito es ayudarnos a realizar productos de calidad más allá de un plan a seguir estrictamente, es darle la bienvenida a los cambios. Extreme Programming o XP tiene su origen en la comunidad Smalltalk, en particular en la colaboración entre Kent Beck y Ward Cunningham a finales de los 80, ambos refinaron sus prácticas durante los 90, extendiendo la idea de que el desarrollo de software es un proceso adaptativo y orientado a las personas. Kent Beck trabajaba de consultor y aplicó estas técnicas en múltiples proyectos, pero en concreto en el proyecto C3 de Chrysler (1993-1997) que se puede considerar el proyecto de creación de XP. Kent Beck acuñó el nombre de Extreme Programming en 1997 naciendo con él, el primer libro sobre esta metodología donde nos muestra 12 prácticas y valores importantes para llevar a cabo el éxito en nuestros proyectos.

Valores en XP

Para que el proyecto tenga éxito, en la metodología XP se presentan cuatro valores fundamentales en los que deben regirse los equipos de trabajo:

  •        Comunicación: Muchos de los problemas que existen en proyectos de software (así como en muchos otros ámbitos) se deben a problemas de comunicación entre las personas. La comunicación permanente es fundamental en XP. Dado que la documentación es escasa, el diálogo frontal, cara a cara, entre desarrolladores, gerentes y el cliente es el medio básico de comunicación. Una buena comunicación tiene que estar presente durante todo el proyecto.
  •        Simplicidad: XP, apuesta a la sencillez, en su máxima expresión. Sencillez en el diseño, en el código, en los procesos, etc. La sencillez es esencial para que todos puedan entender el código, y se trata de mejorar mediante recodificaciones continuas.
  •        Retroalimentación: La retroalimentación debe funcionar en forma permanente. El cliente debe brindar retroalimentación de las funciones desarrolladas, de manera de poder tomar sus comentarios para la próxima iteración, y para comprender, cada vez más, sus necesidades. Los resultados de las pruebas unitarias son también una retroalimentación permanente que tienen los desarrolladores acerca de la calidad de su trabajo.
  •        Coraje: Cuando se encuentran problemas serios en el diseño, o en cualquier otro aspecto, se debe tener el coraje suficiente como para encarar su solución, sin importar que tan difícil sea. Si es necesario cambiar completamente parte del código, hay que hacerlo, sin importar cuanto tiempo se ha invertido previamente en el mismo.

Prácticas o reglas en XP

En esta metodología encontramos entre 12 y 13 prácticas generales que nos ayudarán a lograr nuestro objetivo, ¡ojo! No es seguir el plan, o seguir las prácticas al pie de la letra con una buena orientación puedes elegir la o las prácticas que mejor se adapten a tu necesidad, aquí te presento las reglas de una forma genérica y agrupadas:

1) Reglas y prácticas para la Planificación La metodología XP plantea la planificación como un diálogo continuo entre las partes involucradas en el proyecto, incluyendo al cliente, a los programadores y a los coordinadores o gerentes. El proyecto comienza recopilando “Historias de usuarios”, las que sustituyen a los tradicionales “casos de uso”. Una vez obtenidas las “historias de usuarios”, los programadores evalúan rápidamente el tiempo de desarrollo de cada una. Una vez realizadas estas estimaciones, se organiza una reunión de planificación, con los diversos actores del proyecto (cliente, desarrolladores, gerentes), a los efectos de establecer un plan o cronograma de entregas (“Release Plan”) en los que todos estén de acuerdo. Una vez acordado este cronograma, comienza una fase de iteraciones, en donde en cada una de ellas se desarrolla, prueba e instala unas pocas “historias de usuarios”.

Release Plan (Plan de entregas): El cronograma de entregas establece qué historias de usuario serán agrupadas para conformar una entrega, y el orden de las mismas. Este cronograma será el resultado de una reunión entre todos los actores del proyecto (cliente, desarrolladores, gerentes, etc.). XP denomina a esta reunión “Juego de planeamiento” (“Planning game”), pero puede denominarse de la manera que sea más apropiada al tipo de empresa y cliente (por ejemplo, Reunión de planeamiento, “Planning meeting” o “Planning workshop”) Típicamente el cliente ordenará y agrupará según sus prioridades las historias de usuario. El cronograma de entregas se realiza en base a las estimaciones de tiempos de desarrollo realizadas por los desarrolladores. Luego de algunas iteraciones es recomendable realizar nuevamente una reunión con los actores del proyecto, para evaluar nuevamente el plan de entregas y ajustarlo si es necesario.        

Iteration Plan (Plan de iteraciones): Las historias de usuarios seleccionadas para cada entrega son desarrolladas y probadas en un ciclo de iteración, de acuerdo al orden preestablecido. Al comienzo de cada ciclo, se realiza una reunión de planificación de la iteración. Cada historia de usuario se traduce en tareas específicas de programación. Asimismo, para cada historia de usuario se establecen las pruebas de aceptación. Estas pruebas se realizan al final del ciclo en el que se desarrollan, pero también al final de cada uno de los ciclos siguientes, para verificar que subsiguientes iteraciones no han afectado a las anteriores. Las pruebas de aceptación que hayan fallado en el ciclo anterior son analizadas para evaluar su corrección, así como para prever que no vuelvan a ocurrir.       

Stand-up meeting (Reuniones diarias de seguimiento): El objetivo de tener reuniones diarias es mantener la comunicación entre el equipo, y compartir problemas y soluciones. En la mayoría de estas reuniones, gran parte de los participantes simplemente escuchan, sin tener mucho que aportar. Para no quitar tiempo innecesario del equipo, se sugiere realizar estas reuniones en círculo y de pie.       

 User Stories (Historias de usuario): Las historias de usuario, sustituyen a los documentos de requerimiento funcional o a los “casos de uso”. Estas “historias” son escritas por el cliente, en su propio lenguaje, como descripciones cortas de lo que el sistema debe realizar. Las historias de usuarios deben poder ser programadas en un tiempo entre una y tres semanas. Si la estimación es superior a tres semanas, debe ser dividida en dos o más historias. Si es menos de una semana, se debe combinar con otra historia

.2) Reglas y prácticas para el Diseño La metodología XP hace especial énfasis en los diseños simples y claros. Los conceptos más importantes de diseño en esta metodología son los siguientes:        

Simplicidad: Un diseño simple se implementa más rápidamente que uno complejo. Por ello XP propone implementar el diseño más simple posible que funcione. Se sugiere nunca adelantar la implementación de funcionalidades que no correspondan a la iteración en la que se esté trabajando.

Recodificación: La recodificación (“refactoring”) consiste en escribir nuevamente parte del código de un programa, sin cambiar su funcionalidad, a los efectos de hacerlo más simple, conciso y/o entendible. La metodología XP sugiere recodificar cada vez que sea necesario. Si bien, puede parecer una pérdida de tiempo innecesaria en el plazo inmediato, los resultados de ésta práctica tienen sus frutos en las siguientes iteraciones, cuando sea necesario ampliar o cambiar la funcionalidad. La filosofía que se persigue es, como ya se mencionó, tratar de mantener el código más simple posible que implemente la funcionalidad deseada.

Metáforas: Una “metáfora” es algo que todos entienden, sin necesidad de mayores explicaciones. La metodología XP sugiere utilizar este concepto como una manera sencilla de explicar el propósito del proyecto, y guiar la estructura y arquitectura del mismo. En un trabajo realizado en el School of Computer Science del Carnegie Mellon, se cuestiona la utilidad de su uso.

Soluciones “spike”: Cuando aparecen problemas técnicos, o cuando es difícil de estimar el tiempo para implementar una historia de usuario, pueden utilizarse pequeños programas de prueba (llamados “spike”), para explorar diferentes soluciones que luego de su evaluación son desechados.

3) Reglas y prácticas para el DesarrolloDisponibilidad del cliente: Uno de los requerimientos de XP es tener al cliente disponible durante todo el proyecto. No solamente como apoyo a los desarrolladores, sino formando parte del grupo. El involucramiento del cliente es fundamental para que pueda desarrollarse un proyecto con la metodología XP.        

Uso de estándares: Si bien esto no es una idea nueva, XP promueve la programación basada en estándares, de manera que sea fácilmente entendible por todo el equipo, y que facilite la recodificación.        

Programación dirigida por las pruebas (“Test-driven programming”): En las metodologías tradicionales, la fase de pruebas, incluyendo la definición de los tests, es usualmente realizada sobre el final del proyecto, o sobre el final del desarrollo de cada módulo. La metodología XP propone un modelo inverso, en el que, lo primero que se escribe son los test que el sistema debe pasar. Luego, el desarrollo debe ser el mínimo necesario para pasar las pruebas previamente definidas. Las pruebas a los que se refiere esta práctica, son las pruebas unitarias, realizados por los desarrolladores. La definición de estos test al comienzo, condiciona o “dirige” el desarrollo.        

Programación en pares: XP propone que se desarrolle en pares de programadores, ambos trabajando juntos en un mismo ordenador. Si bien parece que ésta práctica duplica el tiempo asignado al proyecto (y por ende, los costos en recursos humanos), al trabajar en pares se minimizan los errores y se logran mejores diseños, compensando la inversión en horas. El producto obtenido es por lo general de mejor calidad que cuando el desarrollo se realiza por programadores individuales.

Integraciones permanentes: Todos los desarrolladores necesitan trabajar siempre con la “última versión”. Realizar cambios o mejoras sobre versiones antiguas causan graves problemas, retrasan al proyecto. Es por eso que XP promueve publicar lo antes posible las nuevas versiones, aunque no sean las últimas, siempre que estén libres de errores. Idealmente, todos los días deben existir nuevas versiones publicadas. Para evitar errores, solo una pareja de desarrolladores puede integrar su código a la vez.

  Propiedad colectiva del código: En un proyecto XP, todo el equipo puede contribuir con nuevas ideas que apliquen a cualquier parte del proyecto. Asimismo, cualquier pareja de programadores puede cambiar el código que sea necesario para corregir problemas, agregar funciones o recodificar

.4) Reglas y prácticas para las PruebasPruebas unitarias: Las pruebas unitarias son una de las piedras angulares de XP. Todos los módulos deben de pasar las pruebas unitarias antes de ser liberados o publicados. Por otra parte, las pruebas deben ser definidas antes de realizar el código (“Test-driven programming”).

Detección y corrección de errores: Cuando se encuentra un error (“bug”), éste debe ser corregido inmediatamente, y se deben tener precauciones para que errores similares no vuelvan a ocurrir. Asimismo, se generan nuevas pruebas para verificar que el error haya sido resuelto.

 Pruebas de aceptación: Las pruebas de aceptación son creadas en base a las historias de usuarios, en cada ciclo de la iteración del desarrollo. El cliente debe especificar uno o diversos escenarios para comprobar que una historia de usuario ha sido correctamente implementada.

Roles y equipos en XP

¡Si existen los roles en la metodología XP!, de hecho Beck Kent su principal autor en su libro Extreme Programming Explained: Embrace Change, Second Edition nos habla sobre los roles que deben estar presentes en el equipo de desarrollo. Kent nos menciona que no deben ser rígidos y fijos cuando la metodología o el equipo de desarrollo es maduro, es decir cuando ya la metodología fue adoptada completamente. Por el contrario cuando se está comenzando con la metodología si es necesario plantear los roles que debe tener cada miembro del equipo de desarrollo de esta manera se pueden plantear mejor los objetivos, en la orientación sobre la metodología y en la toma de decisiones cuando se tiene las personas adecuadas para cada rol, pero para XP cada persona que conforma el equipo está en la capacidad de “ejercer” cualquier función a medida que el equipo madure, con esto se puede decir que el desarrollador puede ser el arquitecto de software, o el tester. El objetivo es que cada persona contribuya todo lo que pueda con lograr la meta planteada.

¿Cuales son los roles en la metodología?

  • Tester: Es el encargado de apoyar al cliente en la preparación/realización de las pruebas funcionales es quien ejecuta las pruebas funcionales y publica los resultados obtenidos y los comparte con los desarrolladores para que estos puedan realizar los cambios.
  • Programador: Los programadores en un equipo de XP estiman historias y tareas, rompen historias en tareas, escriben pruebas, escriben el código para implementar funciones, y mejoran gradualmente el diseño del sistema. Los programadores trabajan en estrecha colaboración técnica entre ellos y el cliente, por lo que necesitan desarrollar buenas habilidades sociales y de relación.
  • Cliente: Los clientes de un equipo de XP ayudan a escribir y elegir historias y a tomar decisiones de dominio durante el desarrollo. Los usuarios son más valiosos si tienen un amplio conocimiento y experiencia con sistemas similares a la que se está construyendo y si tienen fuertes relaciones con la comunidad de usuarios más grande que usará el sistema una vez que esté completamente desplegado. El entrenador: O coach Si el equipo está comenzando a aplicar XP, puede que le resulte útil incluir un entrenador en su equipo. Este suele ser un consultor externo o alguien de su organización que ha utilizado antes  XP se incluye en el equipo para ayudar a los demás miembros del equipo en las prácticas de XP y para ayudar a su equipo a mantener la autodisciplina. El valor principal del entrenador es que ha pasado por la metodología, la conoce bien y puede ayudar a su equipo a evitar errores que la mayoría de los equipos hacen cuando estan aplicando XP.
  • Jefe del Proyecto: O Project managers en un equipo de XP facilitan la comunicación dentro del equipo y coordinar la comunicación con los clientes, proveedores y el resto de la organización. Los jefes de proyecto actúan como historiadores de equipo, recordando al equipo cuánto progreso ha hecho.   Con la cantidad de roles, y con la práctica de programación en par quizás te preguntes ¿cuál es la capacidad o cuántas personas debe haber en un equipo XP? Como metodología ágil, se requiere que los equipos no sean muy grandes se considera que los equipos deben estar conformados entre 5 y 9 personas.   En la metodología XP si bien no hay un consenso en el número máximo de desarrolladores, todos parecen coincidir en números no mayores a 20. Sus propias prácticas así lo requieren, ya que, por ejemplo, mantener las “Stand-up meeting” con más de 20 personas parece poco razonable, con esto no te quiero decir que con menos personas no podrás aplicar XP se puede pero recuerda que ciertas prácticas no podrás llevar a cabo todo va a depender tu necesidad y lo complejo del proyecto.  

XP o Extreme Programing no es sentarse a “echar código” sin parar, es una metodología ágil con valores y prácticas que te ayudarán a lograr el éxito en tu proyecto. No le temas a la metodología por lo que otros te digan, conoce un poco más y saca tus conclusiones, dale la bienvenida al cambio y ten el coraje de llevarlo a cabo.