Microsoft AZ-400: Pianificazione Agile e gestione del lavoro — Guida allo studio

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Fa parte della Microsoft DevOps Engineer Expert AZ-400 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La pianificazione agile e la gestione del lavoro in Azure DevOps si basano su un modello di dati chiaro, pratiche disciplinate di flusso e iterazione e visibilità tra i team. Azure Boards fornisce una solida gerarchia di tipi di elementi di lavoro e configurazioni flessibili per team, mentre GitHub Projects offre una pianificazione moderna, guidata dall’automazione e strettamente integrata con Issues e Pull Request. L’adozione efficace dipende da definizioni rigorose (Definition of Done, criteri di accettazione), stime coerenti (story point e dimensionamento relativo) e insight pratici (query, piani di recapito e metriche, incluse le DORA). Le sezioni seguenti descrivono in dettaglio come progettare, implementare e gestire queste pratiche su larga scala.

Modello di dati di Azure Boards, modelli di processo e configurazione dei team

I tipi di elementi di lavoro e la loro gerarchia costituiscono la spina dorsale della pianificazione. Nel processo Agile predefinito, la gerarchia di portfolio è Epic > Feature > User Story, con Task e Bug come elementi a livello di esecuzione. I link di tipo Child catturano la scomposizione (User Story → Task) e i Bug possono essere gestiti allo stesso livello di backlog delle User Story o valutati in modo indipendente in base alle policy del team. I tipi di link sono essenziali:

Parent/Child: cattura la gerarchia di scomposizione e guida il rollup dell’avanzamento e dell’impegno (effort).
Predecessor/Successor: esprime le relazioni di pianificazione e dipendenza tra gli elementi di lavoro; queste appaiono nei Delivery Plan come linee di dipendenza.
Related/Duplicate/Blocked by: modella relazioni non gerarchiche e impedimenti.
Link ad artefatti: collega gli elementi di lavoro al codice (commit, branch, PR), alle build e alle release, consentendo una tracciabilità end-to-end.

I modelli di processo di Azure DevOps definiscono stati, campi e la nomenclatura dei WIT (Work Item Type):

Agile: l’elemento a livello di requisito è la User Story; i team che si muovono velocemente spesso scelgono questo modello.
Scrum: l’elemento a livello di requisito è il Product Backlog Item (PBI); gli sprint e gli artefatti Scrum sono elementi di prima classe e i Bug possono essere configurati per comportarsi come i PBI.
CMMI: l’elemento a livello di requisito è il Requirement e include WIT per Change Request, Risk e Review; da scegliere quando è necessario tracciare i rischi e le revisioni formali.
Processi personalizzati (ereditati): In Azure DevOps Services, è possibile estendere un processo di sistema tramite ereditarietà (Inheritance) per aggiungere WIT, stati, regole e campi personalizzati, preservando la compatibilità del servizio. Usare le categorie per posizionare un WIT personalizzato al livello di backlog corretto. Evitare una personalizzazione eccessiva che frammenta la reportistica; standardizzare campi come Story Points e Remaining Work.

I team sono partizioni leggere configurate tramite:

Area path: definiscono l’ambito di competenza (ownership) e il filtraggio del backlog; i team selezionano uno o più area path (e opzionalmente includono le aree figlie) per definire il “loro” lavoro.
Iteration path: rappresentano la cadenza di rilascio e gli sprint; un team sceglie le iterazioni predefinite e correnti per la pianificazione.
Backlog e board di team: ogni team sceglie quali livelli di portfolio (Epic, Feature) mostrare, gli stili delle card e la mappatura delle colonne per team senza influenzare gli altri team.
Dashboard di team: curano la visibilità condivisa utilizzando widget per Velocity, Burndown/Burnup, Cumulative Flow Diagram (CFD), grafici di Lead/Cycle Time e viste di Analytics personalizzate.

Delivery basato sul flusso con Kanban e Governance

