2. Conformación de equipos

Organización de equipos

Tu equipo deberá distribuir tres tipos de responsabilidad, que en Scrum corresponden a los roles que verás en el siguiente tema:

• responsabilidad individual — las tareas concretas que cada integrante se compromete a realizar en un periodo determinado
• responsabilidad colectiva — el resultado del incremento que el equipo completo entrega al final de cada sprint
• coordinación — quién da seguimiento al backlog y quién facilita el proceso

Concepto clave: en un equipo pequeño, quien coordina también programa. Asumir un rol de coordinación no exime a nadie de construir el incremento. Esto contrasta con la idea, común fuera del contexto académico, de que “coordinar” es un trabajo aparte de “construir”: en un equipo de cuatro o cinco personas, ambas cosas recaen en las mismas personas.

Por qué importa

Un equipo que no distingue estos tres tipos de responsabilidad suele caer en uno de dos extremos: o nadie se hace responsable de nada en concreto (“entre todos lo vamos resolviendo”), o una sola persona termina absorbiendo la coordinación, la revisión y buena parte de la construcción, mientras el resto del equipo pierde visibilidad de su propio trabajo. Ninguno de los dos extremos sostiene un proyecto durante un semestre completo.

Estrategias de colaboración

Para que el trabajo de varios integrantes pueda integrarse sin conflictos, tu equipo necesita acordar, desde el inicio:

• cómo se divide el trabajo entre historias de usuario o componentes
• cómo se integran los cambios de distintos integrantes (más adelante en el taller profundizarás en ramas y pull requests, en este bloque basta con acordar una estrategia básica)
• cómo se revisa el trabajo de un compañero antes de darlo por terminado (revisión entre pares)
• cómo se resuelve un desacuerdo técnico dentro del equipo.

Ejemplo profesional. En un equipo de desarrollo real, estas decisiones no quedan implícitas: se documentan (aunque sea de forma breve) precisamente para que, cuando surge un desacuerdo o una persona se ausenta, el resto del equipo sepa cómo proceder sin tener que inventar la respuesta en el momento.

Ejemplo relacionado con tu proyecto. Si tu equipo trabaja en ReservaFIC, una división de trabajo razonable podría separar “gestión de solicitudes de préstamo” (una persona) de “panel del administrador” (otra persona), acordando de antemano que ambas partes comparten el mismo modelo de datos y se integran al final de cada sesión de trabajo, no solo al final del sprint.

Error común

Confundir “estrategia de colaboración” con “nos comunicaremos por WhatsApp”. Comunicarse es necesario pero no es una estrategia: una estrategia responde cómo se divide el trabajo, cómo se integra, cómo se revisa y cómo se resuelve un desacuerdo — cuatro preguntas concretas, no una sola.

Para reflexionar

• En un trabajo en equipo anterior, ¿cómo se resolvía (o no se resolvía) un desacuerdo técnico entre compañeros?
• Si hoy un integrante de tu equipo se ausentara una semana, ¿el resto sabría exactamente qué estaba haciendo y cómo continuarlo?

Actividad y evidencia

Aplica lo estudiado aquí en la Actividad 3 — Taller de conformación de equipos, donde tu equipo distribuirá roles iniciales y acordará por escrito su estrategia de colaboración. El producto esperado es una ficha de equipo: integrantes, roles iniciales asignados y estrategia de colaboración acordada.

Referencias de este tema

• Hunt, A. y Thomas, D. (2019). The Pragmatic Programmer. Ver Referencias del bloque.

Qué sigue

Con el equipo organizado, necesitas un marco de trabajo compartido para decidir qué construir primero y cómo revisarlo: continúa con 3. Introducción a Scrum.