Linear guida completa: team, cicli, roadmap e GitHub

👁 117 letture

Linear è uno strumento per gestire il lavoro sul prodotto progettato per la velocità: issue, cicli di lavoro, progetti e roadmap sono pronti dal primo giorno, senza settimane di configurazione. Questa guida ti accompagna nella configurazione iniziale dello spazio per il tuo team, seguendo la documentazione ufficiale di Linear.

Prima di iniziare: stabilisci tre regole

Linear funziona subito, ma il team ha bisogno di alcune regole condivise per evitare che lo strumento si trasformi in un’altra lista che nessuno legge. Stabilite prima del primo ciclo:

• chi e quando rivede il triage, ad esempio una persona ogni mattina,
• cosa significano le priorità, in modo che “urgente” non significhi tutto,
• come nominate i branch nel codice, così l’integrazione con GitHub aggiorna automaticamente gli stati.

Annotate queste regole in un unico posto, preferibilmente nella descrizione del team in Linear stesso.

Passo 1. Workspace e team

Dopo aver creato l’account, crei il workspace aziendale e il primo team. Un team in Linear è un’unità di lavoro, ad esempio un prodotto, un’app mobile o un reparto. Ogni team ha le proprie issue, stati e cicli. In una piccola azienda un solo team all’inizio è più che sufficiente.

Se stai migrando da un altro strumento, la documentazione di Linear descrive l’importazione delle issue dal sistema esistente.

Passo 2. Issue

Un’issue è l’unità base di lavoro: un bug, un task, un’idea. Ha un titolo, una descrizione, un responsabile, una priorità e uno stato. Linear è progettato per le scorciatoie da tastiera, quindi puoi fare quasi tutto senza mouse: creare un’issue, cambiare priorità, assegnare una persona. Trovi l’elenco completo delle scorciatoie nella guida dell’applicazione. I team riferiscono che con le scorciatoie si possono organizzare decine di issue in pochi minuti.

Passo 3. Cicli, ovvero sprint senza supervisione

I cicli sono periodi di lavoro ripetibili, l’equivalente degli sprint. Imposti la loro durata, il giorno di inizio e cosa succede alle attività non completate. Le issue non completate possono passare automaticamente al ciclo successivo, quindi nessuno deve spostarle manualmente ogni due settimane. Un buon inizio sono cicli di due settimane e il primo ciclo riempito con issue pronte per essere lavorate.

Passo 4. Progetti e roadmap

I progetti servono per iniziative più lunghe, spesso che coinvolgono più team, ad esempio una nuova versione dell’app. Un progetto raccoglie le issue, mostra i progressi e permette di pubblicare aggiornamenti, così il capo non deve chiedere in riunione come sta andando. Dai progetti si compone la roadmap visibile a tutta l’azienda.

Passo 5. Triage, ovvero la casella di posta

Le issue create dalle integrazioni o da persone esterne al team finiscono prima nel triage. È una casella che qualcuno rivede regolarmente e decide: nel ciclo corrente, nella lista per dopo, da rifiutare. In questo modo la lista delle attività del team non si intasa di issue che nessuno ha esaminato.

Passo 6. Integrazione con GitHub

Attivi l’integrazione nelle impostazioni, nella sezione integrazioni. Linear collega le issue alle pull request tramite i nomi dei branch, i titoli o le parole chiave e cambia automaticamente lo stato dell’issue in base a ciò che accade nel codice. Puoi anche sincronizzare le issue tra il repository e il team. Nota pratica: il collegamento più affidabile è dato dal nome del branch secondo la convenzione Linear.

Esempio: prima settimana di un team di cinque persone

Primo giorno: workspace, un team, importazione delle issue dal vecchio foglio di calcolo. Secondo giorno: revisione delle issue, priorità, divisione tra ciclo corrente e lista per dopo. Terzo giorno: collegamento con GitHub e definizione della convenzione per i nomi dei branch. Dalla seconda settimana il team smette di chiedere chi sta lavorando su cosa, perché è visibile nel ciclo.

In questa implementazione, il secondo giorno è il più importante, cioè la revisione delle issue. Un team che stabilisce subito le priorità e rimanda ciò che non è urgente inizia il primo ciclo con un piano realistico. Un team che mette nel ciclo tutto ciò che arriva dal vecchio foglio di calcolo, dopo due settimane ha un senso di fallimento, anche se il problema era solo una pianificazione troppo ottimistica.

Errori più comuni

• Troppi team all’inizio in una piccola azienda.
• Triage non revisionato, che si trasforma in un deposito di spazzatura.
• Mancanza di convenzione per i nomi dei branch, per cui gli stati non si aggiornano.

Come valutare il primo ciclo

Dopo il primo ciclo, ponetevi tre domande. Quante issue pianificate siete riusciti a chiudere, perché questa è la prima misura reale di quanto può stare in due settimane. Se il triage è stato revisionato regolarmente. Se gli stati si sono aggiornati automaticamente dopo il merge del codice, o se qualcuno ha dovuto spostarli manualmente.

Il primo ciclo è quasi sempre sovrapianificato. È normale ed è proprio per questo che lo si fa: il secondo ciclo lo pianificate già sulla base di dati, non di ottimismo.

Se il team arriva da un altro strumento, dagli due o tre cicli per abituarsi prima di iniziare a valutare se il cambiamento è valso la pena. Le prime settimane sono sempre più lente, perché le persone imparano le scorciatoie e il nuovo ritmo di lavoro.

// continua a leggereHiggsfield API: guida completa, costi e integrazione nel 2026MagazineManus guida completa: come delegare task completi all’AI agentMagazineTypeless: guida completa per configurare la dettatura vocaleGuide

Kinetyra