Il Kanban in Azure Boards modella un flusso continuo dall’impegno (commitment) al completamento. Configurare le colonne per mapparle agli stati del flusso di lavoro e, opzionalmente, suddividere gli stati critici in sottocolonne Doing/Done per migliorare il calcolo del throughput e ridurre le code nascoste. Impostare limiti espliciti di WIP (Work In Progress) per colonna e per swimlane; applicarli a livello operativo: il superamento di un limite innesca una conversazione di miglioramento anziché una crescita silenziosa del backlog. Utilizzare swimlane dedicate (ad esempio, Expedite) per separare visivamente gli elementi ad alta priorità e impostare un WIP più restrittivo per quella corsia.

La Definition of Done (DoD) ancora la qualità e la prevedibilità; codificarla come policy della board, campi obbligatori o checklist su transizioni specifiche e collegamenti a test di accettazione. Ad esempio, richiedere un link di tipo Tested By a un Test Case superato prima di spostare un elemento in Done, e catturare i passaggi di verifica del deployment quando si passa a Released.

Utilizzare gli analytics per gestire la salute del flusso:

Il Cumulative Flow Diagram convalida l’equilibrio del WIP e rileva i colli di bottiglia quando le bande si espandono.
Il Lead Time misura il tempo trascorso dalla creazione al completamento; il Cycle Time si concentra sul tempo che intercorre dall’ingresso nello stato Active al completamento.
Il widget del grafico del Cycle Time riporta il tempo trascorso dopo che un elemento di lavoro passa allo stato Active, allineandosi con l’analisi dei colli di bottiglia.
I grafici del Throughput tracciano gli elementi completati per periodo di tempo; monitorare la stabilità e l’andamento (trend).

Pianificazione dell’iterazione, rifinitura del backlog e previsione basata sulla velocity

La pianificazione dello sprint (sprint planning) converte le priorità in un impegno limitato nel tempo (timeboxed). Il backlog dello sprint elenca i PBI (Product Backlog Item) o le User Story inseriti nell’iterazione, scomposti in Task con il Lavoro Rimanente (Remaining Work) espresso in ore. Utilizzare la Capacità dello Sprint (Sprint Capacity) per modellare la disponibilità delle persone:

Capacità per persona in ore/giorno per attività (Sviluppo/Development, Test/Testing, UX).
Giorni di ferie individuali e di team per riflettere festività e permessi.
Bilanciamento del carico a livello di attività, associando i task alle attività e confrontando la capacità con il lavoro pianificato.

La Velocity riassume gli story point consegnati per ogni sprint. Utilizzare il grafico della Velocity per stabilire un andamento stabile; evitare l’ “inflazione dei punti”. Sui backlog di prodotto, abilitare la Previsione (Forecasting) per proiettare quante iterazioni future saranno necessarie per completare (burn down) il backlog, basandosi sulla velocity media storica del team (calcolata su diversi sprint recenti) e sulla durata dell’iterazione. Mantenere la previsione attendibile escludendo il lavoro parzialmente completato e mantenendo una DoD (Definition of Done) rigorosa.

La rifinitura del backlog (backlog refinement) impone chiarezza e dimensionamento relativo:

Criteri di accettazione: registrare dichiarazioni chiare e testabili nel campo Criteri di Accettazione (Acceptance Criteria) dell’elemento di lavoro; preferire il formato Given-When-Then per ridurre l’ambiguità e accelerare la progettazione dei test.
Story point: stimare la complessità e l’incertezza relative a livello di requisito; non convertire i punti in ore: i task contengono il Lavoro Rimanente (Remaining Work).
Stima relativa (Planning Poker): utilizzare una baseline condivisa e una sequenza (Fibonacci o Fibonacci modificata) per convergere rapidamente. I team possono usare estensioni del Marketplace per eseguire sessioni di Planning Poker all’interno di Azure Boards, scrivendo le stime nei campi Story Points/Effort per un reporting coerente.

I bug dovrebbero essere analizzati (triaged) e trattati come requisiti (stimati con story point e pianificati nel backlog) oppure gestiti come task all’interno dello sprint; scegliere una singola policy per team per mantenere la velocity coerente.

Pianificazione inter-team, query, reporting, GitHub Projects e metriche DevOps

I programmi di grandi dimensioni richiedono visibilità tra team e repository:

