SCRUM da zero, senza struttura di base stabilita?

Non penso che molti metodi agili gestiscano bene le attività che sono tipicamente parte del lancio del progetto. Molti dei framework comuni (XP, Scrum, Kanban) non affrontano questo problema, ma alcuni dei framework scalati (Disciplined Agile Delivery, SAFe) fanno in una certa misura.

Alcune persone sostengono il concetto di un incremento iniziale (in Scrum, uno sprint) progettato per impostare il progetto. Questo è spesso chiamato Increment Zero (o, in Scrum, Sprint 0). Tuttavia, non è una parte formale di Scrum e i puristi sostengono che il primo incremento dovrebbe essere potenzialmente rilasciabile.

Tale incremento viene utilizzato per configurare l'ambiente del team, impostare gli ambienti di sviluppo, test e produzione, configurare gli strumenti e gli script di supporto e stabilire gli ambienti di lavoro con i grafici di burndown e gli arretrati. Se qualcuno del team non ha familiarità con gli strumenti di sviluppo utilizzati, è qui che apprendono le basi per funzionare e iniziano a produrre l'output nella prima iterazione.

Accanto a questo, spesso inizierai a scrivere le tue prime storie di utenti e ad assegnare la priorità al backlog del prodotto, poiché a questo punto non c'è uno sprint di backlog. Chiunque sia il proprietario del prodotto elaborerà storie. Se questa persona è nuova per Scrum, imparerebbe come scrivere storie di utenti utili con cui il team può lavorare. Non mettere in risalto tutte le storie, ma ti basteranno abbastanza per dare il via alla prima iterazione di sviluppo.

Diversi team gestiscono Sprint 0 in modo diverso. Alcuni potrebbero timebox nella stessa durata di qualsiasi altro sprint. Altri potrebbero renderlo un po 'più lungo o un po' più breve a seconda delle esigenze della squadra. Poiché questo è il tuo primo tentativo di Scrum, potrei allungarlo, specialmente se hai un iterazioni più brevi come parte del tuo ciclo di sviluppo. Se stai pianificando per due settimane di iterazioni, fallo 3 settimane.

Per quanto riguarda la formulazione dei compiti, non li formulerei necessariamente come storie per gli utenti. Potresti, dal punto di vista dei membri del team e dei vari ruoli (Product Owner, ScrumMaster, sviluppatore, tester, designer, scrittore tecnico e così via). Tuttavia, Sprint 0 è per il team, non per il cliente o l'utente. Un semplice elenco di attività e attività sarebbe sufficiente.

Questi sono i pre-risultati che abbiamo stabilito prima di implementare SCRUM nel nostro team. Una volta terminato l'elenco, è possibile implementare il processo e gli strumenti per la mischia effettiva.

1. I membri del team sono altamente o moderatamente qualificati.
2. Il team è strettamente legato.
3. Lo scambio di informazioni tra i membri del team è veloce, coerente e libero.
4. Il team è co-posizionato.
5. Il business è strongmente coinvolto con il team.
6. L'architettura (Business, Information e Technical) è ben definita.
7. Infrastruttura è attiva e funzionante - Dev, test e ambiente UAT.
8. Creazione e rilascio automatici.
9. Elevato livello di automazione del test.
10. La dipendenza del team dal mondo esterno è minima (idealmente zero).
11. Il conteggio dei sistemi partecipanti è minimo.
12. I requisiti sono stabili a livelli più alti, quindi il backlog del prodotto ha modifiche minime.
13. I membri del team sono autonomi per prendere decisioni su quale user story dovrebbe essere parte dello sprint / scrum e anche il numero totale di scrum / sprint necessari per raggiungere l'obiettivo dichiarato.

Altre due parti importanti:

1. Seleziona le persone per i ruoli (Scrum master, Product owner e team)
2. Avere la lavagna bianca, adesivi pronti