Mapping dei concetti di SAFe® agli artefatti di Azure Boards

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Se si è interessati all'uso di Scaled Agile Framework (SAFe®), è possibile configurare il progetto di Azure Boards per tenere traccia dei risultati finali di SAFe®. Proprio come Azure Boards supporta le procedure Scrum e Agile, può supportare SAFe® e un numero elevato di team per collaborare su Epics che si estendono sulle versioni.

Questa esercitazione illustra come gli artefatti SAFe® seguenti eseguono il mapping a elementi specifici di Azure Boards.

  • Team SAFe® Agile, program e portfolio
  • SaFe® offre risultati come epiche, caratteristiche e storie
  • Visualizzazioni del prodotto, del programma e del portfolio SAFe®
  • SaFe® Release train, sprint e altri timebox
  • Obiettivi e obiettivi dell'iterazione SAFe®
  • Flussi e budget SAFe® Value
  • Visione del portfolio SAFe® e temi strategici
  • Roadmap di SAFe®
  • Attività cardine ed eventi SAFe®
  • SaFe® Retrospettive e recensioni

Per una panoramica del modo in cui Azure Boards implementa Scrum e Kanban, vedere Informazioni su Sprint, Scrum e gestione dei progetti e About Boards e Kanban.

Nota

Questo articolo è uno dei set di esercitazioni su Scaled Agile Framework® applicabili ad Azure Boards e Azure DevOps Services. La maggior parte delle indicazioni è valida sia per il cloud che per le versioni locali. Tuttavia, alcune delle funzionalità e delle procedure sono specifiche per il cloud o la versione più recente di Azure DevOps Server.

L'immagine seguente illustra come configurare Azure Boards per supportare una gerarchia di team a tre livelli ed eseguire il mapping dei team alle rispettive aree e percorsi di iterazione. Gli esempi di compilazione del processo Agile, tuttavia, possono essere applicate a qualsiasi progetto e processo ospitato in Azure Boards.

Struttura degli strumenti Agile per supportare SAFe®

Gli esempi riportati di seguito illustrano come viene configurata una gerarchia di team a tre livelli usando percorsi di area gerarchici. Gli esempi compilati dal processo Agile, tuttavia, è possibile applicare queste modifiche a qualsiasi progetto ospitato in Azure Boards.

Team agile di funzionalità, programma e portfolio

Azure Boards supporta ogni team per avere una propria visualizzazione del proprio lavoro. Configurando una struttura gerarchica del team, ogni team può concentrarsi sul proprio lavoro e passare al livello successivo all'interno della gerarchia del team.

Mapping dei ruoli SAFe® a una gerarchia di team

Per supportare i team SAFe®, si riconfigura il team predefinito come team portfolio per gestire le epiche. Si creano quindi sottoteam per il lavoro a livello di programma e il lavoro a livello di team. Il lavoro può essere monitorato tra team e in tutti i livelli.

Storie, funzionalità, epiche, abilitanti e funzionalità

Tutti i risultati finali e di lavoro vengono acquisiti negli elementi di lavoro. Ogni elemento di lavoro è associato a un tipo di elemento di lavoro specifico con un flusso di lavoro predefinito. Ogni processo di Azure Boards offre supporto per tipi specifici di elementi di lavoro che è possibile usare per tenere traccia dei risultati finali SAFe®.

I tipi di elemento di lavoro disponibili per l'utente sono basati sul processo usato al momento della creazione del progetto, ovvero Agile, Basic, Scrum o CMMI, come illustrato nelle immagini seguenti.

L'immagine seguente mostra la gerarchia per l'elemento di lavoro del backlog del processo Agile:

  • Le storie utente e le attività vengono usate per tenere traccia del lavoro.

  • I bug tengono traccia dei difetti del codice.

  • Le epiche e le funzionalità vengono usate per raggruppare il lavoro in scenari più grandi.

    Diagramma che mostra i tipi di elemento di lavoro Agile.

Ogni team può configurare la modalità di gestione degli elementi di lavoro bug, allo stesso livello degli elementi di lavoro della storia utente o dell'attività, configurando l'impostazione Utilizzo dei bug . Per altre informazioni sull'uso di questi tipi di elemento di lavoro, vedere Processo Agile.

