Implementare procedure Agile per la scalabilità

  • Articolo

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

Le organizzazioni aziendali adottano procedure Agile per molti motivi. I primi tra questi motivi includono:

  • Abbreviare il time-to-market, accelerare la distribuzione dei prodotti
  • Migliorare l'efficacia dell'organizzazione per gestire le priorità mutevoli
  • Migliorare la qualità del software e la prevedibilità del recapito
  • Migliorare la visibilità del progetto e ridurre il rischio del progetto

Man mano che l'organizzazione cresce, è necessario ridimensionare le procedure per rimanere agili e soddisfare obiettivi mutevoli. A tale scopo, considerare questi due principi guida:

  • Qual è l'aspetto del successo, dei team e dell'organizzazione? Quali sono gli aspetti più interessanti: recapito in tempo reale? Qualità del prodotto? Prevedibilità? Soddisfazione?
  • Tornare ai primi principi, tornare ai principi e ai valori condivisi enumerati nel manifesto Agile Come indicato da Ken Schwaber, uno dei fondatori di Scrum:
    • "I valori e i principi vengono ridimensionati, ma le procedure sono sensibili al contesto".
    • "Mantenere i valori, mantenere i principi, pensare per se stessi. Una premessa fondamentale di Agile è che le persone che svolgono il lavoro sono le persone che possono capire meglio come farlo."

Creare ritmo e flusso

Adottando una cadenza condivisa e un set di comunicazioni periodiche, si crea un flusso costante di attività in tutta l'organizzazione. Le procedure che consentono di creare ritmi e flussi all'interno di organizzazioni di grandi dimensioni includono:

  • Frequenza condivisa: gli sprint e le versioni regolari stabiliscono il ritmo dell'attività. Avere tutti i team a lavorare a una cadenza condivisa aiuta con tutte le attività di coordinamento e collaborazione.
  • Email sprint: per mantenere l'organizzazione e tutti i team informati sullo stato di avanzamento e sui piani dei team di funzionalità, ogni team di funzionalità può inviare un riepilogo dei risultati dello sprint precedenti e dei piani sprint correnti.
  • Demo sprint: un video rapido da 2 a 3 minuti che illustra una nuova funzionalità prodotta dal team. I collegamenti a tali video possono essere inclusi nei messaggi di posta elettronica sprint.
  • Riunioni di presentazione: per informare altri team e chiedere commenti e suggerimenti sul software in fase di sviluppo, i team mostrano il lavoro svolto. Condurre queste riunioni a intervalli regolari durante il ciclo di vita del progetto e aprirle a tutte le parti interessate.
  • Messaggi di posta elettronica di riepilogo dei bug: per supportare informazioni dettagliate sulla qualità del prodotto e incoraggiare la gestione della disciplina dei bug, condividere periodicamente le metriche di qualità con l'organizzazione. Queste metriche possono includere bug attivi per team di funzionalità, tendenze di bug e bug per ogni tecnico.
  • Riunioni di coordinamento: organizzare riunioni che coordinano i team a intervalli regolari o con la frequenza necessaria per affrontare obiettivi, dipendenze e rischi sovrapposti.

Interagire con i clienti

Coinvolgere i clienti in tutto il ciclo di vita del prodotto è un principio agile principale. Consentire a ogni team di interagire direttamente con i clienti nei set di funzionalità di cui sono proprietari.

  • Feedback continuo: creare cicli di feedback dei clienti. Questi cicli possono assumere molte forme:
    • Voce del cliente: consente ai clienti di fornire commenti e suggerimenti, aggiungere idee e votare le funzionalità di nuova generazione. Il feedback viene spesso eseguito tramite un sito Web dedicato.
    • Commenti e suggerimenti sul prodotto: i pulsanti di feedback nel prodotto sono un altro modo per richiedere commenti e suggerimenti sull'esperienza del prodotto o sulle funzionalità specifiche.
    • Demo dei clienti: demo pianificate regolarmente che richiedono feedback dai clienti possono aiutare a modellare i prodotti di nuova generazione e tenere traccia delle applicazioni che i clienti vogliono utilizzare.
  • Programmi early adopter: tali programmi devono essere sviluppati con l'idea che tutti i team possano voler partecipare come un certo punto. Gli early adopter ottengono l'accesso alle versioni iniziali del software funzionante, che possono quindi fornire feedback. Spesso, questi programmi funzionano attivando i flag di funzionalità selezionati per un elenco di early adopter.
  • Decisioni basate sui dati: trovare modi per instrumentare il prodotto per ottenere dati utili e in grado di testare varie ipotesi. Aiuta a promuovere una cultura intuitiva che celebra l'apprendimento.