Piani di recapito (Delivery Plans): creano timeline multi-team filtrate per percorsi di area/iterazione. Visualizzano il lavoro per iterazione con linee di dipendenza (dai collegamenti Predecessore/Successore) e indicatori per le milestone (date di rilascio, impegni esterni). Mostrano l’avanzamento di rollup su Feature ed Epic ed espongono campi personalizzati (es. Rischio) per le revisioni di governance.
Query e reporting: costruiscono query a elenco semplice (Flat list) per rispondere a “quali elementi corrispondono a questi filtri”, query ad albero di elementi di lavoro (Tree of work items) per navigare la gerarchia con i rollup, e query a collegamenti diretti (Direct links) per analizzare un singolo “salto” di collegamento (es. da Feature a Story o da Bug a commit). Salvano e condividono query, aggiungono grafici (a torta, a barre, di tendenza) e li fissano sui dashboard. Per un reporting di livello analitico, utilizzano il servizio Azure DevOps Analytics e OData con Power BI per produrre burndown del portfolio, mappe di calore del rischio delle dipendenze e visualizzazioni DORA. I report integrati includono Velocity, Burndown/Burnup, CFD, Lead Time, Cycle Time e l’utilizzo della Capacità dello sprint.

GitHub Projects integra la pianificazione con Issue e PR:

