Tipi di elementi di lavoro e flusso di lavoro del processo CMMI in Azure Boards

servizi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

I team usano i tipi di elementi di lavoro (WITs - Work Item Types) forniti con MSF per CMMI Process Improvement 2015 (CMMI) per pianificare e monitorare i progetti software. I proprietari dei prodotti definiscono i requisiti per gestire il backlog e i team tengono traccia dello stato di avanzamento sulla tua bacheca aggiornando i requisiti e lo stato delle attività.

Immagine concettuale che mostra i tipi di elemento di lavoro del processo CMMI.

I proprietari dei prodotti eseguono il mapping dei requisiti alle funzionalità per visualizzare lo stato di avanzamento a livello di portfolio. Quando i team lavorano nelle iterazioni, creano attività che si collegano automaticamente ai requisiti.

I tester creano ed eseguono test case usando Microsoft Test Manager o il portale Web e registrano bug per tenere traccia dei difetti del codice.

Teams tiene traccia anche delle richieste di modifica, dei rischi, dei problemi e delle note acquisite durante le riunioni di revisione. Se non si ha familiarità con il processo CMMI, iniziare con Pianificare e tenere traccia del lavoro con CMMI.

Definire i requisiti

Creare i requisiti dal pannello di aggiunta veloce nella pagina del backlog del prodotto. Successivamente, aprire ogni requisito per specificare i dettagli e stimarne le dimensioni.

Screenshot che mostra il modulo Elemento di lavoro Requisito.

In alternativa, è possibile aggiungere in blocco i requisiti usando un file CSV (vedere Importare elementi di lavoro da CSV).

Important

Integrazione di Microsoft Project non è più supportata

