Condividi tramite


Implementare Un framework® Agile con scalabilità orizzontale in Azure Boards

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

Molte aziende traggono vantaggio dai singoli team Agile. Maggiore interesse aumenta per ridimensionare le procedure Agile man mano che l'organizzazione cresce. La necessità per le aziende di visualizzare lo stato di avanzamento di molti team Agile e in un portfolio continua ad aumentare. Per soddisfare queste esigenze, molte aziende hanno adottato scaled Agile Framework® (SAFe®).

Se si ha familiarità con Scrum ma non si ha familiarità con SAFe®, vedere SAFe Studio Framework.

Azure Boards supporta le procedure SAFe® tramite team autonomi, backlog, bacheche, report e metriche. Questo articolo illustra come gli artefatti di Azure Boards supportano procedure e artefatti SAFe.

  • Framework Agile® con scalabilità orizzontale
  • SaFe® essenziale
  • SaFe® portfolio
  • SAFe® per soluzioni di grandi dimensioni
  • Mapping di riferimento rapido
  • Implementazione di Azure Boards di SAFe®

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.

Framework® Agile con scalabilità orizzontale

La SAFe® affronta il modo in cui una visione portfolio viene soddisfatta da una gerarchia di team, tutti interessati da obiettivi specifici. Questo framework suddivide epiche in Funzionalità e storie. Teams lavora su questi elementi negli sprint e distribuisce tramite incrementi di programma (PI) e release train. Inoltre, il backlog portfolio può tenere traccia dei risultati finali che eseguono il mapping ai flussi di valore e ai budget associati.

Panoramica dell'architettura SAFe® versione 5.0

Panoramica dell'architettura SAFe® versione 5 © D. Leffingwell

Riprodotto con l'autorizzazione © 2011-2020 Scaled Agile Inc.. Tutti i diritti sono riservati.

SAFe® e Scaled Agile Framework sono marchi registrati di Scaled Agile Inc.

SAFe® 5.0 Business Agility

Molte procedure SAFe® includono la crescita di una cultura che supporta agilità, allineamento e autonomia, tutto mentre è incentrato sul cliente.

Panoramica di SAFe® 5.0 © D. Leffingwell

Riprodotto con l'autorizzazione © 2011-2020 Scaled Agile Inc.. Tutti i diritti sono riservati.

Ecco alcuni dei modi in cui Azure Boards supporta l'agilità aziendale e le impostazioni cultura agile negli articoli seguenti:

SaFe® essenziale

Essential SAFe® richiede il supporto per gli artefatti e le procedure illustrate nel poster seguente.

Panoramica dell'architettura © del poster SAFe® essenziale D. Leffingwell

Riprodotto con l'autorizzazione © 2011-2020 Scaled Agile Inc.. Tutti i diritti sono riservati.

Tutti questi elementi e procedure sono supportati da Azure Boards.

  • Storie, funzionalità e abilitanti: implementati come elementi di lavoro che acquisisce informazioni e stato del lavoro. Questi elementi di lavoro vengono visualizzati automaticamente nei backlog e nelle bacheche del team.
  • Backlog del team e backlog del programma: implementati come backlog del team che filtrano gli elementi di lavoro assegnati a un team e supportano la definizione delle priorità e il raggruppamento del lavoro.
  • Scrum e Kanban: procedure completamente supportate tramite bacheche, backlog sprint e taskboard, team e cadenza sprint.
  • Iterazioni, iterazioni, innovazione e pianificazione (IP), incrementi di programma (PI), attività cardine e rilascio: implementati tramite un elenco semplice o una configurazione gerarchica dei percorsi di iterazione.
  • Agile Release Train: implementato da un set di team Agile e team del programma configurati per supportare visualizzazioni specifiche del team e del programma.
  • Obiettivi PI, obiettivi del team e contesto della soluzione: Teams può usare il wiki predefinito del progetto per condividere obiettivi, obiettivi, informazioni sui clienti e requisiti della soluzione.

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.

SaFe® portfolio

Portfolio SAFe® aggiunge il supporto per la gestione dei portfolio tramite epiche, abilitanti e flussi di valore.

Panoramica dell'architettura © del poster SAFe® portfolio D. Leffingwell

Riprodotto con l'autorizzazione © 2011-2020 Scaled Agile Inc.. Tutti i diritti sono riservati.

Azure Boards offre supporto per i componenti di portfolio seguenti:

  • Epiche: eseguire il mapping al tipo di elemento di lavoro Epic e consentire il rilevamento, il raggruppamento e il rollup degli elementi figlio.
  • Backlog portfolio: implementato come backlog portfolio che supporta il filtro del lavoro in base alla revisione delle esigenze aziendali.
  • Visione portfolio e temi strategici: i proprietari aziendali e i gestori di portfolio possono usare il wiki predefinito del progetto per condividere la propria visione, obiettivi e obiettivi.
  • Flussi valore: i flussi valore possono essere rilevati usando tag o campi personalizzati.
  • Budget snella: le informazioni sul budget possono essere acquisite in campi personalizzati e distribuite per ottenere visibilità sui livelli Funzionalità e Epic.
  • Indicatori KPI: diversi report e widget del dashboard forniscono metriche predefinite. Power BI e il servizio Analisi forniscono supporto per creare rapidamente report personalizzati.

