Tutte le strade portano a Roma, ma con Scrum si fa prima.
Chi ha deciso di fare il passaggio e muove i primi passi all'inizio non ha vita facile. Condividiamo volentieri le nostre esperienze, affinché Scrum funzioni anche da Lei in modo più semplice e fluido. Con questi due consigli la Sua retrospettiva e il Suo Sprint Planning riusciranno meglio.
1. Retrospettiva
Per lo svolgimento della retrospettiva da noi si è dimostrato valido il seguente procedimento: all'inizio dell'evento ogni membro dello Scrum team riceve dei post-it e una penna. Su di essi si annotano tutte le cose percepite come positive e negative durante l'ultimo sprint. Ogni membro presenta poi brevemente i punti e attacca i post-it su una lavagna bianca. Quando tutti i membri hanno elencato i propri punti, i post-it vengono ordinati per tema; di solito già dal numero dei post-it si vede quale tema dovrebbe avere la priorità più alta. Vale quindi: più post-it su un tema, più quel tema è importante. Successivamente si discute sistematicamente ogni tema, dalla priorità più alta alla più bassa. Le proposte di miglioramento vengono messe per iscritto e almeno una di esse confluisce direttamente nello sprint successivo e viene registrata nello Sprint Backlog.
Le seguenti domande sono standard in Scrum:
- Che cosa abbiamo fatto così bene da doverne parlare per non dimenticarlo?
- Che cosa abbiamo imparato?
- Che cosa dobbiamo fare diversamente in futuro?
- Che cosa non abbiamo ancora capito?
Se si vuole rendere la retrospettiva ancora più semplice o più giocosa, le possibilità sono innumerevoli. Ad esempio, lo Scrum Master disegna una stella marina su una lavagna bianca. Le domande vanno sulle braccia della stella marina e poi i post-it vengono assegnati alle domande.
- Che cosa è andato bene, che cosa dobbiamo continuare?
- Quale attività dobbiamo intensificare?
- Quale attività dobbiamo ridurre?
- Quale nuova idea dobbiamo cogliere subito?
- Che cosa è andato meno bene, che cosa dobbiamo smettere di fare?
2. Sprint Planning
Per stimare story, task e bug del Product Backlog durante lo Sprint Planning, per il Planning Poker consigliamo quanto segue. Utilizzi come riferimento per la stima degli story point attività già stimate in precedenza. Se si tratta del 1° sprint, potrebbe avere senso non fornire ancora alcuna stima. In compenso, nel 2° sprint si potrebbero assegnare story point a una story del 1° sprint. Questa può poi essere usata come riferimento per la stima delle story del 2° sprint.
Faccia attenzione che la stima delle attività sia esclusivamente responsabilità del team di sviluppo. Né il Product Owner né lo Scrum Master devono intromettersi in questa stima. Se dovessero comunque intromettersi, può accadere che alcune attività non possano essere completate in uno sprint, cioè vengano sottostimate.
L'esperienza insegna che è sempre meglio fornire una stima prudente piuttosto che ottimistica. Anche quando le attività sembrano analizzate a fondo, spesso si presentano eventi e difficoltà imprevisti che ritardano lo sviluppo. Se in uno sprint si accumulano molte attività sottostimate, lo sprint degenera in stress per gli sviluppatori, il che porta a errori e a un lavoro poco accurato, o semplicemente al fatto che le story non possono essere completate.
kununu