Linear paso a paso: equipos, ciclos, roadmap y GitHub
Linear es una herramienta de gestión de producto diseñada para la velocidad. Te mostramos cómo configurar tu espacio de trabajo, ciclos y la integración con GitHub.
👁 117 lecturas
Linear es una herramienta de gestión de producto construida para la velocidad: issues, ciclos de trabajo, proyectos y roadmaps están disponibles desde el primer día, sin necesidad de una semana de configuración. Este tutorial te guía por la configuración inicial del espacio de trabajo para tu equipo, siguiendo la documentación oficial de Linear.
Antes de empezar: establece tres reglas básicas
Linear funciona desde el primer momento, pero tu equipo necesita algunas reglas comunes para que la herramienta no se convierta en otra lista que nadie lee. Estableced antes del primer ciclo:
- quién y cuándo revisa el triage, por ejemplo una persona cada mañana,
- qué significan las prioridades, para que «urgente» no signifique todo,
- cómo nombráis las ramas en el código, para que la integración con GitHub actualice los estados automáticamente.
Anotad estas reglas en un solo lugar, preferiblemente en la descripción del equipo dentro del propio Linear.
Paso 1: Espacio de trabajo y equipo
Después de crear tu cuenta, creas el espacio de trabajo de la empresa y el primer equipo. Un equipo en Linear es una unidad de trabajo, por ejemplo un producto, una aplicación móvil o un departamento. Cada equipo tiene sus propios issues, estados y ciclos. En una empresa pequeña, un solo equipo es suficiente para empezar.
Si vienes de otra herramienta, la documentación de Linear describe cómo importar issues desde tu sistema actual.
Paso 2: Issues o tareas
Un issue es la unidad básica de trabajo: un bug, una tarea, una idea. Tiene título, descripción, persona responsable, prioridad y estado. Linear está diseñado para atajos de teclado, así que puedes hacer casi todo sin ratón: crear un issue, cambiar la prioridad, asignar a alguien. Encontrarás la lista completa de atajos en la ayuda de la aplicación. Los equipos describen que con los atajos se pueden organizar decenas de issues en pocos minutos.
Paso 3: Ciclos, sprints sin vigilancia
Los ciclos son períodos de trabajo repetibles, el equivalente a los sprints. Configuras su duración, el día de inicio y qué ocurre con las tareas no terminadas. Los issues incompletos pueden pasar automáticamente al siguiente ciclo, así que nadie tiene que moverlos manualmente cada dos semanas. Un buen comienzo son ciclos de dos semanas y el primer ciclo lleno de issues listos para trabajar.
Paso 4: Proyectos y roadmap
Los proyectos sirven para iniciativas más largas, a menudo que abarcan varios equipos, como una nueva versión de la aplicación. Un proyecto agrupa issues, muestra el progreso y permite publicar actualizaciones, así que el jefe no tiene que preguntar en la reunión cómo va todo. Los proyectos componen el roadmap visible para toda la empresa.
Paso 5: Triage, la bandeja de entrada
Los issues creados por integraciones o por personas fuera del equipo llegan primero al triage. Es una bandeja que alguien revisa regularmente y decide: al ciclo actual, a la lista para después, o rechazar. Así la lista de tareas del equipo no se llena de issues que nadie ha revisado.
Paso 6: Conexión con GitHub
Activas la integración en los ajustes, en la sección de integraciones. Linear vincula issues con pull requests mediante nombres de ramas, títulos o palabras clave y cambia automáticamente el estado del issue según lo que ocurre en el código. También puedes sincronizar issues entre el repositorio y el equipo. Consejo práctico: la vinculación más fiable se consigue con el nombre de rama según la convención de Linear.
Ejemplo: primera semana de un equipo de cinco personas
Día uno: espacio de trabajo, un equipo, importación de issues desde la hoja de cálculo antigua. Día dos: revisión de issues, prioridades, división entre ciclo actual y lista para después. Día tres: conexión con GitHub y establecimiento de la convención de nombres de ramas. Desde la segunda semana el equipo deja de preguntar quién trabaja en qué, porque se ve en el ciclo.
En esta implementación, lo más importante es el segundo día, es decir, la revisión de issues. Un equipo que establece prioridades desde el principio y pospone lo que no es urgente comienza el primer ciclo con un plan realista. Un equipo que mete en el ciclo todo lo que venía de la hoja de cálculo antigua tiene sensación de fracaso después de dos semanas, aunque el problema era solo una planificación demasiado optimista.
Errores más frecuentes
- Demasiados equipos al principio en una empresa pequeña.
- Triage sin revisar, que se convierte en un vertedero.
- Falta de convención de nombres de ramas, por lo que los estados no se actualizan.
Cómo evaluar el primer ciclo
Después del primer ciclo, haceos tres preguntas. Cuántos issues planificados se lograron cerrar, porque es la primera medida real de lo que cabe en dos semanas. Si el triage se revisó regularmente. Si los estados se actualizaron solos después de fusionar el código, o si alguien tuvo que moverlos manualmente.
El primer ciclo casi siempre está sobreplanificado. Es normal y precisamente para eso se hace: el segundo ciclo lo planificáis ya basándoos en datos, no en optimismo.
Si el equipo viene de otra herramienta, dale dos o tres ciclos para acostumbrarse antes de empezar a evaluar si el cambio mereció la pena. Las primeras semanas siempre son más lentas, porque la gente aprende los atajos y el nuevo ritmo de trabajo.
More on this from FULGOR
revista·IA en el aula: ¿prohibir o enseñar a usarla?Dos profesores, dos enfoques opuestos ante la IA. Uno la prohíbe, otro la integra. ¿Cuál tiene razón? La respuesta no es tan simple como parece.