Implementare procedure Agile per la scalabilità

  • Articolo
  • 9 minuti per la lettura

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

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à e la prevedibilità del recapito del software
  • Migliorare la visibilità del progetto e ridurre il rischio di 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 dell'utente, 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:
    • "Valori e principi ridimensionano, ma le procedure sono sensibili al contesto."
    • "Mantenere i valori, mantenere i principi, pensare a 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:

  • Cadenza 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 all'interno di 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 per 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: tenere riunioni che coordinano i team a intervalli regolari o con la frequenza necessaria per affrontare obiettivi, dipendenze e rischi sovrapposti.

Interagire con i clienti

Il coinvolgimento dei clienti in tutto il ciclo di vita del prodotto è un principio fondamentale della metodologia Agile. Consentire a ogni team di interagire direttamente con i clienti sui 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. L'offerta di commenti e suggerimenti viene spesso eseguita tramite un sito Web dedicato.
    • Feedback prodotto: i pulsanti di feedback nel prodotto sono un altro modo per chiedere commenti e suggerimenti sull'esperienza del prodotto o 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 per creare 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 qualche 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 che possono 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, più è possibile ridurre i rischi e gestire le dipendenze.The more insight you and your teams have into the goal, vision, and progress of the work being done, the better enabled you'll be be to reduce risks and manage dependencies.

  • Struttura del team: indipendentemente dalla dimensione dell'organizzazione, strutturando l'organizzazione in base a 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: suddividendo 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 effettuare 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 aspettative e presentare eventuali problemi tra team relativi alla funzionalità.

Potenziare una forza lavoro produttiva

Alcune procedure Agile specifiche che aumentano 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à aziendale. Assicurarsi che i team abbiano la sponsorizzazione aziendale necessaria per avere successo.
  • Stand-up giornalieri: oppure le riunioni scrum aiutano i team a concentrarsi su ciò che devono fare quotidianamente per massimizzare la loro capacità di soddisfare gli impegni di sprint. Man mano che le organizzazioni crescono, è consigliabile valutare la possibilità di sfalsare 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 quotidianamente per segnalare il lavoro completato, i passaggi successivi e i problemi o i blocchi che si verificano all'interno dei team rappresentativi.
  • Comunicazioni tra team: fornire e incoraggiare i team a condividere le procedure e le linee guida, a cui possono accedere i team e gli altri team tramite la rete aziendale. Gli strumenti comuni usati a questo scopo includono wiki del team, OneNotes o siti Markdown.
  • Collaborazione: incoraggiare comunicazioni informali tra team e collaborazione all'interno del team. Procedure istituzionalizzanti come revisioni del codice, revisioni di progettazione, revisioni specifiche non solo aumentano la collaborazione tra i team, ma aiutano a sviluppare competenze individuali e complessive aziendali.

Migliorare la cultura dell'organizzazione

È possibile migliorare l'efficacia dell'organizzazione partecipando alle impostazioni cultura da creare. Le modifiche cultura si verificano quando utenti, team e organizzazioni adottano una o più procedure di miglioramento continuo. Di seguito sono descritte diverse procedure Agile scalabili:

  • Retrospettive: ponendo 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 eseguite 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 intervalli regolari.

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

    • Revisioni operative: in genere vengono mantenute mensilmente e includono rappresentanti di un flusso di valori intero. Estendendo un portfolio di progetti e altre iniziative e usando dati oggettivi, 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 monitoraggio dei miglioramenti: buone idee per migliorare i processi possono derivare da qualsiasi elemento in qualsiasi momento. Acquisire queste idee per discutere e decidere come agire rapidamente su di essi è una chiave per supportare gli sforzi di miglioramento dei processi.

    Una lavagna fornisce qualsiasi mezzo semplice e visivo con cui catturare idee. Inoltre, è possibile creare un team di rilevamento dei miglioramenti e acquisire idee tracciate su una lavagna 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 Agile interno per supportare i team che adottano le 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

Poiché la quantità di software, funzionalità e complessità aumentano, è 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 l'attivazione delle funzionalità agli utenti iniziali per ottenere commenti e suggerimenti lavorativi.
  • Training di rilascio: fornire un altro tipo di cadenza per offrire una o più funzionalità. I team di funzionalità comprendono la pianificazione preliminare del push delle nuove funzionalità e del piano correttamente. I treni di rilascio possono corrispondere alla stessa cadenza sprint stabilita per l'organizzazione o si verificano in una cadenza diversa. Vedere Scaled Agile Framework per come configurare gli sprint e rilasciare i training.
  • Integrazione continua: adottare processi che eliminano il lavoro manuale e automatizzano invece il flusso di software attraverso il test, la compilazione e la distribuzione dei cicli.
  • 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 sulla scalabilità degli strumenti Agile negli articoli seguenti:

Risorse del settore

Procedure che non ridimensionano

  • Stima di iniziative di grandi dimensioni: parte dei metodi di progetto a cascata implicano la stima delle risorse e delle pianificazioni. Le iniziative più grandi, meno probabilmente queste stime erano di qualsiasi valore. Man mano che i progetti aumentano, i rischi e gli ostacoli imprevisti 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 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 intervallo è problematico. I team variano nel modo in cui stimano il loro lavoro e tali variazioni aumentano nel tempo.
  • Soluzioni prescrittive top-down: una dimensione non è adatta a tutte e una soluzione in genere non è adatta a tutti i team. Il supporto dell'autonomia del team significa consentire ai team di trovare soluzioni personalizzate.