Le basi di Scrum

Di Troy Dimes

Creare software che offre più valore

Di idee se ne trovano a iosa. Un sacco di gente sembra pensare che la maggior parte del processo di sviluppo del software consista nella semplice creazione di un’applicazione, vagamente legata ad un concetto, che la gente potrebbe desiderare. Probabilmente avrete sentito moltissima gente dire cose come: ”Ho questa idea per un’app che raggiungerà sicuramente un milione di download!” solo per trovare poi la loro applicazione dispersa in un oceano di applicazioni simili. 

La creazione di software eccellente ed il suo rilascio nei tempi corretti richiedono uno schema di implementazione abbastanza sistematico ma non eccessivamente rigido. Qualità e tempi devono convivere. Se si rilascia un software che è pieno di bachi o che ha una user experience mediocre non ci si potrà di certo attendere un’altra commessa da parte del cliente. Molti programmatori temono questo esito e, di conseguenza, impiegano troppo tempo per sviluppare i programmi.

Voi avete una quantità limitata di tempo per sviluppare un software, soprattutto quando dovete rispettare una data di scadenza, autoimposta o meno. Dovrete fare in modo che il software creato sia almeno decente ma, ancora più importante, rilasciato in modo tempestivo. Come si fa a bilanciare la qualità con il tempo?

Questo libro spazia tra questi importantissimi argomenti. Dopo aver letto Le basi di Scrum conoscerete i significati dei ruoli di Scrum, degli Sprint, degli artefatti di Scrum e di molto altro.

Ecco cosa imparerete leggendo Le basi di Scrum:

• Cos’è il metodo Waterfall e perché non dovreste usarlo per i vostri progetti software
• Che cosa è Scrum, da dove viene, perché dovreste usarlo e come potete metterlo in pratica nella vostra organizzazione oggi
• Quale è la differenza tra Scrum e Agile Software Development?
• I vari ruoli di Scrum, tra cui il Product Owner, lo Scrum Master ed i membri del team
• Cosa sono gli Sprint e come pianificarli
• Che cosa fare durante uno Sprint e dopo
• Quali grafici di burn down ci sono e come possono cambiare il modo in cui gestite i progetti
• Creazione e gestione del backlog di prodotto
• Gli strumenti necessari per comunicare efficacemente con tutti i soggetti coinvolti nel progetto
• e altro ancora...

• Lingua: Italiano
• Editore: BadPress
• Data di uscita: 26 ott 2015
• ISBN: 9781507124024

Anteprima del libro

Indice

Introduzione

I ruoli in Scrum

Tutto sugli Sprint

Artefatti Scrum

Conclusioni

Appendice

Un Omaggio Per Voi

Come ringraziamento per la lettura de Le basi di SCRUM, vorrei offrirvi due omaggi. Il primo è una copia di The Scrum Checklist. Con essa, imparerete come partire con Scrum o come valutare la vostra attuale implementazione di Scrum. La checklist contiene un elenco di linee guida che aiuterà voi e il vostro team a mantenere la giusta direzione.

Il secondo omaggio è The Sprint burn down Template che vi consente di visualizzare quanto lavoro è rimasto in uno Sprint. Questo grafico di burn down può essere utilizzato per comunicare lo stato di avanzamento del progetto ai membri del team, ai clienti o alle parti interessate. È un ottimo modo per gestire ambito del progetto e programmazione dei tempi. Questi omaggi sono un complemento perfetto al libro e vi aiuteranno durante il vostro viaggio con Scrum.  Visitate http://www.linuxtrainingacademy.com/scrum-resources per scaricare i vostri omaggi.

Introduzione

Di idee se ne trovano a iosa. Un sacco di gente sembra pensare che la maggior parte del processo di sviluppo del software consista nella semplice creazione di un’applicazione, vagamente legata ad un concetto, che la gente potrebbe desiderare. Probabilmente avrete sentito moltissima gente dire cose come: Ho questa idea per un’app che raggiungerà sicuramente un milione di download! solo per trovare poi la loro applicazione dispersa in un oceano di applicazioni simili.

La creazione di software eccellente ed il suo rilascio nei tempi corretti richiedono uno schema di implementazione abbastanza sistematico ma non eccessivamente rigido. Qualità e tempi devono convivere. Se si rilascia un software che è pieno di bachi o che ha una user experience mediocre non ci si potrà di certo attendere un’altra commessa da parte del cliente. Molti programmatori temono questo esito e, di conseguenza, impiegano troppo tempo per sviluppare i programmi.

Voi avete una quantità limitata di tempo per sviluppare un software, soprattutto quando dovete rispettare una data di scadenza, autoimposta o meno. Dovrete fare in modo che il software creato sia almeno decente ma, ancora più importante, rilasciato in modo tempestivo. Come si fa a bilanciare la qualità con il tempo?

Il tramonto della Metodologia Waterfall (a cascata)

Uno dei più antichi approcci allo sviluppo del software è chiamato The Waterfall (la cascata). Questo metodo costringe i programmatori a formalizzare le loro idee relative al software. Si inizia con una fase di pianificazione in cui le persone annotano minuziosamente tutto ciò che riguarda il software che sta per essere sviluppato. Tutti i passi che è necessario intraprendere sono documentati ed il team fa una stima di quanto tempo ci vuole affinché il software sia completato. Gli stakeholder, quindi, controllano il piano. Una volta che si ottiene la loro approvazione, i programmatori iniziano il loro lavoro. Questa metodologia si chiama The Waterfall, perché quando i team completano il lavoro loro assegnato lo passano al team successivo. Quando il lavoro è completato, il software viene accuratamente testato e poi consegnato al cliente o al committente.

I problemi di questa metodologia sono la sua rigidità e la sua tediosità. Tutto deve essere scritto, con ipotesi praticamente scritte sulla pietra e piani che devono essere seguiti scrupolosamente. Avete mai notato che quando provate a stimare quanto tempo potreste impiegare a fare qualcosa, a volte il risultato effettivo si rivela in realtà il doppio, il triplo o addirittura il quadruplo di quanto preventivato? Considerate questo fenomeno, applicatelo ad un progetto enorme ed avrete in agguato