Gli elementi nel backlog possono essere denominati Problemi relativi alle storie utente (Agile) (Basic), agli elementi backlog del prodotto (Scrum) o ai requisiti (CMMI). Tutti e quattro sono simili: descrivono il valore del cliente da consegnare e il lavoro da completare.

È possibile tenere traccia degli enabler usando storie utente o funzionalità e funzionalità usando funzionalità o epiche. In alternativa, se si hanno esigenze specifiche di rilevamento e creazione di report, è possibile aggiungere tipi di elementi di lavoro personalizzati per tenere traccia di questi tipi di risultati finali. Per altre informazioni, vedere Personalizzare Azure Boards, Aggiungere tipi di elementi di lavoro personalizzati.

Gli elementi di lavoro forniscono supporto per le attività seguenti:

  • Aggiungere descrizione e criteri di accettazione
  • Assegnare a un team o a un percorso di area e a un membro del progetto
  • Aggiornare lo stato e assegnare a un'iterazione o uno sprint
  • Collegare elementi di lavoro, allegare file, aggiungere tag
  • Aggiungere commenti e visualizzare un thread di discussione

I backlog di prodotti e portfolio consentono ai team di aggiungere e classificare rapidamente in ordine di priorità le storie utente, le funzionalità e le epiche. Per altre informazioni sugli elementi di lavoro e sui tipi di elementi di lavoro, vedere Tenere traccia delle storie utente, dei problemi, dei bug, delle funzionalità e delle epiche.

Backlog e bacheche del team

I backlog SAFe® eseguono il mapping ai backlog di team, programma e portfolio. Per impostazione predefinita, il processo Agile supporta i livelli di backlog User Story, Feature e Epic. La struttura di backlog gerarchica mostra il lavoro svolto per supportare funzionalità e storie utente in corso di un'epica.

Backlog gerarchico: epiche, funzionalità e storie

È possibile personalizzare il backlog e le bacheche, anche aggiungendo backlog portfolio, come descritto in Personalizzare Azure Boards, Personalizzare i backlog.

La visualizzazione della bacheca Kanban di ogni backlog è configurabile da ogni team.

Incrementi, versioni e sprint del programma

SaFe® Release Train, Releases, Iterations, Program Increments (PIs) e Sprints vengono mappati facilmente ai percorsi di iterazione. Condividendo le iterazioni nella gerarchia del team, le versioni vengono gestite in modo coesivo.

Mapping dei treni di rilascio SAFe® alle iterazioni

Poiché le epiche possono estendersi su diversi treni di rilascio, il team portfolio non è associato ad alcuna iterazione specifica. I team del programma tengono traccia dei risultati finali delle funzionalità, che vengono forniti con un pi. E i team delle funzionalità lavorano in Sprint per completare diverse storie. Ogni team sceglie le iterazioni che li supportano per tenere traccia del set mirato di risultati finali.

Teams tiene traccia dei risultati finali usando iterazioni

Obiettivi e obiettivi dell'iterazione

Le procedure SAFe® includono team di rilascio Agile che definiscono gli obiettivi e gli obiettivi dell'iterazione. È consigliabile usare il wiki del progetto o i dashboard del team per acquisire informazioni sul team. Il wiki del progetto e i dashboard del team supportano sia Markdown per aggiungere informazioni sul formato.

Per altre informazioni, vedere Condividere informazioni più avanti in questo articolo.

Flussi di valore e budget

È possibile usare i tag per un modo rapido e semplice per eseguire il mapping delle funzionalità e delle epiche al relativo valore Flussi, temi strategici e budget associati. È possibile aggiungere campi personalizzati per acquisire stime del budget per le funzionalità che possono quindi essere implementate in Epics.

I tag possono tenere traccia dei flussi di valori o dei budget associati

Con i tag aggiunti agli elementi di lavoro, è possibile:

  • Filtrare qualsiasi backlog o scheda Kanban
  • Creare query basate su tag e filtrare i risultati delle query in base ai tag
  • Creare grafici o report di avanzamento e tendenza in base ai tag

Per un mapping più affidabile dell'architettura o delle funzionalità aziendali, è possibile specificare l'area valore per ogni epica, caratteristica o storia.

