Rendere Esplicite le Politiche

Le regole implicite creano problemi:

• Le persone fanno assunzioni diverse
• Sorgono conflitti su "come facciamo le cose"
• I nuovi membri del team non conoscono le regole non scritte
• I miglioramenti sono difficili perché la base di partenza non è chiara

Le politiche esplicite sono accordi scritti e visibili su come il lavoro fluisce attraverso il vostro sistema.

Non devono essere complesse. "Rivediamo le PR entro 4 ore" è una politica. "Gli elementi bloccati vanno in cima alla colonna" è una politica. "Il QA inizia solo se i test unitari passano" è una politica.

Criteri di ingresso: Cosa deve essere vero perché il lavoro entri in una fase?

• "Pronto per Dev: Criteri di accettazione scritti, design allegati"
• "Pronto per Review: Tutti i test passano, nessun commit WIP"

Criteri di uscita (Definition of Done): Cosa deve essere vero per uscire?

• "Sviluppo Completato: Codice revisionato, CI verde, documentazione aggiornata"

Limiti WIP: Quanti elementi possono essere in questa fase?

• "Dev: Massimo 3 elementi in corso"

Politiche di gestione: Cosa succede in situazioni specifiche?

• "Bloccato: Aggiungi tag blocker, discuti nello standup, escalation dopo 24 ore"
• "Conflitto di priorità: Decide lo sviluppatore senior, escalation al lead se necessario"

Politiche temporali: Aspettative sui tempi?

• "Code review completate entro 4 ore lavorative"
• "Il QA inizia entro 1 giorno dalla disponibilità"

Politiche di selezione: Come scegliamo su cosa lavorare dopo?

• "FIFO all'interno della classe di priorità"
• "Bug rivolti al cliente prima dei problemi interni"

Le politiche dovrebbero essere visibili, non sepolte in documenti che nessuno legge.

Opzioni:

• Sulla board: Scrivi le politiche sopra o accanto a ogni colonna
• Documento collegato: Mantieni un documento di politiche vivo, collegalo dalla board
• Tooltip/hover: Le board digitali spesso supportano descrizioni delle colonne
• Card intestazione: La prima card in ogni colonna descrive la politica

Il test: Un nuovo membro del team può comprendere le politiche entro 5 minuti guardando la board?

Cadenza di revisione: Le politiche non sono statiche. Rivedile nelle retrospettive:

• Stiamo seguendo questa politica?
• Questa politica sta aiutando o ostacolando?
• Cosa manca?

Le politiche imposte non funzionano. Le politiche collaborative sì.

Processo per creare politiche:

1. Osserva la pratica attuale: "Come decidiamo effettivamente su cosa lavorare dopo?"
2. Fai emergere i disaccordi: "Sembra che Alice prenda quello che è più vecchio, ma Bob prende quello che è più piccolo?"
3. Discuti i compromessi: "Quali sono i pro e i contro di ogni approccio?"
4. Concordate sulla politica: "Proviamo FIFO per le prossime due settimane"
5. Rendila visibile: Scrivila sulla board
6. Rivedi e adatta: "Come ha funzionato FIFO? Dovremmo aggiustare?"

Principio chiave: Le politiche sono esperimenti, non comandamenti. Se una politica non aiuta, cambiatela.

Eccesso di documentazione: 20 politiche per colonna che nessuno legge. Inizia con 2-3 politiche essenziali per fase.

Mancata applicazione: Le politiche esistono ma vengono regolarmente ignorate. O le applicate o le eliminate.

Regole rigide: "Non superare mai il limite WIP in nessuna circostanza." La realtà è più complessa. Consenti il giudizio rendendo visibile l'eccezione.

Escalation mancante: Cosa succede quando le politiche entrano in conflitto o si rompono? "Se il limite WIP è raggiunto e arriva lavoro urgente, escalation al team lead."

Politiche obsolete: Regole di sei mesi fa che non si adattano più. Rivedi le politiche regolarmente.

Politiche individuali: "Il lavoro di Bob non passa per la code review." L'equità conta. Le politiche dovrebbero applicarsi al lavoro, non alle persone.