Lo primero que aprendí al entrar en el mundo Scrum fue que, en contra de lo que yo pensaba, Scrum y XP no valen para lo mismo. Ambos pertenecen al mundo de “Tecnologías Ágiles” pero Scrum es una metodología (o como dicen los puristas, un marco de trabajo) de Gestión y XP es una metodología de Desarrollo y de hecho se complementan muy bien.
Antes de seguir adelante vamos a dar una breve descripción de cada una de ellas:
Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. Define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.
El eXtreme Programming (XP) es una metodología de desarrollo que se basa en la simplicidad, la comunicación y la realimentación o reutilización del código desarrollado.
Tanto una como otra están enfocadas en técnicas de programación, comunicación clara y equipo de trabajo que nos permite lograr desarrollar el software con un coste más bajo, con menos defectos, con mayor productividad y con un mayor retorno de la inversión.
A continuación se detallan algunas de las características que comparten:
Comunicación: El objetivo es dar a los a todos los intervinientes una visión compartida del sistema, alineada con la de los usuarios del sistema, favoreciendo diseños simples, la colaboración entre usuarios y programadores, comunicación verbal frecuente. Es recomendable que cada integrante del equipo conozca las tareas del resto para así, si alguno tiene un problema que otro ha solucionado con anterioridad pueden solucionarlo juntos (no reinventar la rueda). La comunicación es importante para crear un sentido de equipo y cooperación eficiente.
Simplicidad: Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Tanto XP como Scrum, fomentan iniciar con la solución más simple y desarrollar a partir de esa, versiones mejores. Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece.
Retroalimentación (Feedback): Ejecutar periódicamente pruebas unitarias e integradas, facilita la retroalimentación del sistema así los programadores conocerán su estado después de implementar cambios. Las pruebas de aceptación elaboradas por el cliente, realizadas cada dos o tres semanas (Después de cada Sprint), permiten retroalimentar el desarrollo. Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos.
Respeto: Los miembros del equipo de trabajo deben respetarse entre sí. Nadie en el equipo de trabajo debe sentirse despreciado o ignorado ya que esto mejora la motivación de todos para conseguir los objetivos del proyecto. Una forma de respeto al trabajo propio es siempre buscar la más alta calidad y las mejores soluciones al desarrollar el producto.
Sentarse juntos: Desarrollar en un espacio abierto suficientemente grande para todo el equipo. La proximidad física aumenta la comunicación entre los integrantes del equipo.
El equipo completo: Incluir a toda la gente del equipo en el éxito del proyecto gracias a las habilidades de cada uno. La gente necesita un sentido de equipo.
Espacio de trabajo informativo: Tener una especie de muro informativo (físico o virtual) con las tareas finalizadas, las que están en proceso, las pendientes, etc. Para que todos sean conscientes del progreso y de lo que queda.
Trabajo con energía: Trabajar solo tantas horas como puedas ser productivo. Trabajar más horas de las aconsejables es contraproducente. Nuestro trabajo es mental y por lo tanto nuestra mente tiene que estar descansada para rendir lo mejor posible.
Tareas: Especificar las tareas con su respectiva estimación de tiempo. Darles un nombre y una descripción. Es una buena forma de organizar lo que queda por hacer para poder planificarlo mejor.
Ciclo semanal / Scrum Diario: En XP se promueve la planificación del trabajo para una semana. Tener una reunión al principio de la semana para revisar el progreso del proyecto, revisar las tareas de la semana anterior y asignar tareas para la actual. Proporciona un flujo de trabajo y nos da feedback de lo ocurrido en la semana anterior. En Scrum estas reuniones se realizan de forma diaria.
Ciclo trimestral / Sprint: En XP se promueve la planificación del trabajo para un trimestre. Scrum define los sprints de no más de un mes de duración. Una vez pasado el tiempo espeficicado, se verifica el progreso, los próximos objetivos, identificar cuellos de botella, etc. Ver con el cliente si se están cumpliendo los requisitos (Revisión del sprint). Proporciona mucho feedback, tanto interno como externo.
Implicación real del cliente: Hacer que alguien del cliente sea parte del equipo. Para Scrum existe explícitamente el rol de Dueño del producto. Esto reduce malgastar esfuerzo en desarrollar funciones mal explicadas o mal entendidas poniendo en contacto directo a la gente que tiene la necesidad con la que puede aportar la solución a dicha necesidad.
Despliegue incremental / Entrega de cada Sprint: Empezar desplegando una pequeña pieza de funcionalidad e ir haciendo pequeños despliegues de nueva funcionalidad poco a poco. Permite al cliente ver en que se está gastando el dinero, poder empezar a amortizar su inversión y dar feedback de lo que se ha desarrollado.
Como se puede ver, gran parte de los valores y las prácticas de cada una de las dos metodologías son muy parecidas o incluso coinciden por completo, y por el contrario no hay ninguna en la que choquen, por ello se complementan con tanta facilidad.
