Promuovere una cultura Agile all'interno del team

  • Articolo

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, il ridimensionamento di Agile richiede la gestione delle impostazioni cultura e degli strumenti all'interno dell'organizzazione.

Nota

Novità di Agile? Per altre informazioni, vedere Agile Culture and Scaling Agile to Large Teams .For more information, see Agile Culture and 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.

Troppi allineamenti con i lead di autonomia del team insufficienti non supportano l'innovazione o l'agilità dei team per fare le cose. Troppo poco allineamento con ogni team che esegue il proprio programma non fornisce le informazioni dettagliate e il coordinamento necessari 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 utente 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 pianificazioni regolari di rilascio e sprint promuove il ritmo dell'azienda.
Ogni iterazione di durata costante in fase di sprint tra due e quattro settimane include la pianificazione, l'esecuzione, il recapito, la riflessione e l'impegno nel miglioramento continuo.

Tutti i team gestiscono il proprio lavoro all'interno della cadenza sprint impostata. Il team fornisce l'input nella lunghezza dello sprint che funziona meglio per loro.
Il team sceglie i metodi Agile che funzionano per loro, Scrum, Kanban o una combinazione di entrambi. Il team acquisisce anche la proprietà di iniziare e agire sul proprio set di procedure di miglioramento continuo.
È possibile che alcuni team eseseguono in 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ì troppo fare 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.
I messaggi di posta elettronica dello sprint del team, lo stato della barra dei bug e lo stato di distribuzione delle funzionalità del team sono esempi di comunicazioni regolari.

Un team determina i dettagli che comunicano e chi sviluppa la comunicazione. 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 eseguire lo stage delle basi di bug per le nuove funzionalità o alla fine di ogni sprint. Possono scegliere un individuo per funzionare come scudo di bug su base rotante.

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 tutto ciò che possono fare i team 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.

Team strutturati

Quando si ridimensiona, una delle attività più importanti da considerare è la struttura dei 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.

Configurare i team lungo i flussi di valore che l'organizzazione vuole distribuire. 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: si aggiungono team per supportare l'autonomia del team e fornire loro gli strumenti che possono configurare e gestire che supportano il modo in cui vogliono lavorare. Questi strumenti includono backlog del prodotto, bacheche Kanban, backlog sprint, schede attività e altri.

    È anche possibile configurare i team per supportare una gerarchia di backlog e backlog del portfolio, in modo che i responsabili del portfolio possano esaminare la priorità e lo stato di avanzamento in 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 backlog portfolio. I team delle funzionalità incentrati su un sottoinsieme del backlog del prodotto possono rimanere concentrati solo sul backlog. I gestori di portfolio che vogliono visualizzare e organizzare i backlog per tenere traccia dello stato di avanzamento e delle dipendenze possono gestire backlog portfolio di funzionalità e 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.

Scalabilità con team e non 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.

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 delle impostazioni cultura Agile