Metodologías

Scrum, un framework que está muy de moda al día de hoy, cuando en las empresas se habla de agile, transformación digital, cultural y mejora continua. Es el framework por excelencia que adoptan la mayoría de las empresas para organizar a sus equipos, el flujo de trabajo y desarrollar los planes estratégicos que permitan a la organización cumplir sus objetivos de transformación.

Además, esta transformación “digital” está comúnmente asociada con la innovación en forma de software de calidad creado de manera ágil y continua, sin embargo, muy poco se escucha, en estas mismas organizaciones que buscan la transformación, hablar de la metodología Extreme Programming (XP) o de sus principios, valores y prácticas de ingeniería y excelencia técnica.

El objetivo de este artículo es mostrar cómo no puede existir una transformación “digital” que implique la creación de software utilizando únicamente lo que promueve el framework de Scrum y que es necesario aplicar Extreme Programming dentro del proceso de desarrollo para realmente lograr los objetivos de los proyectos y la excelencia técnica constante que se busca con la agilidad.

No es Scrum vs. Extreme Programming

En el artículo Extreme Programming: Qué es y cómo aplicarlo definimos la programación extrema y mostramos como actualmente es utilizado como un conjunto de buenas prácticas que facilitan el trabajo de equipos que utilizan otras metodologías o frameworks ágiles como Scrum.

La realidad es que para cualquier equipo que busque ser ágil y entregar software de calidad de forma constante y sostenible en el tiempo, Scrum por sí solo no es suficiente ni es lo único que pueden hacer, y a quien piense lo contrario, puedes compartirle este artículo. Lo queramos aceptar o no, los equipos de desarrollo que en la actualidad entregan software de forma ágil de verdad, y que se llaman así mismos equipos Scrum, integran dentro de su proceso de desarrollo valores, principios y prácticas que son originarias de XP.

Scrum y XP no son competencia el uno del otro, al utilizarlos como complementos en nuestro proceso de desarrollo, realmente podemos experimentar la esencia de la agilidad, esencia que encontramos en el famoso Manifiesto por el Desarrollo Ágil de Software. Me atrevo a decir, que un equipo Scrum de desarrollo de software que sigue solo las reglas de Scrum sin complementarlas, le costará mucho poder tener éxito en su proyecto, ya que Scrum no prescribe prácticas de ingeniería de software que promueven la excelencia técnica, la integración del código o la ejecución de pruebas, es por eso que, es recomendable que al menos implemente en su desarrollo un subconjunto de las prácticas de XP para poder lograr el éxito continuo del equipo y del proyecto.

Scrum no está hecho para equipos de software

Scrum se puede utilizar y se utiliza a menudo en el desarrollo de software. Sin embargo, Scrum en sí no tiene elementos centrados en el software. En sus reglas no especifica principios o prácticas que estén relacionadas con el software.

Pero no es que Scrum esté mal hecho, en realidad Scrum está hecho así a propósito, ya que en su esencia no busca ser solo un framework aplicable a equipos de software, sino que su fin es ayudar a equipos a resolver cualquier tipo de problema complejo donde exista mucha incertidumbre y donde el desarrollo iterativo incremental y feedback continuo permita al equipo ir despejando esa incertidumbre.

Desde mi punto de vista existen dos razones por la que Ken Schwaber y Jeff Sutherland, quienes crearon Scrum, lo hayan definido de esa manera:
Scrum intenta ser una forma general para desarrollar productos, no simplemente un método para crear software como XP.
La intención de Scrum es ser lo más simple posible. Brindar una guía de pasos mínimos que permitan al equipo organizarse y definir su propio proceso, incluyendo prácticas y herramientas. Por esta misma razón omite detalles, que no son tan “universales” en la creación de producto o resolución de problemas como el resto.

Agile, XP y la excelencia técnica

En el Manifiesto por el Desarrollo Ágil de Software, en uno de sus principios consta que:

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

La primera frase “La atención continua a la excelencia técnica”, quiere decir que continuamente debemos optar por diseñar, crear e implementar nuestro código siguiendo las mejores prácticas e introduciendo en nuestro desarrollo, procesos y herramientas que nos permitan obtener esa excelencia técnica.

