Scalabilità agile: procedure per la scalabilità

Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

Enterprise le organizzazioni adottano le procedure Agile per diversi motivi. Prime tra queste includono:

  • Ridurre il time-to-market e accelerare la distribuzione del prodotto
  • Migliorare l'efficacia dell'organizzazione per gestire le priorità mutevoli
  • Migliorare la qualità del software e la prevedibilità della distribuzione
  • Migliorare la visibilità del progetto e ridurre i rischi del progetto

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

  • Qual è l'aspetto del successo per l'utente, i team e l'organizzazione? Cosa interessa di più: recapito in tempo? 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 fanno 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 ritmo e flusso all'interno di organizzazioni più grandi includono:

  • Cadenza condivisa: sprint e rilasci regolari stabiliscono il ritmo dell'azienda. Il lavoro di tutti i team in una cadenza condivisa consente di coordinare e collaborare.
  • Messaggi di posta elettronica 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.
  • Presentare le riunioni: per informare altri team e ottenere feedback sul software in fase di sviluppo, i team mostrano il lavoro svolto. Condurre queste riunioni a intervalli regolari durante tutto 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 favorire la gestione della disciplina dei bug, condividere periodicamente 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.

Clienti entusiasti

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 nei set di funzionalità di cui è proprietario.

  • Feedback continuo: creare cicli di feedback dei clienti. Queste possono assumere molte forme:
    • Voce del cliente: consente ai clienti di fornire commenti e suggerimenti, aggiungere idee e votare sulle funzionalità di nuova generazione. Questa operazione viene spesso eseguita tramite un sito Web dedicato.
    • Commenti e suggerimenti sul prodotto: i pulsanti di feedback nel prodotto sono un altro modo per inviare commenti e suggerimenti sull'esperienza del prodotto o sulle funzionalità specifiche.
    • Demo dei clienti: le demo pianificate regolarmente che inviano commenti e suggerimenti ai clienti possono aiutare a modellare i prodotti di nuova generazione e a tenere traccia delle applicazioni che i clienti vogliono usare.
  • Programmi di adozione anticipati: tali programmi devono essere sviluppati con l'idea che tutti i team potrebbero voler partecipare come punto. Gli utenti che adottano in anticipo ottengono l'accesso alle prime versioni del software funzionante, che possono quindi fornire commenti e suggerimenti. Spesso questi programmi funzionano attivando i flag di funzionalità select per un early adopter di lavoro.
  • Decisioni guidate sui dati: consente di instrumentare il prodotto per ottenere dati utili e di testare varie ipotesi. Aiuta a ottenere una cultura sperimentale che esezioni l'apprendimento.

Migliorare la visibilità del progetto

Maggiore è l'approfondimento che l'utente e i team hanno sull'obiettivo, sulla visione e sull'avanzamento del lavoro in corso, più è possibile'ridurre i rischi e gestire le dipendenze.

  • Struttura del team: indipendentemente dalla dimensione dell'organizzazione, strutturando l'organizzazione in base a piccoli team di 6-9 scale. Creare team di funzionalità verticali e autonomi raggruppati in aree di gestione del portfolio.
  • Struttura di suddivisione del lavoro: la suddivisione di obiettivi, funzionalità o requisiti di grandi dimensioni in requisiti più piccoli rimane una stabile gestione dei progetti. Suddividendo il lavoro in attività di dimensioni simili, i team possono effettuare stime migliori e identificare rischi e dipendenze.
  • Viste consolidate: usare gli strumenti di rilevamento online per aggregare il lavoro per acquisire informazioni tra i team. Creare dashboard per visualizzare lo stato di avanzamento e le tendenze.
  • Verifiche dell'esperienza: queste riunioni, tenute prima dell'inizio dello sviluppo su una funzionalità, vengono usate per istruire la leadership su scenari e priorità, raccogliere commenti e suggerimenti, impostare aspettative ed inviare eventuali problemi tra team sulla funzionalità.

Forza lavoro produttiva

Alcune specifiche procedure Agile che scalano bene e portano a dipendenti soddisfatti, impegnati e produttivi includono:

  • Leadership incorporata: consente ai team e ai leader all'interno dell'organizzazione di auto-organizzare e gestire il più possibile. L'autonomia del team aumenta l'efficacia del team di agilità aziendale. Assicurarsi che i team hanno la sponsorizzazione aziendale necessaria per avere successo.
  • Stand-up giornalieri: in caso contrario, le riunioni Scrum consentono ai team di concentrarsi su ciò che devono fare ogni giorno per ottimizzare la capacità di soddisfare gli impegni di sprint. Con l'aumentare delle dimensioni delle organizzazioni, è consigliabile valutare la possibilità di sfalsare queste riunioni in modo che la partecipazione tra team possa verificarsi in base alle esigenze.
  • Scrum of scrums ( Scrum di scrum): i membri giornalieri di membri di team Agile diversi si riuniranno 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 tra i team: fornire e invitare i team a condividere le proprie procedure e linee guida, a cui possono accedere insieme ad altri team tramite la rete aziendale. Gli strumenti comuni usati a questo scopo includono wiki del team, OneNotes o siti markdown.
  • Collaborazione: favorire comunicazioni informali da team a team e collaborazione all'interno del team. Le procedure di istituzionalizzazione, ad esempio le revisioni del codice, le revisioni di progettazione e le specifiche, non solo aumentano la collaborazione tra i team, ma consentono di sviluppare competenze individuali e aziendali complessive.

