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...