Affinamento del backlog – automatizzato

Perfezionamento del portafoglio ordini

Il perfezionamento del backlog è l'attività di preparazione degli elementi di lavoro su cui potrà lavorare il team del software. Il tuo arretrato di storie utente, attività di sviluppatore e idee epiche è il coda di potenziali elementi di lavoro su cui lavorare nelle prossime settimane (sprint). Per mantenere un flusso di lavoro costante per il team, dovrebbe essere pronto un elenco perfezionato di elementi del backlog su cui il team può iniziare a lavorare in qualsiasi momento. Dovrebbe essercene un po' di più pronto e prioritario di quello di cui la squadra ha bisogno per i prossimi sprint.

Cosa significa raffinazione del backlog?

Perfezionamento del backlog (aka backlog grooming) significa lavorare sulla validità e sui dettagli dei requisiti/idee/attività in modo che le domande chiave ricevano una risposta corretta in modo che lo sviluppatore/tester faccia la cosa giusta la prima volta. Le storie degli utenti dovrebbero essere perfezionate e pronte prima che inizi il lavoro di codifica e test.

Per abbreviare le riunioni arretrate, desideri che il tuo contributo sia della massima qualità possibile. Ciò significa chiedere al tuo analista aziendale o al proprietario del prodotto di perfezionare il più possibile le storie degli utenti prima della riunione. L'analisi automatizzata può davvero aiutarti in questo, poiché ti aiuterà a mettere le tue storie in buona forma prima della riunione di perfezionamento.

Cosa significa realmente “pronto”?

Pronto, o definizione di pronto, significa che PRIMA della codifica sono state completate verifiche, domande, riformulazioni, revisioni e analisi sufficienti, in modo che il lavoro di codifica possa essere eseguito correttamente al primo tentativo. Ciò significa che gli obiettivi dell'utente sono pienamente compresi, chiari, idealmente misurabili e certamente inequivocabili prima che venga scritta una riga di codice. (La prototipazione Nb è spesso un mezzo utile per verificare i requisiti, ma la prototipazione non è necessariamente codifica).

Una user story raffinata dovrebbe essere:

Semplificato

Le storie degli utenti dovrebbero essere brevi e concise dichiarazioni funzionali che descrivano completamente i passaggi funzionali dei requisiti utente completi. Tale che il sistema sia in uno stato stazionario prima e dopo che le fasi hanno avuto luogo.

Chiarito

Le tue storie utente dovrebbero essere chiare, concise e inequivocabili. L'ideale è che diversi membri descrivano la loro interpretazione di ciascuna storia utente. Ogni interpretazione è la stessa. Ora, questo è difficile con la lingua inglese, a volte anche se tutte le parti erano presenti durante la conversazione che descriveva la storia dell’utente. L'obiettivo è ottenere quell'interpretazione coerente da parte di tutti i membri del team, ad es. UN comprensione condivisa.

Orientato all'utente

Vediamo molte storie utente che iniziano con "come sviluppatore..." Questo non descrive i requisiti dal punto di vista dell'utente, è invece un compito.  Prima di creare attività di sviluppo, è necessario disporre di una storia utente che descriva ciò che l'utente deve ottenere e perché. Allora e solo allora potrai suddividerlo in attività di sviluppatore, se necessario.

Coerenza controllata

È fondamentale utilizzare termini coerenti in tutte le storie degli utenti per ciascun personaggio utente. È inoltre fondamentale utilizzare parole identiche per ciascun tipo di oggetto. Questo problema è molto comune quando due o più persone creano le user story, ma può anche succedere che solo una persona stia svolgendo il lavoro. L'uso incoerente dei nomi degli oggetti o dei personaggi degli utenti porterà a interpretazioni ed errori incoerenti.

Completezza verificata

La tua storia utente è completa, descrive tutte le funzionalità necessarie per offrire l'esperienza utente o le funzionalità necessarie? Hai "seppellito" la funzionalità effettiva nei tuoi criteri di accettazione (questo è un errore molto comune).

Se si mantengono i dati all'interno di un sistema, è pratica comune eseguire un'analisi CRUD, creare una matrice CRUD. Ciò ti aiuterà a garantire che tutti i dati vengano creati, letti, aggiornati ed eliminati da almeno un processo. L'analisi CRUD è un mezzo efficiente ed efficace per garantire che le tue storie utente siano competitive in se stesse. Alla fine, tutti i dati devono essere completamente gestiti da un sistema. L'esecuzione anticipata dell'analisi CRUD consentirà di apprezzare meglio la portata finale del progetto.

Dimensioni

È importante dimensionare ciascuna storia utente, epica o attività nel tuo backlog. Perché? In modo che tu possa pianificare e dare priorità al lavoro. Sebbene molte squadre utilizzino l’idea delle taglie delle magliette o degli story point, questi sono di utilità limitata poiché sono incoerenti e non hanno un significato assoluto. Noi raccomandiamo:

• Compiti sono dimensionati in ore o giorni del personale.
• Storie degli utenti, le storie utente specificamente funzionali sono dimensionate in punti funzione COSMIC (CFP).
• Epiche di solito può essere stimato in CFP.

N.B. I CFP per un team sono generalmente facilmente convertibili in ore stimate. Per ulteriori informazioni sui punti funzione COSMIC.

Priorità

Dovrebbe essere data priorità agli elementi in arretrato. La priorità (e la sequenza degli elementi con priorità simile) dovrebbe essere determinata almeno con le seguenti considerazioni:

• Valore della funzionalità per l'azienda, compreso il probabile utilizzo
• Dimensioni (determina lo sforzo probabile per la consegna).
• Impatto sull'attività di un ritardo in questo. Costo del ritardo.
• Relazione tecnica di questa funzionalità con altre, ovvero dipendenze tecniche
• Rischio di incognite che potrebbero portare a un cambiamento significativo in altri lavori svolti.

Una tecnica comune per mappare alcune di queste considerazioni su un valore numerico è chiamata Weighted Shortest Job First (WSJF).

Colin Hammond, 2022

Perfezionamento del backlog automatizzato

Altri articoli su questo argomento discuteranno della suddivisione e dell'elaborazione della storia. Riteniamo che questi termini siano un po' vaghi. Siamo stati più specifici perché è importante esserlo. Una parola sbagliata in un requisito può portare a un'errata interpretazione e potenzialmente a ore e ore di spreco, se il codice deve essere riscritto.

Ulteriori letture da siti esterni

Ho faticato a trovare molti articoli che posso sostenere con forza. Consiglio questo libro Requisiti software, di Karl Wiegers e Joy Beatty

Articolo Digite sul perfezionamento dell'arretrato