Resumen de eXtreme Programing

Hola a tod@s,

Hoy voy a hacer un resumen de eXtreme Programing. La información que presento en esta entrada está extraída íntegramente de las webs de eXtreme Programing (http://www.extremeprogramming.org/ y http://www.agile-process.org/). Para empezar voy a adelantar que muchas cosas de las que voy a contar a muchos ya os sonarán porque también se usan en Scrum. eXtreme Programing es otro framework Agile que nos va a permitir cumplir con esos valores que tan familiares nos son.

EXtreme Programing, al igual que cualquiera de los frameworks ágiles, no es una manera de trabajar válida para implementar cualquier producto. Los productos deben tener las siguientes características principales:

• Cuando se están cambiando los requisitos constantemente.
• Proyectos con un riesgo elevado (cuando se tiene que entregar en una fecha concreta, cuando es un desafío para el equipo de desarrollo, cuando es un desafío para la industria del software, etc.)

El objetivo de eXtream Programing es entregar el Software que se necesita cuando se necesita.

Valores

EXtreme Programin se sustenta en cinco valores:

• Simplicidad: Haremos lo que sea necesario y se pida pero no más. Se desarrollará lo justo y necesario, esto hará que se tengan los mínimos fallos posibles, se desarrolle en fechas y tenga un coste de mantenimiento mínimo.
• Comunicación: Todo el mundo es parte del equipo y nos comunicamos cara a cara diariamente. Esto incluye a los desarrolladores, los gestores y los clientes.
• Feedback: Se realizan entregas tempranas de software funcionando. Después se escucha atentamente el feedback del cliente/usuario y se realizan los cambios necesarios. Hablamos del producto y nos adaptamos a sus necesidades y no supeditamos el producto a nuestra forma de trabajar.
• Respeto: Todo el mundo se debe respetar desde el punto de vista de que todos aportan valor. Por ello, los desarrolladores respetan a los usuarios/clientes en su conocimiento del negocio, y los usuarios/clientes respetan al os desarrolladores por su conocimiento de las tecnologías. Así el gestor respeta la autoridad del equipo sobre su trabajo y que son responsables.
• Coraje: Debemos ser valientes y decir la verdad en referente al progreso y estimaciones. No se deben buscar excusas acerca de los motivos de los fallos para justificar lo bueno que es nuestro plan. No debemos tener miedo porque no trabajamos solos. Nos adaptamos cuando esto ocurra.

Roles

Encontramos 3 roles que van a cubrir todas las necesidades de un proyecto:

• Cliente o Product Owner: 
• Es la persona encargada de dar la visión del producto y priorizar las funcionalidades. Estará en todas las conversaciones decisivas y deberá asegurarse de que se sigue su visión. 
• Además es la persona que decide si la funcionalidad desarrollada es la solicitada, es decir, será quien valide el desarrollo.
• Desarrollador: 
• Este rol incluye a los desarrolladores, arquitectos, DBA, tester o cualquier otra persona que intervenga en la construcción de software. 
• Entre todos deberán organizarse y decidir qué es lo siguiente a hacer para construir la funcionalidad definida por el cliente. 
• Deben liderarse a si mismos y aceptar la responsabilidad de buscar los potenciales bloqueos así como la manera de superarlos. Esto va más allá que simplemente programar.
• Gestor: 
• Debe mantener al equipo unido. 
• Ayudar al Cliente a liderar la visión del producto.
• Deberá trabajar en eliminar todos los obstáculos que haya en el camino y que impida el éxito del producto.
• Será quien tenga la última palabra en cuanto al cambio de dirección de una iteración. 
• Sólo en un caso muy extremo podrá sustituir al cliente o a un desarrollador si fuera necesario. En primer lugar deberá ver cuál es el motivo raíz y solventarlo. 

Priorización de funcionalidades

La gestión de funcionalidades se realiza de una forma muy similar a la de otros frameworks agiles tales como Scrum. En este caso dispondremos de dos pilas de productos:

• Unfinished Features (UF): Es como el Product Backlog con Historias de Usuario.
• Most Important Features (MIF): De la pila Unfinished Features se seleccionan las características más importantes. No existe una manera unificada de cómo decidir qué es lo más importante ya que cada producto o cada equipo puede establecer sus prioridades en función de distintos variables (ROI más pequeño, mayor riesgo, etc.).

En eXtreme Programing las estimaciones es realizan en semanas ideales. Una semana ideal es aquella en la que no tienes nada más que hacer, no te llega ningún trabajo inesperado y no tienes dependencias externas. Una vez realizadas las estimaciones negocio podrá decidir la importancia de las Historias de Usuario.

Planificación

La planificación del trabajo en eXtreme Programing se realiza a tres niveles. A nivel de Release, a nivel de Interacción y a nivel Diario. 

• Release Plan: Una Release se define por una funcionalidad o grupo de funcionalidades que se quieren sacar a la vez o por fecha. 
• Si el objetivo es desarrollar un grupo de funcionalidades, se definen o seleccionan las Historias de Usuario que las componen y los Desarrolladores deberán estimar las interacciones que son necesarias para completarlas. 
• Si la Release se define por fecha los Desarrolladores deberán establecer qué Historias de Usuario les da tiempo a desarrollar hasta la fecha fijada.
• Iteration Plan (1 semana): Es un subconjunto del Release Plan. Las Historias deberán terminarse en la siguiente Iteración. Sólo existe un plan de Iteración al mismo tiempo. A partir del MIF los desarrolladores realizan una estimación de esfuerzo. Esta planificación suele implicar granular las Historias de Usuario en tareas técnicas y así obtener con mayor detalle el esfuerzo necesario. El Gestor puede establecer el esfuerzo que se debe realizar en una iteración, pero qué se puede hacer con ese esfuerzo sólo lo puede definir el equipo. La Iteración recomendada en eXtreme Programing es de 1 semana. El objetivo es conseguir mayor flexibilidad en el cambio el rumo sin necesidad de romper la planificación, unos días puede esperar casi cualquier cambio dirección.
• Daily - Stand Up Meeting: En esta reunión se define el plan diario.

La Retrospectiva

Como buen marco de trabajo Agile, eXtreme Programing pone especial relevancia en revisar el modo en el que se ha estado trabajando hasta ahora y ver cómo mejorarlo. La retrospectiva en eXtreme Programing no está fijada de una manera tan formal como en Scrum. Sin embargo, si se recomienda que se haga al acabar cada Iteración o cada pocas Iteraciones. 

Para realizar buenas retrospectivas, así como para que el equipo pueda tener la confianza necesaria para auto-organizarse, lo primero que hay que hacer es eliminar las culpas. Un equipo puede titubear a la hora de tomar decisiones si después van a recibir una represalia o se les va a señalar.

Resumen visual