Estas buenas prácticas, procesos y herramientas son las que nos brinda XP, ya que define un conjunto de buenas prácticas de las que podemos utilizar todas o las que más beneficien al equipo y al proyecto de software.

Pero no se trata solo de prácticas técnicas, la excelencia técnica comienza y termina con la cultura y esto es una de los principales aspectos que promueve XP en sus valores y principios.

Estos son algunos aspectos importantes a considerar sobre la excelencia técnica:

• La excelencia técnica evoluciona en torno a una cultura de equipo en la que la mejora continua es clave, tanto en términos de habilidades duras de desarrollo y habilidades blandas como la colaboración en equipo y la capacidad de ayudar y entrenar a otros.
• La excelencia técnica es la curiosidad por aprender continuamente nuevas habilidades, probar nuevos enfoques y esforzarse por mejorar la calidad de los productos y el código.
• La excelencia técnica es cultura en el sentido de que no es un enfoque de un solo programador, es un trabajo en equipo. Un desarrollador no es excelente porque se encarga de definir la arquitectura, crear el código y las pruebas todo por sí mismo, sin involucrar al resto del equipo de desarrollo. Un desarrollador excelente tiene la responsabilidad de incluir al resto del equipo y el equipo de incluirse entre sí de manera que puedan trabajar de forma colaborativa, elevando constantemente el nivel general de las competencias técnicas que tiene el equipo, enseñando, entrenando y ayudándose mutuamente continuamente.
• La excelencia técnica consiste en “descubrir mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo” (así es como empieza el Manifiesto por el Desarrollo Ágil de Software).

La excelencia técnica se trata de mejorar… ¡Todos los días!

Scrum y las buenas prácticas de XP

Ya he comentado antes que no existen razones para no aprovechar la potencia que nos da la combinación de Scrum y XP y creo, en mi opinión muy personal, que así debería ser en cualquier equipo Scrum que desarrolla software. Si quisiéramos determinar las diferencias entre ellos y poder entenderlos mejor, Scrum nos provee prácticas y herramientas para organizarnos como equipo y gestionar nuestros objetivos, y XP se centra más en las prácticas de desarrollo de software que promueven la excelencia técnica y la creación de software que agregue valor real a los usuarios finales.

Scrum y XP se complementan e integran muy bien porque nos permiten gestionar aspectos y procesos distintos en nuestros equipos.

Si lo decide el equipo, puede intentar aplicar todas las prácticas de XP o al menos experimentar con todas ellas y quedarse solo con las que les generen resultados positivos.

A continuación, veremos las prácticas de desarrollo de software más populares y más utilizadas por los equipos Scrum de alto rendimiento en la actualidad:

• Programación en Parejas: Una forma colaborativa de crear código, en donde dos programadores trabajan en conjunto desde la misma computadora aprovechando el conocimiento y la inteligencia colectiva para resolver el problema que tienen enfrente. Con esta práctica, el diseño del código es mejor porque se hace en pareja, porque existe comunicación constante, pueden criticarse mutuamente, encontrar errores más rápido y utilizar las mejores ideas de ambos en beneficio del producto que están construyendo.
  Además, algunos equipos Scrum potentes practican alternativas más extremas como el Swarming (todo el equipo enfocado en resolver en el mismo problema, cada uno en su propia computadora) o el Mob Programming (todo el equipo está frente a la misma computadora, rotando la posición de control).
