Close

Topologie dei team

In che modo quattro topologie fondamentali influiscono su una trasformazione DevOps.

Ian Buchanan

Principal Solutions Engineer

Contributo editoriale: Shana Vu

Scopri i vantaggi dei team allineati al flusso e in che modo lavorano con i team della piattaforma, i team dei sottosistemi e i team abilitanti per offrire valore ai clienti.

Introduzione alle topologie dei team


Ai team di ingegneri viene richiesto di muoversi più velocemente che mai per offrire valore ai propri clienti. L'aumento dei servizi cloud, SaaS e sempre attivi significa che i clienti si aspettano nuove funzioni, meno bug e tempi di attività del 99,99% (o superiori).

Per stare al passo con queste esigenze, le organizzazioni hanno adottato pratiche Agile e, più recentemente, pratiche DevOps, che promettono un time-to-market/lead time più rapido, miglioramento della frequenza di distribuzione, cultura del team migliore e maggiore collaborazione tra team/reparti.

Sebbene l'adozione delle pratiche DevOps sia più facile a dirsi che a farsi, il libro Team Topologies offre indicazioni approfondite sui modi in cui le organizzazioni possono integrare DevOps nella propria azienda, incluso il tipo di team che potrebbe essere più efficace. Questo libro offre un punto di partenza per capire il concetto di team di Atlassian. Invece di ribadire i loro risultati, vogliamo condividere la nostra prospettiva sui tipi di team.

Il primo passo verso una trasformazione DevOps comporta l'identificazione della struttura organizzativa esistente. Tuttavia, oggi in qualsiasi azienda sono presenti numerosi tipi di team diversi e, in alcuni casi, singoli team che assumono più ruoli e responsabilità. A causa di questa proliferazione di titoli è difficile per la leadership avere una vista d'insieme del panorama organizzativo e rispondere a domande come:

scopri la soluzione

Strumenti DevOps per tutto il team

materiale correlato

Crea una cultura DevOps

  • Abbiamo i team giusti?
  • In alcune aree mancano delle capacità a cui nessun team sopperisce?
  • I team hanno l'equilibrio necessario tra autonomia e supporto da parte di altri team?

I responsabili dello sviluppo e delle operazioni possono capire meglio se dispongono dei team giusti esaminando la loro organizzazione nell'ottica delle topologie dei team. Consigliamo di ridurre il numero di variazioni del team a quattro topologie di team fondamentali che sono facilmente assimilabili sia da parte dell'alta dirigenza che dagli stessi membri del team:

  • Team allineato al flusso
  • Team della piattaforma
  • Team di sottosistemi complicati
  • Team abilitante

Tieni presente che questi tipi di team assumono forme diverse a seconda delle dimensioni e della maturità dell'azienda. In realtà, la combinazione di più tipi di team, o di un team che si presta a svolgere le funzioni di un altro team, rappresenta spesso l'approccio migliore.

Team allineato al flusso

I team allineati al flusso si concentrano su un unico flusso di lavoro di grande impatto. Può trattarsi di un singolo prodotto o servizio, di un singolo set di funzioni, di un singolo percorso utente o di un singolo utente tipo. Il team è autorizzato a creare e fornire valore per il cliente o l'utente nel modo più rapido, sicuro e indipendente possibile, senza dover trasferire parte del lavoro ad altri team.

Poiché i team allineati al flusso lavorano sull'intera gamma di consegna, sono, per necessità, più vicini al cliente e di solito sono già Agile. Questo team tiene conto del feedback dei clienti nei cicli di sviluppo, mantenendo allo stesso tempo il software in produzione.

