Di questo argomento ho già scritto con una serie di articoli su demand & project management, al termine dei quali accennavo anche alle metodologie agili ed in particolare al metodo SCRM.
Ho avuto modo recentemente di approfondire il tema, preparando il corso “Agile Project Management in Financial Institution” che ho tenuto l’11 febbraio alla CeTIF Academy, e che terrò nuovamente in maggio. Trovo utile in attesa della seconda edizione condividere alcuni concetti di base, augurandomi di ricevere vostri contributi e arricchimenti sul tema, soprattutto in termini di esperienze che vadano al di là dell’utilizzo di agile nello sviluppo del software.
Importanti fonti di ispirazione per me sono state:
- Agile Project Management with SCRUM, di Ken Schwaber, uno dei firmatari dell’Agile Manifesto e degli inventori del metodo SCRUM, dal quale ho appreso la sottile “arte del possibile”
- Henrik Kniberg, di Crisp, un agile coach che lavora, fra l’altro, con Spotify e Lego e sul cui blog potete trovare le ricette pratiche per applicare al meglio le metodologie agili. Alcune delle quali sono diventare addirittura virali 😉
- Alistair Cockburn, un altro firmatario dell’Agile Manifesto, che mi ha incantato con il suo esercizio Elephant Carpaccio
- Andrea Tomasini, di Agile 42, agile coach e trainer di consolidata esperienza.
Nei prossimi post approfondirò alcuni concetti chiave, sottostanti alle metodologie agili, di cui è bene appropriarsi prima di procedere:
- Empirical Process Control: attraverso la trasparenza, l’ispezione e l’adattamento, i migliori processi emergeranno mentre si procede e solo retrospettivamente sarà possibile riconoscere gli adattamenti di successo, rispetto agli altri.
- Lean Thinking: il processo si migliora nel continuo, attraverso l’osservazione costante delle irregolarità in un flusso, nei materiali o nel carico di lavoro delle persone, ed attraverso eliminazione delle attività non necessarie.
- Iterative & Incremental: lo sviluppo di un prodotto in release, frutto di iterazioni successive, non solo aumenta la qualità esplicita del prodotto (grazie al vincolo di rilasciabilità alla fine del ciclo), ma insegna anche a tutti coloro che sono coinvolti nel progetto cosa è realmente necessario per supportare una business vision.
- Pull Principle ed empowerment: team auto organizzati ed auto diretti decidono quanto lavoro prendere in carico e quale conoscenza è necessario costruire per realizzare software di valore per l’utente e di qualità. Essendo una loro decisione, nel momento in cui scelgono, esprimono il proprio impegno alla realizzazione e faranno del loro meglio (best effort) per riuscirci. Il concetto di best effort è contro intuitivo, rispetto al concetto di produttività, tuttavia riflettete sul fatto che il TCPIP, il protocollo di rete grazie al quale funziona internet, è un protocollo best effort: i pacchetti di messaggi seguono strade diverse e se una spedizione fallisce, viene ripetuta…
luigiatauro.com 
L’ha ribloggato su The thoughts of Paul.
"Mi piace""Mi piace"