Backlog item con preparazione per il futuro sprint Scrum

Suppongo che dal momento che desideri prepararti per il lavoro, ritieni che la funzionalità di back-end sia più grande di quella che potrebbe rientrare in uno sprint? (non è possibile costruirlo nello sprint in cui è richiesta la funzionalità)

In tal caso, suggerirei di utilizzare la funzionalità generale di back-end e suddividerla in più parti indipendenti che sono abbastanza piccole da essere completate all'interno di uno sprint. Prendi ciascuno di questi pezzi come una storia e costruisci la funzionalità di back-end per ogni pezzo in sequenza tra più sprint, evolvendo l'architettura di back-end e l'interfaccia utente di gestione degli utenti man mano.

Ad esempio, potresti iniziare con qualcosa di semplice come una storia di accesso, che richiede al back-end di avere il concetto di nome utente e password. Non devi preoccuparti di tutti i ruoli e i gruppi, inizia con qualcosa.

Ci sarà un processo di refactoring lungo il percorso, non è necessario specificare tutto in anticipo. Ciò non significa che non dovresti pensare all'architettura e al tuo obiettivo finale, ma puoi approfondire i dettagli secondo necessità. Forse nella user story 5 ti rendi conto che qualcosa nella user story 2 è stata fatta male. Quando valuti la storia 5, assicurati di includere lo sforzo per rielaborare ciò che è stato fatto nella storia 2.

Uno dei modi più semplici per supportarlo in una demo è pensare a quali sono gli obiettivi dell'utente di alto livello per la gestione degli utenti. Nella tua demo, mostra un utente che raggiunge uno degli obiettivi. Gli obiettivi possono essere qualcosa di simile a questo:

1. Accedi
2. Modifica il mio profilo
3. Visualizza altri utenti nel sistema
4. Assegna ruoli ad altri utenti
5. Gestisci gruppi
6. Gestione sicura dei gruppi
7. Gestione sicura degli utenti

Questi 7 obiettivi potrebbero diventare le tue storie (o potresti raggrupparne alcune a seconda delle loro dimensioni e delle tue preferenze personali). Puoi quindi gestirli in modo incrementale attraverso i tuoi sprint, pianificandoli in modo che siano tutti a posto nel momento in cui raggiungi lo sprint in cui sono necessarie tutte le funzionalità.

Adottando un approccio agile a questo non farei come suggerisci e costruisci l'interfaccia fittizia prima di iniziare il lavoro. Vorrei evolvere l'interfaccia mentre avanzi.

Prima di tutto concentrati sulle storie più preziose (ed è VITALE che queste soddisfano INVESTA i principi).

La parte difficile qui è come costruisci le tue storie e ottenere la definizione giusta sia con il team che con il proprietario del prodotto è essenziale. Questo farà o distruggerà il progetto. Ci sono due opzioni che prenderei in considerazione per questo, prendiamo ad esempio la storia 'Come utente che voglio accedere' . (So che questa è una user story terribilmente formata, ma riesce a far valere il mio punto di vista semplicemente). Ci sono due opzioni per definirlo, e entrambi gli approcci potrebbero essere migliori a seconda di come il tuo team / team sta lavorando al progetto:

• L'opzione Scrum "pura" - come farei se sei un singolo team Scrum.

Specifica i requisiti tecnici come criteri di accettazione della storia. Per esempio. Il login deve essere sicuro utilizzando la crittografia XXX, la sicurezza della password ecc.

Mentre costruisci questa storia, disegni gli aspetti toccati dalla storia - ad es. Utenti e password nel DB e tutti i campi obbligatori. Se un'altra storia in futuro significa che questo avrà bisogno di refactoring, questo è incluso nella dimensione di quella storia. Inoltre, i test unitari sono essenziali per garantire che il refactoring non rotti la funzionalità esistente. Questo è probabilmente l'approccio migliore se esiste una sola squadra di scrum sul prodotto, poiché è meglio ottenere tutta la qualità della produzione man mano che si procede.

• L'opzione Scrum commerciale - come avrei fatto in un'azienda con più team Scrum, che non sono puramente interfunzionali.

Ignora i requisiti tecnici e separali in una storia separata. Per esempio. viene creato un pulsante "login" che passa sempre e consente al sistema di continuare. Ciò significa che il team "front-end" (o sprint) può continuare a lavorare e fornire ulteriore valore, e una storia separata mantiene i requisiti tecnici e la progettazione del DB di accesso. È fondamentale che tutti sappiano che la funzionalità non esiste ancora. / p>

I principali vantaggi della seconda opzione sono:

• Un team può costruire l'interfaccia utente mentre un altro team crea il DB. Possono quindi continuare con altre storie.
• Le parti interessate possono vedere i progressi molto prima e avere un'idea di ciò che si sta creando, che può influenzare il design fin dalle prime fasi.

Il grande rischio è che le persone credano che il progresso sia più lontano del previsto, perché hai qualcosa che sembra "quasi fatto" ma che in realtà non fornisce valore. Ecco perché la prima opzione è più Scrum "puro".