Condividi tramite

Promuovere una cultura Agile all'interno del team

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

Man mano che il team cresce, si vuole che gli strumenti crescano con esso. Inoltre, se sei un'azienda che adotta metodologie Agile, vuoi che gli strumenti Agile supportino gli obiettivi aziendali dell'azienda.

Tuttavia, scalare Agile con successo richiede di affrontare sia la cultura che gli strumenti all'interno dell'organizzazione.

Nota

Novità di Agile? Per ulteriori informazioni, vedere Agile Culture e Scaling Agile to Large Teams.

Abilitare l'autonomia

Le organizzazioni che aspirano a essere agili devono prendere in considerazione gli obblighi gemelli di creazione dell'allineamento in tutta l'azienda e il supporto dell'autonomia del team. Un team ha bisogno di autonomia per essere efficiente. E le aziende devono essere allineate tra i team e l'organizzazione per essere efficienti.

Troppo allineamento con un'autonomia del team insufficiente non supporta l'innovazione o l'agilità dei team nel raggiungere gli obiettivi. Troppo poco allineamento quando ciascun team esegue il proprio programma non fornisce la consapevolezza e il coordinamento richiesti per soddisfare gli obiettivi aziendali.

Con il giusto livello di allineamento all'interno dell'organizzazione e dell'autonomia del team, i singoli utenti hanno la possibilità di innovare e ispirare la collaborazione per soddisfare gli obiettivi aziendali.

Creare l'allineamento

Durante la pianificazione della crescita del set di strumenti Agile, prendere in considerazione le aree seguenti. Queste aree sono fondamentali per la creazione dell'allineamento aziendale durante lo sviluppo dell'autonomia del team.

Area

Creare l'allineamento

Autonomia di supporto

Visione del prodotto

L'organizzazione definisce gli obiettivi e la roadmap per l'organizzazione. È possibile definire gli obiettivi come epiche e funzionalità che vengono visualizzate nel backlog del portfolio.

Un team determina come soddisfare al meglio la roadmap. Il team suddivide gli obiettivi nelle storie degli utenti o negli elementi di backlog del prodotto usando i backlog del team.

Struttura del team

In base agli obiettivi aziendali, le organizzazioni determinano il numero e le dimensioni dei team. I team di funzionalità strutturati verticalmente portano a una maggiore autonomia ed efficienza.

Con i team devono essere definiti alcuni ruoli, ad esempio il proprietario del prodotto e i lead di sviluppo, ma anche spazio per ruotare i ruoli. Ad esempio, i membri del team possono agire come Scrum Master, sviluppare demo sprint, eseguire retrospettive sprint o creare messaggi di posta elettronica sprint.

Frequenza di sviluppo

Le organizzazioni Agile devono rilasciare prodotti e aggiornamenti delle funzionalità a intervalli regolari. Stabilire programmi regolari di rilascio e sprint promuove il ritmo dell'azienda.
Ogni sprint, un'iterazione a durata fissa tra due e quattro settimane, include la pianificazione, l'esecuzione, il recapito del valore, la riflessione e l'impegno nel miglioramento continuo.

Tutti i team gestiscono il proprio lavoro all'interno della cadenza sprint impostata. Il team fornisce input sulla durata dello sprint che meglio si adatta a loro.
Il team sceglie i metodi Agile che funzionano per loro, Scrum, Kanban o una combinazione di entrambi. Il team si assume anche la responsabilità di iniziare e agire sul proprio set di pratiche di miglioramento continuo.
È possibile che alcuni team eseguano degli sprint più brevi. Ad esempio, se un'organizzazione imposta una cadenza sprint di 2 settimane, alcuni team possono scegliere di operare in sprint di 1 settimana, pur rimanendo allineati alla pianificazione organizzativa.

Frequenza di comunicazione

Proprio come gli sprint portano un ritmo naturale al flusso di lavoro, così fanno anche le comunicazioni regolari. Impostando le aspettative per i tipi di comunicazioni che vogliono vedere per rimanere allineati e la frequenza con cui si verificano, le organizzazioni creano naturalmente l'allineamento tra i team e l'azienda.
Le email di sprint del team, lo stato dei bug e lo stato di rilascio delle funzionalità del team sono esempi di comunicazioni regolari.

Un team determina i dettagli della comunicazione e chi li svilupperà. I messaggi di posta elettronica sprint possono contenere un riepilogo dei risultati dello sprint precedenti e dei piani sprint successivi o includere una demo delle funzionalità completate di recente.

Qualità

Ogni organizzazione deve impostare i criteri e gli standard in base ai quali valutano la qualità e impostano le aspettative per gli standard di qualità. Alcuni modi in cui definiscono i criteri sono l'impostazione dei criteri di uscita per lo sviluppo di nuove funzionalità, gli standard per gestire il debito tecnico e i limiti di bug per i team o i singoli utenti.
Inoltre, possono monitorare lo stato dei bug e le tendenze creando dashboard di bug.

Un team sceglie come soddisfano gli standard di qualità. Possono organizzare cacce ai bug per le nuove funzionalità o alla fine di ogni sprint. Possono scegliere un individuo per funzionare come scudo contro i bug a rotazione.

Gestire i rischi, tenere traccia del lavoro

L'organizzazione determina il modo in cui ogni unità funzionale comunica lo stato e il rischio. Stabiliscono un "contratto di comunicazione" in base alle informazioni minime necessarie per l'organizzazione.
Inoltre, l'organizzazione fornisce l'infrastruttura per ridurre i rischi. L'organizzazione deve ai team tutto ciò che può per ridurre i rischi comuni tra i team.

