Tutte le strade portano a Roma, ma con Scrum si arriva prima.
Chi ha deciso di passare a Scrum e muove i primi passi, all'inizio non ha vita facile. Qui diamo un piccolo aiuto per partire, affinché Scrum funzioni in modo più semplice e fluido anche da Lei.
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 efficace il seguente procedimento: all'inizio dell'evento ogni membro dello Scrum Team riceve dei post-it e una penna. Su di essi vengono annotate tutte le cose percepite come positive e negative durante l'ultimo sprint. Ogni membro presenta poi brevemente i propri punti e attacca i post-it su una whiteboard. Quando tutti i membri hanno esposto i loro 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 la regola: più post-it ci sono su un tema, più quel tema è importante. Successivamente ogni tema viene discusso in modo sistematico, 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?
Ci sono innumerevoli modi per rendere la retrospettiva ancora più semplice. Ad esempio, si possono scrivere le seguenti domande su una whiteboard. Tutti i membri del team possono rispondere.
- 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 attività già stimate come riferimento per la Sua stima degli story point. Se si tratta del primo sprint, può essere sensato non fare ancora alcuna stima. In compenso, nel secondo sprint è possibile assegnare story point a una story del primo sprint in modo che possa poi servire da riferimento per la stima delle story del secondo 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. Ciò potrebbe far sì che le attività non possano essere completate in uno sprint, perché sottostimate.
L'esperienza insegna che è sempre meglio fare una stima prudente e non troppo ottimistica. Anche quando le attività sembrano discusse nel dettaglio, 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.
È ancora agli inizi e non ci capisce nulla?
Offriamo corsi di formazione Scrum per facilitarLe l'approccio all'argomento.
kununu