Tipi di elementi di lavoro e flusso di lavoro del processo CMMI in Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Teams usa i tipi di elementi di lavoro forniti con il processo MSF for CMMI Process Improvement 2015 (CMMI) per pianificare e tenere traccia dello stato di avanzamento dei progetti software. I team definiscono i requisiti per gestire il backlog del lavoro e quindi, usando la lavagna Kanban, tenere traccia dello stato aggiornando lo stato dei requisiti.
Per ottenere informazioni dettagliate su un portfolio di requisiti, i proprietari dei prodotti possono mappare i requisiti alle funzionalità. Quando i team lavorano nelle iterazioni, definiscono le attività che si collegano automaticamente ai requisiti.
Usando Microsoft Test Manager e il portale Web, i tester creano ed eseguono test case e definiscono i bug per tenere traccia dei difetti del codice.
Per supportare altri processi CMMI, i team possono tenere traccia delle richieste di modifica, dei rischi, dei problemi e delle note acquisite nelle riunioni di revisione. Se non si ha familiarità con il processo CMMI, esaminare la sezione Pianificare e tenere traccia del lavoro con CMMI per iniziare.
Definire i requisiti
Creare i requisiti dal pannello di aggiunta rapida nella pagina del backlog del prodotto. Successivamente, è possibile aprire ogni requisito per fornire altri dettagli e stimarne le dimensioni.
In alternativa, è possibile aggiungere in blocco i requisiti usando un file cvs.
Importante
Integrazione di Microsoft Project e il TFSFieldMapping comando non sono supportati per:
- Visual Studio 2019 e Azure DevOps Office Integration 2019.
- Azure DevOps Server 2019 e versioni successive, tra cui Azure DevOps Services.
Il supporto completo per l'integrazione di Microsoft Excel viene gestito e supporta l'importazione e l'aggiornamento bulk degli elementi di lavoro. Le alternative all'uso di Microsoft Project includono:
- Piani di recapito.
- Estensione del Marketplace, ad esempio Project Connessione o diagramma di GANTT.
I requisiti specificano le funzioni e gli elementi del prodotto che i team devono creare. I proprietari dei prodotti definiscono in genere i requisiti di classificazione dello stack nella pagina del backlog del prodotto. Il team definisce quindi l'ambito delle dimensioni dello sforzo per fornire gli elementi con priorità più alta.
Usare le indicazioni seguenti e fornite per i campi usati in comune tra i tipi di elemento di lavoro durante la compilazione del modulo. Per altre informazioni, vedere Pianificare un progetto.
Campo
Utilizzo
Fornire dettagli sufficienti per stimare la quantità di lavoro necessaria per implementare il requisito. Concentrarsi su chi è il requisito, su ciò che gli utenti vogliono eseguire e sul perché. Non descrivere come deve essere sviluppato il requisito. Fornire dettagli sufficienti in modo che il team possa scrivere attività e test case per implementare l'elemento.
Nei campi HTML è possibile aggiungere testo RTF e immagini.
L'impatto del cliente di non implementare questo requisito. È possibile includere i dettagli del modello Kano sul fatto che questo requisito si trovi nelle categorie sorprendenti, obbligatorie o ovvie. Queste informazioni vengono acquisite nel campo HTML RTF corrispondente a Impact Assessment.
Tipo di requisito (obbligatorio)
Tipo di requisito da implementare. È possibile specificare uno dei seguenti valori:
- Obiettivo aziendale
- Funzionalità (impostazione predefinita)
- Funzionale
- Interfaccia
- Canale operativo
- Qualità del servizio
- protezione anticaduta
- Scenario
- Sicurezza
Area del valore del cliente indirizzato dall'elemento epico, funzionalità, requisito o backlog. I valori includono:
- Architettura: servizi tecnici per implementare funzionalità aziendali che offrono una soluzione
- Business: servizi che soddisfano le esigenze dei clienti o degli stakeholder che offrono direttamente valore al cliente per supportare l'azienda (impostazione predefinita)
Stimare la quantità di lavoro necessaria per completare un requisito usando qualsiasi unità numerica di misura preferita dal team. Definendo le dimensioni per i requisiti, i team possono usare i grafici di velocità Agile e gli strumenti di previsione per stimare le iterazioni future o le attività di lavoro. Il diagramma di flusso cumulativo Kanban fa riferimento ai valori in questo campo. Per altre informazioni, vedere il white paper Stima .
Quantità di lavoro stimata necessaria per completare un'attività. In genere, questo campo non cambia dopo l'assegnazione.
È possibile specificare il lavoro in ore o in giorni. Al campo non sono associate unità temporali intrinseche.
Date di destinazione per l'inizio o la fine del lavoro.
Priorità (obbligatorio)
Valutazione soggettiva del requisito in relazione all'azienda. I valori consentiti sono i seguenti:
- 1: Il prodotto non può essere spedito senza l'articolo.
- 2: (impostazione predefinita) Il prodotto non può essere spedito senza l'articolo, ma non deve essere risolto immediatamente.
- 3: L'implementazione dell'elemento è facoltativa in base a risorse, tempo e rischio.
Indica il tipo di decisione di valutazione in sospeso per l'elemento di lavoro. Utilizzare questo campo quando l'elemento di lavoro si trova nello stato Proposto e specificare uno dei valori seguenti: In sospeso (impostazione predefinita), Altre informazioni, Informazioni ricevute e Valutazione.
Indica se un membro del team non può eseguire progressi verso l'implementazione di un requisito o di un'attività o la risoluzione di un bug, una richiesta di modifica o un rischio. Se è stato aperto un problema per tenere traccia di un problema di blocco, è possibile creare un collegamento al problema. È possibile specificare Sì di no.
Commit (obbligatorio)
Indica se il commit del requisito viene eseguito nel progetto o meno. È possibile specificare Sì o No (impostazione predefinita).
Numero di build del prodotto che incorpora il requisito, la richiesta di modifica o corregge un bug.
Test di accettazione utente (obbligatorio)
Stato del test di accettazione dell'utente per un requisito. È possibile specificare uno dei seguenti valori:
- Passare
- Fail
- Non pronto (impostazione predefinita)
- Pronto
- Ignorato
- Informazioni ricevute
Si specifica Non pronto quando il requisito è nello stato Attivo e si specifica Pronto quando il requisito si trova nello stato Risolto.
Nomi dei membri del team che hanno familiarità con l'area del cliente rappresentata da questo requisito.
Acquisire commenti nella sezione Discussione
Utilizzare la sezione Discussione per aggiungere ed esaminare i commenti relativi al lavoro eseguito.
La barra degli strumenti dell'editor di testo RTF viene visualizzata sotto l'area di immissione del testo. Viene visualizzato quando si seleziona ogni casella di testo che supporta la formattazione del testo.
Nota
Non esiste un campo Elemento di lavoro Discussione . Per eseguire query sugli elementi di lavoro con i commenti immessi nell'area Discussione, filtrare il campo Cronologia. Il contenuto completo del testo immesso nella casella di testo Discussione viene aggiunto al campo Cronologia.
Menzionare un utente, un gruppo, un elemento di lavoro o una richiesta pull
Per aprire un menu delle voci recenti effettuate per menzionare qualcuno, collegarsi a un elemento di lavoro o collegarsi a una richiesta pull, selezionare 
o 
o immettere @, #o .!
Immettere un nome o un numero e i filtri dell'elenco di menu in modo che corrispondano alla voce. Scegliere la voce da aggiungere. Per inserire un gruppo nella discussione, immettere @ e il nome del gruppo, ad esempio un team o un gruppo di sicurezza.
Modificare o eliminare un commento
Per modificare o eliminare i commenti di discussione, scegliere 
Modifica o scegliere l'icona 
azioni e quindi scegliere Elimina.
Nota
La modifica e l'eliminazione di commenti richiede Azure DevOps Server 2019 Update 1 o versione successiva.
Dopo aver aggiornato il commento, scegliere Aggiorna. Per eliminare il commento, confermare che si desidera eliminarlo.
Un audit trail completo di tutti i commenti modificati ed eliminati viene mantenuto nella scheda Cronologia del modulo dell'elemento di lavoro.
Importante
Per Azure DevOps Server locale, è necessario configurare un server SMTP per consentire ai membri del team di ricevere notifiche.
Aggiungere una reazione a un commento
Aggiungere una o più reazioni a un commento scegliendo un'icona sorridente nell'angolo superiore destro di qualsiasi commento. In alternativa, scegliere tra le icone nella parte inferiore di un commento accanto a eventuali reazioni esistenti. Per rimuovere la tua reazione, scegli la reazione nella parte inferiore del tuo commento. L'immagine seguente mostra un esempio dell'esperienza di aggiunta di una reazione e la visualizzazione di reazioni su un commento.
Salvare un commento senza salvare l'elemento di lavoro
Nota
Questa funzionalità è disponibile a partire da Azure DevOps Server 2022.1.
Se si dispone solo delle autorizzazioni per aggiungere alla discussione di un elemento di lavoro, è possibile farlo salvando i commenti. Questa autorizzazione è controllata dai nodi Percorso area e dai commenti Modifica elemento di lavoro in questa autorizzazione del nodo . Per altre informazioni, vedere Impostare le autorizzazioni di rilevamento del lavoro, Creare nodi figlio, modificare gli elementi di lavoro in un'area o in un percorso di iterazione.
Dopo aver salvato i commenti, non è necessario salvare l'elemento di lavoro.
Nota
Quando si salvano le modifiche apportate al controllo Discussione , viene salvato solo il commento. Nessuna regola dell'elemento di lavoro definita per il tipo di elemento di lavoro eseguito.
Tenere traccia dello stato di avanzamento del lavoro
Man mano che il lavoro avanza, si modifica il campo Stato per aggiornare lo stato. Facoltativamente, è possibile specificare un motivo. I campi di stato e motivo vengono visualizzati nel modulo dell'elemento di lavoro nell'area di intestazione.
Stati del flusso di lavoro CMMI
Questi diagrammi mostrano i principali stati di avanzamento e regressione per i wit requisiti, bug e attività.
| Requisito | Bug | Attività |
|---|---|---|
 |
 |
 |