Value Area tiene traccia delle attività aziendali o dell'architettura

Con il rollup, è possibile ottenere stime del budget per epiche da un rollup delle stime definite nelle funzionalità figlio, come illustrato nell'immagine seguente.

Rollup della stima del budget

Per aggiungere campi personalizzati, vedere Personalizzare Azure Boards, Aggiungere un campo personalizzato.

Usare il wiki del progetto per supportare la visione del portfolio e i temi strategici

Le informazioni possono essere ampiamente condivise con un'organizzazione usando il wiki del progetto Azure DevOps. Il wiki è simile a un repository Git che supporta l'aggiunta e la modifica di pagine tramite Markdown e un editor WYSIWYG. Esegue le versioni di ogni pagina in modo che sia facile tenere traccia di chi ha apportato modifiche e recuperare le versioni precedenti.

Usare il wiki del progetto per supportare la condivisione degli artefatti SAFe® seguenti:

  • Visione portfolio
  • Temi strategici
  • Tassonomia
  • Obiettivi
  • Obiettivi
  • Procedure incentrate sui clienti

Per altre informazioni sul wiki del progetto, vedere Condividere informazioni più avanti in questo articolo.

Attività cardine ed eventi chiave

La fine di ogni incremento del programma, sprint, training di rilascio o iterazione IP (Innovation and Planning) rappresenta le attività cardine SAFe® naturali. Molte attività cardine sono associate a cerimonie o pratiche specifiche, ad esempio l'esecuzione di analisi retrospettive o la dimostrazione di software funzionante.

In Azure Boards è possibile tenere traccia di altri tipi di attività cardine o eventi chiave nei modi seguenti.

  • Campo personalizzato, ad esempio Campo cardine o Rilascio con elenco a discesa predefinito
  • Come tag aggiunto agli elementi di lavoro
  • Come elemento di lavoro che specifica una data di destinazione
  • Come percorso di iterazione di un giorno

Con i campi e i tag personalizzati, è possibile filtrare rapidamente backlog, bacheche e query in base a un'attività cardine specifica.

Struttura del team dei servizi condivisi

Le risorse condivise tra i team possono essere rappresentate tramite il proprio team di funzionalità Agile, ad esempio un team di progettazione dell'esperienza utente o un team di conformità alla sicurezza. Possono gestire il backlog mentre il lavoro viene visualizzato anche nei backlog dei team supportati.

Di seguito viene illustrato il modo in cui i percorsi di area vengono assegnati al team di progettazione dell'esperienza utente e quindi percorsi secondari selettivi ad altri team Agile. Gli elementi di lavoro visualizzati nei percorsi di area condivisa vengono visualizzati nei backlog e nelle bacheche dei team associati.

Percorso dell'area dei servizi condivisi e struttura del team

Retrospettive e recensioni

Per supportare i team che eseguono analisi retrospettive, è consigliabile usare l'estensione Retrospettive di Microsoft DevLabs.

Scheda retrospettiva

Questa estensione consente ai team di creare le proprie bacheche retrospettive e di acquisire le attività seguenti:

  • Raccogliere commenti e suggerimenti sulle attività cardine del progetto
  • Organizzare e classificare in ordine di priorità il feedback
  • Creare e tenere traccia delle attività eseguibili per aiutare ogni team nei processi di miglioramento.

Condividere informazioni

Azure Boards offre molti modi per condividere informazioni.

  • I moduli degli elementi di lavoro forniscono campi RTF per acquisire descrizioni, criteri di accettazione e altro ancora. Gli allegati di file possono essere aggiunti agli elementi di lavoro o ai collegamenti alle condivisioni file di rete.
  • I dashboard di progetto e team possono essere usati per condividere informazioni insieme a grafici di stato e stato e widget. Per altre informazioni, vedere Aggiungere Markdown a un dashboard.
  • Il wiki di Project fornisce un repository centrale con il controllo delle versioni predefinito per condividere informazioni con tutti i membri del progetto. È possibile creare altri wiki in base alle esigenze. Per altre informazioni, vedere Informazioni su Wiki, READMEs e Markdown.

Per informazioni dettagliate sulle funzionalità markdown supportate, vedere gli articoli seguenti.

Passaggi successivi

Impostazioni cultura e scalabilità