Mentre i team allineati al flusso sono comuni in molte aziende software, altre organizzazioni potrebbero avere maggiore familiarità con le strutture dei team organizzate per funzione (ad es. team separati per l'ingegneria, la progettazione, il controllo di qualità), invece che con il flusso di distribuzione.

Poiché il team allineato al flusso è il tipo di team più comune nelle organizzazioni, il ruolo degli altri team è definito rispetto al primo. I team allineati al flusso dovrebbero contattare regolarmente i team di assistenza (team del sottosistema complicato, abilitante e della piattaforma) per migliorare continuamente la velocità di consegna e la qualità dei loro prodotti e servizi.


Stream-aligned teams focus on a single, impactful stream of work. It can be a single product or service, a single set of features, a single user journey, or a single user persona. The team is empowered to build and deliver customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform parts of the work.

Because stream-aligned teams work on the full spectrum of delivery, they are, by necessity, closer to the customer and usually already agile. This team incorporates customer feedback in development cycles, while maintaining software in production. 

While stream-aligned teams are common at many software companies, other organizations may be more familiar with team structures organized by function (i.e. separate teams for engineering, design, QA), rather than the delivery stream. 

Since the stream-aligned team is the most common team type in organizations, the role of other teams is defined relative to stream-aligned teams. Stream-aligned teams should regularly reach out to the following supporting teams (complicated subsystem, enabling, and platform) to continuously improve the speed of delivery and quality of their products and services.

Team della piattaforma

I team della piattaforma consentono ai team allineati al flusso di operare con una notevole dose di autonomia. Mentre il team allineato al flusso mantiene la piena responsabilità della creazione, dell'esecuzione e della correzione di un'applicazione in produzione, il team della piattaforma fornisce servizi interni che il team allineato al flusso può utilizzare.

I team della piattaforma creano funzionalità che possono essere utilizzate da numerosi team allineati al flusso, con un sovraccarico minimo. Ottimizzando un prodotto, i team della piattaforma riducono al minimo le risorse e i carichi cognitivi del team allineato al flusso. Ciò offre vantaggi anche agli utenti finali, poiché i team della piattaforma possono creare un'esperienza coerente che si estende a diverse esperienze utente o a diversi prodotti.

In Atlassian i team della piattaforma creano servizi utilizzati da tutti i nostri prodotti (come la gestione delle identità) e sono tenuti a fornire documentazione, assistenza e consulenza per i team allineati al flusso.


Platform teams enable stream-aligned teams to deliver work with substantial autonomy. While the stream-aligned team maintains full ownership of building, running, and fixing an application in production, the platform team provides internal services that the stream-aligned team can use.

Platform teams create capabilities that can be used by numerous stream-aligned teams, with little overhead. By optimizing a product, platform teams minimize resources and cognitive loads of the stream-aligned team. This also benefits end-users too, since platform teams can create a cohesive experience that spans across different user experiences or products.

Here at Atlassian, platform teams build services used by all of our products (like identity management) and are expected to provide documentation, support, and consultation for stream-aligned teams.

Team di sottosistemi complicati

Un team di sottosistemi complicati è responsabile della creazione e della manutenzione di una parte del sistema che dipende da competenze e conoscenze specifiche. La maggior parte dei membri del team deve essere specializzata in una particolare area di conoscenza per comprendere e apportare modifiche al sottosistema.

L'obiettivo di questo team è ridurre il carico dei team allineati al flusso che lavorano su sistemi che includono o utilizzano il sottosistema. Con l'esperienza e le capacità del team di sottosistemi complicati, i team allineati al flusso non devono sviluppare competenze in aree eccessivamente complicate per il loro lavoro quotidiano. I membri di questo team possono avere conoscenze specializzate in determinati microservizi (ad esempio un servizio di fatturazione), algoritmi o persino intelligenza artificiale.

Un'insidia comune è quella di includere specialisti in ogni team allineato al flusso che utilizza il sottosistema. Per quanto questa scelta possa sembrare efficiente, in ultima analisi non è conveniente in termini di costo e non rientra nell'ambito di competenza di un team allineato al flusso.


A complicated-subsystem team is responsible for building and maintaining a part of the system that depends on specific skills and knowledge. Most team members must be specialists in a particular area of knowledge to understand and make changes to the subsystem.

The goal of this team is to reduce the load of stream-aligned teams who work on systems that include or use the subsystem. With the complicated-subsystem team’s expertise and capabilities, stream-aligned teams don’t have to build capabilities in areas too complicated for their daily work. Team members from this team may have specialized knowledge in certain microservices (i.e. a billing service), algorithms, or even artificial intelligence. 

A common pitfall is to embed specialists in every stream-aligned team who uses the subsystem. While this may seem efficient, it’s ultimately not cost-effective and out of scope for a stream-aligned team. 

Team abilitante

I team allineati al flusso sono sotto costante pressione per fornire risultati e rispondere rapidamente al cambiamento, pertanto hanno difficoltà a trovare il tempo per la ricerca, l'apprendimento e l'esercizio di nuove competenze.

Un team abilitante costituito da specialisti in un determinato dominio tecnico (o prodotto) aiuta a colmare questa lacuna di capacità. Questi team si concentrano sulla ricerca e sulla sperimentazione per fornire consigli informati su strumenti, framework e scelte di ecosistemi che influiscono sullo stack di strumenti.

Ciò offre ai team allineati al flusso il tempo di acquisire e modificare le capacità senza sottrarre tempo ai loro obiettivi primari. Il team abilitante cerca principalmente di aumentare l'autonomia dei team allineati al flusso, accrescendone le capacità con particolare attenzione ai problemi, invece che alle soluzioni.

Se un team abilitante svolge bene il suo lavoro, il team assistito diventa autonomo dopo poche settimane. Il team abilitante non dovrebbe mai favorire una dipendenza permanente.


Stream-aligned teams are under constant pressure to deliver and respond to change quickly, making it challenging to find time for researching, learning, and practicing new skills.

An enabling team composed of specialists in a given technical (or product) domain help bridge this capability gap. These teams focus on research and experimentation to make informed suggestions about tooling, frameworks, and ecosystem choices that affect the tool stack.

This gives stream-aligned teams time to acquire and evolve capabilities without taking time away from their primary goals. The enabling team seeks to primarily increase the autonomy of stream-aligned teams by growing their capabilities with a focus on problems, rather than solutions.

If an enabling team does its job well, the team it assists should no longer need help after a few weeks or so. The enabling team should never work on a permanent dependency.

Are you a stream-aligned team?


The following questions should be asked to determine if you have a stream-aligned team:

Does your team aim to produce a steady flow of features?
Mature teams release multiple times per week, and in some cases, multiple times per day. In pursuit of this goal, mature teams should use continuous integration and continuous delivery (CI/CD) to ship features frequently.

Is your team quick to change direction based on feedback (customer or internal) from the latest changes?
It’s often best to use an experimental approach to product evolution. Mature DevOps processes include automated testing to ensure quality code shipments. Yet experimentation goes beyond simple unit or acceptance tests. You can ensure that your products deliver the most value to customers by using feature flags to automate roll-outs to a subset of users, alpha and beta releases to solicit and measure user feedback and behavior, and qualitative continuous feedback via comments, support tickets, and community forums.

Does your team have minimal hand-offs of work to other teams?
This should be true in two ways. Your team should be self-contained and work should happen with immediate teammates to ensure fast delivery. Beyond work scope, minimal hand-offs can also take the form of automated processes. Automating your development cycle ensures that moving things along is a seamless process, regardless if the next step is an action like an automated test or merge to main, or an actual human.

Bonus points if….
Does your team have time to address code quality changes (a.k.a. “tech debt”) to ensure changes are safe and easy? 
Mature teams rely on trunk-based development and CI/CD practices to maintain their codebase. Capacity planning should include dedicated time to address tech debt. Plus, large-scale projects that address underlying infrastructure or platform issues should receive as much attention as feature development.

Is your team evaluated by the right metrics?
Beyond how fast your team ships, it should also consider team-health and technical quality metrics in their measures of success.

Regarding the last question around measurement, DevOps teams have traditionally considered the four key DevOps Research and Assessment (DORA) metrics in their definition of “success”:

  • Deployment frequency - How often an organization successfully releases to production
  • Lead time for changes - The amount of time it takes a commit to get into production
  • Change failure rate - The percentage of deployments that cause a failure in production
  • Time to restore service - How long it takes an organization to recover from a failure in production

In addition to these metrics specified by DORA, Atlassian found that high-performing, stream-aligned teams also monitor these attributes

  • Balanced team -  Your team has a diverse set of skills and perspectives 
  • Full-time owner - A full-time owner ensures that the nuclear team and cross-functional participants know who to ask questions to and how to make decisions related to projects owned by the team 
  • Shared understanding - There is a shared understanding of the requirements, along with the definition for values and metrics for success
  • A focus on value and metrics -  Your team has north stars that guide which tasks to tackle in order to move projects to release  
  • Proof-of-concept - Having a real artifact to spar and test assumptions with helps a team constantly iterate and improve 
  • Managed dependencies to maintain velocity - Understanding managed dependencies keeps blockers at bay and helps the team maintain velocity

 

In conclusione...

DevOps non è una destinazione, ma un percorso di costante miglioramento degli strumenti, della cultura del team e delle pratiche. Se stai compiendo i primi passi nel percorso DevOps, inizia orientando i tuoi obiettivi per offrire valore ai clienti. Man mano che maturi, aggiungi l'automazione ai tuoi strumenti e processi. Infine, quando i membri del tuo team diventano professionisti avanzati, includi l'osservabilità per assicurarti di monitorare, misurare e migliorare gli aspetti appropriati.


DevOps is not a destination, but a journey of constant improvement of tools, team culture, and practices. If you’re new to DevOps, start by orienting your goals to deliver value to customers. As you mature, add automation to your tools and processes. And finally, when your team becomes advanced practitioners, incorporate observability to ensure you’re monitoring, measuring, and improving on the right things.

Ian Buchanan
Ian Buchanan

Ian Buchanan è Principal Solutions Engineer per DevOps presso Atlassian, dove si occupa della community DevOps emergente e dell'applicazione di Jira, Bitbucket e Bamboo per migliorare la continuous integration e la continuous delivery. Ian Buchanan vanta una lunga e vasta esperienza delle tecnologie Java e .NET ed è noto per essere un promotore delle pratiche Lean e Agile nelle aziende di grandi dimensioni.

Nel corso della sua carriera, ha gestito con successo strumenti per lo sviluppo software aziendale in tutte le fasi del loro ciclo di vita, dall'inizio alla fine. Si è occupato del miglioramento dei processi a livello di organizzazione riuscendo a ottenere maggiore produttività, qualità superiore e migliore soddisfazione del cliente. Ha creato team Agile multinazionali in cui viene valorizzata la capacità di gestire e organizzare autonomamente il lavoro. Quando non parla o codifica, Ian si dedica alle sue passioni: parser, metaprogrammazione e linguaggi specifici di dominio.


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.

Illustrazione su Devops

Community DevOps

Illustrazione su Devops

Percorso di apprendimento DevOps

Illustrazione di una mappa

Inizia gratis

Iscriviti alla nostra newsletter DevOps

Thank you for signing up