I Quattro Valori Agile
Comprendere cosa valutiamo di più, e cosa valutiamo ancora (solo meno).
1Leggere Correttamente il Manifesto
Il Manifesto Agile dichiara quattro preferenze, non assoluti:
"Siamo arrivati a valorizzare X più di Y. Cioè, pur essendoci valore negli elementi a destra, valutiamo di più gli elementi a sinistra."
Questo è cruciale. Non è "X buono, Y cattivo." È "quando costretti a scegliere, preferisci X."
Fraintendimento Comune
"Non abbiamo bisogno di documentazione perché siamo agile" NON è ciò che dice il manifesto. La documentazione ha valore; semplicemente non è il focus primario.
2Individui e Interazioni più di Processi e Strumenti
Ottimi strumenti e processi non possono salvare un team disfunzionale. Ma un ottimo team può avere successo con strumenti mediocri.
Cosa significa in pratica:
- Assumere per la collaborazione, non solo per competenze tecniche
- Scegliere processi che servono il team, non il contrario
- Quando il processo crea attrito, correggere il processo
- La conversazione faccia a faccia batte le catene di email
Cosa non significa:
- Caos senza processo
- Ignorare strumenti utili
- Conoscenza tribale non documentata
Il team nota che il loro standup giornaliero è diventato un report di stato al manager. Discutono e cambiano il formato per concentrarsi sulla collaborazione.
Un team usa Jira esattamente come impone l'azienda, anche se il workflow non corrisponde a come lavorano realmente. Mantengono due sistemi.
3Software Funzionante più di Documentazione Esaustiva
La migliore documentazione di ciò che fa un sistema è il sistema stesso. Il codice che funziona batte le specifiche che descrivono cosa il codice potrebbe fare un giorno.
Cosa significa in pratica:
- Rilasciare presto e spesso
- Misurare il progresso con funzionalità funzionanti, non documenti completati
- Scrivere documentazione sufficiente, al momento giusto
- Mantenere i documenti vicini al codice così rimangono aggiornati
Cosa non significa:
- Mai nessuna documentazione
- Codice illeggibile senza commenti
- Nessuna discussione di design prima di codificare
4Collaborazione col Cliente più di Negoziazione dei Contratti
I contratti presumono che tu possa specificare tutto in anticipo. La collaborazione presume che imparerete insieme. In un mondo di incertezza, vince la collaborazione.
Cosa significa in pratica:
- Includere gli stakeholder nelle revisioni regolari
- Cercare feedback presto, non solo alla fine
- Adattare lo scope basandosi sull'apprendimento
- Costruire fiducia attraverso la trasparenza
Cosa non significa:
- Nessun contratto o accordo
- Scope creep illimitato
- Il cliente ha sempre ragione (spesso non sa cosa gli serve)
5Rispondere al Cambiamento più di Seguire un Piano
I piani sono utili. Aggrapparsi a piani obsoleti è dannoso. L'obiettivo non è evitare la pianificazione—è pianificare in modo da permettere l'adattamento.
Cosa significa in pratica:
- Iterazioni brevi con opportunità di ripianificazione
- Accogliere requisiti che cambiano, anche tardi nello sviluppo
- Tracciare la velocity per migliorare le stime future
- Terminare progetti presto quando non funzionano
Cosa non significa:
- Nessuna pianificazione
- Cambiare direzione ogni giorno
- Sviluppatori che ignorano la roadmap
Il Paradosso della Pianificazione
Nell'agile, pianifichiamo effettivamente PIÙ frequentemente che nel waterfall—solo in lotti più piccoli. "Rispondere al cambiamento" richiede ripianificazione costante.
- Il manifesto dichiara preferenze, non assoluti—il contesto conta
- Gli elementi a destra hanno ancora valore
- Ogni valore affronta una specifica modalità di fallimento dello sviluppo tradizionale
- Essere agile significa interiorizzare questi valori, non solo seguire regole