Migliorare la visibilità del progetto

Maggiori sono le informazioni dettagliate che l'utente e i team hanno nell'obiettivo, nella visione e nello stato di avanzamento del lavoro svolto, il modo migliore è quello di ridurre i rischi e gestire le dipendenze.

  • Struttura del team: indipendentemente dalla dimensione dell'organizzazione, strutturando l'organizzazione in team di piccole dimensioni da 6 a 9. Creare team di funzionalità verticali e autonomi raggruppati in aree di gestione portfolio.
  • Struttura di suddivisione del lavoro: suddividere obiettivi, funzionalità o requisiti di grandi dimensioni in quelli più piccoli rimane una stabile di gestione dei progetti. Suddividendo il lavoro in attività di dimensioni simili, i team possono eseguire stime migliori e identificare rischi e dipendenze.
  • Visualizzazioni consolidate: usare gli strumenti di rilevamento online per aggregare il lavoro per acquisire informazioni tra i team. Creare dashboard per mostrare lo stato di avanzamento e le tendenze.
  • Revisioni dell'esperienza: queste riunioni, tenute prima dell'inizio dello sviluppo su una funzionalità, vengono usate per informare la leadership su scenari e priorità, raccogliere feedback, impostare le aspettative e presentare eventuali problemi tra team relativi alla funzionalità.

Potenziare una forza lavoro produttiva

Alcune procedure Agile specifiche che si adattano bene e portano a dipendenti più felici, impegnati e produttivi includono:

  • Leadership incorporata: consente ai team e ai leader all'interno dell'organizzazione di organizzare e auto-gestire il più possibile. L'autonomia del team aumenta l'efficacia del team di agilità organizzativa. Assicurarsi che i team abbiano la sponsorizzazione aziendale necessaria per avere successo.
  • Stand-up giornalieri: in alternativa, le riunioni Scrum aiutano i team a concentrarsi su ciò che devono fare quotidianamente per massimizzare la capacità di soddisfare gli impegni di sprint. Man mano che le organizzazioni aumentano, è consigliabile prendere in considerazione lo sfalsamento di queste riunioni in modo che la partecipazione tra team possa avvenire in base alle esigenze.
  • Scrum of scrums: ogni giorno stand up di membri di diversi team Agile si incontrano ogni giorno per segnalare il lavoro completato, i passaggi successivi e i problemi o i blocchi che si verificano all'interno dei team rappresentativi.
  • Comunicazioni del team: fornire e incoraggiare i team a condividere le proprie procedure e linee guida, a cui possono accedere i team e gli altri team tramite la rete aziendale. Gli strumenti comuni usati per questo scopo includono wiki del team, OneNote o siti Markdown.
  • Collaborazione: incoraggiare comunicazioni informali tra team e collaborazione all'interno del team. Le procedure di istituzionalizzazione, ad esempio revisioni del codice, revisioni di progettazione, revisioni specifiche non solo aumentano la collaborazione del team, ma aiutano a sviluppare competenze individuali e complessive aziendali.

Migliorare la cultura organizzativa