Integrazione di Microsoft Project e il TFSFieldMapping comando non sono più disponibili per:

  • Visual Studio 2019 e versioni successive (inclusa l'integrazione di Office in Azure DevOps)
  • Azure DevOps Server 2020 e versioni successive
  • Servizi di Azure DevOps

Cosa funziona ancora: L'integrazione di Microsoft Excel rimane completamente supportata per l'importazione e l'aggiornamento bulk degli elementi di lavoro.

Alternative consigliate:

  • Piani di recapito - Funzionalità nativa di Azure DevOps per la pianificazione del progetto e il rilevamento tra team
  • Estensioni per la gestione dei progetti - Esplorare Azure DevOps Marketplace per le soluzioni di gestione dei progetti e del grafico di Gantt correnti
  • Integrazioni di terze parti : molti strumenti di gestione dei progetti offrono connettori Azure DevOps per l'integrazione senza problemi del flusso di lavoro

I requisiti descrivono gli elementi e le funzioni del prodotto che i team devono sviluppare. I proprietari di prodotti definiscono in genere i requisiti di stack-rank nella pagina del backlog del prodotto. Il team definisce quindi l'ambito delle attività necessarie e scrive attività e test case per implementare ogni elemento.

Utilizzare le seguenti indicazioni e la sezione campi usati in comune tra i tipi di elemento di lavoro quando si completa il modulo. Per altre informazioni, vedere Pianificare un progetto.

Field

Usage

Description

Fornire dettagli sufficienti per il team per stimare il lavoro di implementazione. Concentrarsi su chi serve il requisito, su cosa vogliono ottenere gli utenti e sul perché. Evitare di descrivere come implementare il requisito. Includere un contesto sufficiente in modo che il team possa scrivere attività e casi di test dall'elemento.

Nei campi HTML è possibile aggiungere testo RTF e immagini.

Valutazione dell'impatto

Documentare l'impatto sui clienti dell'assenza di implementazione del requisito nel campo di testo arricchito di Valutazione dell'impatto. È possibile includere i dettagli del modello Kano che indicano se il requisito è una funzionalità sorprendente, obbligatoria o ovvia.

Tipo di requisito (obbligatorio)

Specificare uno di questi valori per Tipo di requisito:

  • Obiettivo aziendale
  • Funzionalità (impostazione predefinita)
  • Functional
  • Interface
  • Operational
  • Qualità del servizio
  • Safety
  • Scenario
  • Security

Area di valore

Indicare l'area del valore per il cliente a cui si rivolge l'epica, la funzionalità o il requisito. I valori comuni includono:

  • Architettura: servizi tecnici per implementare funzionalità aziendali che offrono funzionalità di soluzione.
  • Business: servizi che soddisfano le esigenze degli stakeholder e forniscono direttamente il valore del cliente (impostazione predefinita).

Size

Stimare il lavoro necessario per completare un requisito usando qualsiasi unità numerica preferita dal team. I team usano Dimensioni per grafici e previsioni di velocità. Il diagramma di flusso cumulativo fa anche riferimento ai valori in questo campo. Per ulteriori informazioni, vedere il white paper Stima.

Stima originale

Specificare la stima originale per un'attività. In genere questo valore non cambia dopo l'assegnazione dell'attività. È possibile specificare il lavoro in ore o giorni; il campo non ha un'unità temporale intrinseca.

Data di inizio/Data fine

Fornire le date di inizio e fine previste per il lavoro.

Priorità (obbligatorio)

Impostare una classificazione soggettiva che rifletta la priorità aziendale:

  • 1: Il prodotto non può essere spedito senza l'articolo.
  • 2: (impostazione predefinita) Il prodotto non può essere spedito senza l'articolo, ma non richiede attenzione immediata.
  • 3: L'implementazione è facoltativa in base a risorse, tempo e rischio.

Triage (obbligatorio)

Usare Triage quando un elemento di lavoro si trova nello stato Proposto. Scegliere uno di: In sospeso (impostazione predefinita), Altre informazioni, Info ricevute, Valutazione.

Blocked

Indicare se un membro del team non può eseguire progressi nell'elemento di lavoro. Se un problema blocca il funzionamento, creare un collegamento al problema. Scegliere Sì o No.

Impegnato. Obbligatorio

Indicare se il team si è impegnato a fornire il requisito. Scegliere Sì o No (impostazione predefinita).

Integrato in

Registrare il numero di build del prodotto che include il requisito, la richiesta di modifica o la correzione di bug.

Test di accettazione utente (obbligatorio)

Impostare lo stato del test di accettazione dell'utente per un requisito da:

  • Pass
  • Fail
  • Non pronto (impostazione predefinita)
  • Ready
  • Skipped
  • Informazioni ricevute

Usare Non pronto quando il requisito è Attivo e Pronto quando viene risolto.

Esperti in materia

Elencare i membri del team che hanno familiarità con l'area del cliente rappresentata dal requisito.

Catturare i commenti nella sezione Discussione

Usare la sezione Discussione per collaborare agli elementi di lavoro aggiungendo ed esaminando i commenti.

Istantanea della sezione Discussione all'interno di un modulo di un elemento di lavoro.

Quando si posiziona il cursore in una casella di testo che supporta la formattazione, viene visualizzata la barra degli strumenti dell'editor rtf.

Screenshot della sezione Discussione, barra degli strumenti dell'Editor di Testo Formattato.

Note

Non esiste un campo del tipo "Discussione" per gli elementi di lavoro. Per eseguire query sugli elementi di lavoro con commenti dall'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

Usa una delle icone seguenti per aprire gli elementi recenti relativi a persone, elementi di lavoro o pull request:

È possibile aprire lo stesso menu con i tasti di scelta rapida: at-mention @, hashtag #e punto esclamativo !.

Screenshot della sezione Discussione, menu a discesa selettore di persone.

Immettere un nome o un numero per filtrare l'elenco e quindi selezionare l'elemento da aggiungere. Per menzionare un gruppo, immettere @ seguito dal nome del gruppo, ad esempio un team o un gruppo di sicurezza.

Modificare o eliminare un commento

Per aggiornare o rimuovere uno dei commenti, selezionare Modifica o selezionare Altre azioni ( ) e quindi selezionare Elimina:

Screenshot della sezione Discussione in cui è possibile scegliere Modifica o Elimina azioni.

Dopo aver modificato un commento, selezionare Aggiorna. Per rimuovere un commento, confermare l'eliminazione. La scheda Cronologia gestisce un audit trail di tutti i commenti modificati ed eliminati.

Important

Per le Azure DevOps Server locali, configurare un server SMTP in modo che i membri del team possano ricevere notifiche.

Aggiungere una reazione a un commento

Aggiungere una o più reazioni a un commento selezionando un'emoji nel commento. Per rimuovere la reazione, selezionare di nuovo la stessa reazione. L'immagine seguente mostra un esempio di aggiunta e visualizzazione di reazioni su un commento.

Screenshot della sezione di Discussione, aggiungi una reazione a un commento.

Salvare un commento senza salvare l'elemento di lavoro

Note

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 dal permesso Modifica commenti degli elementi di lavoro in questo nodo. Per altre informazioni, vedere Impostare le autorizzazioni per il monitoraggio del lavoro - Creare nodi figlio, modificare gli elementi di lavoro in un'area o in un percorso di iterazione.

Quando si salvano i commenti, non è necessario salvare l'elemento di lavoro.

Screenshot della sezione Discussione, commento salvato.

Note

Quando si salvano le modifiche apportate al controllo Discussione , viene salvato solo il commento. Non vengono eseguite regole degli elementi di lavoro definite per il tipo di elemento di lavoro.

Tenere traccia dello stato di avanzamento del lavoro

Man mano che il lavoro procede, aggiornare il campo Stato in modo da riflettere lo stato corrente. Facoltativamente, specificare un motivo; I campi di stato e motivo vengono visualizzati nell'intestazione del modulo dell'elemento di lavoro.

Screenshot che mostra l'area dell'intestazione del modulo per l'elemento di lavoro Bug.

Stati del flusso di lavoro CMMI

I diagrammi seguenti illustrano i principali stati di avanzamento e regressione per i WIT requisito, Bug e Attività.

Requirement Bug Task
Immagine concettuale che mostra gli stati del flusso di lavoro dei Requisiti, processo CMMI. Immagine concettuale che mostra gli stati del flusso di lavoro Bug, processo CMMI. Immagine concettuale che mostra gli stati del flusso di lavoro delle attività, processo CMMI.

Il flusso di lavoro tipico per un requisito segue questa procedura:

  • Il proprietario del prodotto crea un requisito nello stato Proposto con il motivo predefinito Nuovo requisito.
  • Il proprietario del prodotto sposta il requisito su Attivo all'inizio del lavoro.
  • Il team imposta lo stato su Risolto al termine dello sviluppo e quando i test di sistema sono superati.
  • Infine, il team o il proprietario del prodotto sposta il requisito su Chiuso dopo i criteri di accettazione e i test di convalida confermano il completamento.

Aggiornare lo stato di lavoro con una bacheca o schede attività

Usare la scheda o la bacheca attività sprint per aggiornare gli stati degli elementi. Il trascinamento di un elemento in una colonna diversa aggiorna i campi Stato e Motivo.

Screenshot che mostra lo stato di avanzamento della bacheca nel portale Web.

È possibile personalizzare la tavola per aggiungere più corsie o colonneda bagno.

Mappare i requisiti alle funzionalità

Quando si gestiscono più prodotti o esperienze utente, definire funzionalità e mappare i requisiti a tali funzionalità per visualizzare l'ambito e lo stato di avanzamento nel portfolio.

Utilizzare i backlog di portfolio per approfondire i dettagli tra i livelli di backlog e aggregare il lavoro in corso tra i team. È anche possibile visualizzare i rollup dopo aver configurato una gerarchia di team.

L'elemento di lavoro della funzionalità contiene campi simili ai requisiti e ad altri campi descritti nel riferimento.

Definire le attività

Quando il tuo team consegna lavoro a sprint, suddividi i requisiti in attività dalla pagina del backlog dello sprint e stima lo sforzo.

Screenshot che mostra il collegamento Aggiungi attività in una pagina di backlog sprint nel portale Web

Assegnare un nome all'attività e stimare il lavoro.

Screenshot che visualizza la scheda dell'elemento di lavoro dell'attività CMMI

Quando i team stimano il lavoro, definiscono le attività e stimano le ore o i giorni per completarli. I team prevedono la capacità e affinano le attività all'inizio di un'iterazione; ogni membro del team esegue quindi un subset di attività. Le attività possono includere attività di sviluppo, test e altre attività. Ad esempio, uno sviluppatore crea attività per implementare un requisito mentre un tester crea attività per scrivere ed eseguire test case. Collegando le attività ai requisiti e ai bug, i team vedono chiaramente lo stato di avanzamento dell'implementazione. Per altre informazioni, vedere Attività di iterazione.

Field

Usage

Tipo di attività

Selezionare il tipo di attività da:

  • Azione correttiva
  • Azione di mitigazione
  • Planned

Discipline

Scegli la disciplina rappresentata da questa attività quando stimi la capacità dello sprint per ciascuna attività.

  • Analysis
  • Development
  • Test
  • Istruzione utente
  • Esperienza utente

Questo campo consente anche di calcolare la capacità in base alla disciplina. Viene assegnato a type="Activity" nel file ProcessConfiguration. Per altre informazioni, vedere Implementare le attività di sviluppo.

Stima originale

Immettere la stima originale per l'attività.

Lavoro rimanente

Aggiornare il lavoro rimanente man mano che il team procede. Questo valore alimenta i grafici di capacità, il grafico burndown sprint e i report correlati. Se si suddivide un'attività in sottoattività, tenere traccia delle ore solo nelle sottoattività.

Lavoro completato

Registrare il lavoro già dedicato all'implementazione dell'attività.

Tenere traccia dello stato di avanzamento dei test

Requisiti di test

Nel portale Web o in Test Manager, creare test case che si colleghino automaticamente a un requisito o a un bug, oppure aggiungere un collegamento dalla scheda Collegamenti.

Screenshot che mostra la selezione del gruppo di test e l'aggiunta di un test case.

Il test case contiene molti campi, inclusi i campi che si integrano con il processo di compilazione e test. Per informazioni dettagliate , vedere Query basata sui campi di integrazione di compilazione e test .

Screenshot che mostra il modulo dell'elemento di lavoro Test case nel portale Web.

La scheda (collegamenti) elenca tutti i requisiti e i bug a cui fa riferimento un test case. Il collegamento consente ai team di tenere traccia dello stato di avanzamento dei test e supporta report come il report Panoramica dei requisiti.

Tenere traccia dei difetti del codice

Creare bug dal portale Web, Visual Studio o Test Manager (vedere Gestire i bug).

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 ai bug, il processo CMMI raccomanda questi WITs:

  • Richiesta di modifica per gestire le modifiche proposte ai prodotti di lavoro sotto il controllo delle modifiche.
  • Problema per tenere traccia di eventi o situazioni che potrebbero bloccare il lavoro. I problemi differiscono dai rischi perché i team identificano in genere i problemi spontaneamente durante le riunioni quotidiane.
  • Rischio per tenere traccia della probabilità e della varianza tra risultati effettivi e desiderati. Quando si gestiscono i rischi, è possibile ridurre al minimo la varianza tra i risultati previsti e effettivi.
  • Esaminare per documentare il modo in cui una revisione della progettazione o del codice soddisfa gli standard, ad esempio la correttezza dei nomi, la pertinenza del codice, l'estendibilità, la complessità e la sicurezza.

È possibile aggiungere un problema usando il widget Nuovo elemento di lavoro in un dashboard del team o dal menu Nuovo nella pagina Query.

Screenshot che mostra l'aggiunta di un elemento di lavoro da un widget Nuovo elemento di lavoro.

Gli elementi di lavoro aggiunti dal widget rientrano automaticamente nell'area predefinita e nei percorsi di iterazione del team. Per modificare il contesto del team, vedere Cambiare il contesto del team.

Definizioni per i campi comuni di monitoraggio del lavoro

Nella maggior parte degli elementi di lavoro vengono visualizzati i campi e le schede seguenti. Le schede comuni includono Cronologia, Collegamenti e Allegati.

Per tutti i tipi di elemento di lavoro, Title è l'unico campo universalmente obbligatorio. Quando si salva un elemento di lavoro, Azure DevOps assegna un ID univoco. I campi obbligatori sono evidenziati in giallo. Per altri campi, vedere Indice dei campi elemento di lavoro.

Note

Altri campi potrebbero essere necessari in base alle personalizzazioni del processo e del progetto.

Campo o scheda Usage
Title Immettere una breve descrizione (fino a 255 caratteri). È possibile modificare il titolo in un secondo momento.
Assegnato a Assegnare l'elemento di lavoro alla persona responsabile del completamento o lasciarlo non assegnato fino a quando la proprietà non è chiara.
State Al momento della creazione, Stato è impostato per impostazione predefinita sul primo stato del flusso di lavoro (ad esempio Nuovo o Non assegnato). Aggiornalo man mano che il lavoro procede.
Reason Il motivo spiega perché l'elemento si trova nello stato corrente. I valori predefiniti variano in base al tipo di elemento di lavoro e al processo.
Area Selezionare il percorso dell'area per il prodotto o il team. Per informazioni dettagliate, vedere Definire i percorsi di area e assegnarli a un team.
Iteration Selezionare lo sprint/iterazione per il completamento pianificato. Per informazioni dettagliate, vedere Definire i percorsi di iterazione (sprint) e configurare le iterazioni del team.
Scheda Cronologia Visualizzare il log delle modifiche completo per l'elemento di lavoro, inclusi i campi autore, data e aggiornamento. È anche possibile aggiungere testo formattato in Cronologia.
Scheda Collegamenti Aggiungere relazioni ad altri artefatti, ad esempio elementi di lavoro padre/figlio, insiemi di modifiche, file di origine o risultati dei test.
Scheda Allegati Aggiungere file di supporto, ad esempio documenti, immagini, log o thread di posta elettronica.

Personalizzare i tipi di elemento di lavoro

Per la maggior parte dei tipi di elementi di lavoro, è possibile aggiungere campi, aggiornare il flusso di lavoro, definire regole personalizzate, aggiungere pagine personalizzate e creare 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, aggiornare il flusso di lavoro, definire regole personalizzate, aggiungere pagine personalizzate e creare 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.

Contenuti correlati

Ordine della lista backlog

Usare il campo Stack Rank per tenere traccia della classificazione relativa dei requisiti, delle funzionalità o delle epiche. La pagina backlog determina la sequenza in base alla posizione in cui si aggiungono o spostano elementi nella pagina (vedere Creare il backlog). Durante il trascinamento degli elementi, un processo in background aggiorna il campo Stack Rank. Questo campo non viene visualizzato nel modulo dell'elemento di lavoro per impostazione predefinita.

  • Last updated on