Bacheche di progetto: creano viste Kanban o a tabella a livello di organizzazione o repository, definiscono campi personalizzati (Stato, Iterazione, Priorità) e filtrano per team.
Regole di automazione: configurano flussi di lavoro integrati per impostare lo Stato quando una Issue o una PR viene aperta, unita (merged) o chiusa; archiviano automaticamente gli elementi completati; assegnano o etichettano in base alle modifiche dei campi; e spostano elementi tra le viste. Si combinano con GitHub Actions per automazioni avanzate.
Integrazione di Issue e PR: le Issue e le PR sono elementi di prima classe in Projects. Utilizzano parole chiave nelle descrizioni delle PR (Fixes #123) per collegare e chiudere automaticamente le Issue. Lo stato e i revisori sono visibili sulla bacheca, abilitando la tracciabilità dal codice al piano.

Le metriche DevOps devono collegare codice, deployment e risultati:

Metriche DORA:
- Frequenza di deployment: conteggio dei deployment in produzione al giorno/settimana; la fonte sono gli eventi di rilascio della pipeline.
- Lead time per le modifiche: misura dal commit del codice (o dal merge della PR) al deployment in produzione; assicura che le pipeline emettano timestamp di deployment e li correlino ai commit.
- Tasso di fallimento delle modifiche (Change failure rate): rapporto tra i deployment in produzione che causano un incidente con impatto sul cliente o un rollback; si integra con i tag di gestione degli incidenti e gli esiti della pipeline.
- Tempo medio di ripristino (MTTR): tempo trascorso dall’inizio dell’incidente al ripristino del servizio; si ricava dagli avvisi di monitoraggio e dai tempi di chiusura degli incidenti. Correlare le metriche DORA con le analisi della bacheca (Lead/Cycle time) per rilevare se il vincolo è nella pianificazione o nella consegna. Usare i dashboard per presentare entrambi i set di metriche allo stesso pubblico per un miglioramento continuo.

Scenario pratico del problema

La divisione Advertising di Microsoft sta allineando otto team interfunzionali che sviluppano una piattaforma condivisa per la gestione delle campagne. Il codice si trova su GitHub; l’organizzazione necessita di impegni trimestrali affidabili, chiara visibilità delle dipendenze e metriche di flusso e DORA utilizzabili senza aumentare la proliferazione degli strumenti.

Scegliere il processo Agile di Azure DevOps e configurare i team

Perché: il processo Agile fornisce la gerarchia Epic > Feature > User Story che bilancia la semplicità con i rollup a livello di portfolio. Creare otto team, ciascuno con il proprio percorso di area e percorsi di iterazione attuali/futuri, consentendo autonomia nelle bacheche e nei dashboard pur mantenendo il reporting a livello di organizzazione.

Definire la governance Kanban e la configurazione della bacheca

Perché: il flusso continuo tra gli sprint riduce i tempi di attesa. Configurare le colonne mappate agli stati con suddivisioni Doing/Done per “In Progress” e “Code Review”. Impostare limiti WIP per colonna e aggiungere una swimlane “Expedite” con un WIP inferiore. Aggiungere policy sulla bacheca che definiscano la Definition of Done (test unitari superati, PR approvata, checklist di verifica del deployment completata) per regolare il passaggio a “Done”.

Implementare il refinement del backlog e la disciplina di stima

Perché: impegni prevedibili richiedono dimensionamento coerente e chiarezza. Acquisire i criteri di accettazione usando il formato Given-When-Then sulle User Story. Standardizzare gli Story Point tramite Planning Poker (Fibonacci 1–13) usando un’estensione di Azure Boards e mantenere le stime dei task in ore di Lavoro Rimanente (Remaining Work) per supportare la Capacità dello Sprint.

Pianificare gli sprint con previsioni basate su capacità e velocity

Perché: la pianificazione della capacità riduce l’eccesso di impegni. Inserire le capacità individuali per attività e giorni di ferie. Usare il grafico della Velocity degli ultimi sei sprint per definire un obiettivo di sprint realistico. Abilitare la funzione di Forecasting del backlog per proiettare quanti sprint sono necessari per raggiungere gli obiettivi trimestrali degli Epic, allineando le aspettative degli stakeholder.

Stabilire Piani di recapito (Delivery Plans) per la visibilità inter-team

Perché: le dipendenze e le milestone devono essere visibili su un’unica timeline. Creare un Piano di recapito che includa tutti gli otto team e i livelli di portfolio. Aggiungere indicatori di milestone per le date di rilascio trimestrali e gli eventi di mercato. Usare i collegamenti Predecessore/Successore per mostrare le linee di dipendenza e far emergere i rischi dove gli elementi si estendono su più iterazioni.

Integrare GitHub Projects per viste di esecuzione incentrate sul repository

Perché: gli sviluppatori “vivono” in GitHub; i Projects mantengono il contesto di esecuzione vicino al codice. Creare un GitHub Project a livello di organizzazione con viste a bacheca e a tabella. Aggiungere regole di automazione per impostare lo Stato su “In Progress” all’apertura di una PR, su “Done” al merge della PR e per archiviare automaticamente le Issue chiuse. Usare “Fixes #<id>” nelle PR per chiudere le Issue collegate e riflettere lo stato sulla bacheca.

Collegare codice e lavoro per la tracciabilità

Perché: la tracciabilità end-to-end consente reporting e audit accurati. Imporre il riferimento all’ID dell’elemento di lavoro di Azure Boards nei messaggi di commit e nelle descrizioni delle PR; usare i collegamenti ad artefatti sugli elementi di lavoro in modo che i Piani di recapito e gli analytics possano effettuare il rollup dell’avanzamento dall’attività sul codice.

Strumentare le metriche di flusso e DORA sui dashboard

Perché: metriche condivise e automatizzate guidano il miglioramento. Sui dashboard di team, aggiungere i grafici CFD, Lead Time e Cycle Time per gestire il flusso. Su un dashboard di programma, presentare la Velocity, il riepilogo del Piano di recapito e le metriche DORA: calcolare la frequenza di deployment e il lead time usando gli eventi di deployment della pipeline dagli stage di produzione; derivare il tasso di fallimento delle modifiche e l’MTTR taggando gli incidenti e correlandoli ai deployment. Questa vista unificata evidenzia se i vincoli si trovano nella pianificazione (lead/cycle time della bacheca) o nella consegna (DORA).

Questo approccio bilancia l’autonomia del team (bacheche, capacità e dashboard specifici del team) con la governance del programma (Piani di recapito, dipendenze e milestone). Azure Boards fornisce pianificazione gerarchica e analytics, GitHub Projects semplifica il tracciamento quotidiano degli sviluppatori con l’automazione legata a Issue e PR, e le metriche DORA collegano la pianificazione con i risultati operativi per impegni credibili e basati sui dati.

← Gestione dei pacchetti e gestione degli artefatti · Tutti i domini

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →