Attività e ticket — cosa sono, sistemi di tracciamento e lavoro con le attività

Cos'è un'attività e un ticket?

Attività — un'unità di lavoro registrata in un sistema di tracciamento. Contiene descrizione, priorità (Critical, High, Medium, Low), assegnatario, scadenza e stato. Nello sviluppo mobile, un'attività può essere “Aggiungere schermata profilo con avatar”, “Implementare paginazione del feed” o “Aggiornare targetSdk a 35”. Ogni attività è legata a un progetto, sprint e a uno sviluppatore o team specifico.

Ticket — un'entità più ampia. Un ticket può essere una segnalazione di bug (“L'app si blocca durante la rotazione dello schermo su Android 14”), una richiesta di funzionalità (“Aggiungere supporto per tema scuro”), una richiesta di supporto tecnico (“La notifica push non arriva”) o un compito del manager (“Preparare il report del tasso di crash del mese”). Il confine tra attività e ticket è sfumato: in Jira, entrambi i concetti sono combinati in Issue. La differenza chiave: un'attività ha sempre un assegnatario, mentre un ticket può essere una richiesta senza un assegnatario specifico fino al triage.

In Scrum e Kanban, le attività sono l'elemento principale del backlog. Ogni attività deve soddisfare i criteri INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Le attività indipendenti possono essere implementate in qualsiasi ordine. Stimabili — il team può stimare lo sforzo. Piccole — rientrano in uno sprint. Testabili — hanno criteri di accettazione chiari. Le attività grandi (epic) vengono suddivise in attività più piccole fino a quando tutti i criteri non sono soddisfatti.

Tipi di attività nello sviluppo mobile

Feature — nuova funzionalità dell'applicazione. Esempio: “Schermata di login biometrico (Face ID / Touch ID)”. Le attività Feature sono sempre collegate a una user story e hanno Criteri di Accettazione. La stima è in story point (1, 2, 3, 5, 8, 13). Bug — un difetto trovato durante lo sviluppo o il test. La priorità di un ticket bug è determinata dalla gravità (crash → Critical, bug UI → Medium, refuso → Low). Nello sviluppo mobile, un tasso di crash superiore allo 0,1% è un bug critico che richiede una correzione immediata.

Tech Debt / Chore — attività tecniche senza effetto visibile per l'utente: aggiornamento librerie (Dependency Bump), refactoring (Migrazione da ViewPager a ViewPager2), configurazione CI/CD, scrittura test. Le attività Tech Debt sono spesso sottovalutate, sebbene secondo Stripe 2025, fino al 30% del tempo di un team mobile viene dedicato alla manutenzione e al pagamento del debito tecnico. Ignorare il debito tecnico porta a un aumento dei bug e a un rallentamento dello sviluppo di nuove funzionalità.

Tipi aggiuntivi: Spike (attività di ricerca — esplorare una nuova tecnologia, scrivere un POC), Task (qualsiasi lavoro non legato al codice — documentazione, revisione design), Improvement (miglioramento di funzionalità esistente — ottimizzazione del tempo di caricamento della schermata). In Jira, i tipi di issue sono personalizzabili per progetto. Il set standard per un team mobile: Story, Bug, Task, Improvement, Epic. Epic — un grande tema che unisce più storie. Esempio: “E-commerce: carrello e checkout”.

Ciclo di vita di un'attività: dalla creazione alla chiusura

Open (To Do) — attività creata ma non iniziata. Contiene descrizione, Criteri di Accettazione, priorità. In questo stato, l'attività deve passare attraverso il grooming (affinamento e stima) prima di entrare in uno sprint. In Progress — lo sviluppatore ha iniziato a lavorare. Nello sviluppo mobile, è importante collegare commit e pull request all'attività: in Jira tramite Smart Commits (APP-123 #comment fix bug), in GitHub/GitLab tramite parole chiave nella descrizione del PR (Closes APP-123).

In Review — codice inviato per revisione. Controlli automatici: CI (Gradle build, lint, unit tests), SonarQube (qualità del codice), Danger (changelog, tests). Lo sviluppatore non può prendere l'attività successiva mentre quella corrente è in Review — questo previene il multitasking. QA / Testing — il tester verifica su dispositivi reali (Android — varie versioni del SO e dimensioni dello schermo, iOS — diversi modelli di iPhone). Se vengono trovati bug, l'attività torna in In Progress con un commento.

Done (Closed) — attività completata: codice unito in main/master, testato, pronto per il rilascio. Alcuni team aggiungono uno stato Deployed — l'attività raggiunge l'utente solo dopo che il build è stato pubblicato negli store. È importante chiudere le attività con un commento sul risultato: quale versione, quale PR, quali metriche sono cambiate. Secondo Linear (2025), i team che chiudono le attività con una descrizione del risultato hanno il 40% in meno di probabilità di tornare sulle stesse attività.

Il ciclo di vita può includere uno stato Blocked — l'attività non può essere completata a causa di una dipendenza esterna (in attesa di design, risposta dal backend, approvazione del manager). Le attività bloccate devono avere un commento con il motivo e la data del prossimo controllo. Una revisione settimanale delle attività bloccate aiuta a identificare ritardi sistemici nel processo di sviluppo. I bloccanti che durano più di 2 settimane richiedono escalation al livello del product manager.

Sistemi di tracciamento delle attività

Jira — lo standard del settore per team di 10 o più persone. Supporta bacheche Scrum e Kanban, personalizzazione avanzata del workflow, campi personalizzati, automazioni e integrazione con Bitbucket/GitHub. Svantaggi: eccessivo per team piccoli, UI lenta, configurazione complessa. Per i progetti mobile, Jira viene personalizzato con: il plugin Mobile-specific fields (Platform, OS version, Device model), integrazione con TestFlight e Firebase Test Lab, e automazione dei build di rilascio. Jira è la scelta per progetti enterprise con processi burocratici.

Linear — un tracker moderno per team di prodotto. UI veloce, supporto di prima classe per scorciatoie da tastiera, Cycle integrato (analogo allo sprint), integrazione con GitHub e Slack. Vantaggi: creazione rapida di attività tramite CMD+K, distribuzione automatica delle fasi (Triaged → Backlog → Upcoming → Current → Completed), documentazione e roadmap integrate. Linear è scelto da startup e team di prodotto che apprezzano la velocità. Nel 2025, il 40% dei nuovi progetti mobile utilizza Linear.

Trello — una semplice bacheca kanban per team piccoli (2–5 persone). Carte con checklist, etichette, scadenze. Svantaggio: niente sprint, analisi limitata, difficile da scalare. YouGile — un analogo russo di Trello con bacheche kanban, chat e videochiamate. Asana — un tracker focalizzato su progetti e timeline. La scelta del tracker dipende dalle dimensioni del team, dal budget e dalle preferenze: Jira per enterprise, Linear per team di prodotto, Trello/YouGile per startup. Importante: lo strumento deve essere unificato per l'intero team — designer, sviluppatori, QA, manager lavorano tutti nello stesso sistema.

Buone pratiche per la gestione delle attività

Scrivere Criteri di Accettazione — i criteri di accettazione devono essere specifici e verificabili. Male: “La schermata di login funziona”. Bene: “L'utente inserisce email e password, clicca Accedi. Se i dati sono corretti — naviga alla schermata principale. Se errati — mostra l'errore “Email o password non validi””. I Criteri di Accettazione (CA) sono il contratto tra sviluppatore, tester e product manager. Senza CA, un'attività non soddisfa la Definition of Ready (DoR) e non dovrebbe entrare in uno sprint.

Collega tutto. Commit, PR, casi di test, mockup di design (Figma), discussioni Slack — tutto deve essere collegato all'attività. In Jira, questo viene fatto tramite link nei commenti; in Linear, tramite collegamento automatico del PR. La regola di un clic: dall'attività al design/codice/test — non più di un clic. Lo sviluppatore apre l'attività e vede immediatamente il mockup Figma, il link del PR e i casi di test. Questo accelera l'onboarding dei nuovi membri del team del 30% secondo Linear (2025).

Non creare attività fantasma. Un'attività senza descrizione, senza CA e senza priorità è spazzatura. Se al daily standup nessuno ricorda perché è stata creata un'attività — dovrebbe essere eliminata o chiarita. La regola delle 48 ore: se un'attività è rimasta in stato In Progress senza attività per 48 ore, lo sviluppatore deve lasciare un commento sui motivi del ritardo. Secondo Jira (2025), il 60% delle attività inattive per più di 3 giorni finisce per essere chiuso senza completamento.

Decomposizione delle attività: epic, user story e sotto-attività

Epic — una grande area funzionale che unisce molte storie. Esempio: “Onboarding utente” include “Schermata di benvenuto”, “Selezione interessi”, “Caricamento avatar”, “Impostazioni notifiche”. User Story — un'attività dal punto di vista dell'utente. Formato: “Come [ruolo], voglio [azione] per [valore]”. Esempio: “Come utente, voglio accedere con biometria per non dover inserire la password ogni volta”. Le User Story sono scritte dal product manager o dal product owner.

Sotto-attività (Sub-task) — decomposizione del lavoro tecnico all'interno di una Story / Task. Esempio per la Story “Schermata profilo”: Sotto-attività 1: Costruire UI (XML / SwiftUI), Sotto-attività 2: Collegare al ViewModel, Sotto-attività 3: Scrivere Test Unitari, Sotto-attività 4: Snapshot Test, Sotto-attività 5: UI Test (Espresso / XCUITest). Regola di decomposizione: ogni sotto-attività viene completata in 1–2 giorni. Se uno sviluppatore stima una sotto-attività più lunga — suddividi ulteriormente. Le sotto-attività sono una tecnica interna del team, non sono visibili nel backlog di prodotto. La somma delle stime delle sotto-attività non è necessariamente uguale alla stima della Story padre (parte del lavoro è comunicazione, code review, test).

Piramide di decomposizione: Epic (Trimestre / Semestre) → Feature / Story (Sprint) → Task (1–3 giorni) → Sub-task (Diverse ore). La tecnica INVEST aiuta a verificare la qualità della decomposizione. Se un'attività non è Independent (dipende da altre) — questo segnala una decomposizione errata. Se un'attività non è Small (più di 8 story point) — necessita di ulteriore suddivisione. Schema comune: Epic → 5–15 Stories → ogni Story → 3–8 Sub-tasks. La stima finale dell'epic = somma delle stime delle Stories, ma il primo sprint di solito dà un margine di errore del 20–30% nelle stime.

Errori comuni nel lavoro con le attività

Errore 1: attività troppo grandi. Un'attività di 2 settimane è un epic che necessita di decomposizione. Le attività grandi non possono essere integrate nel tracciamento quotidiano; rimangono in In Progress per settimane. Regola: dimensione massima dell'attività — 2–3 giorni di lavoro. Tutto ciò che è più grande deve essere decomposto. Effetto collaterale: lo sviluppatore percepisce progresso chiudendo 2–3 attività a settimana invece di una gigantesca. Questo aumenta la motivazione e la prevedibilità delle scadenze.

Errore 2: mancanza di Criteri di Accettazione. Lo sviluppatore ha implementato la funzionalità, il tester ha verificato — tutto bene. Il manager: “Dov'è il pulsante di modifica?” — “Non era nell'attività”. Senza CA, ogni parte comprende l'attività in modo diverso. Risultato: rilavorazione, conflitti, scadenze mancate. CA è un contratto: se l'attività non ha criteri, non è pronta per lo sprint. Nel grooming, la prima cosa verificata è la presenza di CA. Se mancano CA, l'attività viene restituita al Product Manager per l'affinamento.

Errore 3: dimenticare il debito tecnico. Il team fa solo attività Feature sprint dopo sprint. Sei mesi dopo: la build impiega 15 minuti, Gradle è indietro di 3 versioni principali, i test falliscono su CI a causa di deprecazioni. Soluzione: riservare il 20% del tempo del team per Tech Debt (pratica Google SRE “Budget errori basato su SLO”). Crea almeno un'attività Tech Debt per ogni sprint di Feature. Proporzione: ogni 3 attività Feature — 1 Tech Debt o Bug. Questo previene l'accumulo di debito tecnico e mantiene la velocità di sviluppo.