Agile Project Management per principianti
Padroneggiare le basi con Scrum
Di Bryan Mathis
*****
CONTENUTI
*****
Introduzione
1.Panoramica Agile
2.<Uno sguardo da vicino ad Agile
3.Introduzione a Scrum
4.Uno sguardo da vicino a Scrum:Il ciclo Sprint
5.Agile in azione
Appendice:I 12 principi di Agile
Omaggio e ringraziamenti
*****
INTRODUZIONE
*****
La mia prima esperienza con Agile è avvenuta nel 2005 in una piccola startup di tecnologia sulla costa occidentale. All'epoca, il concetto di “software as a service “(SaaS) era agli albori. Finimmo per sviluppare un ottimo prodotto che però non era all'altezza del suo potenziale perché il pubblico era ancora legato a prodotti software per computer desktop.
Tuttavia, le fondamenta era state gettate, e da allora ho trascorso tutta la mia carriera lavorando come appaltatore in piccole startup specializzate in sviluppo di software. Con l'emergere del cloud computing nel 2008, molti pezzi del puzzle, per me, iniziarono a incastrarsi. Da quel momento, ho fatto parte di numerosi grandi progetti, tra cui una serie di applicazioni web per cellulare. Immancabilmente, le aziende di maggior successo con cui ho lavorato hanno usato Agile per la gestione dei loro team.
Il mio intento nello scrivere questo libro è di usare la mia esperienza di membro del team Agile per presentare ai lettori i principi di base dello stesso . Questo non è da intendersi un manuale pratico-avanzato su Agile. In effetti, credo che una volta apprese le basi, il posto migliore per imparare i metodi Agile avanzati sia sul posto di lavoro. Il mio ruolo sarà quello di spiegare i concetti base e delineare come nella realtà le varie parti di Agile si incastrano tra di loro in un unico sistema di riferimento per la gestione dei progetti.
Il fulcro del libro è sulla variante Scrum di Agile, dato che Scrum è la metodologia Agile più conosciuta e più utilizzata. Nella sua forma originale, precede lo stesso Agile e servì da ispirazione per i principi di Agile. Per tale ragione, ho preso la ponderata decisione di usare Scrum come se fosse una finestra dalla quale il lettore può accedere ad Agile. I lettori dovrebbero comprendere che Scrum non è l'unica forma di Agile, o la migliore per tutti i tipi di progetti. È semplicemente il miglior punto di osservazione (secondo me) per comprendere Agile e i metodi per lo sviluppo software “lightweight” in generale.
Agile è un strumento potente che favorisce il lavoro di squadra e il supporto reciproco, ma questo avviene solo quando tutti i membri del team condividono la stessa consapevolezza su come funziona. Agile è ottimo per definire ruoli e generare strategie di problem solving, ma può anche servire come fonte di ispirazione e cameratismo. Questo in particolarmente è punto critico in una startup, dove la pressione può essere sobbarcante.
I principi di Agile sono così performanti che si estendono ben oltre il mondo dello sviluppo del software. Il mio intento nello scrivere questo libro è presentare la struttura di base di Agile in una forma semplice che anche tu, lettore, possa apprenderlo e applicarlo a una varietà di campi, come la gestione di una società non tecnologica, la costruzione di una casa, padroneggiare nuove abilità o hobby, o vivere una vita più produttiva e significativa.
Spero che questo libro ponga le basi per mettere in pratica il metodo Agile nello sforzo di raggiungere i tuoi obiettivi e che diventi strumento permanente nella tua vita quotidiana.
- Andy Webb
*****
CAPITOLO 1
PANORAMICA AGILE
*****
Che cos'è Agile?
Agile è un metodo di sviluppo software “lightweight” che mira a essere più efficiente rispetto ai modelli di sviluppo tradizionali plan-driven. Agile cerca di fare di più con meno:
- più decisioni a livello di squadra
- tempi di sviluppo più rapidi
- risposta più rapida alle esigenze specifiche dei clienti
- risoluzione dei problemi più rapida
- maggiore soddisfazione del cliente
- team più piccoli
- meno spese
- meno sforzo
- meno funzioni del prodotto finale, al fine di evitare non funzionamenti o inutilizzo di alcune di esse
Lavorando come appaltatore di diversi team di sviluppo nei primi anni 2000, ho sperimentato in prima persona l’inefficacia dei metodi plan-driven per lo sviluppo di software. Confesso la mia colpa per aver aiutato e sostenuto lo sviluppo di ciò che è divenuto noto come "bloatware". Lo sviluppo di questi programmi ha richiesto spesso tre o più anni, ma il livello di soddisfazione del clienti era scarso. Dopo aver lavorato per alcuni anni con i team Agile, ho capito perché questi progetti enormi si sono spesso trasformati in enormi fallimenti in passato. Vi propongo un riassunto delle ipotesi errate che hanno portato alla proliferazione di bloatware.
Le funzionalità complete sono sempre le migliori : prima di Agile, la credenza più diffusa era quella che un buon servizio clienti significava sviluppare software con centinaia di funzionalità per soddisfare ogni esigenza del cliente, grande o piccola, come se avessero la stessa importanza. In realtà, il software completo era per un mercato limitato, mentre i clienti avevano bisogno di programmi semplici, facili da imparare, che avrebbero risolto problemi specifici.
Credenza in aspettative statiche da parte dei clienti : un altro problema era la convinzione che la domanda dei clienti potesse essere catturata sotto forma d’istantanea, e sarebbe rimasta, per convenienza, invariata mentre il team di sviluppo faceva la sua parte. Questo poteva essere vero prima dell’era digitale, ma non appena i consumatori hanno iniziato a utilizzare il Web. L...