Tag: agile, scrum, kanban, sprint, retrospectives, user-stories
Livello: intermedio
TL;DR: Principali domande di colloquio sulle metodologie Agile, Scrum e Kanban, con risposte pronte basate sull'esperienza pratica in team di sviluppo.
Manifesto Agile: individui e interazioni, software funzionante, collaborazione col cliente, rispondere al cambiamento.
Scrum: framework iterativo con ruoli rigorosamente definiti (Scrum Master, Product Owner, Developers).
Kanban: metodologia basata sul flusso continuo, visualizzazione del lavoro e limite del Work In Progress.
Sprint: iterazione a tempo fisso per rilasciare un incremento di prodotto potenzialmente rilasciabile.
User Story: descrizione di una funzionalità software dal punto di vista dell'utente finale.
Story Point: unità di misura relativa per stimare la complessità complessiva di un task.
Definition of Done (DoD): criteri condivisi che un lavoro deve soddisfare per essere considerato completato.
Q: Qual è la differenza principale tra Scrum e Kanban?
R: Scrum usa iterazioni a tempo fisso ed è strutturato, mentre Kanban si basa su un flusso continuo limitando il Work in Progress.
Q: Come gestisci i requisiti che cambiano durante uno Sprint?
R: Proteggo lo Sprint in corso per mantenere il focus, inserendo i nuovi requisiti nel Product Backlog per valutarli nei prossimi Sprint.
Q: Cos'è la Velocity e come la usi?
R: È la media degli Story Point completati negli Sprint precedenti. Serve per prevedere quanto lavoro il team può assumersi nello Sprint successivo.
Q: Qual è lo scopo della Retrospective?
R: È il momento in cui il team ispeziona il proprio processo per identificare successi e aree di miglioramento, producendo action item concreti.
Q: Cosa fai se il team fallisce costantemente l'obiettivo dello Sprint?
R: Analizzo le cause nella Retrospective. Riduco il carico nello Sprint successivo o rafforzo le sessioni di refinement se i requisiti erano poco chiari.
Q: Che differenza c'è tra Definition of Done e Acceptance Criteria?
R: La Definition of Done si applica a tutte le storie nel backlog, mentre i criteri di accettazione sono specifici per una singola storia.
Usare gli Story Point come stima di tempo esatto in ore o giorni anziché di complessità.
Saltare le Retrospective per mancanza di tempo, perdendo così la principale opportunità di miglioramento del processo.
Avere un Product Owner non disponibile o non autorizzato a prendere decisioni sul prodotto.
Allungare la durata dello Sprint in corso per riuscire a finire il lavoro in ritardo.
Assegnare i task a singole persone durante il planning anziché lasciare che il team si auto-organizzi.
[ ] Calcolo corretto del limite di Work In Progress (WIP limit) ottimale in Kanban.
[ ] Gestione dei ticket di bug urgenti all'interno di uno Sprint Scrum già in corso.