Oltre a soddisfare le esigenze impostate dall'organizzazione, i team determinano eventuali altri dettagli necessari per gestire e tenere traccia per ridurre i rischi. Che usino una lavagna con note permanenti o un diagramma di Gantt completo, gestiscono i dettagli. Ad esempio, i team possono aggiungere un elemento backlog per tenere traccia di una dipendenza che hanno in un altro team. Oppure possono tenere traccia dei loro rischi tramite un elenco di problemi o ostacoli. Inoltre, i team contribuiscono regolarmente a migliorare il processo e l'infrastruttura per supportare la capacità dell'organizzazione di gestire i rischi e ottenere informazioni dettagliate.

Strutturare i team

Quando espandi, una delle attività più importanti da considerare è come strutturi i tuoi team. Tradizionalmente, le strutture orizzontali del team dividono i team in base all'architettura software: interfaccia utente, architettura orientata ai servizi e team di dati.

Grafico che mostra i team orizzontali e verticali.

Tuttavia, con l'adozione di procedure Agile, strutture di team verticali che si estendono sull'architettura offrono una maggiore autonomia del team. I team verticali possono offrire le funzionalità di cui sono proprietari lavorando nell'architettura software. Hanno anche diffuso le conoscenze necessarie per lavorare a tutti i livelli di architettura in tutti i team.

Configura i team lungo i flussi di valore che l'organizzazione vuole implementare. Ad esempio, Fabrikam Fiber organizza i team nei sette team di funzionalità seguenti.

Grafico che mostra sette team di funzionalità: Carrello acquisti, Profilo cliente, Stato del servizio, Posta elettronica, Voce, Internet e TV

Ogni team pianifica le funzionalità da offrire. Hanno l'autonomia di determinare come strutturare i dati, progettare i servizi e progettare le interfacce utente Web e per dispositivi mobili. Pianificano il rispetto degli standard di qualità impostati dall'organizzazione e ai quali tutti i team contribuiscono.

Configurare gli strumenti Agile per la scalabilità

Man mano che l'organizzazione cresce, è possibile ridimensionare gli strumenti Agile nei modi seguenti.

  • Aggiungere team e visualizzazioni backlog filtrate: i team vengono aggiunti per supportare la loro autonomia e fornire loro gli strumenti che possono configurare e gestire, supportando il loro modo di lavorare. Questi strumenti includono backlog di prodotto, bacheche, backlog sprint, taskboard e altri.

    È anche possibile configurare i team per supportare una gerarchia di backlog e backlog di portfolio, in modo che i responsabili del portfolio possano esaminare la priorità e lo stato di avanzamento di diversi team.

  • Configurare sprint e versioni: è possibile strutturare le iterazioni per supportare un set flat di sprint o un set di sprint incorporati nelle versioni pianificate. Ogni team attiva il set di sprint e versioni a cui devono partecipare.

  • Gestire i portfolio: configurando una gerarchia di team e backlog e attivando i backlog di portfolio. I team delle funzionalità incentrati su un sottoinsieme del backlog del prodotto possono rimanere focalizzati esclusivamente sul loro backlog. I gestori di portfolio che desiderano visualizzare e organizzare i backlog per monitorare lo stato di avanzamento e le dipendenze possono gestire i backlog di portfolio relativi a funzionalità ed epiche.

    Se sono necessari altri backlog del portfolio, ad esempio Scenari o Iniziative, è possibile aggiungerli anche.

  • Configurare i dashboard: con i dashboard del team è possibile configurare grafici che tengono traccia dello stato di avanzamento all'interno di un team o tra team. In particolare, è possibile aggiungere grafici di stato e di tendenza in base alle query create.

  • Raggruppare o classificare il lavoro: esistono diversi modi per raggruppare il lavoro che si vuole tenere traccia. I backlog filtrano gli elementi di lavoro in base alle assegnazioni dell'area del team. E i backlog portfolio consentono di raggruppare gli elementi di backlog in Funzionalità ed Epiche.

    Se si desidera tenere traccia e creare report sugli elementi di lavoro in base ad altri raggruppamenti, è possibile. È possibile aggiungere tag agli elementi di lavoro e quindi filtrare i backlog o le query in base ai tag. È anche possibile aggiungere percorsi di area secondaria per rappresentare aree di funzionalità più granulari.

  • Aggiungere cartelle e usare i preferiti del team: man mano che i team aumentano, viene visualizzato un elenco crescente di query sugli elementi di lavoro, definizioni di compilazione e cartelle del codice sorgente. Usando cartelle, sottocartelle e preferiti del team, è possibile gestire più facilmente molti di questi elenchi. È possibile aggiungere i preferiti del team per query condivise, codice sorgente e definizioni di compilazione.

Scala con i team piuttosto che con i progetti

Spesso, le organizzazioni esaminano l'aggiunta di un progetto per ogni progetto di sviluppo software.

È consigliabile aggiungere team per ridimensionare gli strumenti anziché aggiungere progetti per i motivi seguenti:

  • Visibilità: è più facile visualizzare lo stato di avanzamento in tutti i team
  • Rilevamento e controllo: è più semplice collegare elementi di lavoro ad altri oggetti a scopo di rilevamento e controllo
  • Manutenibilità: ridurre al minimo la manutenzione dei gruppi di sicurezza ed elaborare gli aggiornamenti.

Per altre informazioni, vedere Informazioni sui progetti e sul ridimensionamento dell'organizzazione.

Contenuti correlati

Prima di poter creare o usare uno degli strumenti Agile, è necessario un progetto. Se non ne hai ancora uno, puoi crearne uno.

Se si è pronti per passare da un team a due team o configurare più team, vedere Aggiungere team. Per aggiungere un amministratore del team o configurare gli asset del team, vedere Gestire i team e configurare gli strumenti del team.

Vedi questi articoli per ulteriori informazioni:

Risorse del settore della cultura Agile