La progressione tipica del flusso di lavoro per un requisito è:
- Il proprietario del prodotto crea un requisito nello stato Proposto con il motivo predefinito Nuovo requisito.
- Il proprietario del prodotto aggiorna lo stato su Attivo quando iniziano a implementarlo.
- Il team aggiorna lo stato su Risolto al termine dello sviluppo del codice e i test di sistema sono stati superati.
- Infine, il team o il proprietario del prodotto sposta il requisito su Chiuso quando il proprietario del prodotto accetta che è stato implementato in base ai criteri di accettazione e ha superato tutti i test di convalida.
Aggiornare lo stato di lavoro con Kanban o Taskboard
Teams può usare la bacheca Kanban per aggiornare lo stato dei requisiti e lo sprint taskboard per aggiornare lo stato delle attività. Il trascinamento degli elementi in una nuova colonna di stato aggiorna i campi Stato e Motivo.
È possibile personalizzare la lavagna Kanban per supportare più corsie o colonne da bagno. Per altre opzioni di personalizzazione, vedere Personalizzare l'esperienza di rilevamento del lavoro.
Eseguire il mapping dei requisiti alle funzionalità
Quando si gestisce una suite di prodotti o esperienze utente, è possibile visualizzare l'ambito e lo stato di avanzamento del lavoro nel portfolio di prodotti. È possibile visualizzare l'ambito definendo funzionalità e mapping dei requisiti alle funzionalità.
Usando i backlog del portfolio, è possibile eseguire il drill-down da un backlog a un altro per visualizzare il livello di dettaglio desiderato. È anche possibile usare i backlog del portfolio per visualizzare un rollup del lavoro in corso in più team quando si configura una gerarchia di team.
L'elemento di lavoro della funzionalità contiene campi simili forniti per i requisiti e include altri campi, come descritto nella tabella seguente.
Definizione delle attività
Quando il team gestisce il lavoro negli sprint, può usare la pagina di backlog sprint per suddividere il lavoro da eseguire in attività distinte.
Assegnare un nome all'attività e stimare il lavoro che verrà prenderà.
Quando i team stimano il lavoro, definiscono le attività e stimano le ore o i giorni per completare le attività. I team prevedono il lavoro e definiscono le attività all'inizio di un'iterazione e ogni membro del team esegue un subset di tali attività. Le attività possono includere sviluppo, test e altri tipi di lavoro. Ad esempio, uno sviluppatore può definire attività per implementare i requisiti e un tester può definire attività per scrivere ed eseguire test case. Collegando le attività ai requisiti e ai bug, viene visualizzato lo stato di avanzamento di questi elementi. Per altre informazioni, vedere Attività di iterazione.
Campo
Utilizzo
Selezionare il tipo di attività da implementare dai valori consentiti:
Azione correttiva
Azione di mitigazione
Pianificato
Selezionare la disciplina rappresentata da questa attività quando il team stima la capacità sprint per attività.
Analisi
Sviluppo
Test
Istruzione utente
Esperienza utente
Questo campo viene usato anche per calcolare la capacità in base alla disciplina. Viene assegnato a type="Activity" nel file ProcessConfiguration. (2)
Per altre informazioni, vedere Implementare le attività di sviluppo.
Quantità di lavoro stimata necessaria per completare un'attività. In genere, questo campo non cambia dopo l'assegnazione.
Quantità di lavoro rimanente per completare un'attività. Man mano che il lavoro procede, aggiornare questo campo. Viene usato per calcolare i grafici di capacità, il grafico burndown sprint e il report Sprint Burndown . Se si divide un'attività in sottoattività, specificare ore solo per le sottoattività. È possibile specificare il lavoro in qualsiasi unità di misura scelta dal team.
Quantità di lavoro impiegato per l'implementazione di un'attività.
Tenere traccia dello stato di avanzamento dei test
Requisiti di test
Dal portale Web o da Gestione test è possibile creare test case che si collegano automaticamente a un requisito o a un bug. In alternativa, è possibile collegare un requisito a un test case dalla 
scheda (collegamenti).
Il test case contiene molti campi, molti dei quali sono automatizzati e integrati con Gestione test e il processo di compilazione. Per una descrizione di ogni campo, vedere Eseguire query in base ai campi di integrazione di compilazione e test.
La scheda (collegamenti) elenca tutti i requisiti e i bug in un test case. Usando il collegamento, il team può tenere traccia dello stato di avanzamento di ogni elemento e supporta le informazioni visualizzate nel report Panoramica dei requisiti.
Tenere traccia dei difetti del codice
È possibile creare bug dal portale Web del portale Web, Visual Studio o durante il test con Gestione test.
Tenere traccia delle richieste di modifica, dei rischi, dei problemi e delle note acquisite nelle riunioni di revisione
Oltre ai requisiti, alle funzionalità, alle attività e alle connessioni WIT di bug, è possibile tenere traccia delle informazioni consigliate dal processo CMMI con le connessioni WITS seguenti.
- Richiesta di modifica per gestire le modifiche proposte a qualsiasi prodotto di lavoro sottoposto a controllo delle modifiche.
- Problema per tenere traccia di un evento o di una situazione che potrebbe bloccare il lavoro o blocca il lavoro sul prodotto. I problemi differiscono dai rischi in quanto i team identificano spontaneamente i problemi, in genere durante le riunioni quotidiane del team.
- Rischio per tenere traccia della probabilità e del grado di varianza tra risultati effettivi e desiderati. Quando si gestiscono i rischi, si riduce in modo strategico la varianza tra il risultato desiderato e il risultato effettivo.
- Esaminare per documentare i risultati di una revisione della progettazione o del codice. I membri del team possono acquisire i dettagli del modo in cui la progettazione o il codice soddisfa gli standard nelle aree di correttezza dei nomi, pertinenza del codice, estendibilità, complessità del codice, complessità algoritmica e sicurezza del codice.
È possibile aggiungere un problema dal widget Nuovo elemento di lavoro aggiunto a un dashboard del team o dal menu Nuovo nella pagina Query.
Gli elementi di lavoro aggiunti dal widget vengono automaticamente limitati all'area predefinita e ai percorsi di iterazione del team. Per modificare il contesto del team, vedere Cambiare il contesto del team.
Definizioni per i campi di rilevamento di lavoro comuni
Nella maggior parte degli elementi di lavoro vengono visualizzati i campi e le schede seguenti. Ogni scheda viene usata per tenere traccia di informazioni specifiche, ad esempio 
Cronologia, Collegamenti o
Allegati. Queste tre schede forniscono una cronologia delle modifiche, la visualizzazione degli elementi di lavoro collegati e la possibilità di visualizzare e allegare file.
L'unico campo obbligatorio per tutti i tipi di elemento di lavoro è Title. Quando si salva un elemento di lavoro, il sistema lo assegna a un ID univoco. Il modulo evidenzia il campo obbligatorio in giallo. Per informazioni su altri campi, vedere Indice dei campi dell'elemento di lavoro.
Nota
È possibile che siano necessari campi aggiuntivi a seconda delle personalizzazioni apportate al processo e al progetto.
Campo/scheda
Utilizzo
Immettere una descrizione di 255 caratteri o meno. È sempre possibile modificare il titolo in un secondo momento.
Assegnare l'elemento di lavoro al membro del team responsabile dell'esecuzione del lavoro.
Quando viene creato l'elemento di lavoro, per impostazione predefinita Lo stato viene impostato sul primo stato del flusso di lavoro. Man mano che il lavoro procede, aggiornarlo in modo da riflettere lo stato corrente.
Usare prima il valore predefinito. Aggiornarlo quando si modifica lo stato. Ogni stato è associato a un motivo predefinito.
Scegliere il percorso dell'area associato al prodotto o al team oppure lasciare vuoto fino a quando non viene assegnato durante una riunione di pianificazione. Per modificare l'elenco a discesa delle aree, vedere Definire i percorsi di area e assegnarli a un team.
Scegliere lo sprint o l'iterazione in cui il lavoro deve essere completato oppure lasciarlo vuoto e assegnarlo in un secondo momento durante una riunione di pianificazione. Per modificare l'elenco a discesa delle iterazioni, vedere Definire i percorsi di iterazione (sprint) e configurare le iterazioni del team.
Esaminare il audit trail acquisito dal sistema e acquisire informazioni aggiuntive.
Ogni volta che l'elemento di lavoro viene aggiornato, le informazioni vengono aggiunte alla cronologia. La cronologia include la data della modifica, chi ha apportato la modifica e quali campi sono stati modificati. È anche possibile aggiungere testo formattato al campo della cronologia.
Aggiungere tutti i tipi di collegamenti, ad esempio collegamenti ipertestuali, insiemi di modifiche, file di origine e così via.
Questa scheda elenca anche tutti i collegamenti definiti per l'elemento di lavoro.
Condividere informazioni più dettagliate aggiungendo file all'elemento di lavoro, ad esempio thread di posta elettronica, documenti, immagini, file di log o altri tipi di file.
Personalizzare i tipi di elemento di lavoro
Per la maggior parte dei tipi di elementi di lavoro, è possibile aggiungere campi, modificare il flusso di lavoro, aggiungere regole personalizzate e aggiungere pagine personalizzate al modulo dell'elemento di lavoro. È anche possibile aggiungere tipi di elementi di lavoro personalizzati. Per altre informazioni, vedere Personalizzare un processo di ereditarietà.
Per la maggior parte dei tipi di elementi di lavoro, è possibile aggiungere campi, modificare il flusso di lavoro, aggiungere regole personalizzate e aggiungere pagine personalizzate al modulo dell'elemento di lavoro. È anche possibile aggiungere tipi di elementi di lavoro personalizzati. Per altre informazioni, vedere Personalizzare un processo di ereditarietà o Personalizzare il modello di processo XML locale a seconda del modello di processo usato dal progetto.
Articoli correlati
- Creare un progetto
- Aggiungere elementi di lavoro per gestire un progetto
- Creare un backlog
- Usare una scheda Kanban
- Pianificare uno sprint
Ordine elenco backlog
Il campo Stack Rank viene usato per tenere traccia della classificazione relativa dei requisiti, delle funzionalità o delle epiche. Per impostazione predefinita, tuttavia, non viene visualizzato nel modulo dell'elemento di lavoro. La sequenza di elementi nella pagina backlog viene determinata in base alla posizione in cui sono stati aggiunti gli elementi o spostati gli elementi nella pagina. Durante il trascinamento degli elementi, un processo in background aggiorna questo campo.
Questo campo non viene visualizzato nel modulo dell'elemento di lavoro.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per