SAFe® per soluzioni di grandi dimensioni

SaFe® di soluzioni di grandi dimensioni include il supporto per un backlog della soluzione, i training delle soluzioni e le funzionalità.

Panoramica dell'architettura dell'architettura © SAFe® di grandi soluzioni D. Leffingwell
Riprodotto con l'autorizzazione © 2011-2020 Scaled Agile Inc.. Tutti i diritti sono riservati.

È possibile implementare soluzioni di grandi dimensioni nello stesso modo in cui si implementa Portfolio SAFe®. Tuttavia, è anche possibile aggiungere tipi di elementi di lavoro personalizzati e backlog personalizzati per supportare altri requisiti della soluzione.

SaFe® completo

SaFe® completo include i tre livelli di Essential SAFe®, Large Solution SAFe e Portfolio SAFe®®.

Panoramica dell'architettura © del poster SAFe® completo D. Leffingwell

Mapping degli artefatti SAFe® ad Azure Boards

La tabella seguente esegue il mapping di termini o artefatti SAFe® al termine o all'artefatto di Azure Boards equivalente. Scegliere il collegamento per informazioni sui dettagli di implementazione.

Termine o artefatto SAFe®

Termine o artefatto di Azure Boards

Team Agile

Teams. Si definisce una gerarchia di team per soddisfare le esigenze dei team di sviluppo, dei team di sviluppo, del programma e del portfolio o dei team di training delle soluzioni.

Agile Release Train (ART)

Teams. I team Agile gestiscono il lavoro dei risultati finali per un set di funzionalità. Ogni team Agile ha un set di strumenti Agile per supportare il flusso di lavoro e rivedere lo stato di avanzamento e i risultati finali.

Budget

Tag, Area valore. È possibile usare tag o il campo Area valore per tenere traccia del lavoro associato a un flusso di budget o valore specifico.

Funzionalità

Elemento di lavoro. È possibile definire, pianificare e tenere traccia delle funzionalità simili alle epiche e alle funzionalità. Le acquisisci negli elementi di lavoro e nei vari backlog del team.

Componenti principali

Elemento di lavoro. È possibile definire, pianificare e tenere traccia di abilitanti simili a Epics, Features e Stories. Le acquisisci negli elementi di lavoro e nei vari backlog del team.

Epiche

Elemento di lavoro epico. Si definisce un'epica usando il tipo di elemento di lavoro Epic. Le epiche si trovano nella parte superiore della gerarchia degli elementi di lavoro di Epiche, Funzionalità e Storie.

Funzionalità

Elemento di lavoro funzionalità. Si definisce una funzionalità usando il tipo di elemento di lavoro Funzionalità. Le funzionalità sono un contenitore per molte storie e sono rappresentate nel proprio backlog del portfolio.

Iterazione innovazione e pianificazione (IP)

Percorso iterazione. Si definiscono percorsi di iterazione per un progetto e si impostano le date di inizio e di fine. Ogni team sottoscrive le iterazioni con cui lavora.

Iterazione

Percorso iterazione. Si definiscono percorsi di iterazione per un progetto e si impostano le date di inizio e di fine. Ogni team sottoscrive le iterazioni con cui lavora.

Passaggi fondamentali

Attività cardine ed eventi chiave. Le attività cardine vengono eseguite alla fine di ogni iterazione. I campi e i tag personalizzati possono essere usati anche per associare attività cardine ed eventi chiave.

Portfolio Backlog

Backlog portfolio. Un backlog portfolio elenca le epiche associate a un portfolio con l'opzione per espandere e visualizzare le funzionalità e le storie figlio.

Portfolio Kanban

Scheda Epiche portfolio. La scheda del team portfolio visualizza il backlog Epics come schede in una scheda interattiva, configurabile e filtrabile.

Visione portfolio

Wiki. Usare il wiki del progetto per condividere in modo ampio all'interno delle informazioni dell'organizzazione correlate a strategia, soluzioni e come i team collaborano per produrre risultati finali di portfolio e programma.

Backlog del programma

Backlog delle funzionalità. Un backlog funzionalità elenca le funzionalità associate a un programma con l'opzione per espandere e visualizzare le storie figlio.

Programma Kanban

Scheda Funzionalità programma. La scheda Programmi visualizza il backlog Funzionalità come schede in una scheda interattiva, configurabile e filtrabile.

Percorso di iterazione dell'incremento del programma

