Task

Il task (o "attività") è l'unità minima di lavoro assegnabile e tracciabile in un progetto. È il mattone con cui si costruisce il piano operativo.

Gerarchia del lavoro

I task non vivono isolati: si inseriscono in una gerarchia che parte dagli obiettivi e arriva all'azione quotidiana.

Goal / Obiettivo strategico
   ↓
Outcome / Risultato atteso
   ↓
Deliverable / Output concreto
   ↓
Work Package (foglia della WBS)
   ↓
Task / Attività singola
   ↓
Sub-task (opzionale)

Il task è quindi la foglia operativa della WBS.

Anatomia di un buon task

Un task ben scritto contiene:

Elemento	Esempio
Titolo (azione + oggetto)	"Implementare endpoint POST /orders"
Descrizione	Specifica cosa fare e perché
Assignee (R nella RACI)	Marco
Stima	6 ore / 1 story point
Deadline o sprint	Sprint 3 / 22-set
Definition of Done	Endpoint testato, documentato in OpenAPI, code review approvata
Dipendenze	Bloccato da: "Schema DB ordini"
Priorità	Alta / Media / Bassa (vedi Eisenhower)
Tag / Categoria	backend, api

Caratteristiche di un task efficace — INVEST

Mutuato dall'agile (per le user story), i criteri INVEST valgono anche per i task generici:

Lettera	Significato	Significato pratico
I	Independent	Eseguibile senza dipendere da troppi altri task
N	Negotiable	I dettagli si possono discutere
V	Valuable	Produce un valore (o avanzamento) chiaro
E	Estimable	Si può stimare con ragionevolezza
S	Small	Piccolo abbastanza da finirlo in poco tempo (idealmente 1-3 giorni)
T	Testable	Esiste un modo verificabile per dire "fatto"

Stima dei task

Tre approcci principali:

1. Stima in ore/giorni

Pro: traducibile in costi, comprensibile
Contro: tende a essere ottimistica, "Hofstadter's law"
Tipica in contesti waterfall e a budget fisso

2. Story points (relativi)

Pro: si stima la complessità relativa, non il tempo assoluto
Contro: serve un team stabile per essere significativo
Tipica in contesti agile (Scrum)
Scala comune: Fibonacci modificata → 1, 2, 3, 5, 8, 13, 21

3. T-shirt sizing

XS, S, M, L, XL — stima qualitativa
Pro: velocissima, utile in early stage
Contro: poco precisa, va raffinata dopo

→ Regola d'oro: un task che stimi > 2 giorni o > 8 story point dovrebbe essere spezzato. Se non riesci a spezzarlo, non lo capisci abbastanza.

Stato del task (workflow)

Il ciclo di vita tipico:

Personalizza il workflow al tuo contesto, ma:

Limita gli stati: 4-6 stati sono sufficienti, di più diventa burocrazia
Definisci criteri di transizione: cosa deve essere vero perché un task passi da uno stato all'altro?
Tracca i blocchi: "Blocked" non è uno stato finale — serve un owner che lo sblocchi

Task vs Issue vs Ticket vs User Story

Termini spesso confusi:

Termine	Cosa è	Esempio
Task	Unità di lavoro	"Configurare il dominio DNS"
Issue	Termine ombrello (può essere task, bug, feature)	Linear/GitHub "issue"
Ticket	Item proveniente da supporto/helpdesk	"Cliente segnala errore 500 al login"
User Story	Esigenza espressa dal punto di vista utente	"Come admin, voglio resettare la password degli utenti"
Epic	Insieme di task/story correlati a un tema	"Sistema di autenticazione"

Strumenti di gestione task

Strumento	Stile	Quando usarlo
Gantt	Lineare, temporale	Progetti con dipendenze forti e scadenze fisse
Kanban	Flusso continuo, visual	Operations, flussi di lavoro ripetitivi, team agile
Scrum board	Sprint a tempo fisso	Sviluppo prodotto iterativo
Lista (Todoist, Things, paper)	Semplice, personale	Task individuali

Buone pratiche

Scrivi task azionabili: comincia con un verbo ("Implementare", "Validare", "Inviare"), non con un sostantivo ("Login utente")
Un owner per task: condividi la conoscenza, non la responsabilità
Niente "task contenitore": se un task ha 10 sotto-attività eterogenee, non è un task — è un mini-progetto
Tracca il tempo solo se serve: utile per stime future, dannoso se diventa sorveglianza
Chiudi i task aperti: una to-do list piena di task vecchi mai chiusi smette di essere uno strumento

Anti-pattern

✕ Task troppo grandi ("Sviluppare il backend")
✕ Task troppo piccoli ("Aprire il file index.js") → overhead di gestione > lavoro
✕ Task senza Definition of Done → "fatto" diventa soggettivo
✕ Task senza assignee → nessuno lo farà
✕ Lista task = piano di progetto → la lista task è il cosa fare oggi, il piano è il come arriviamo all'obiettivo

Collegamenti

WBS — i task sono le foglie della WBS
RACI Matrix — definisce chi è R/A su ogni task
Eisenhower Matrix — per prioritizzare i task
Gantt — visualizzare i task nel tempo
Kanban — visualizzare i task nel flusso
Esecuzione — fase di vita quotidiana dei task
Definition of Done / Ready — criteri di completamento dei task
Scrum — task del Sprint Backlog
User Stories — granularità superiore al task, con focus utente