• Desarrollo Guiado por Pruebas (TDD): Involucra 2 etapas, escribir la prueba primero, es decir, antes del código que pensamos poner en producción y refactorizar el código, es decir mejorar su estructura, diseño o composición, sin alterar el resultado que este genera. Una de las razones para aplicar TDD, es que las pruebas no deben ser opcionales en ningún software, ya que un software sin pruebas es una bomba de tiempo a punto de estallar. Además que TDD tiene un efecto profundamente positivo en el diseño del sistema, ya que cuando se crea una prueba primero, desde el principio se piensa en el mejor diseño que se puede implementar en el código para cubrir la necesidad de los clientes.
• Diseño Incremental: Considera la creación del diseño de la arquitectura del código de forma simple desde el principio, evolucionándolo y mejorándolo continuamente, en lugar de conseguir que todo esté definido desde el inicio, y que sea tomado como algo escrito en piedra como se hacía en proyectos creados con el método tradicional o en cascada.
• Integración continua: Implica combinar los cambios en el código dentro de un repositorio central de forma periódica (CI server), donde luego se empaqueta el software y se ejecutan las pruebas automáticas. La integración continua conlleva un componente tecnológico y de automatización (herramienta de CI, frameworks de automatización de pruebas) y un componente cultural (aprender a integrar con frecuencia, pensar en cómo afecta tu código al código de tu compañero).
• Ten minute build: Esta práctica está muy relacionada con la integración continua. Busca que el equipo cuente con un proceso de integración de todo el software, que ejecute todas las pruebas, empaquete el software y despliegue el software en un entorno de pruebas, todo en diez minutos o menos con el objetivo de recibir feedback muy rápido y poder tomar acciones correctivas, cuanto antes mejor.
  Estándares de código: Promueve la creación de un estándar común para escribir el código, de modo que todo el código creado parezca haber sido escrito por una sola persona. Normalmente estos estándares de código se basan en el libro Clean Code escrito por Robert C. Martin (Uncle Bob) uno de los firmantes del manifiesto por el desarrollo de software ágil y promotor de manifiesto por la artesanía de software.
• Propiedad colectiva del código: Promueve que cualquier desarrollador puede cambiar, agregar una funcionalidad, corregir errores, mejorar diseños o refactorizar cualquier línea de código siempre y cuando sea para mejorarlo y optimizarlo sin necesidad de pedir permiso. Esta práctica es soportada por herramientas de versionamiento de código como GIT.
• Espacio informativo: Consiste en promover el uso de radiadores de información que permitan tanto al equipo como a cualquier persona interesada en el proyecto entender el estado actual del mismo y saber si existen riesgos o problemas, sin necesidad de preguntar al equipo constantemente. Un tablero Kanban se utiliza, por lo regular, como punto de partida para habilitar esta práctica en un equipo, que luego va evolucionando según las herramientas que utilizan y el contexto del proyecto y la organización.

Todas estas prácticas promueven que el equipo debe estar continuamente creando código caracterizado por una firma de calidad y excelencia. Además de esto, si un equipo Scrum conoce y práctica los valores y principios de XP en conjunto con los valores de Scrum, pueden desarrollar una mejora en su propia cultura y comportamiento.

Scrum y XP son mejores juntos

Scrum es un marco de trabajo generalmente utilizado para el desarrollo de productos de software, también es un contenedor donde puedes agregar otras prácticas que beneficien la construcción del producto. XP te provee un conjunto de prácticas que puedes utilizar como complemento dentro del marco de Scrum.

Como has podido ver, no existen razones por las que tu equipo deba elegir entre usar Scrum o XP. Aunque las reglas y prácticas de XP no son fáciles de implementar porque requieren un alto nivel de compromiso personal y técnico, agregar estas prácticas a Scrum debería ser el próximo paso natural para los equipos que utilizan Scrum y se esfuerzan por ser un equipo Scrum profesional de verdad.

En mi experiencia, he visto que los equipos Scrum que aplican prácticas de XP en su proceso de desarrollo, son equipos que alcanzan un alto nivel técnico, potencian su rendimiento, a la vez que logran cumplir con sus propios objetivos y los del negocio.

XP es una de las piezas fundamentales que un equipo Scrum necesita cuando quiere crear código con una calidad muy alta. Los valores de Scrum y XP buscan los mismos objetivos “crear cultura de equipo”, lo que permite que al utilizar ambos al unísono, potenciemos el cambio cultural en el equipo.

Así que ya sabes, la pregunta de si usar Scrum o XP, de una forma excluyente entre ellos, es totalmente irrelevante.