Cosa è lo Sprint
Il cuore di Scrum è lo Sprint, cioè una iterazione che dura da due settimane ad un mese a seconda della complessità e quindi della durata complessiva del progetto.
Secondo la mia esperienza se il numero di persone che formano il team è superiore a 4-5 e se il team non è affiatato e esperto della metodologia è molto difficile gestire sprint che durano meno di tre settimane.
Per un progetto abbastanza complesso con un team di 6-8 persone la durata di 4 settimane secondo me è il giusto compromesso fra la velocità di deliverare nuove funzionalità e l'efficienza dell'attività di sviluppo. Bisogna tenere presente infatti che anche se il team è collaudato e affiatato l'impegno che bisogna dedicare alla fase di test (verifica e validazione interna del software), deploy e (molto probabile) bug fixing del progetto scende raramente sotto i 3-4 giorni, occupando quasi interamente la 4-ta settimana.
Tutti gli Sprint devono utilizzare lo stesso framework Scrum e tutti gli Sprint devono consegnare un incremento del prodotto finale che è potenzialmente rilasciabile al Cliente.
L'ultimo giorno dello Sprint il team è dedicato alla riunione di fine sprint (Sprint Retrospective) dove il Team (e solo il team) si interroga sugli aspetti positivi e negativi che sono emersi durante l'ultimo Sprint e propone al Project Manager delle contromisure per arginare o eliminare le cause dell'inefficienza rilevata. Il tempo da dedicare a questa importante riunione varia a seconda della complessità del progetto, dalla maturità del team e dal grado di affiatamento delle risorse, comunque nella norma una riunione di 20 minuti è sufficiente a individuare le criticità e concordare le azioni da intraprendere per superarli.
Lo Sprint successivo inizia immediatamente dopo la fine del precedente attraverso una riunione (Sprint Planning Meeting) che coinvolge tutto il team, durante la quale il Product Owner spiega al team gli obiettivi che devono essere conseguiti e chiarisce con sufficiente grado di dettaglio le funzionalità che devono essere realizzate durante il prossimo Sprint.
Il Product Owner deve preparare la riunione individuando, insieme al Cliente, le funzionalità la cui realizzazione ha maggiore priorità per la buona riuscita del progetto fra quelle riportate nel Product Backlog. Il product owner deve quindi prioritizzare le attività riportate nel Product Backlog insieme al Cliente e assicurarsi che quelle a più alta priorità, quindi papabili di essere sviluppate nell'imminente Sprint, siano state definite con un sufficiente grado di dettaglio che non lasci spazio ad interpretazioni ambigue da parte del team.
E' sempre consigliabile, compatibilmente con le esigenze del Cliente, affrontare lo sviluppo delle funzionalità con un più alto grado di rischio dal punto di vista tecnologico.
Scrum offre quattro artefatti principali per supportare il Project Manager nella gestione dello Sprint:
Il cuore di Scrum è lo Sprint, cioè una iterazione che dura da due settimane ad un mese a seconda della complessità e quindi della durata complessiva del progetto.
Secondo la mia esperienza se il numero di persone che formano il team è superiore a 4-5 e se il team non è affiatato e esperto della metodologia è molto difficile gestire sprint che durano meno di tre settimane.
Per un progetto abbastanza complesso con un team di 6-8 persone la durata di 4 settimane secondo me è il giusto compromesso fra la velocità di deliverare nuove funzionalità e l'efficienza dell'attività di sviluppo. Bisogna tenere presente infatti che anche se il team è collaudato e affiatato l'impegno che bisogna dedicare alla fase di test (verifica e validazione interna del software), deploy e (molto probabile) bug fixing del progetto scende raramente sotto i 3-4 giorni, occupando quasi interamente la 4-ta settimana.
Tutti gli Sprint devono utilizzare lo stesso framework Scrum e tutti gli Sprint devono consegnare un incremento del prodotto finale che è potenzialmente rilasciabile al Cliente.
L'ultimo giorno dello Sprint il team è dedicato alla riunione di fine sprint (Sprint Retrospective) dove il Team (e solo il team) si interroga sugli aspetti positivi e negativi che sono emersi durante l'ultimo Sprint e propone al Project Manager delle contromisure per arginare o eliminare le cause dell'inefficienza rilevata. Il tempo da dedicare a questa importante riunione varia a seconda della complessità del progetto, dalla maturità del team e dal grado di affiatamento delle risorse, comunque nella norma una riunione di 20 minuti è sufficiente a individuare le criticità e concordare le azioni da intraprendere per superarli.
Lo Sprint successivo inizia immediatamente dopo la fine del precedente attraverso una riunione (Sprint Planning Meeting) che coinvolge tutto il team, durante la quale il Product Owner spiega al team gli obiettivi che devono essere conseguiti e chiarisce con sufficiente grado di dettaglio le funzionalità che devono essere realizzate durante il prossimo Sprint.
Il Product Owner deve preparare la riunione individuando, insieme al Cliente, le funzionalità la cui realizzazione ha maggiore priorità per la buona riuscita del progetto fra quelle riportate nel Product Backlog. Il product owner deve quindi prioritizzare le attività riportate nel Product Backlog insieme al Cliente e assicurarsi che quelle a più alta priorità, quindi papabili di essere sviluppate nell'imminente Sprint, siano state definite con un sufficiente grado di dettaglio che non lasci spazio ad interpretazioni ambigue da parte del team.
E' sempre consigliabile, compatibilmente con le esigenze del Cliente, affrontare lo sviluppo delle funzionalità con un più alto grado di rischio dal punto di vista tecnologico.
Scrum offre quattro artefatti principali per supportare il Project Manager nella gestione dello Sprint:
- Product Backlog: è l’elenco di tutto ciò che potrebbe essere necessario al prodotto, ordinato per priorità;
- Sprint Backlog: è l'elenco delle attività che il team deve effettuare per trasformare la parte di Product Backlog selezionata per lo Sprint in corso in un incremento di prodotto potenzialmente rilasciabile e quindi vendibile;
- Burndown: misura la quantità di attività residue associate al Backlog nel corso del tempo;
- Release Burndown: misura la quantità residua di Product Backlog rispetto al piano di rilascio (Release Plan).
Nessun commento:
Posta un commento