Configurare Azure Boards per supportare programmi e portfolio SAFe®
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Questa esercitazione illustra i passaggi per convertire un nuovo progetto con un singolo team in uno configurato per supportare programmi e portfolio di Scaled Agile Framework (SAFe®). In particolare, si apprenderà come configurare Azure Boards per supportare programmi e portfolio SAFe® completando le attività seguenti:
- Definire team Agile, programma e portfolio
- Configurare una gerarchia di percorsi di area per supportare i team
- Definire i percorsi di iterazione per supportare i training di rilascio SAFe®, le api, gli sprint e gli indirizzi IP
- Configurare ogni team per supportare SAFe®
Per eseguire queste configurazioni, è necessario essere membri del gruppo Project Amministrazione istrators.
Dopo aver completato queste configurazioni di base, è possibile valutare la possibilità di personalizzare il progetto per supportare esigenze aziendali specifiche. Le opzioni di personalizzazione vengono risolte in Personalizzare Azure Boards per supportare SAFe® .
Suggerimento
Se si prevede di aggiungere tipi di elementi di lavoro personalizzati, backlog del portfolio o flussi di lavoro; è consigliabile creare prima tali personalizzazioni e quindi definire e configurare i team.
Se non si ha familiarità con Azure Boards, prima di aggiungere e configurare i team è consigliabile vedere Informazioni sui team e sugli strumenti Agile e percorsi di iterazione (sprint). Inoltre, due articoli eccellenti per esaminare la struttura del team e la cultura Agile sono Introduzione alla pianificazione di carichi di lavoro efficienti con DevOps e Building productive, team incentrati sui clienti.
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.
Informazioni sulla gerarchia del team
In questo articolo si passerà dalla presenza di un progetto e di un team, entrambi denominati "Fabrikam", al set seguente di nove team.
Nota
Azure Boards non supporta una gerarchia di team. Tuttavia, configurando i percorsi di area come indicato in questo articolo, si crea in modo efficace un tipo di gerarchia del team. La gerarchia viene definita tramite la struttura dei percorsi di area.
Si configurerà quindi il percorso dell'area alla gerarchia seguente e si configurerà il percorso dell'area di ogni team. Questa configurazione supporta la visualizzazione backlog di ogni team e il rollup delle visualizzazioni all'interno della gerarchia.
Suggerimento
Se si dispone di un numero elevato di team, percorsi di area e iterazioni da aggiungere, è possibile usare la riga di comando o gli strumenti a livello di codice. Vedere la riga di comando e gli strumenti programmatici forniti più avanti in questo articolo.
Tutti i team possono gestire il proprio carico di lavoro e le proprie priorità, comprendendo chiaramente il modo in cui supportano tali epiche gestite nel backlog del team del portfolio. Allo stesso tempo, il team del portfolio può monitorare lo stato di avanzamento del backlog nella propria scheda Kanban, classificare in ordine di priorità gli elementi nel backlog e visualizzare lo stato di avanzamento tra i treni di rilascio.
Anche se l'esempio precedente può sembrare complicato, in realtà ci vuole poco configurazione per configurare i team e iniziare. Per passare da un progetto con un team predefinito, definire prima di tutto ogni team durante la creazione automatica di un percorso di area predefinito per tale team. Riconfigurare quindi il set flat di percorsi di area in una struttura gerarchica. Definire quindi i percorsi di iterazione per supportare la struttura di versione desiderata e i team di programma e Agile da usare. Infine, configurare ogni team e popolare l'appartenenza dei team.
Definire i team
Per iniziare, si aggiungerà ogni team, creando un percorso di area predefinito per ognuno. Più avanti in questo articolo verranno configurati i percorsi di area nella gerarchia necessaria. Questa struttura esegue il mapping dei team SAFe® seguenti ai team di Azure Boards:
- Team portfolio:> team di primo livello predefinito, team Fabrikam (già definito)
- Team di programma :> team di livello secondario, Fiber Suite e Service Suite
- Team Agile:> team di livello terziario definiti in Fiber Suite e Service Suite.
Per completare questi passaggi, sarà necessario essere un amministratore del progetto. Se sono necessarie indicazioni più dettagliate, vedere Gestione portfolio.
Aggiungere ogni team, uno alla sola.
Nota
La procedura seguente usa l'interfaccia utente nuova pagina di Teams disponibile in anteprima. Per abilitare questa funzionalità, vedere Gestire o abilitare le funzionalità.
Nel portale Web scegliere Impostazioni progetto e aprire Teams.
Scegliere Nuovo team.
Assegnare un nome al team e facoltativamente una descrizione.
Qui si aggiunge il team dell'app. Scegliere l'amministratore del team e verificare che la casella di controllo Crea un percorso di area con il nome del team sia selezionata. Facoltativamente, aggiungere membri del team.
Assegnare al team Scrum Master, Program Manager o Portfolio Manager come amministratore del team. Gli amministratori del team possono configurare gli strumenti del team per supportare le procedure Agile e le esigenze aziendali.
Ripetere i passaggi 2 e 3 per definire tutti i team.
Facoltativo. Se si hanno due o più team portfolio, creare un team per ognuno di essi.
Configurare i percorsi di area
Per supportare la gerarchia del team, si configureranno ora i percorsi di area creati nel primo passaggio della definizione dei team in una gerarchia.
Nella pagina Project Impostazioni scegliere Configurazione progetto e quindi Aree. Verrà visualizzato un elenco semplice di percorsi di area.
È necessario scegliere il percorso area di ogni team di funzionalità sotto il percorso area superiore e spostarlo nella gerarchia Percorso area a cui appartiene.
È possibile trascinare e rilasciare ogni percorso dell'area nel nodo padre a cui appartiene. Ad esempio, qui si trascina il nodo Migrate nel nodo Fiber Suite.
È invece possibile aprire il menu di scelta rapida per Il percorso area, scegliere Modifica e selezionare il nodo in cui si vuole spostarlo.
Ripetere il passaggio 2 e 3 per i percorsi rimanenti dell'area del team Agile.
Se sono stati definiti due o più team di portfolio, è necessario modificare il percorso dell'area di ogni team del programma nel percorso dell'area del team di portfolio corrispondente.
Al termine, la struttura del percorso dell'area dovrebbe essere simile all'immagine seguente.
Importante
Questa struttura mostra che i percorsi di area sono di proprietà di team Agile, team del programma e team del portfolio. Questa struttura verrà corretta più avanti in questo articolo quando si configura ogni team come unico proprietario del percorso dell'area.
Definire i percorsi di iterazione
Per tenere traccia dello stato di avanzamento verso Versioni, creare la struttura del percorso di iterazione. A differenza dei percorsi di area, più team possono condividere la stessa struttura del percorso di iterazione. La condivisione della struttura di iterazione consente a più team di lavorare nello stesso sprint cadenza verso gli stessi treni di rilascio.
Importante
L'eliminazione, la ridenominazione o lo spostamento di percorsi di iterazione causano una perdita di dati cronologici associati.
Se sono già presenti iterazioni per il team predefinito, è possibile rinominarle. Si vuole creare una struttura di iterazione che supporti l'intera struttura del team, non solo un team.
Nella pagina Project Impostazioni scegliere Configurazione progetto e quindi Iterazioni.
Nell'iterazione predefinita, che condivide lo stesso nome del progetto, creare un'iterazione figlio che rappresenta il primo incremento del programma. Facoltativamente, aggiungere una data di inizio e di fine per il PI, ma tenere presente che l'iterazione viene suddivisa ulteriormente in sprint.
Creare quindi un'iterazione figlio per ogni sprint all'interno del pi. Impostare le date per questi sprint in modo che corrispondano alle cadenza dei team Agile.
Continuare ad aggiungere tutte le iterazioni necessarie per soddisfare la struttura di cadenza della casella temporale per tutti i team.
Al termine, dovrebbe essere presente una struttura simile all'immagine seguente.
Suggerimento
È possibile trascinare e rilasciare Percorsi di iterazione per strutturare le iterazioni, come illustrato nel passaggio 2 in Configura percorsi di area. Azure Boards elenca sempre i percorsi di iterazione in ordine di date in ogni nodo padre.
Configurare i team
Ora che i team, i percorsi di area e i percorsi di iterazione sono definiti, il passaggio successivo consiste nel configurare ogni team. È necessario configurare le impostazioni seguenti per ogni team.
- Backlog attivi
- Uso dei bug
- Impostare il percorso di iterazione predefinito
- Selezionare percorsi di iterazione del team
Nella tabella seguente sono elencate le impostazioni consigliate da apportare in base al livello del team.
Configurare
Team delle funzionalità Agile
Team del programma
Team portfolio
Livelli di spostamento backlog
Caratteristiche, Storie
Caratteristiche, Storie
Epiche
Uso dei bug
I bug vengono gestiti con i requisiti
I bug non vengono gestiti nei backlog e nelle bacheche
I bug non vengono gestiti nei backlog e nelle bacheche
Iterazione predefinita
@CurrentIteration
@CurrentIteration
@CurrentIteration
Iterazione backlog
Fabrikam
Fabrikam
Fabrikam
Iterazioni selezionate
Sprint 1 thru Sprint 4, IP Sprint
PI 1, PI 2, PI 3
None
Aree
Includi aree secondarie
Escludere le aree secondarie
Escludere le aree secondarie
Nota
Impostando l'iterazione predefinita su @CurrentIteration, tutti gli elementi di lavoro creati dal backlog o dalla lavagna del team vengono assegnati all'iterazione corrente in base alla data corrente. Impostando l'iterazione backlog sulla radice, Fabrikam indica che solo il percorso area funge da filtro per visualizzare gli elementi di lavoro nei backlog e nelle bacheche del team.
Nella pagina Impostazioni progetto scegliere Configurazione team.
Scegliere il team da configurare dal selettore Team.
Nella pagina Generale deselezionare i backlog che non si desidera essere attivi.
Ad esempio, per il team portfolio, selezionare solo la casella di controllo Epics .
Per i team di programma e Agile, deselezionare la casella di controllo Epics .
Per i team di programma e portfolio, scegliere il pulsante di opzione Uso dei bug come illustrato.
Inoltre, per i team Agile, scegliere l'opzione Uso dei bug per tenere traccia dei bug insieme ai requisiti.
Scegliere la scheda Iterazioni per configurare le iterazioni del team.
Per i team Agile, configurare le impostazioni come illustrato.
Per i team del programma, scegliere solo le iterazioni PI.
Per i team di programma e portfolio, scegliere la scheda Aree per modificare l'impostazione predefinita da Includi aree secondarie in Escludi aree secondarie.
Aprire il
menu di scelta rapida e scegliere Escludi aree secondarie.
Nota
Poiché ogni team è stato creato con il percorso Crea un'area con il nome del team selezionato, ogni team è già preconfigurato con il percorso dell'area predefinito. Questo percorso area funge da filtro principale per gli elementi di lavoro visualizzati nei backlog e nelle bacheche di ogni team.
Ripetere i passaggi da 2 a 5 in base alle esigenze per ogni team che è necessario configurare.
Dopo aver completato il passaggio 5 per tutti i team, verificare la struttura Area Path-Team. Scegliere Configurazione progetto e Aree. Il percorso area e la struttura del team dovrebbero ora essere visualizzati come illustrato, in cui ogni team è proprietario del percorso area e non lo condivide con altri team.
Configurare i team per supportare i servizi condivisi
Per i team che supportano diversi altri team, ad esempio un team di progettazione dell'esperienza utente, configurare i team come descritto nei passaggi seguenti.
Aggiungere un team per ogni team di Servizi condivisi. Per informazioni dettagliate, vedere Definire i team.
Tornare alla pagina Percorsi area di configurazione>progetto e in ogni percorso dell'area dei servizi condivisi aggiungere percorsi di area secondaria per ogni team Agile supportato dai servizi condivisi. Per altre informazioni, vedere Configurare percorsi di area forniti in precedenza in questo articolo.
Ad esempio, qui vengono aggiunti quattro percorsi di area secondaria nel percorso dell'area UX Design, uno per ogni team Agile supportato dal team di progettazione dell'esperienza utente.
Configurare ogni team di Servizi condivisi come team di funzionalità Agile come descritto in Configurare i team.
Per ogni team Agile, aprire la pagina Aree di configurazione>del team, come illustrato nel passaggio 5 di Configurare i team. Scegliere Seleziona aree e aggiungere il percorso dell'area secondaria per il team.
Qui aggiungiamo il percorso dell'area secondaria UX Design\App al team delle funzionalità dell'app.
Tornare alla pagina Percorsi area di configurazione>progetto e verificare che la struttura Percorso area sia visualizzata come previsto per ogni percorso dell'area Servizi condivisi.
Per il team di progettazione dell'esperienza utente, la struttura dovrebbe essere visualizzata come illustrato.
Gli elementi di lavoro visualizzati nei percorsi di area condivisa vengono visualizzati nei backlog e nelle bacheche dei team associati.
Strumenti da riga di comando e programmatici
È possibile usare gli strumenti da riga di comando di Azure DevOps per aggiungere o aggiornare gli elementi seguenti:
- Teams: creazione del team di Azure DevOps
- Percorsi di area: creazione di un progetto di area di Azure DevOps
- Percorsi di iterazione: creazione del progetto di iterazione di Azure DevOps
Usare gli strumenti programmatici
È possibile usare le API REST di Azure DevOps per aggiungere o aggiornare gli artefatti seguenti:
- Teams: Teams (API REST)
- Percorsi di area: nodi di classificazione (API REST)
- Percorsi di iterazione: nodi di classificazione (API REST)
Passaggi successivi
Articoli correlati
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