Implementare scaled Agile Framework® in Azure Boards

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

Molte aziende possono trarre vantaggio da singoli team Agile. Maggiore interesse aumenta per ridimensionare le procedure Agile man mano che l'organizzazione aumenta. 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®, questi video in Scaled Agile sono un buon modo per orientarsi.

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

  • Framework Agile® con scalabilità orizzontale
  • SaFe® essenziale
  • Portfolio SAFe®
  • SaFe® di soluzioni di grandi dimensioni
  • Mapping rapido dei riferimenti
  • Azure Boards'implementazione di SAFe®

Nota

Questo articolo è uno dei set di esercitazioni di Scaled Agile Framework® che si applicano 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 del cloud o della versione più recente di Azure DevOps Server.

Framework® Agile con scalabilità orizzontale

La SAFe® illustra come una visione del portfolio viene soddisfatta da una gerarchia di team, tutti interessati a obiettivi specifici. Questo framework suddivide Epics in Funzionalità e storie. I team lavorano su questi elementi in Sprint e forniscono tramite Incrementi di programma (PI) e Release Training. Inoltre, il backlog del portfolio può tenere traccia dei risultati finali che vengono mappati 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 dal © 2011 al 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 l'agilità, l'allineamento e l'autonomia, tutto mentre è incentrato sul cliente.

Panoramica saFe® 5.0 © D. Leffingwell

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

Alcuni dei modi in cui Azure Boards supportano l'agilità aziendale e le impostazioni cultura agile sono illustrati 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 dal © 2011 al 2020 Scaled Agile Inc.. Tutti i diritti sono riservati.

Tutti questi artefatti e procedure sono supportati da Azure Boards.

  • Storie, funzionalità e abilitanti: implementati come elementi di lavoro che acquisiscono informazioni e stato del lavoro. Questi elementi di lavoro vengono visualizzati automaticamente nei backlog del team e nelle schede Kanban.
  • Backlog del team e Backlog di programma: implementati come backlog del team che filtrano gli elementi di lavoro assegnati a un team e supportano la priorità e il raggruppamento del lavoro.
  • Scrum e Kanban: procedure completamente supportate usando schede Kanban, backlog sprint e taskboard, team e cadenze sprint.
  • Iterazioni, innovazione e pianificazione (IP),incrementi di programmi (PI),cardine e treni di rilascio: implementati tramite un elenco flat o una configurazione gerarchica dei percorsi di iterazione.
  • Agile Release Training: 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 del progetto predefinito 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 AboutBoards e Kanban.

Portfolio SAFe®

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

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

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

Azure Boards fornisce supporto per i componenti di portfolio seguenti:

  • Epics: 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 del portfolio che supporta il filtro del lavoro in base alla revisione delle esigenze aziendali.
  • Visione portfolio e temi strategici: i proprietari e i gestori di portfolio possono usare il wiki del progetto predefinito per condividere la loro visione, gli obiettivi e gli obiettivi.
  • Flussi valore: i flussi di valore possono essere monitorati usando tag o campi personalizzati.
  • Budget sgra: le informazioni sul budget possono essere acquisite nei campi personalizzati e implementate 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 report personalizzati rapidamente.

SaFe® di soluzioni di grandi dimensioni

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

Panoramica © dell'architettura del poster di Large Solution SAFe® D. Leffingwell
Riprodotto con l'autorizzazione dal © 2011 al 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 di 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

Modalità di mapping degli artefatti SAFe® a 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 dell'implementazione.

Termine o artefatto SAFe®

Azure Boards termine o artefatto

Team Agile

Teams. È possibile definire una gerarchia di team per soddisfare le esigenze 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 esaminare lo stato di avanzamento e i risultati finali.

Budget

Tag, area valore. È possibile usare tag o il campo Area valori 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 a Epics e Funzionalità. Li acquisisci negli elementi di lavoro e all'interno di vari backlog del team.

Componenti principali

Elemento di lavoro. È possibile definire, pianificare e tenere traccia degli abilitanti simili a Epics, Funzionalità e Storie. Li acquisisci negli elementi di lavoro e all'interno di 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 della 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 backlog del proprio portfolio.

Iterazione innovazione e pianificazione (IP)

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

Iterazione

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

Attività cardine

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 Epics portfolio. La bacheca del team portfolio visualizza il backlog Epics come schede in una scheda Kanban interattiva, configurabile e filtrabile.

Visione portfolio

Wiki. Usare il wiki del progetto per condividere in modo ampio all'interno dell'organizzazione le informazioni relative a strategia, soluzioni e come i team collaboreranno per produrre portfolio e risultati finali del 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.

Kanban del programma

Scheda Funzionalità del programma. Nella scheda Programmi viene visualizzato il backlog Funzionalità come schede in una scheda Kanban interattiva, configurabile e filtrabile.

Percorso di iterazione dell'incremento del programma

Percorso di iterazione. I percorsi di iterazione definiscono una casella temporale per un progetto con date di inizio e 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 di 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 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. Temi strategici, simili a Portfolio Vision, possono essere acquisiti in un wiki del progetto.

Storie

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

Team Backlog

Backlog delle storie. Il backlog Stories elenca le storie utente assegnate al percorso dell'area associato al team.

Team Kanban

Bacheca storie. La bacheca Stories visualizza il backlog Stories come schede in una scheda Kanban 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.

Azure Boards'implementazione 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 i programmi e i progetti SAFe®.

Successiva attività da provare

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 è una soluzione tecnologica professionale per Microsoft e ALM Ranger.
  • Willy-Peter Schaub è un ex program manager con Gli ALM Rangers di Visual Studio 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 nell'assolata città di Durban, Sud Africa. Passa molto tempo alla tastiera occupandosi di Visual Studio oppure si rilassa insieme alla famiglia. Il suo blog è a gordonbeeming.xyz e puoi seguirlo su Twitter a twitter.com/gordonbeeming.
  • Brian Blackman è uno dei principali consulenti di Microsoft Premier Developer e si occupa di aiutare i partner ISV e le organizzazioni a raggiungere il successo in campo tecnologico e sul mercato. Ha conseguito un MBA, le certificazioni CSM, CSP, MCSD (C++) e MCTS ed è un Visual Studio ALM Ranger. Quando non è Ruck Mastering e contribuisce ai progetti di Visual Studio ALM Ranger, dedica il suo tempo a scrivere codice, creare e distribuire workshop e consulenza in varie concentrazioni, in particolare aiutando le organizzazioni nella loro ricerca di agilità aziendale.
  • Gregg Boer è uno dei principali responsabili del programma in Microsoft. Gregg è il proprietario del prodotto per l'esperienza di gestione Agile fornita da Azure DevOps e da TFS locale.
  • Kathryn Elliott è una scrittrice senior di articoli tecnici in Microsoft.
  • Susan Ferrell è una scrittrice senior di articoli tecnici e una Visual Studio ALM Ranger.
  • Willy-Peter Schaub è un ex manager del programma con Visual Studio ALM Rangers nel Centro sviluppo Microsoft Canada. A partire dalla metà degli anni '80, si è impegnato per semplicità e gestibilità nell'ingegneria del software. Puoi seguirlo su Twitter in twitter.com/wpschaub.
  • Grazie speciali agli esperti tecnici seguenti 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).