Rigoberto

ermitir que los desarrolladores trabajen de manera concurrente y en equipo



Uno de los valores claves en Scrum es que los desarrolladores trabajen en equipo, evitando el código con propietarioy fomentando la colaboración. Lógicamente cualquier herramienta de gestión del código fuente habilita escenarios de compartición de fuentes entre desarrolladores y el trabajo compartido. Luego aquípodríamos decir que para cubrir este objetivo necesitamos poco más que instalar una herramienta de gestión de código, crear una línea de código, y utilizar la herramienta. Pero esto es cierto hastacierto punto. Cuando los equipos crecen y hay un número relevante de desarrolladores tocando la misma línea de código compartida se producen continuos cuellos de botella (si utilizamos bloqueosexclusivos, práctica nada recomendada) o continuos conflictos a la hora de integrar las fuentes (si no utilizamos bloqueos).



La solución habitual en este tipo de escenarios es utilizar una rama pordesarrollador, pero esta no es una buena solución. De hecho se trata de un antipatrón conocido como 'Berlin Wall', ya que si bien es cierto que aísla a los desarrolladores de los cambios de otrosdesarrolladores, también impide que varios desarrolladores trabajen en equipo para desarrollar un misma característica.



Una aproximación que funciona mejor es usar 'ramas por característica'. En laaproximación de rama por característica se crea una rama de desarrollo partiendo de la rama de desarrollo principal, generalmente llamada DEV, con el fin de desarrollar sobre ella una determinadacaracterística. La rama de característica incluye todo el código de la rama principal de desarrollo (DEV) Una vez completada esta característica la línea creada converge de nuevo con la línea principal dedesarrollo (DEV). Varios desarrolladores trabajan de manera concurrente sobre cada rama de característica, pero el número de desarrolladores que en un equipo trabajan sobre una característica...