alcuni principi e concetti base
E vabbe', famo 'sto Scrum, però senza er planning, i standupp e le retrospettive, che qui dovemo lavorà, mica parlà de cazzate.
La metodologia Agile è un insieme di metodi che consentono di raggiungere obiettivi prefissati con il massimo delle performance in maniera veloce e produttiva realizzando software testato e di qualità.
Serve a raggiungere (o non) risultati in tempi brevi, tramite processi trasparenti, condivisi tra team e cliente e organizzati in una serie di microcicli adeguati alle risorse e al tempo a disposizione.
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
le funzionalità finite da completare, genericamente le chiamiamo User Story.
In esse descriviamo il tipo di lavoro da svolgere utilizzando i seguenti campi principali:
descrizione
è tutto quello che dobbiamo sapere per svolgere il lavoro
estimate
è un valore che indica un misto tra complessità, tempo e rischio.
acceptance criteria
è un elenco di criteri che devono essere rispettati nel completare la storia.
Utili anche per i test.
framework di metodi empirici
termine deriva da: pacchetto di mischia del rugby
si procede uniti verso la meta andando avanti ed indietro
- trasparenza
- adattabilità
- controllo
Product owner
Responsabile del prodotto. Colui che da la direzione commerciale e le priorità dei task da fare.
Scrum Master
Responsabile del flusso. Colui che aiuta il lavoro del team e lo mette in contatto con il PO, facilitando i task e i meeting.
Team di sviluppo
Chi sviluppa. Il team (3-9 persone) è indipendente ed auto-organizzato per lo sviluppo del progetto (team cross-funzionale).
(Stakeholders)
Portatori di interesse. Tutti quelli che sono coinvolti nel risultato del progetto (spesso il cliente)
Gli step fondamentali dello sviluppo in scrum
deriva da: produzione Toyota
看板 - poster, cartellone.
visualizzare il flusso di lavoro eliminando i "colli di bottiglia" nella catena
Scrum vs. Kanban | scrum | kanban |
---|---|---|
cadenza | regolare e fissa (sprint 2-4 settimane) | flusso continuo |
rilascio | alle fine di ogni sprint (se approvato dal PO) | rilasci continui a discrezione del team |
ruoli | product owner, scrum master, team di sviluppo | nessun ruolo; il team può essere aiutato da un agile coach |
valori chiave | velocity (estimate/items) | cicli di rilascio |
obiettivi | fissati ad inizio sprint e costanti durante l'iterazione (goal) | possono cambiare in ogni momento |
ma non si capisce una fava!
qualche risorsa:
http://www.scrumguides.org/scrum-guide.html
http://scrumprimer.org/
https://www.atlassian.com/agile/kanban
https://www.agilealliance.org/agile101/
https://www.infoq.com/minibooks/scrum-xp-from-the-trenches-2
https://www.youtube.com/watch?v=uhghehlVGo0&t=185s
ancora niente?
ask @agilegigi
Is this still Scrum? I’m not sure, but does it really matter? Anything that works for you is right, anything that doesn’t is wrong.
Henrik Kniberg
Crisp/Spotify/Lego