Mapping dei concetti di SAFe® agli artefatti Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018
Se si è interessati a usare Scaled Agile Framework (SAFe®), è possibile configurare il progetto di Azure Boards per tenere traccia dei risultati finali 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 su versioni.
Questa esercitazione illustra il mapping degli artefatti SAFe® seguenti a elementi Azure Boards specifici.
- TEAM SAFe® Agile, program e portfolio
- Risultati finali SAFe®, ad esempio 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
- SaFe® Portfolio Vision and Strategic Themes
- Roadmap SAFe®
- Attività cardine ed eventi SAFe®
- Analisi retrospettive e recensioni di SAFe®
Per una panoramica di come Azure Boards implementa Scrum e Kanban, vedere Informazioni su Sprint, Scrum e gestione dei progettie About Boards e Kanban.
Nota
Questo articolo è uno di un set di esercitazioni su Agile Framework® con scalabilità applicata a Azure Boards e Azure DevOps Services. La maggior parte delle linee guida è 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.
Gli esempi riportati di seguito illustrano come viene configurata una gerarchia di team a tre livelli usando percorsi di area gerarchici. Gli esempi di compilazione del processo Agile, tuttavia, è possibile applicare queste modifiche a qualsiasi progetto ospitato in Azure Boards.
Team agile di funzionalità, programmi e portfolio
Azure Boards supporta ogni team per visualizzare il proprio lavoro. Configurando una struttura gerarchica del team, ogni team può concentrarsi sul proprio lavoro e impostare il proprio lavoro fino al livello successivo all'interno della gerarchia del 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 i team e in tutti i livelli.
Storie, funzionalità, epiche, abilitanti e funzionalità
Tutte le operazioni e i risultati finali 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 fornisce supporto per tipi di elementi di lavoro specifici 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 quando è stato creato il progetto, Agile, Basic, Scrum o CMMI, come illustrato nelle immagini seguenti.
L'immagine seguente mostra la gerarchia dell'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 e epiche e funzionalità vengono usati per raggruppare il lavoro in scenari più grandi.
Ogni team può configurare la modalità di gestione dei bug, allo stesso livello delle storie utente o delle attività, configurando l'impostazione Uso 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 di Storie utente ( Agile) (Basic), Elementi backlog del prodotto (Scrum) o 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 elemento 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 assegnarlo a un'iterazione o a 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 dell'uso di storie utente, problemi, bug, funzionalità ed epiche.
Backlog e bacheche del team
I backlog SAFe® eseguono il mapping ai backlog del team, del programma e del portfolio. Per impostazione predefinita, il processo Agile supporta i livelli di backlog User Story, Feature e Epic. La struttura del backlog gerarchico mostra il lavoro svolto per supportare funzionalità e storie utente in corso di un'epica.
È 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 esegue facilmente il mapping ai percorsi di iterazione. Condividendo le iterazioni nella gerarchia di team, è possibile gestire i rilasci in modo coerente.
Poiché le epiche possono estendersi su diversi treni di rilascio, il team portfolio non è associato ad iterazioni specifiche. I team program tengono traccia dei risultati finali della feature forniti con PI. E i team di funzionalità lavorano in Sprint per completare diverse storie. Ogni team sceglie quali iterazioni supporteranno per tenere traccia del set mirato di risultati finali.
Obiettivi e obiettivi dell'iterazione
Le procedure SAFe® includono i 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 e formattare le informazioni.
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 ai flussi di valore, ai temi strategici e ai budget associati. È possibile aggiungere campi personalizzati per acquisire stime del budget per le funzionalità che possono quindi essere rollup in Epics.
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 di avanzamento e tendenza o report 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.
Con il rollup è possibile ottenere stime del budget per epiche da un rollup delle stime definite nelle funzionalità figlio, come illustrato nell'immagine seguente.
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 usando Markdown e un editor WYSIWYG. Esegue la versione di ogni pagina in modo che sia facile tenere traccia degli utenti che hanno apportato modifiche e ripristinare 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 di 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 di sottoarea 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.
Retrospettive e recensioni
Per supportare i team che eseguono analisi retrospettive, è consigliabile usare l'estensione Retrospettiva di Microsoft DevLabs.
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. Altri wiki possono essere creati 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.
- Indicazioni sulla sintassi per l'utilizzo di Markdown in Wiki
- Indicazioni sulla sintassi per l'utilizzo di markdown di base