Qualcosa che ho trovato fastidioso per un bel po’ di tempo è quanto sia comune per molti nel settore usare termini come “Scrum ma …” in senso peggiorativo, implicando che i team dovrebbero seguire solo il piccolo insieme di pratiche che fanno parte di Scrum. La realtà è che per qualsiasi team Agile per essere in grado di consegnare ripetutamente software funzionante per un periodo di tempo significativo, Scrum da solo non è sufficiente. Che se ne rendano conto o no, la stragrande maggioranza dei team che si definiscono Scrum stanno operando come un ibrido Scrum-XP, o un ibrido Scrum-Kanban-XP, dove impiegano almeno un sottoinsieme delle pratiche tecniche che hanno avuto origine con XP.
Per la cronaca, lasciatemi dire che i team che stanno seguendo solo le pratiche Scrum difficilmente avranno successo a lungo termine, perché almeno un sottoinsieme delle pratiche tecniche XP sono un must per un successo continuo come team di consegna Agile.
Ho osservato che non ci sono abbastanza persone che capiscono cosa comprende e non comprende Scrum, quindi cominciamo da qui.
Cos’è Scrum – un insieme di pratiche di gestione
Scrum è l’applicazione del controllo empirico dei processi, che è un modo elegante per dire che dovremmo prendere decisioni basate sull’esperienza, non basate su un ipotetico insieme di presupposti che non sono fondati sulla realtà.
Semplicemente detto, Scrum consiste in un piccolo insieme di pratiche di gestione che hanno lo scopo di aiutare i team a collaborare efficacemente e a consegnare il lavoro in modo iterativo (lasciatemi sottolineare ancora una volta – non ci sono pratiche tecniche in Scrum).
Per riassumere brevemente il contenuto della Guida Scrum:
- C’è un team Scrum, che è composto da sviluppatori, il Product Owner e lo Scrum Master.
- Ci sono gli eventi di Scrum, che consistono nello Sprint, nella pianificazione dello Sprint, nello Scrum quotidiano (noto anche come Daily Standup, in XP), nella Sprint Review e nella Sprint Retrospective.
- Ci sono Artefatti Scrum, che consistono nel Product Backlog, lo Sprint Backlog, e l’Incremento, dove un Incremento esiste non appena un elemento dello Sprint Backlog incontra la Definizione di Fatto.
- C’è una Definizione di Fatto, dove ogni Team Scrum ha una comprensione condivisa di cosa significa “fatto” per ogni elemento del Product Backlog. Si noti che in contrasto con i Criteri di Accettazione, la Definizione di Fatto è applicata globalmente, mentre i Criteri di Accettazione sono specifici ai singoli Item del Product Backlog.
Cosa non è Scrum
Contrariamente alla credenza popolare, nessuna delle seguenti cose fa parte di Scrum:
- Storie utente. Gli elementi di lavoro in ogni dato Product Backlog o Sprint Backlog del team Scrum sono scritti come storie utente (spesso nel formato “Come <persona/ruolo>, voglio <obiettivo>, così che <risultato desiderato>”), ma Scrum non impone alcun costrutto o formato particolare. Si noti che le storie utente fanno parte di XP.
- Stima. Anche se la stragrande maggioranza dei team Scrum esegue una stima a qualche livello, la pratica della stima non fa parte di Scrum.
- Velocity. Anche la velocità non fa parte di Scrum; la nozione di velocità del progetto fa parte di XP.
- Pratiche tecniche. Come notato sopra, non c’è alcuna nozione di pratiche tecniche (CI, CD, programmazione a coppie, TDD, ecc.) in Scrum. La stragrande maggioranza delle pratiche tecniche che i team tipicamente seguono hanno avuto origine con XP.
Che cos’è l’Extreme Programming?
Sono passati più di due decenni da quando si è formato il primo team di Extreme Programming (XP), dove hanno lavorato su un progetto chiamato Chrysler Comprehensive Compensation (C3). I metodi impiegati da quel team ebbero origine in misura significativa negli anni ’80, quando Kent Beck e molti altri stavano sperimentando modi migliori per sviluppare software, cioè un’alternativa all’approccio “a cascata” che era diventato dominante a quel tempo.
Rendere il lavoro visivo è sempre stato un modo importante di informare il modo in cui lavorano i team Agili. Pertanto, come introduzione all’XP, raccomando che chiunque voglia saperne di più sarebbe ben servito iniziando con questi diagrammi:
- Progetto di programmazione estrema (diagramma end-to-end)
- Iterazione (diagramma che si concentra su ciò che accade all’interno di un’iterazione; si noti che ciò che XP chiama iterazione è concettualmente simile a ciò che Scrum chiama Sprint)
- Sviluppo (diagramma che si concentra sulle interazioni e le attività di sviluppo)
- Proprietà collettiva del codice (diagramma che si concentra sulle pratiche tecniche fondamentali)
Nota: Per una visualizzazione che combina molti degli elementi dei diagrammi precedenti in una pagina, vedere Extreme Programming Overview di Bill Wake.
Letture aggiuntive su XP
Se le immagini di cui sopra vi intrigano abbastanza da voler leggere di più su XP, guardate le seguenti fonti di informazione, che sono elencate più o meno in ordine di lettura più breve > più lunga:
- Don Wells, Extreme Programming: a gentle introduction
- Martin Fowler, BeckDesignRules (vedi anche Xp Simplicity Rules)
- Kent Beck, Ward Cunningham, et al., Extreme Programming Core Practices (aka i 12 XpXtudes)
- Don Wells, The Rules of Extreme Programming
- Ward Cunningham, et al.,Extreme Programming (aka il WikiWikiWeb)
- Ron Jeffries, What is Extreme Programming?
- Kent Beck & Cynthia Andres, Extreme Programming Explained: Embrace Change (2nd Ed.)
Riferimenti aggiuntivi
Tutti i riferimenti in questa sezione sono dal sito web XP di Don Wells, se non diversamente indicato.
- I modelli agili sono dipinti, non fotografie (tutti i modelli sono sbagliati; alcuni sono utili)
- Proverbi del Processo Agile (parole per ogni team da vivere)
- Bill Wake, Arrange, Act, Assert (schema per scrivere test unitari)
- Bill Wake, Sudoku Solver (interessante variazione su TDD)
- Bill Wake, Tests from a Hat (un approccio creativo verso la scrittura di test unitari)
- Piani onesti (come appare in pratica la stima)
- Gestisci i tuoi obiettivi invece delle attività (differenze principali tra sviluppo Waterfall e Agile)
- I valori della programmazione estrema (semplicità, Comunicazione, Feedback, Rispetto, Coraggio)
- XP e i database (un modello basato sui database oro > argento > bronzo)