Artikelen
Tutorials
Interactieve handleidingen
Team Topologies
De invloed van vier fundamentele topologieën op een DevOps-transformatie.
Ian Buchanan
Principal Solutions Engineer
Redactionele bijdrage: Shana Vu
Bekijk meer informatie over de voordelen van op stream afgestemde teams, hoe ze werken met platformteams en subsysteemteams, en teams in staat stellen waarde te leveren aan klanten.
Inleiding tot 'Team Topologies'
Engineeringteams moeten sneller dan ooit zijn om waarde aan hun klanten te leveren. De opkomst van cloud-, SaaS- en 'Always-on'-services betekent dat klanten nieuwe functies, minder bugs en een uptime van 99,99% (of hoger) verwachten.
Om aan deze eisen te voldoen, hebben organisaties agile werkwijzen toegepast en onlangs ook DevOps-werkwijzen, waardoor de time-to-market/doorlooptijd sneller verloopt, de implementatiefrequentie verhoogd wordt, de teamcultuur verbetert en de samenwerking tussen teams/afdelingen toeneemt.
Het toepassen van DevOps-werkwijzen is gemakkelijker gezegd dan gedaan. Daarom bevat het boek Team Topologies handige manieren waarop organisaties DevOps in hun bedrijf kunnen implementeren, waaronder informatie over welke soort teams het effectiefst is. Dit boek geeft een uitgangspunt van de denkwijze van Atlassian over teams. In plaats van hun bevindingen te herhalen, willen we onze eigen kijk op de soorten teams geven.
De eerste stap naar een DevOps-transformatie is de identificatie van de bestaande organisatiestructuur. Bij elk bedrijf zijn er tegenwoordig echter veel verschillende soorten teams, en in sommige gevallen neemt één team meerdere rollen en verantwoordelijkheden op zich. Hierdoor is het voor managementteams moeilijk om de volledige organisatie in kaart te brengen en vragen te beantwoorden als:
oplossing bekijken
DevOps-tools voor het hele team
gerelateerde content
Een DevOps-cultuur creëren
- Hebben we de juiste teams?
- Hebben we een gebrek aan capaciteiten op bepaalde gebieden die niet door een team worden aangepakt?
- Hebben teams de nodige balans tussen zelfstandigheid en support van andere teams?
Ontwikkelings- en operationsleiders hebben meer inzicht of de juiste teams aanwezig zijn door naar hun organisatie te kijken door de 'Team Topologies'-lens. We raden aan om het aantal teamvariaties terug te brengen tot vier fundamentele 'Team Topologies' die duidelijk zijn voor zowel het hogere management als de teamleden zelf:
- Op stream afgestemd team
- Platformteam
- Gecompliceerd subsysteemteam
- Uitvoerend team
Houd er rekening mee dat deze soorten teams verschillende vormen hebben, afhankelijk van hoe groot en gevorderd het bedrijf is. In werkelijkheid is een combinatie van meerdere soorten teams of een team dat verandert in een ander team vaak de beste aanpak.
Op stream afgestemd team
Op stream afgestemde teams richten zich op één impactvolle werkstroom. Dit kan één product of service zijn, één set van functies, één gebruikerstraject of één gebruikerspersona. Het team is in staat om klant- of gebruikerswaarde zo snel, veilig en onafhankelijk mogelijk te ontwikkelen en te leveren, zonder dat andere teams onderdelen van het werk hoeven uit te voeren.
Op stream afgestemde teams werken aan het volledige spectrum van levering, staan per noodzaak dichter bij de klant en zijn meestal al agile. Dit team verwerkt feedback van klanten in ontwikkelingscycli, terwijl de software in productie blijft.
Hoewel op stream afgestemde teams bij veel softwarebedrijven gebruikelijk zijn, komen in andere organisaties beter vaak teamstructuren voor die zijn geordend op basis van functie (d.w.z. afzonderlijke teams voor engineering, design, QA), in plaats van de leveringsstroom.
Aangezien op stream afgestemde teams het meest voorkomen in organisaties, wordt de rol van andere teams gedefinieerd ten opzichte van op stream afgestemde teams. Op stream afgestemde teams moeten regelmatig contact opnemen met de volgende supportteams (gecompliceerd subsysteem, uitvoerend en platform) om de snelheid van levering en kwaliteit van hun producten en services voortdurend te verbeteren.
Platformteam
Platformteams stellen op stream afgestemde teams in staat om zelfstandig werk uit te voeren. Terwijl het op stream afgestemde team de volledige controle behoudt bij het ontwikkelen, uitvoeren en repareren van een applicatie in productie, biedt het platformteam interne services die het op stream afgestemde team kan gebruiken.
Platformteams creëren capaciteiten die kunnen worden gebruikt door talloze op stream afgestemde teams, met weinig overhead. Door een product te optimaliseren, kunnen platformteams middelen en cognitieve belastingen van het op stream afgestemde team minimaliseren. Dit komt ook ten goede aan eindgebruikers, omdat platformteams een samenhangende ervaring kunnen creëren die zich uitstrekt over verschillende gebruikerservaringen of producten.
Bij Atlassian ontwikkelen platformteams services die door al onze producten worden gebruikt (zoals identiteitsbeheer) en wordt verwacht dat ze documentatie, support en advies bieden voor op stream afgestemde teams.
Gecompliceerd subsysteemteam
Een gecompliceerd subsysteemteam is verantwoordelijk voor de ontwikkeling en het onderhoud van een deel van het systeem dat afhankelijk is van specifieke vaardigheden en kennis. De meeste teamleden moeten specialisten zijn op een bepaald gebied om het subsysteem te begrijpen en te wijzigen.
Het doel van dit team is om de druk te verminderen van op stream afgestemde teams die werken aan systemen die het subsysteem bevatten of gebruiken. Met de expertise en capaciteiten van het gecompliceerde subsysteemteam hoeven op stream afgestemde teams geen mogelijkheden te creëren op gebieden die te ingewikkeld zijn voor hun dagelijkse werk. Teamleden van dit team kunnen gespecialiseerde kennis hebben op het gebied van bepaalde microservices (d.w.z. een factureringsservice), algoritmen of zelfs kunstmatige intelligentie.
Een veelvoorkomende valkuil is het inzetten van specialisten in elk op stream afgestemd team dat het subsysteem gebruikt. Hoewel dit misschien efficiënt lijkt, is het uiteindelijk niet kosteneffectief en ligt het buiten de scope voor een op stream afgestemd team.
Uitvoerend team
Op stream afgestemde teams staan voortdurend onder druk om snel te leveren en op wijzigingen te reageren, waardoor het lastig kan zijn om tijd te vinden voor onderzoek, leren en oefenen van nieuwe vaardigheden.
Een team dat bestaat uit specialisten op een bepaald technisch (of productgericht) gebied helpt deze capaciteitskloof te overbruggen. Deze teams richten zich op onderzoek en experimenten om weloverwogen suggesties te doen over tools, frameworks en ecosysteemkeuzes die van invloed zijn op de toolstack.
Dit geeft op stream afgestemde teams de tijd om capaciteiten te verwerven en te ontwikkelen, en zich op de primaire doelen te blijven richten. Het uitvoerend team vergroot met name de zelfstandigheid van op stream afgestemde teams door hun capaciteiten uit te breiden, waarbij de focus op problemen ligt in plaats van op oplossingen.
Als een uitvoerend team het werk goed doet, heeft het team dat het uitvoerend team helpt na een aantal weken geen hulp meer nodig. Het is niet de bedoeling dat een team permanent afhankelijk blijft van het uitvoerend team.
Ben je een op stream afgestemd team?
Bepaal aan de hand van de volgende vragen of je een op stream afgestemd team hebt:
Wil je team een constante stroom van functies produceren?
Gevorderde teams releasen meerdere keren per week, en in sommige gevallen meerdere keren per dag. Om dit doel te realiseren, moeten gevorderde teams continue integratie en continue levering (CI/CD) gebruiken om functies regelmatig te leveren.
Verandert je team snel van richting op basis van feedback (klant of intern) over de laatste wijzigingen?
Vaak werkt een experimentele benadering van productevolutie het beste. Gevorderde DevOps-processen hebben geautomatiseerde tests om kwalitatieve codes te leveren. Bij experimenteren komt echter meer kijken dan eenvoudige testen van apparaten of acceptatie. Je kunt ervoor zorgen dat je producten de meeste waarde leveren aan klanten door functievlaggen te gebruiken om releases naar een subset gebruikers te automatiseren, alfa- en bèta-releases om feedback en gedrag van gebruikers te vragen en te meten, en kwalitatieve continue feedback via opmerkingen, ondersteuningstickets en communityforums te krijgen.
Doet je team het meeste werk zelf, zonder hulp van andere teams?
Dit is de bedoeling vanwege twee redenen. Je team moet zelfstandig zijn en samenwerken met directe teamgenoten om een snelle levering te garanderen. Buiten de werkscope kunnen geautomatiseerde processen er ook voor zorgen dat het meeste werk binnen hetzelfde team blijft. Het automatiseren van je ontwikkelingscyclus zorgt ervoor dat verplaatsingen naadloos verlopen, ongeacht of de volgende stap een actie is zoals een geautomatiseerde test of samenvoegen met main, of een mens.
Bonuspunten voor het volgende ...
Heeft je team tijd om kwaliteitswijzigingen in code aan te pakken (ook wel 'tech debt' genoemd) om ervoor te zorgen dat wijzigingen veilig en gemakkelijk verlopen?
Gevorderde teams vertrouwen op trunk-gebaseerde ontwikkeling en CI/CD-werkwijzen om hun codebase te behouden. Capaciteitsplanning moet ingebouwde tijd bevatten om 'tech debt' of technische schulden weg te werken. Bovendien moeten grootschalige projecten die onderliggende infrastructuur- of platformproblemen aanpakken evenveel aandacht krijgen als de ontwikkeling van functies.
Wordt je team geëvalueerd aan de hand van de juiste statistieken?
Naast hoe snel je team levert, moet er ook rekening worden gehouden met de statistieken van teamgezondheid en technische kwaliteit in hun maatstaven voor succes.
Betreffende de laatste vraag over meten, hebben DevOps-teams doorgaans de vier belangrijkste DevOps Research and Assessment-statistieken (DORA) in hun definitie van 'succes' opgenomen:
- Implementatiefrequentie - Hoe vaak een organisatie een productie releaset
- Doorlooptijd voor wijzigingen - Hoeveel tijd een commit nodig heeft tot de productie
- Foutpercentage van wijzigingen - Het percentage implementaties dat een fout in de productie veroorzaakt
- Tijd om de service te herstellen - Hoelang het duurt voordat een organisatie hersteld is van een productiefout
Naast deze door DORA gespecificeerde statistieken, ontdekte Atlassian dat goed presterende, op stream afgestemde teams ook deze kenmerken bewaken:
- Gebalanceerd team - Je team heeft een gevarieerde set vaardigheden en perspectieven
- Fulltime eigenaar - Een fulltime eigenaar zorgt ervoor dat het nucleaire team en de cross-functionele deelnemers weten aan wie ze vragen moeten stellen en hoe ze beslissingen kunnen nemen met betrekking tot projecten die eigendom zijn van het team
- Gedeeld begrip - De vereisten plus de definitie van waarden en statistieken voor succes zijn voor iedereen duidelijk
- Focus op waarde en statistieken - Je team heeft doelen die bepalen welke taken uitgevoerd moeten worden om projecten te releasen
- Proof-of-concept - Als een team een echt artefact heeft om over veronderstellingen te sparren en deze te testen, kan het team constant herhalingen uitvoeren en zich verbeteren
- Beheerde afhankelijkheden om de snelheid te behouden - Inzicht in beheerde afhankelijkheden houdt blockers op afstand en helpt het team om de snelheid te behouden
De conclusie ...
DevOps is geen bestemming, maar een reis waarbij tools, teamcultuur en werkwijzen continu verbeterd worden. Ben je net aan de slag met DevOps? Begin dan met het oriënteren van doelen om waarde te leveren aan klanten. Voeg na een tijdje automatisering toe aan je tools en processen. Wanneer je team uiteindelijk steeds gevorderder wordt, implementeer je observering om ervoor te zorgen dat je de juiste dingen bewaakt, meet en verbetert.
Deel dit artikel
Volgend onderwerp
Aanbevolen artikelen
Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.
DevOps-community
DevOps-leertraject