Cultura dell'organizzazione

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

  • Retrospettive: ponendo domande quali: "What went well?", "What should we do differently?", and "What should we stop doing?" aiutare i team a riflettere su come possono migliorare i processi e le procedure. Le retrospettive aiutano i team a capire cosa funziona bene e cosa richiede miglioramenti. Le retrospettive possono essere eseguite in qualsiasi momento e ovunque. Tuttavia, l'istituzionalizzazione di alcune retrospettive a cadenza regolare consente di istituzionalizzare le procedure di miglioramento continuo. Ad esempio:

    • Le retrospettive sprint possono aiutare i team a identificare le aree da migliorare a cadenza regolare.

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

    • Revisioni operative: vengono in genere tenute mensilmente e includono i rappresentanti di un intero flusso di valori. Estendendo un portfolio di progetti e altre iniziative e usando dati oggettivi e 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 retrospettive, vedere Agile Retrospective Resource Wiki. Vedere anche l'estensione Marketplace Retrospectives.

  • Scheda di rilevamento del miglioramento: le buone idee per migliorare i processi possono derivare da qualsiasi processo in qualsiasi momento. L'acquisizione di queste idee per discutere e decidere come agire in modo corretto è una chiave per supportare le attività di miglioramento dei processi.

    Una lavagna bianca offre qualsiasi mezzo semplice e visivo con cui acquisire idee. È anche possibile creare un team di rilevamento del miglioramento e acquisire idee da tenere traccia in una scheda Kanban elettronica.

  • Condivisione in modo istituzionale: la condivisione delle procedure consigliate e la comunicazione di idee consentono a tutti i team all'interno di un'organizzazione di crescere e migliorare. Lo sviluppo di una cultura dell'apprendimento è fondamentale per supportare questa e altre attività di miglioramento continuo. Alcune idee da considerare:

    • Wiki in-house

    • Liste di distribuzione all'interno

    • Settimane di Hackathon o tempo di hacking del 10%

    • Team di supporto agile interno per supportare i team che adottano le procedure Agile

      Culture Game offre una buona risorsa per i manager Agile per aiutare i team ad adottare Agile e condividere le procedure consigliate.

  • Community di pratica: supporto di discipline comuni interne (ad esempio, amministratori di database, 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 alla scala temporale più breve."
"Il software funzionante è la misura principale dello stato di avanzamento".
- Manifesto Agile

Con l'aumentare della quantità di software, funzionalità e complessità, è necessario adottare procedure che consentono di produrre soluzioni utilizzabili.

  • Flag di funzionalità: usare i flag di funzionalità per abilitare o disabilitare l'accesso a funzionalità diverse. Fornire supporto per l'attivazione delle funzionalità ai primi utenti per ottenere commenti e suggerimenti sul lavoro.
  • Release trains(Versione: fornisce un altro tipo di cadenza) per offrire una o più funzionalità. I team delle funzionalità comprendono la pianificazione pre-pianificata per l'estrazione di nuove funzionalità e pianificano di conseguenza. I programmi di rilascio possono corrispondere alla stessa cadenza dello sprint stabilita per l'organizzazione o essere eseguiti con una cadenza diversa. Vedere Scaled Agile Framework (Framework Agile ridimensionato) per informazioni su come configurare sprint e release trains.
  • 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 interna: è possibile portare il valore e gli ethos sviluppati nella community del software open source ai team di sviluppo interni.

Oltre alle procedure indicate in precedenza, negli argomenti seguenti sono disponibili indicazioni aggiuntive sul ridimensionamento degli strumenti Agile:

Risorse del settore

Procedure che non vengono ridimensionate

  • Stima di iniziative di grandi dimensioni: parte dei metodi di progetto a cascata comportava la stima di risorse e pianificazioni. Più grandi sono le iniziative, minore è la probabilità che queste stime siano di qualsiasi valore. Con l'aumentare dei progetti, possono verificarsi rischi e problemi imprevisti e ostacoli, invalidando molte stime.
  • Velocità: anche se 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 diversi team per eseguire in modo affidabile previsioni a lungo raggio è problematico. Teams variano nel modo in cui stimano il lavoro e tali variazioni aumentano nel tempo.
  • Soluzioni prescrittive dall'alto verso il basso: una dimensione non è adatta a tutte e una soluzione in genere non è adatta a tutti i team. Supportare l'autonomia dei team significa consentire ai team di trovare le proprie soluzioni.