Scrum! Sopravvivere e gestire progetti tra polli, maiali e clienti
3 likes1,033 views
Il documento descrive i principi e le pratiche del metodo Scrum per la gestione dei progetti, evidenziando l'importanza del miglioramento continuo, del rispetto per le persone e della collaborazione. Vengono delineati i ruoli chiave nel processo Scrum, come il Product Owner e lo Scrum Master, insieme agli strumenti utilizzati come il product backlog e lo sprint backlog. Inoltre, si sottolinea la necessità di cicli di sprint per facilitare il feedback continuo e il progresso nei progetti.
Scrum! Sopravvivere e gestire progetti tra polli, maiali e clienti
- 1. Scrum! Sopravvivere e gestire progetti tra polli, maiali e clienti Belluno, 16 aprile 2015 @larin
- 2. Toyota Way / Lean Production • L’obiettivo di un’azienda è il miglioramento continuo, cercando innovazione ed evoluzione. • Il rispetto per le persone è alla base di un’azienda: fare il possibile per capirsi l'un l'altro, prendersi la responsabilità delle proprie azioni e fare del nostro meglio per costruire una fiducia reciproca. • Lavoro di squadra: stimolare la crescita personale e professionale, condividere le opportunità per sviluppare abilità di squadra ed individuali. • Basa le decisioni manageriali su una filosofia a lungo termine, anche se questo comporta sacrifici economici a breve termine. Il giusto processo produrrà i giusti risultati • Costruisci la cultura di fermarsi per correggere i problemi, la qualità come primo obiettivo. • Usa un sistema di controllo visuale, così non ci saranno problemi nascosti. • Cresci leader che capiscano veramente il lavoro, che vivano la filosofia dell’azienda e che la insegnano agli altri. • Prendi decisioni lentamente. implementa le decisioni rapidamente.
- 3. Scrum! Ogniuno ha il suo ruolo. Tutti spingono nella stessa direzione.
- 4. A cosa mi serve? Facciamo un esempio.
- 5. Gestire un progetto di cui non sono chiare le specifiche in fase iniziale. E vivere felici.
- 6. Manifesto per lo sviluppo Agile di Software Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso. Grazie a questa attività siamo arrivati a considerare importanti: Gli individui e le interazioni più che i processi e gli strumenti Il software funzionante più che la documentazione esaustiva La collaborazione col cliente più che la negoziazione dei contratti Rispondere al cambiamento più che seguire un piano Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.
- 7. Seguiamo questi principi: La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua. Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente. Consegnamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi. Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
- 8. Fondiamo i progetti su individui motivati. Diamo loro l'ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine. Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all'interno del team. Il software funzionante è il principale metro di misura di progresso. I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.
- 9. La continua attenzione all'eccellenza tecnica e alla buona progettazione esaltano l'agilità. La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale. Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano. A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
- 10. Scrum Le regole del gioco
- 11. Parleremo di.. • Ruoli • Strumenti • Il “ciclo” di Scrum (sprint cycle)
- 12. I ruoli nello scrum Un Maiale ed un Pollo camminavano per strada. Il Pollo disse: "Hey Maiale, mi è venuta una bella idea, potremmo aprire un ristorante!" Il Maiale replicò: "Hm, non so, come potremmo chiamarlo?" Il Pollo rispose: "Che dici di 'uova e pancetta'?" Il Maiale pensò un momento e disse: "No grazie. Io sarei completamente coinvolto mentre tu saresti solo interessato!"
- 13. I “maiali” dello scrum 1. Product Owner -> rappresenta il cliente 2. Scrum Master -> un maniaco dello scrum 3. Team Master -> I membri del team
- 14. Il product owner • Rappresenta il cliente • Deve massimizzare il ritorno del prodotto in termini di business. • Per raggiungere questo obiettivo: • E’ l’unico autorizzato a chiedere al team di sviluppo di fare un lavoro e ne detta le priorità. • Ha la responsabilità di spiegare BENE al team cosa deve fare.
- 15. Lo scrum master • E’ un membro del team di sviluppo. • Il suo obiettivo è un team motivato, organizzato, preciso. • Non è il capo del team! Ma è quello con maggior esperienza nel metodo scrum.
- 16. Il team di sviluppo • Ha completa autonomia sul COME realizzare il lavoro e su QUANTO tempo richiede. • Gli elementi sono altamente collaborativi: l’obiettivo non è FARE IL MIO lavoro ma raggiungere i risultati nei tempi previsti.
- 17. Il membro di uno scrum team in sintesi: • è responsabile del completamento delle user- story • si organizza autonomamente per svolgere tutto il lavoro che deve fare • crea ed è responsabile dei preventivi • decide “come” fare un lavoro • non risponde mai “non è il mio lavoro"
- 18. • Lo scrum team ideale è composto dai cinque ai nove elementi. • Meno persone difficilmente hanno tutte le competenze per sviluppare un prodotto complesso, con più persone è difficile gestire la fase organizzativa e le comunicazioni.
- 19. Gli strumenti dello scrum • Il “product backlog” • Le “user-story” • Lo “sprint backlog” • Definition of “Done”
- 20. Il product backlog • è un documento gestito dal product owner. Contiene la lista delle implementazioni desiderate per un prodotto. Include nuove caratteristiche, bugfix, modifiche alla documentazione. • I punti di un product backlog vengono chiamati backlog-item o “user story”, per ricordare che l’obiettivo di ogni modifica è rispondere ad un’esigenza dell’utente. • Queste “storie” sono ordinate in ordine di importanza: le prime da “evadere” saranno all’inizio della lista. Dovranno essere brevi e molto chiare per il team. Le storie in fondo alla lista potranno essere più generiche e meno chiare, tanto passerà del tempo prima che il team ci lavori.
- 21. User Story • Le “cose da fare” nello scrum sono descritti sottoforma di storie. Una storia dovrebbe contenere queste informazioni: 1. Quale utente ne trarrà benefici 2. Una breve descrizione delle funzionalità desiderate 3. Che scopo ha questa storia 4. Quante ore lavoro richiede l’implementazione di questa storia* 5. Con che criteri capiamo se l’abbiamo implementata correttamente*
- 22. “As a <role>, I want <a feature>, so I can <accomplish something>” “Come <ruolo>, Voglio <funzionalità>, in modo da <obiettivo>”
- 23. Sprint Backlog • Sono le story del product backlog che si puntano a sviluppare durante il ciclo di scrum corrente (ne parliamo tra poco..) • A queste si aggiungono le “task”. Ogni story è composta da più tasks che tutte insieme portano al completamento della storia: es. aggiungi un campo al database, inserisci una pagina nella guida, aggiungi un javascript al menu, ecc.
- 24. Definition of “Done” • Un team scrum lo decide a priori, condividendo una definizione di “fatto”, trasformandola in checklist e attaccandola dove tutti possono vederla. (es. scrittura codice, revisione codice, superamento test, scrittura documentazione).
- 25. La “liturgia” dello scrum: lo sprint cycle. • Pianificazione dello sprint • Daily Scrum • Story Time • Revisione dello sprint • Team meeting di revisione
- 26. Lo sprint cycle Lo “sprint cycle” è il ritmo del processo scrum. All’interno di questo si prendono in mano poco a poco, pezzettino per pezzettino, dei pezzi di software, si completano prima di prendere in mano un pezzettino successivo. Alla fine ci un ciclo di sprint, devi dimostrare di aver prodotto del software o “sei fottuto”. Sostanzialmente deve rispettare due requisiti: • Ha la qualità giusta per essere rilasciato? • Produce un incremento di valore tale da avere senso sotto il profilo business? Il senso di un cycle in scrum è avere feedback continui sui prodotti, in questo senso più breve è uno sprint meglio è. Normalmente un ciclo dura 2 settimane, ma è sempre maggiore la tendenza di cicli di una settimana.
- 27. Meeting di pianificazione dello sprint • E’ diviso in due parti: • PARTE PRIMA: Che “user story” vogliamo sviluppare? -> il “product owner” presenta cosa gli piacerebbe che il team sviluppasse durante lo sprint. Le richieste vengono strutturate in “user story” e approfondite finché il team di sviluppo non è sicuro di averle capite bene. Poi il team decide se può impegnarsi a sviluppare tutte quelle cose per la fine dello sprint o se rimandarle a uno sprint successivo. • NB: la separazione dei ruoli! Il “product owner” decide che storie dovranno essere prese in considerazione, ma solo il team decide se sono fattibili o no all’interno di questo sprint.
- 28. Pianificazione dello sprint • E’ diviso in due parti: • PARTE SECONDA: Quali sono le task to-do per ogni user story? (es. aggiungere un campo al database, scrivere un aiuto, inserire un menù, ecc). In questa parte del meeting il “product owner” è a disposizione per rispondere alle domande. • DURATA: Da 1 a 2 ore per settimana di sprint. • RISULTATO: lo sprint backlog. Il product owner si impegna a non chiedere altro al team durante lo sprint a meno che la richiesta non arrivi dal team stesso.
- 29. Daily Scrum • meeting quotidiano e breve (15 minuti) • ogni partecipante dice che task ha completato il giorno precedente, che task conta di completare durante il giorno, che ostacoli vede. • Se ci sono dei problemi l’obiettivo è che emergano in questo meeting, non che vengano risolti! Le persone più adatte si accorderanno per confrontarsi dopo il meeting se necessario per risolvere un problema.
- 30. Story Time • Un’ora alla settimana, con il product owner, per ragionare su possibili “user story” future, sui tempi da assegnare a ciascuna e per rivedere la definizione di “fatto” del team. • In questo meeting si fa “story splitting”: le storie prossime allo sviluppo devono essere brevi e chiare. • Anche se lo story-splitting è responsabilità del product-owner, questo meeting è l’occasione per chiedere l’aiuto al team di sviluppo.
- 31. Revisione dello sprint • E’ la fine dello sprint. E l'occasione per il team di mostrare quello che ha fatto, per raccogliere osservazioni, suggerimenti, ecc. • In questo senso è un meeting che può essere aperto anche ad esterni - clienti, beta tester, stakeholders, ecc. • In questo meeting NON si prendono decisioni, è solo un momento di condivisione e di raccolta di opinioni. • Durata: dai 30 minuti a 1 ora per ogni settimana di sprint.
- 32. Team meeting di revisione • L’obiettivo dello scrum è la crescita continua e costante del team. Questo meeting, riservato al team di sviluppo, è l’occasione per condividere quello che ha imparato e di identificare uno o due cambiamenti strategici da testare durante lo sprint successivo. • Durata: da 1 a 2 ore per settimana di sviluppo.
- 34. Tool per gestire lo scrum
- 35. Tool per gestire lo scrum