Creazione di un backlog prodotto di grandi dimensioni
Il team crea un backlog del prodotto, che contiene in genere storie utente, per rappresentare ciò che i clienti desiderano e ritengono importante. Nel corso del progetto, il team aggiungerà informazioni dettagliate alle storie utente, le suddividerà in storie più piccole, le classificherà in ordine di priorità, le valuterà e, infine, le implementerà e fornirà i risultati ai clienti. Scrivendo le storie utente e aggiornando continuamente il backlog del prodotto, il team può fornire valore ai clienti in modo più efficace.
Secondo Bill Wake ciò che rende ottima una storia utente è il fatto che sia indipendente, negoziabile, utile, stimabile, piccola e testabile. Per ulteriori informazioni, vedere il seguente sito Web: XPlorations. Mike Cohn illustra come scrivere storie utente in uno dei suoi libri; il capitolo attinente può essere scaricato dal sito Web User Stories Applied for Agile Software Development relativo alle storie utente applicate allo sviluppo di software Agile.
Quando il team crea una storia utente, verificare che rappresenti il valore aggiunto per il cliente rispondendo alle domande seguenti:
Chi è l'utente?
Cosa deve fare?
Perché deve fare ciò?
Nella maggior parte dei casi, il team riesce a rendere questo creando un titolo d'effetto. Mike Cohn suggerisce la forma "In qualità di <utente>, devo <azione> per <motivo>". Tale approccio può essere illustrato con l'esempio seguente: "In qualità di rappresentante del supporto tecnico, devo accedere alle informazioni sul cliente in modo da poter rispondere più rapidamente alle sue domande". In molti casi, il motivo è ovvio Ad esempio, "In quanto vegetariano, posso filtrare la visualizzazione in modo da vedere solo cibi vegetariani".
Le storie utente devono essere definite anche in modo che sia possibile implementarle in qualsiasi ordine. Tuttavia, non è sempre utile renderle completamente indipendenti. Bill Wake e Mike Cohn descrivono le tecniche che il team può utilizzare quando rendere indipendenti le storie utente rappresenta una sfida.
Le storie utente utili e indipendenti, come descritto in precedenza, costituiscono il backlog del prodotto. Vengono stimate e classificate in ordine di priorità, quindi il team inizia a lavorare sulle storie utente che occupano i primi posti della classifica. Una storia utente, prima di poter essere implementata dal team, deve presentare le caratteristiche indicate nell'elenco riportato di seguito. Il proprietario del prodotto verificherà che le storie utente che occupano i primi posti della classifica soddisfino questi criteri prima di presentarle a una riunione di pianificazione dello sprint.
Piccole abbastanza da poter essere implementate nello sprint
Le storie utente che stanno per essere implementate devono essere piccole abbastanza per poter essere completate nello sprint. Il proprietario del prodotto lavorerà con il team per suddividere le storie utente troppo grandi. Ad esempio, la storia utente "In qualità di rappresentante del supporto tecnico, devo accedere alle informazioni sul cliente in modo da poter rispondere più rapidamente alle sue domande" potrebbe essere troppo grande per poter essere completata in uno sprint. Si potrebbe quindi suddividere in storie quali "In qualità di rappresentante del supporto tecnico, devo accedere al nome del cliente e al riepilogo delle chiamate recenti tramite il numero telefonico del cliente" e "In qualità di rappresentante del supporto tecnico, devo accedere alla cronologia completa delle chiamate dei clienti in modo da poter analizzare dettagliatamente il problema corrente".
Abbastanza dettagliate da descrivere e stimare il lavoro necessario per implementare la storia
Prima di essere incluse in uno sprint, le storie utente vengono stimate in punti. Si tratta di stime intenzionalmente approssimative, utilizzate principalmente per gestire il backlog e consentire la preparazione dello sprint. Quando viene avviato uno sprint, il team suddividerà la storia utente nelle attività necessarie per implementarla. Lavorerà con il proprietario del prodotto durante la riunione di pulitura del backlog del prodotto per determinare quali storie necessitano di ulteriori informazioni prima di poter essere suddivise in attività per stimare le ore di lavoro. Il proprietario del prodotto può raggruppare questi dettagli e registrarli nella descrizione della storia utente.
Prestare attenzione a non aggiungere alla storia utente più dettagli del necessario. La storia utente deve essere la base di una conversazione e negoziazione con il proprietario del prodotto e i clienti che si protrae finché la storia utente non viene completata e accettata. Troppi dettagli possono danneggiare la negoziazione creando un'implicazione di precisione non accurata.
Criteri di accettazione definiti
Alla fine di uno sprint, i clienti o il proprietario del prodotto accetteranno la storia utente come terminata o la rifiuteranno. Prima dell'avvio dello sprint, i criteri per l'accettazione del cliente devono essere descritti nel modo più chiaro possibile. Naturalmente, una storia utente potrebbe non essere accettata per motivi che non sono stati illustrati in precedenza. Tuttavia, le conversazioni che il team ha con i clienti per consentire di definire i criteri di accettazione permetteranno di verificare che abbia compreso le aspettative dei clienti. I criteri di accettazione possono essere utilizzati come base per i test di accettazione in modo da poter valutare più efficacemente se una storia utente è stata completata.
Poemi epici e temi
È stato ribadito più volte che le storie utente devono essere piccole. Tale affermazione è vera per le storie utente che stanno per essere implementate. Tuttavia, le storie che si trovano nella parte inferiore della classifica possono essere più grandi. Infatti, mantenendole grandi è possibile evitare che il backlog del prodotto diventi troppo grande per poter essere gestito. Le storie utente possono essere suddivise in storie utente più piccole man mano che si avvicinano alla parte superiore del backlog del prodotto classificato in ordine di priorità. È utile considerare le storie utente grandi come poemi epici e temi.
I poemi epici sono storie utente molto grandi che rappresentano una quantità significativa di lavoro. Quando si suddivide un poema epico, è possibile creare molti temi e altre storie utente più piccole.
I temi sono storie utente abbastanza grandi, generalmente di dimensioni maggiori rispetto a quelle che si implementerebbero in uno sprint. Prima che il team implementi un tema, deve essere suddiviso in storie utente più piccole.
Quando il backlog del prodotto viene classificato in ordine di priorità, suddividere i poemi epici e i temi che occupano posti vicini alla testa della classifica e classificare in ordine di priorità le storie utente nuove e più piccole. Una volta terminato, le storie utente con maggiore priorità devono essere abbastanza piccole da supportare l'implementazione. Generalmente, nelle posizioni inferiori del backlog classificato in ordine di priorità la maggior parte delle storie utente è maggiore.
Picchi
Talvolta, il team dovrà effettuare un lavoro che non è un'implementazione diretta di una storia utente. Questo lavoro è definito picco. Tre tipi comuni di picchi sono: ricerca, debito di bug e miglioramenti al processo o alla progettazione. Per creare un picco in Team Foundation, creare un elemento di lavoro della storia utente, impostare il tipo su Picco, quindi classificarlo in ordine di priorità nel backlog del prodotto insieme alle altre storie utente.
Ricerca
La ricerca si verifica quando sono presenti domande aperte relative a una storia utente a cui è necessario rispondere prima che la storia utente possa essere completamente suddivisa in attività e stimata. Ad esempio, il team rileva la storia "In qualità di viaggiatore assiduo, posso prenotare viaggi premio" durante una riunione di pianificazione dello sprint. Dopo la discussione, il numero di domande supera le risposte. Il team crea una storia utente per rappresentare il picco. " In qualità di membro del team, capisco il significato di "prenotare viaggi premio" in modo da poter scrivere storie da includere nei prossimi sprint". Il team determina quante ore è disposto a dedicare a tale ricerca e scrive il numero come intervallo di tempo per il picco. Nessuna delle storie scritte durante il picco può essere effettuata durante tale iterazione. Il lavoro deve essere pianificato per un'iterazione futura tramite il backlog del prodotto.
Debito di bug
Il momento migliore per correggere un bug è quando viene rilevato. Se non è possibile correggerlo lo stesso giorno in cui viene rilevato, è necessario creare un elemento di lavoro bug per assicurarsi di non perderlo. Evitare di accumulare bug. Se il team accumula bug, creare una storia utente e connettere i bug al picco in modo che possa essere stimato e classificato in ordine di priorità insieme alle altre storie utente e ai picchi.
Miglioramenti al processo o alla progettazione
Il team apporterà miglioramenti al processo o alla progettazione per riuscire a ottenere risultati positivi. Questi miglioramenti vengono spesso identificati durante le riunioni retrospettive dello sprint e le riunioni scrum giornaliere. Ad esempio, il team potrebbe dover migliorare il code coverage tramite unit test o ridurre il tempo di compilazione nel server di integrazione continuata.