miércoles, 21 de mayo de 2014

Scrum, Integración Continua y Git-Flow

Es estupendo ver como varias de las más grandes piezas del puzle en la gestión de proyectos y desarrollo encajan con tal perfección que me produce síndrome de Stendhal.


Scrum

A mi entender, Scrum (y las metodologías o marcos de trabajo ágiles en general) es el camino a seguir para bajar el alto porcentaje de proyectos fallidos. Con este marco de trabajo solo 2 cosas son estrictamente necesarias para el éxito de un proyecto (y, por lo tanto, la falta de ellas conduce, de forma inevitable, al fracaso absoluto):

  • Un equipo de gente con talento, multidisciplinar, proactivo y en constante aprendizaje y reciclaje.
  • Un dueño del producto comprometido, con autoridad y profundos conocimientos de los procesos que se van a modelar.
Si alguno de estos dos elementos falla, el proyecto esta abocado al fracaso. Esto no supone una desventaja de Scrum con respecto a otros marcos de trabajo y otros modelos de gestión de proyectos; puesto que estos también fallarían en caso de que alguna de las condiciones anteriores fallase y además introducen muchos más puntos de 'ruido' que también pueden provocar el fracaso del proyecto. Por lo tanto con Scrum minimizamos los riesgos de fracaso. Scrum es lo suficientemente flexible como para adaptarse y enmendar los errores cometidos en ciclos anteriores y que estos no supongan un lastre a la hora de llegar al éxito.

Integración y Distribución Continua

La integración y distribución continua es un paso más allá de Scrum que surge de forma muy natural y encaja perfectamente con los cortos ciclos de un Sprint de Scrum. Al fin y al cabo, si al final de un Sprint tenemos una o varias funcionalidades totalmente terminadas y potencialmente entregables ¿Por qué no entregarla y poder recibir rápidamente el feedback de los usuarios? Esto permite corregir bugs e introducir mejoras en el siguiente Sprint antes de que el proyecto crezca y se creen más dependencias.

Git-Flow

Git es una herramienta potente y flexible. Desgraciadamente he visto como, a causa de esa potencia y esa flexibilidad, esta herramienta puede llegar a utilizarse muy mal. Con Git es muy fácil empezar a ramificar, fusionar y subir cambios tan a lo loco y fuera de contexto que el historial generado se convierte en un plato de espaguetis ilegible. (¿Acabo de acuñar el termino Spaghetti Branching o ya existía?). Debido a esto han surgido desde auténticos Git haters, pasando por los que no recomiendan crear ramas, hasta los que insisten mucho en mantener un historial limpio aplastando commits y realizando rebases. La solución pasa por establecer unas normas en la gestión de las ramas remotas y una vez establecidas el desarrollador sólo se tiene que preocupar de aplicar el sentido común y mantener un historial limpio de su rama local (aplastar los commits de "me voy a casa", rebases de ramas si ha realizado un fork de la rama local, etc) antes de hacer un push a la rama remota. Todo lo anteriormente expuesto se consigue fácilmente con unas extensiones para Git llamadas Git-Flow.
Como yo me explico muy mal os dejo un enlace donde puedéis encontrar una serie de entradas muy interesantes sobre estas extensiones.
Es increíblemente gratificante ver como se integra Git-Flow con la forma de trabajar con Scrum y la integración continua. Encaja a la perfección. Scrum le da mucha importancia al 'pulso' (heartbeat) del proyecto y gracias a Git-Flow ese 'pulso' se puede apreciar limpio y perfecto en el gráfico del historial del repositorio remoto de código fuente.

Por cierto, la versión en castellano de Git-Flow cheatsheet es una contribución mía. Si algún lector tiene un buen nivel en algún idioma en el que todavía no este traducida es bienvenido si desea realizar un fork en Git-Hub.

No hay comentarios:

Publicar un comentario