Pulire e stimare il backlog

Articolo
03/05/2013

In base alle procedure veloci, dopo che il proprietario del prodotto ha creato un piano di alto livello per il prodotto, il team va in contro al backlog estima gli elementi.Lavorare su un backlog definendo più elementi, aggiungendo elemento per rappresentare ulteriori funzioni, come la ricerca, o per indirizzare bug rilevanti.Prima di stimare il livello di impegno, il team deve accettare cosa il successo significa per ogni elemento.

Questo argomento continua su esercitazione che segue i membri del team fittizio Fiber Fabrikam durante la creazione di un backlog del prodotto ed esegue un ciclo dello sprint seguendo procedure veloci.Il team utilizza le pagine scheda di backlog e attività di Team Web Access.

Julia, come proprietario del prodotto, detiene la visione e relative guida di orientamento di alto livello per il portale del servizio clienti in una serie di elementi di backlog come descritto in Creare o aggiungere al backlog prodotto.Il team è pronto per definire e stimare il backlog.

[!NOTA]

Se si utilizza il modello di processo Scrum 2.0 di Visual Studio, è possibile creare un elemento di backlog del prodotto per descrivere una storia utente, i requisiti, o una parte trasferibile del progetto.Se si utilizza MSF for Agile Software Development, è possibile creare una storia utente.Se si utilizza MSF for CMMI Process Improvement, è possibile creare un requisito.

In questo argomento

Criteri di accettazione di revisione e impegno stimato
Picchi di acquisizione o lavoro senza storia nel backlog
Risorse aggiuntive per supportare la stima degli impegni

Requisiti

Per seguire le procedure descritte in questo argomento, è necessario disporre delle seguenti autorizzazioni:

Visual Studio Premium, Visual Studio Ultimate o Visual Studio Test Professional.
È necessario essere un membro del team e avere l'autorizzazione Modifica permessi degli elementi di lavoro in questo nodo impostata su Consenti.Come impostazione predefinita, tutti i membri del team dispongono di questa autorizzazione, poiché il gruppo team è un membro del gruppo Contributors del progetto team.
Per visualizzare la pagina Backlog, è necessario appartenere al gruppo di accesso Completo in Team Web Access.

Per ulteriori informazioni, vedere Gestire il profilo personale e visualizzare le autorizzazioni personali e Accedere alle funzionalità in Team Web Access.

Criteri di accettazione di revisione e impegno stimato

Fornire più dettagli possibili che si vogliono descrivere non solo l'elemento o il bug di backlog, ma anche descrivere i criteri che verranno utilizzati per verificare se l'elemento è stato integrato o il bug è stato corretto.Una volta che i criteri di accettazione sono ben definiti, il team può quindi stimare collaborativamente ogni elemento di backlog in accordo con qualsiasi processo che hanno adottato.

Criteri di accettazione e lavoro richiesto nell'elemento di backlog

Aprire Team Web Access, passare alla home page del progetto team o team e scegliere Visualizza backlog.
Fare doppio clic sull'elemento di lavoro che si desidera revisionare, o sceglierlo e premere invio.

Rivedere e aggiornare i campi Criteri di accettazione e Descrizione con il consenso del team per l'elemento o il bug di backlog.

Suggerimento
I nomi di questi campi possono variare in base al modello di processo utilizzato per creare il progetto team, ad esempio, Descrizione con criteri di accettazione o Descrizione.

Riguardo ai criteri di accettazione: Alla fine di un'iterazione o di uno sprint, i clienti o il proprietario del prodotto accetteranno la storia utente finita 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 il team 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.

Sulla base del metodo di stima che il team utilizza, inserire un valore per Lavoro richiesto.All'inizio del progetto, è necessario disporre solo di una stima approssimativa.

[!NOTA]

I nomi di questi campi possono variare in base al modello di processo utilizzato per creare il progetto team, ad esempio, Lavoro richiesto per Scrum, Punti della storia for Agile e Dimensioni per CMMI.

About Story Points: in questo libro, Agile Estimation and Planning, Mike Cohn definisce gli Story Points in questo modo: "Gli Story Points sono un'unità di misura per esprimere le dimensioni complessive di una storia utente, una funzionalità o un altro elemento di lavoro". Cohn spiega che gli story points sono valori relativi che non vengono tradotti direttamente in un numero specifico di ore.I punti della storia consentono invece a un team di quantificare le dimensioni generali della storia utente.Queste stime relative sono meno precise in modo da richiedere meno sforzo in fase di determinazione ma perdurano meglio nel tempo.Realizzando stime in punti della storia, il team fornirà inizialmente le dimensioni generali delle storie utente e svilupperà successivamente una stima più dettagliata delle ore di lavoro necessarie, quando i membri del team saranno pronti per iniziare l'implementazione delle storie utente.Per ulteriori informazioni, vedere Stimare.
Scegliere il pulsante Salva e chiudi.

Picchi di acquisizione o lavoro senza storia nel backlog

Talvolta, il team dovrà effettuare un lavoro che non è un'implementazione diretta di una storia utente o un requisito del prodotto.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 backlog o una storia utente, opzionalmente includere "picco" nel titolo, e quindi classificarlo in ordine di priorità nel backlog del prodotto insieme alle altre storie utente.

Aggiungere il pannello alla pagina backlog prodotto

Nel pannello di aggiunta alla pagina di backlog del prodotto, immettere una descrizione nel campo Titolo per i picchi o lavori senza storia che devono essere completati e quindi scegliere il pulsante Aggiungi.

Suggerimento
Se il pannello di aggiunta non viene visualizzato, scegliere il collegamento Aggiungi elementi a per passare alla visualizzazione del pannello.

Si consiglia di definire il lavoro di non storia per le attività seguenti:

Ricerca: Quando il team ha domande aperte relative a una storia utente a cui è possibile rispondere prima che la storia utente possa essere completamente suddivisa in attività e stimata, è necessario stimare la ricerca richiesta per rispondere alla domanda.Ad esempio, una volta che un team determina che la storia, "As a frequent flyer, I can book award travel" ha parecchie domande senza risposta.Il team crea l'elemento, "As a team member, I can understand what ‘book award travel’ means." per rappresentare il picco.Il team stima il lavoro richiesto di ricerca nelle stesse unità come stimano altri elementi di backlog.

Importante
Nessuno degli elementi di backlog che richiedono la ricerca devono essere aggiunti all'iterazione corrente fino a quando il team non completa la ricerca.L'operazione di ricerca e l'elemento di backlog devono essere forniti per verificare separatamente le future iterazioni.

Bug Debt: 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 del processo o della progettazione: Il team apporterà miglioramenti di progettazione e del processo che l'aiuteranno a portarlo al successo.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.

Per ogni elemento di lavoro senza storia o picco che il team deve acquisire, ripetere i passaggi da 2 a 5 come descritto in "Criteri di accettazione di revisione e impegno di stima" per verificare che il team individui il lavoro da eseguire e stimare il lavoro.Per ulteriori informazioni, vedere Creare o aggiungere al backlog prodotto.