Percorso iterazione. I percorsi di iterazione definiscono una casella di tempo per un progetto con date di inizio e di fine. I percorsi di iterazione possono essere definiti da una settimana a 12 settimane o più.

Retrospettive e recensioni

Retrospettive. Ogni team può aggiungere una bacheca per acquisire, classificare in ordine di priorità e creare elementi di azione per supportare i processi di miglioramento.

Roadmap

Piani di recapito, Sequenza temporale delle funzionalità. Azure Boards offre visualizzazioni configurabili e interattive per esaminare le roadmap e i risultati finali del team.

Servizi condivisi

Struttura del team dei servizi condivisi: le risorse condivise tra i team possono essere rappresentate tramite il proprio team di funzionalità Agile. Ognuno può gestire il backlog mentre il proprio lavoro viene visualizzato anche nei backlog dei team supportati.

Soluzioni

Soluzioni: le soluzioni possono essere rappresentate tramite un tipo di elemento di lavoro della soluzione personalizzato.

Backlog della soluzione

Backlog del portfolio di soluzioni. È possibile definire un tipo di elemento di lavoro personalizzato e un backlog portfolio per acquisire requisiti aziendali speciali di soluzioni di grandi dimensioni o usare backlog epici e portfolio epici per acquisire soluzioni.

Temi strategici

Wiki. I temi strategici, simili a Visione portfolio, possono essere acquisiti in un wiki del progetto.

Storie

Elemento di lavoro Storia utente. Le storie utente acquisiscino le funzionalità che vuoi distribuire. In genere vengono ridimensionate in modo da essere completate con una singola iterazione.

Team Backlog

Backlog storie. Il backlog Stories elenca le storie utente assegnate al percorso di area associato al team.

Team Kanban

Bacheca storie. La scheda Storie visualizza il backlog Stories come schede in una scheda interattiva, configurabile e filtrabile.

Flussi valore

Tag, Area valore. È possibile usare tag o il campo Area valore per tenere traccia del lavoro associato a un flusso di budget o valore specifico.

Implementazione di Azure Boards di SAFe®

Ognuno degli articoli seguenti all'interno di questa suite di esercitazioni fornisce informazioni dettagliate su come configurare, personalizzare e usare Azure Boards per implementare programmi e progetti SAFe®.

Passaggi successivi

Informazioni sugli autori

Molti grazie ai collaboratori seguenti per la revisione e il feedback al contenuto corrente.

  • Phillip Eng è senior architect presso Microsoft, Digital Pursuit and Guidance.
  • Hosam Kamel è un professionista della soluzione tecnologica per Microsoft e ALM Ranger.
  • Willy-Peter Schaub è un ex program manager con Visual Studio ALM Rangers presso il Microsoft Canada Development Center. È possibile seguire Willy-Peter su Twitter all'indirizzo twitter.com/wpschaub.

Gli articoli di questa serie sono stati aggiornati da un white paper precedente sviluppato in collaborazione con gli autori seguenti:

  • Gordon Beeming è uno sviluppatore software di Derivco nella città soleggiata di Durban, Sudafrica. Passa la maggior parte del suo tempo alla tastiera in Visual Studio o con la sua famiglia rilassante. Il suo blog è a gordonbeeming.xyz e puoi seguirlo su Twitter a twitter.com/gordonbeeming.
  • Brian Blackman è un consulente principale con Microsoft Premier Developer, concentrandosi sull'impatto sui partner ISV e sul successo delle aziende nella progettazione e nel marketplace. Ha un MBA ed è un CSM, CSP, MCSD (C++) e MCTS ed è un Ranger ALM di Visual Studio. Quando non è Ruck Mastering e contribuisce ai progetti di Visual Studio ALM Ranger, dedica tempo alla scrittura di codice, alla creazione e alla distribuzione di workshop e alla consulenza in varie concentrazioni, in particolare aiutando le organizzazioni nella ricerca dell'agilità aziendale.
  • Gregg Kubernetes è un principal program manager di Microsoft. Gregg è il proprietario del prodotto per l'esperienza di gestione Agile fornita da Azure DevOps e TFS locale.
  • Kathryn Elliott è uno scrittore tecnico senior di Microsoft.
  • Susan Ferrell è un senior technical writer e un Visual Studio ALM Ranger.
  • Willy-Peter Schaub è un ex program manager con Visual Studio ALM Rangers presso il Microsoft Canada Development Center. Dalla metà degli anni '80, si impegna per semplicità e manutenibilità nell'ingegneria del software. Puoi seguirlo su Twitter a twitter.com/wpschaub.
  • Grazie speciali ai seguenti esperti tecnici per la revisione di questo articolo: Mike Douglas (consulente indipendente, ALM Ranger), Richard Hundhausen (consulente indipendente, ALM Ranger) e Bill Heys (consulente indipendente, ALM Ranger).