È possibile migliorare l'efficacia dell'organizzazione partecipando alla cultura che si vuole creare. Le modifiche alle impostazioni cultura si verificano quando utenti, team e organizzazioni adottano una o più procedure di miglioramento continuo. Alcune procedure Agile scalabili includono:

  • Retrospettive: porre domande come: "Cosa è andato bene?", "Cosa dobbiamo fare in modo diverso?", e "Cosa dobbiamo smettere di fare?" aiutano i team a riflettere su come possono migliorare i processi e le procedure. Le analisi retrospettive aiutano i team a individuare ciò che funziona bene e quali sono le esigenze di miglioramento. Le retrospettive possono essere condotte in qualsiasi momento e ovunque. Tuttavia, l'istituzionalizzazione di determinate analisi retrospettive a cadenza regolare aiuta a istituzionalizzare le pratiche di miglioramento continuo. Ad esempio:

    • Le analisi retrospettive sprint consentono ai team di identificare le aree per migliorare a cadenza regolare.

    • Le analisi retrospettive sul rilascio possono aiutare le organizzazioni a identificare le aree per migliorare le comunicazioni e le procedure interne e migliorare il carburante per la prossima versione.

    • Revisioni operative: in genere vengono tenute mensilmente e includono rappresentanti di un flusso di valore intero. Estendendo un portfolio di progetti e altre iniziative e usando obiettivi, dati quantitativi, progettare queste retrospettive per provocare discussioni sulle dinamiche che influiscono sulle prestazioni tra i team.

      Per idee, suggerimenti e strumenti per la pianificazione e l'esecuzione di analisi retrospettive, vedere Il Wiki delle risorse retrospettive Agile. Vedere anche l'estensione Analisi retrospettive del Marketplace.

  • Scheda di rilevamento dei miglioramenti: le buone idee per migliorare i processi possono derivare da qualsiasi elemento in qualsiasi momento. Acquisire queste idee per discutere e decidere come agire rapidamente è una chiave per supportare le attività di miglioramento dei processi.

    Una lavagna bianca fornisce qualsiasi mezzo semplice e visivo con cui acquisire idee. Inoltre, è possibile creare un team di rilevamento dei miglioramenti e acquisire idee tracciate su una bacheca Kanban elettronica.

  • Istituzionalizzare la condivisione: condividere le procedure consigliate e comunicare idee aiuta tutti i team all'interno di un'organizzazione a crescere e migliorare. Lo sviluppo di una cultura dell'apprendimento è fondamentale per supportare questo e altre attività di miglioramento continuo. Alcune idee da considerare:

    • Wiki interni

    • Liste di distribuzione interne

    • Hackathon settimane o 10% tempo hack

    • Team di supporto Interno di Agile per supportare i team che adottano procedure Agile

      Il gioco cultura offre una buona risorsa per i manager Agile per aiutare i team ad adottare agile e condividere le procedure consigliate.

  • Community di pratica: supportare discipline comuni interne (ad esempio, DBA, architetti SW, progettazione dell'esperienza utente)

Software funzionante

"Distribuire spesso software funzionante, da un paio di settimane a un paio di mesi, con una preferenza per la scala cronologica più breve".
"Il software funzionante è la misura principale dello stato di avanzamento".
- Manifesto Agile

Man mano che aumenta la quantità di software, funzionalità e complessità, è necessario adottare procedure che consentono di produrre soluzioni di consumo.

  • Flag di funzionalità: usare i flag di funzionalità per abilitare o disabilitare l'accesso a funzionalità diverse. Fornire supporto per attivare le funzionalità agli early adopter per ottenere feedback lavorativo.
  • Treni di rilascio: fornire un altro tipo di cadenza per offrire una o più funzionalità. I team delle funzionalità comprendono la pianificazione pianificata per il push di nuove funzionalità e pianificare correttamente. I treni di rilascio possono corrispondere alla stessa cadenza di sprint per l'organizzazione o a una frequenza diversa. Vedere Scaled Agile Framework per informazioni su come configurare sprint e rilasciare i training.
  • Integrazione continua: adottare processi che eliminano il lavoro manuale e automatizzano invece il flusso del software attraverso i cicli di test, compilazione e distribuzione.
  • Open Source interno: portare il valore e l'ethos sviluppati nella community Open Source Software ai team di sviluppo interni.

Oltre alle procedure precedenti, sono disponibili altre indicazioni sul ridimensionamento degli strumenti Agile negli articoli seguenti:

Risorse del settore

Procedure che non vengono ridimensionate

  • Stima di iniziative di grandi dimensioni: parte dei metodi di progetto a cascata coinvolti nella stima delle risorse e delle pianificazioni. Più grandi sono le iniziative, meno probabilmente queste stime sono state di qualsiasi valore. Man mano che i progetti crescono, i rischi e i problemi imprevisti e gli ostacoli possono verificarsi, invalidando molte stime.
  • Velocità: mentre la velocità del team può fornire una metrica utile per ottenere informazioni dettagliate sulla quantità di lavoro che ogni team può completare durante un ciclo di sprint, non è possibile aggiungere velocità del team per ottenere metriche significative o utili. Inoltre, l'uso della velocità ottenuta da molti team per completare in modo affidabile le previsioni a lungo raggio è problematico. I team variano nel modo in cui stimano il lavoro e le variazioni aumentano nel tempo.
  • Soluzioni prescrittive dall'alto verso il basso: una dimensione non è adatta a tutte e una soluzione in genere non rientra in tutti i team. Supportare l'autonomia del team significa consentire ai team di trovare le proprie soluzioni.