Velocity negativa: come innalzare il limite di complessità
Uno degli obiettivi più comuni di un'organizzazione di progettazione è fornire velocemente software di qualità elevata.
Scopri la vision aziendale del CIO o del CTO e senti cos'hanno da dire. Probabilmente stanno "inseguendo" una permutazione di questo obiettivo. Sebbene sia un obiettivo comune, c'è un ampio divario tra i team che raggiungono il nirvana e quelli bloccati nel limbo della distribuzione del software. Alcuni team inseriscono costantemente nuovo codice nella produzione, con pochi imprevisti o impatti negativi sui clienti, mentre altri trovano difficoltà nei rilasci trimestrali.
Uno degli obiettivi più comuni di un'organizzazione di progettazione è fornire velocemente software di qualità elevata.
Scopri la vision aziendale del CIO o del CTO e senti cos'hanno da dire. Probabilmente stanno "inseguendo" una permutazione di questo obiettivo. Sebbene sia un obiettivo comune, c'è un ampio divario tra i team che raggiungono il nirvana e quelli bloccati nel limbo della distribuzione del software. Alcuni team inseriscono costantemente nuovo codice nella produzione, con pochi imprevisti o impatti negativi sui clienti, mentre altri trovano difficoltà nei rilasci trimestrali.
Qual è la causa di questa discrepanza nelle prestazioni?
La complessità nella distribuzione è la differenza tra chi riesce e chi non riesce a fornire velocemente software di qualità elevata, tra chi canta vittoria dopo un rilascio di successo ogni settimana e un team di distribuzione software demotivato e frustrato che, dopo mesi di lavoro sull'ultimo rilascio, ottiene come unico risultato sei nuovi bug e un rollback.
Confronta la velocità e la qualità con cui le startup e le grandi organizzazioni affermate rilasciano nuovi prodotti e funzionalità. Nel settore finanziario, ad esempio, le startup fintech nell'ultimo decennio hanno ridotto la quota di mercato delle banche principali. Le grandi banche citano spesso i facili vantaggi delle startup fintech, che operano con meno supervisione normativa e senza dover mantenere sistemi di applicazioni monolitici preesistenti. Le dimensioni ridotte del team consentono una maggiore agilità e la capacità di adattarsi in base alle esigenze dei clienti. Essenzialmente le fintech, non essendo complesse come le banche consolidate, sono in grado di muoversi più velocemente e con meno rischi. La complessità non è sempre un aspetto negativo, anche se può rallentare i team software.
materiale correlato
Tieni sotto controllo la proliferazione di software
Scopri la soluzione
Gestisci i componenti con Compass
Complessità nella distribuzione del software
La complessità può essere positiva: è estremamente gratificante risolvere problemi intricati, motiva i team ad affrontare le sfide e i problemi e a ribaltare un settore. Ma c'è un punto in cui la complessità non consiste più nella risoluzione di un problema difficile e provoca un impatto negativo sui team software.
La complessità organizzativa riveste un ruolo chiave nel ridurre l'efficacia dei team software. La complessità, per definizione, è lo stato di avere molte parti diverse collegate o correlate tra loro in modo complicato. In termini pratici, la complessità organizzativa è l'aggregato di informazioni, dipendenze, modifiche, altri team, strumenti e richieste, che i team software devono esplorare quando si interfacciano con il resto dell'organizzazione.
Livelli più elevati di complessità organizzativa rendono più difficile fornire software di alta qualità in tempi rapidi, perché i team dedicano più tempo a orientarsi nell'organizzazione che a risolvere problemi intricati. Le organizzazioni in crescita scoprono presto che i team software hanno un limite di complessità: la quantità di complessità che i team sono in grado di gestire prima che ciò influisca sulla soddisfazione lavorativa, sulla qualità e sulla velocità del software prodotto. Sembrerebbe, quindi, che la riduzione della complessità organizzativa consenta ai team di concentrarsi sulla risoluzione di problemi intricati e sulla fornitura di software di qualità superiore e in meno tempo. Vediamo perché non è necessariamente così.
Impatto della complessità su un team software
L'introduzione di un'architettura di microservizi fornisce un buon esempio dell'impatto che la complessità ha sui team software. La definizione di complessità è anche una descrizione perfetta di un'architettura di microservizi: lo stato di avere molte parti diverse collegate o correlate tra loro in modo complicato. È vero che i microservizi consentono ai team di muoversi in modo indipendente, distribuire più velocemente e far crescere i sistemi in sicurezza (per questo sono così apprezzati), tuttavia ciò aggiunge una complessità significativa.
Analizziamo l'efficacia dei team software di Atlassian durante il percorso pluriennale verso l'adozione di un'architettura di microservizi.
All'inizio del percorso verso i microservizi di Atlassian, le metriche DORA sembravano perfette. Frammenti di codice più piccoli hanno semplificato il test e la distribuzione, consentendo ai team di muoversi in sicurezza e più velocemente aumentando anche la soddisfazione sul lavoro. Durante questa fase, i team hanno raccolto i frutti previsti da un'architettura di microservizi. Sebbene la complessità sia aumentata, non abbiamo registrato effetti negativi sui team.
Best for CI/CD: Bitbucket
Visti i vantaggi, molte organizzazioni hanno iniziato ad adottare un'architettura di microservizi, che di conseguenza ha aumentato la complessità organizzativa. Più team autonomi richiedevano maggiore collaborazione, più microservizi implicavano maggiori dipendenze. Il ritmo del cambiamento è salito alle stelle: tutti segni della proliferazione di software. Per i team software l'aumento della complessità ha comportato una riduzione dell'efficacia, come indicato da un calo della velocity delle modifiche, rendendo il carico cognitivo un ostacolo.
Best version control system: Git
Poiché non sono stati presi provvedimenti, l'organizzazione ha raggiunto alla fine il valore limite di complessità e l'efficacia del team software è diminuita. I vantaggi in materia di velocità, autonomia e qualità, riscontrati all'inizio dell'adozione dei microservizi, si sono annullati, con un comprensibile calo della soddisfazione da parte degli sviluppatori. Questi segnali indicano un'organizzazione che ha raggiunto il limite di complessità. Il team software dedica più impegno a destreggiarsi tra le complessità organizzative che a risolvere problemi intricati: è una situazione difficile.
Best for application deployment: Ansible
Poiché non sono stati presi provvedimenti, l'organizzazione ha raggiunto alla fine il valore limite di complessità e l'efficacia del team software è diminuita. I vantaggi in materia di velocità, autonomia e qualità, riscontrati all'inizio dell'adozione dei microservizi, si sono annullati, con un comprensibile calo della soddisfazione da parte degli sviluppatori. Questi segnali indicano un'organizzazione che ha raggiunto il limite di complessità. Il team software dedica più impegno a destreggiarsi tra le complessità organizzative che a risolvere problemi intricati: è una situazione difficile.
Best for infrastructure automation: Chef
Poiché non sono stati presi provvedimenti, l'organizzazione ha raggiunto alla fine il valore limite di complessità e l'efficacia del team software è diminuita. I vantaggi in materia di velocità, autonomia e qualità, riscontrati all'inizio dell'adozione dei microservizi, si sono annullati, con un comprensibile calo della soddisfazione da parte degli sviluppatori. Questi segnali indicano un'organizzazione che ha raggiunto il limite di complessità. Il team software dedica più impegno a destreggiarsi tra le complessità organizzative che a risolvere problemi intricati: è una situazione difficile.
Best for large-scale configurations: Puppet
Poiché non sono stati presi provvedimenti, l'organizzazione ha raggiunto alla fine il valore limite di complessità e l'efficacia del team software è diminuita. I vantaggi in materia di velocità, autonomia e qualità, riscontrati all'inizio dell'adozione dei microservizi, si sono annullati, con un comprensibile calo della soddisfazione da parte degli sviluppatori. Questi segnali indicano un'organizzazione che ha raggiunto il limite di complessità. Il team software dedica più impegno a destreggiarsi tra le complessità organizzative che a risolvere problemi intricati: è una situazione difficile.
Best for automating workflows: Bitbucket Pipelines
Poiché non sono stati presi provvedimenti, l'organizzazione ha raggiunto alla fine il valore limite di complessità e l'efficacia del team software è diminuita. I vantaggi in materia di velocità, autonomia e qualità, riscontrati all'inizio dell'adozione dei microservizi, si sono annullati, con un comprensibile calo della soddisfazione da parte degli sviluppatori. Questi segnali indicano un'organizzazione che ha raggiunto il limite di complessità. Il team software dedica più impegno a destreggiarsi tra le complessità organizzative che a risolvere problemi intricati: è una situazione difficile.
Best for high-speed and scalability: SaltStack
Poiché non sono stati presi provvedimenti, l'organizzazione ha raggiunto alla fine il valore limite di complessità e l'efficacia del team software è diminuita. I vantaggi in materia di velocità, autonomia e qualità, riscontrati all'inizio dell'adozione dei microservizi, si sono annullati, con un comprensibile calo della soddisfazione da parte degli sviluppatori. Questi segnali indicano un'organizzazione che ha raggiunto il limite di complessità. Il team software dedica più impegno a destreggiarsi tra le complessità organizzative che a risolvere problemi intricati: è una situazione difficile.
Best for problem management: Jira Service Management
Poiché non sono stati presi provvedimenti, l'organizzazione ha raggiunto alla fine il valore limite di complessità e l'efficacia del team software è diminuita. I vantaggi in materia di velocità, autonomia e qualità, riscontrati all'inizio dell'adozione dei microservizi, si sono annullati, con un comprensibile calo della soddisfazione da parte degli sviluppatori. Questi segnali indicano un'organizzazione che ha raggiunto il limite di complessità. Il team software dedica più impegno a destreggiarsi tra le complessità organizzative che a risolvere problemi intricati: è una situazione difficile.
Best for container orchestration: Kubernetes
Poiché non sono stati presi provvedimenti, l'organizzazione ha raggiunto alla fine il valore limite di complessità e l'efficacia del team software è diminuita. I vantaggi in materia di velocità, autonomia e qualità, riscontrati all'inizio dell'adozione dei microservizi, si sono annullati, con un comprensibile calo della soddisfazione da parte degli sviluppatori. Questi segnali indicano un'organizzazione che ha raggiunto il limite di complessità. Il team software dedica più impegno a destreggiarsi tra le complessità organizzative che a risolvere problemi intricati: è una situazione difficile.
Come capire se ti stai avvicinando al limite di complessità
Raggiungere il limite di complessità può sembrare inevitabile, ma alcuni segnali indicano ai team che si stanno avvicinando al limite. Non esiste una metrica assoluta che indichi quanto sia vicino il limite di complessità, ma è possibile capirlo grazie a questi indicatori.
L'indicatore più evidente che un team ha raggiunto il limite di complessità è quando dedica più tempo a gestire la complessità organizzativa che a risolvere i problemi intricati su cui dovrebbe concentrarsi. L'andamento dei lead time di DORA per le modifiche (velocità) e le metriche del tasso di errore delle modifiche (qualità) mostrano se i team rallentano o accelerano nel tempo. Anche se altri fattori influenzano queste metriche, sono un buon indicatore dell'efficacia del team.
La soddisfazione degli sviluppatori è un ulteriore indicatore della complessità organizzativa che i team software stanno gestendo. Gli sviluppatori, più di altri, preferiscono passare il tempo a risolvere problemi intricati piuttosto che affrontare attività inutili che intralciano il lavoro. La scarsa soddisfazione degli sviluppatori è un segnale che la complessità organizzativa rappresenta un problema per il team software.
La semplificazione è una strategia perdente
Quando le aziende si rendono conto che i team sono sopraffatti dalla complessità, spesso avviano un "progetto di semplificazione" per ripristinare la semplicità nell'organizzazione. La semplificazione è una strategia perdente perché la complessità aumenta più velocemente di quanto qualsiasi organizzazione possa semplificare il proprio ambiente e questi "progetti di semplificazione" operano proprio nell'ambiente complesso che mirano a semplificare.
La semplificazione generalmente inizia riducendo il numero di applicazioni, disattivando o consolidando ove possibile. La disattivazione di un'applicazione richiede che il team comprenda tutte le dipendenze a monte e a valle, chi utilizza l'applicazione, come sostituire la funzionalità, dove e come verranno archiviati o migrati i dati e che affronti una serie di altre complicazioni derivanti da questo tipo di attività. Sfortunatamente, i notevoli sforzi richiesti per ottenere questo risultato non sono ricompensati da una riduzione altrettanto significativa della complessità. C'è un limite alla quantità di applicazioni che un'azienda può disattivare senza influire sulle attività principali o sull'esperienza utente, ma non c'è limite al numero di nuovi componenti software che gli ingegneri possono creare. È probabile che nei 12 mesi necessari per disattivare un'applicazione siano stati creati centinaia di nuovi microservizi. Poiché un ambiente tecnologico sano cresce nel tempo, non è consigliabile limitarlo a un numero fisso di applicazioni o componenti software per ridurre la complessità.
I progetti di semplificazione includono in genere la rielaborazione della struttura organizzativa per eliminare la complessità nel flusso di comunicazione. Le strutture organizzative meno complesse prevedono team gerarchici di grandi dimensioni con tutto il personale co-ubicato. Le strutture organizzative più complesse coinvolgono team piccoli, distribuiti e autonomi. La legge di Conway mostra quanto sia probabile che i grandi team gerarchici producano applicazioni monolitiche, mentre i piccoli team distribuiti producano applicazioni utilizzando architetture modulari come i microservizi. La produzione di software di alta qualità in tempi rapidi è resa possibile da modelli di architettura modulare come quella di microservizi; una struttura organizzativa più complessa ha quindi maggiori probabilità di successo. Se da un lato "semplificare" la struttura organizzativa ne renda più facile la comprensione, dall'altro è controproducente per l'obiettivo finale del progetto di semplificazione.
La semplificazione è importante e vantaggiosa, ma sarebbe più utile integrarla come miglioramento continuo, per i team software e di team, piuttosto che come attività una tantum; nonostante possa ritardare il raggiungimento del limite di complessità, non riporterà un'organizzazione alla libertà e alla dinamicità proprie degli ambienti delle startup.
Innalzamento del limite di complessità
How do configuration management tools enhance collaboration in software teams?
Le organizzazioni devono aumentare il limite di complessità per ripristinare l'efficacia dei team software. Ciò significa essenzialmente aumentare la complessità organizzativa che ogni team può affrontare prima che influisca sulla soddisfazione lavorativa e sulla qualità e velocità con cui il team rilascia il software.
La progettazione della piattaforma è un concetto significativo nella ricerca di innalzare il limite di complessità di un'organizzazione. I team più efficienti di progettazione delle piattaforme si concentrano sulla riduzione del carico cognitivo dei team software astraendo la complessità organizzativa dal loro lavoro quotidiano. Se implementata correttamente, la progettazione della piattaforma consente ai team di riequilibrare la maggior parte degli sforzi per risolvere problemi intricati, dedicando meno tempo alla gestione della complessità organizzativa.
How do you start with Bitbucket for configuration management?
Per questo motivo Atlassian ha creato Compass, una piattaforma per l'esperienza di sviluppo. Compass aiuta a innalzare il limite di complessità consentendo ai team software di orientarsi facilmente nella complessità organizzativa attraverso il catalogo componenti, le metriche e le scorecard e di concentrarsi sulla creazione di una sana cultura di progettazione. L'aspetto principale è che la complessità organizzativa non si è ridotta all'interno di Atlassian, ma ha continuato a crescere man mano che l'organizzazione passava a un'architettura di microservizi in misura sempre maggiore. Il tempo che i team software impiegano per gestire la complessità è stato ridotto, il che costituisce la differenza tra un progetto di semplificazione e l'innalzamento del limite di complessità.
Anche se Atlassian conta oltre 10.000 dipendenti e più di 17.000 componenti software, gran parte dei nostri team software opera con la stessa libertà di una startup, fornendo velocemente software di qualità elevata. La chiave per il successo? Aumentare il limite di complessità per migliorare l'efficacia del team software.
Ecco due azioni per iniziare a innalzare il limite di complessità:
- Monitorare e valutare le metriche DORA. Come ti sembrano le metriche DORA per il tuo team? Se ancora non le stai monitorando, sono fornite pronte all'uso con Compass.
- Comprendere e valutare la soddisfazione degli sviluppatori. Come si trovano gli sviluppatori nei tuoi team software? La maggior parte delle organizzazioni effettua sondaggi sulla soddisfazione dei dipendenti. Per comprendere il livello di soddisfazione degli sviluppatori, esamina i risultati suddivisi per area funzionale. Le domande chiave includono la valutazione delle seguenti dichiarazioni:
- Il risultato finale è quello che mi aspettavo
- Riesco a gestire lo stress sul lavoro
- Sono consapevole che il mio lavoro contribuisce al raggiungimento degli obiettivi aziendali
In alternativa, Compass acquisisce queste informazioni durante il rituale CheckOps, in cui i team condividono le loro impressioni sull'ultima settimana e i dettagli sugli aspetti da migliorare.
L'innalzamento del limite di complessità richiede una combinazione di strumenti, processi e rituali. Una piattaforma per l'esperienza di sviluppo come Compass può aiutare a comprendere lo stato d'integrità del sistema, mappare le dipendenze e creare rituali continui, contribuendo a innalzare il limite di complessità e a sbloccare il potenziale dei team di distribuzione del software nella tua organizzazione.
Prova Compass gratuitamente oggi stesso.
Condividi l'articolo
Argomento successivo
Letture consigliate
Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.
Community di Compass
Tutorial: Creare un componente
