Cuando trabajas con equipos de desarrollo, entender cómo funciona el flujo tradicional de gestión de código y tareas es fundamental para identificar sus limitaciones y valorar alternativas más eficientes. Aquí se recorre paso a paso este proceso usando Git, GitHub, Jira y VS Code, mostrando cada cambio de contexto que implica.
¿Cómo se configura un equipo en Jira antes de empezar?
Antes de cualquier tarea, es necesario que los miembros del equipo estén correctamente invitados y aceptados dentro del proyecto. En este caso, Marcelo invita a Gustavo enviándole una invitación por correo electrónico [0:25]. Una vez que Gustavo acepta, aparece como parte del equipo y puede participar en la asignación y revisión de tareas.
Este paso inicial es clave para que el Kanban Board de Jira funcione correctamente, ya que cada miembro debe tener permisos para mover tickets entre columnas y ser asignado como revisor.
¿Cuáles son los pasos del flujo tradicional para un pull request?
El ejemplo utilizado es una tarea sencilla: agregar el campo apellido a un formulario de registro en el proyecto Escuela JS. A pesar de su simplicidad, el flujo tradicional requiere múltiples herramientas y pasos:
¿Cómo se crea un feature branch y se realiza el cambio?
- En el Kanban Board de Jira, Marcelo mueve el ticket "agregar apellido al formulario de registro" a la columna in progress [1:08].
- Luego abre la terminal y ejecuta el comando
git para crear un feature branch llamado "agregar-apellido" [1:22].
- En VS Code, realiza el cambio en el código, agregando el campo apellido al formulario [1:33].
- Tras completar la modificación, hace un commit y publica el branch desde el menú de source control en VS Code [1:45].
Hasta aquí ya se han usado tres herramientas distintas: Jira, la terminal y VS Code.
¿Cómo se crea el pull request y se asigna un revisor?
- El siguiente paso requiere ir a GitHub, donde se hace clic en compare and pull request y se selecciona el branch correcto [1:55].
- Se crea el pull request directamente desde la interfaz de GitHub [2:08].
- Dentro del flujo tradicional, se elige al revisor — en este caso Gustavo — desde el panel lateral del pull request [2:16].
- De vuelta en Jira, Marcelo mueve el ticket a la columna done, marcando la tarea como completada [2:28].
En este punto, se ha añadido GitHub como cuarta herramienta, lo que suma otro cambio de contexto.
¿Qué ocurre cuando el revisor solicita cambios?
Gustavo revisa el pull request y solicita modificaciones [2:43]. En el flujo tradicional, esto implica:
- Volver al editor (VS Code) para realizar los ajustes pedidos.
- Hacer un nuevo commit y push al mismo branch.
- Pedir a Gustavo que verifique nuevamente los cambios realizados [2:55].
Cada ida y vuelta entre herramientas multiplica los cambios de contexto, aumentando la posibilidad de errores y repeticiones innecesarias.
¿Por qué importa identificar los cambios de contexto?
El flujo tradicional utiliza cuatro herramientas de forma constante: Jira para la gestión de tareas, la terminal para comandos Git, VS Code para edición de código y GitHub para la creación y revisión de pull requests [3:05]. Cada salto entre ellas interrumpe la concentración del desarrollador.
El concepto de cambio de contexto se refiere precisamente a esta alternancia entre aplicaciones y entornos, que no solo consume tiempo sino que introduce fricción en el proceso. Un feature branch es la rama creada específicamente para desarrollar una funcionalidad aislada del código principal, y el pull request es el mecanismo para solicitar que esos cambios sean revisados e integrados.
Comprender este flujo en detalle permite compararlo con enfoques más modernos donde estas operaciones se integran directamente en el editor, reduciendo pasos y minimizando errores. ¿Has experimentado esta fricción en tu equipo? Comparte tu experiencia sobre cuántas herramientas alternas en un solo ciclo de desarrollo.
