Volwassenheidsmodel Engineering Excellence

Maak van vage zorgen over codekwaliteit concrete verbeteringen.

Probeer deze gezondheidscheck nu live uit

Wat is het Volwassenheidsmodel Engineering Excellence?

Engineers weten meestal wel waar de codebase pijn doet. Lastiger is het om als team eens te worden over welke problemen het zwaarst wegen en hoe ver je bent met het oplossen ervan. Met het Volwassenheidsmodel Engineering Excellence beoordeelt je team 12 praktijken in vier groepen (Codekwaliteit & standaarden, Architectuur & schaalbaarheid, Beheer van technische schuld, en Samenwerking & ondersteuning in engineering) op een schaal van vijf niveaus, van Ad hoc tot Geoptimaliseerd. Omdat elk niveau beschreven is, maken de scores van vage gevoelens over kwaliteit iets concreets: codereviews die bugs vinden maar geen kennis verspreiden, of technische schuld waar iedereen van weet maar die niemand bijhoudt. Die gedeelde taal helpt engineers en leidinggevenden om het eens te worden over wat als eerste verbeterd moet worden. Voer het regelmatig uit en je ziet of de veranderingen die je hebt doorgevoerd de praktijken een niveau hoger hebben gebracht.

Afmetingen

Codekwaliteit & standaarden

Hoe consequent het team schone, onderhoudbare en goed gereviewde code schrijft op basis van gedeelde standaarden.

  • Consistentie in codeerstandaarden

    Hoe consequent het team gedeelde codeerrichtlijnen toepast.

    1. Ad hocCodeerpraktijken lopen sterk uiteen; er worden geen gedeelde standaarden gevolgd.
    2. In opkomstEr bestaan enkele standaarden, maar ze worden niet consequent toegepast.
    3. GedefinieerdStandaarden zijn gedocumenteerd en worden meestal gevolgd.
    4. BeheerstStandaarden worden consequent toegepast en regelmatig herzien.
    5. GeoptimaliseerdEr is een sterke cultuur rond codekwaliteit; standaarden ontwikkelen zich via samenwerking en best practices.

  • Onderhoudbaarheid van code

    Hoe makkelijk code te lezen, te begrijpen, aan te passen en uit te breiden is.

    1. Ad hocCode is moeilijk te lezen, te doorgronden of te hergebruiken.
    2. In opkomstEr zijn enkele verbeteringen doorgevoerd, maar problemen met onderhoudbaarheid blijven bestaan.
    3. GedefinieerdDe codebase is grotendeels begrijpelijk en onderhoudbaar.
    4. BeheerstCode is schoon, modulair en voorspelbaar, met sterke praktijken voor onderhoudbaarheid.
    5. GeoptimaliseerdOnderhoudbaarheid is de norm in de cultuur; teams verbeteren en ontwikkelen codestructuren proactief.

  • Kwaliteit van codereviews

    Hoe effectief codereviews de kwaliteit en het leren binnen het team verbeteren.

    1. Ad hocReviews zijn zeldzaam, gehaast of oppervlakkig.
    2. In opkomstEr worden reviews gedaan, maar diepgang en nut lopen sterk uiteen.
    3. GedefinieerdReviews vangen problemen op en verbeteren de kwaliteit betrouwbaar.
    4. BeheerstReviews zijn constructief en consistent en verbeteren zowel de kwaliteit als de vaardigheden van het team.
    5. GeoptimaliseerdReviews zijn gezamenlijk, rijk aan kennis en een vast onderdeel van engineering excellence.

Architectuur & schaalbaarheid

Hoe helder de architectuur van het systeem is en hoe goed het schaalt, presteert en technische risico's beheerst.

  • Helderheid van de architectuur

    Hoe goed de architectuur van het systeem gedefinieerd, gedocumenteerd en begrepen is.

    1. Ad hocDe architectuur is onduidelijk of niet gedocumenteerd.
    2. In opkomstEr is enige documentatie, maar die is onvolledig of onduidelijk.
    3. GedefinieerdDe architectuur is gedocumenteerd en wordt door de meeste teamleden begrepen.
    4. BeheerstDe architectuur stuurt beslissingen en ontwikkelt zich via gestructureerde samenwerking.
    5. GeoptimaliseerdDe architectuur is schaalbaar en doordacht en wordt continu verfijnd op basis van inzichten en lessen.

  • Schaalbaarheid & robuustheid

    Het vermogen van het systeem om groei, prestatie-eisen en betrouwbaarheidsbehoeften aan te kunnen.

    1. Ad hocHet systeem heeft moeite onder belasting; opschalen gebeurt ongepland.
    2. In opkomstSommige componenten schalen, maar er blijven beperkingen.
    3. GedefinieerdHet systeem verwerkt normale belasting met acceptabele prestaties.
    4. BeheerstHet systeem schaalt betrouwbaar en prestaties worden actief gemonitord en geoptimaliseerd.
    5. GeoptimaliseerdSchaalbaarheid is een sterk punt; het systeem vangt groei soepel en voorspelbaar op.

  • Beheer van technische risico's

    Hoe effectief engineeringrisico's worden geïdentificeerd, beoordeeld en beperkt.

    1. Ad hocRisico's komen laat aan het licht en veroorzaken flinke verstoringen.
    2. In opkomstRisico's worden af en toe besproken, maar niet systematisch beheerd.
    3. GedefinieerdRisico's worden tijdens de planning geïdentificeerd en waar nodig aangepakt.
    4. BeheerstGestructureerde risicobeoordeling maakt proactieve beheersing mogelijk.
    5. GeoptimaliseerdRisicobeheer is verankerd in alle engineeringprocessen en voorkomt grote problemen.

Beheer van technische schuld

Hoe zichtbaar technische schuld wordt bijgehouden en teruggedrongen, en hoe goed die wordt gekoppeld aan de impact op de oplevering.

  • Zichtbaarheid van schuld

    Hoe technische schuld wordt geïdentificeerd, bijgehouden en gecommuniceerd.

    1. Ad hocTechnische schuld is verborgen en wordt niet beheerd.
    2. In opkomstEr is enig besef van schuld, maar die wordt zelden gedocumenteerd.
    3. GedefinieerdSchuld wordt bijgehouden en periodiek besproken.
    4. BeheerstDe backlog met schuld is geprioriteerd en wordt meegenomen in de planning.
    5. GeoptimaliseerdZichtbaarheid en preventie van schuld zijn kernpraktijken binnen engineering.

  • Praktijken om schuld af te bouwen

    Hoe effectief het team technische schuld aanpakt en terugdringt.

    1. Ad hocSchuld stapelt zich op zonder dat er iets aan gedaan wordt.
    2. In opkomstSchuld wordt besproken, maar zelden opgelost.
    3. GedefinieerdSchuld wordt aangepakt wanneer dat haalbaar is.
    4. BeheerstSchuld wordt proactief afgebouwd als onderdeel van het reguliere werk.
    5. GeoptimaliseerdHet team houdt schuld minimaal door gedisciplineerde engineering en continue verbetering.

  • Bewustzijn van impact

    Inzicht in hoe technische schuld snelheid, kwaliteit en risico beïnvloedt.

    1. Ad hocHet team legt geen verband tussen technische schuld en problemen bij de oplevering.
    2. In opkomstEr is enig besef, maar er wordt weinig mee gedaan.
    3. GedefinieerdDe impact van schuld wordt begrepen en beïnvloedt sommige beslissingen.
    4. BeheerstDe impact van schuld stuurt consequent de planning en prioritering.
    5. GeoptimaliseerdEen sterke cultuur van schuldbewustzijn voorkomt opstapeling en ondersteunt een duurzaam tempo.

Samenwerking & ondersteuning in engineering

Hoe effectief het team kennis deelt, vaardigheden spreidt en ontwikkelaars de tools geeft om uitstekend werk te leveren.

  • Kennisdeling

    Hoe effectief engineeringkennis en expertise binnen het team worden gedeeld.

    1. Ad hocKennis zit in silo's; het team is sterk afhankelijk van enkele personen.
    2. In opkomstEr wordt wel kennis gedeeld, maar niet consequent.
    3. GedefinieerdKennis wordt gedeeld via informele of gestructureerde kanalen.
    4. BeheerstKennis stroomt soepel; onboarding verloopt efficiënt.
    5. GeoptimaliseerdEen sterk samenwerkende cultuur met continu leren en gedeeld eigenaarschap.

  • Breedte & flexibiliteit van vaardigheden

    Het vermogen van het team om aan meerdere delen van het systeem te werken.

    1. Ad hocSterke silo's leiden tot knelpunten door afhankelijkheden.
    2. In opkomstAf en toe leren teamleden elkaars vaardigheden aan.
    3. GedefinieerdTeamleden kunnen de meeste kerngebieden afdekken.
    4. BeheerstGrote flexibiliteit; het team past zich snel aan de werkdruk aan.
    5. GeoptimaliseerdDiepe en brede expertise in het hele team maakt snelle, veerkrachtige oplevering mogelijk.

  • Ondersteuning van ontwikkelaars

    Kwaliteit van de tools, processen en omgeving die de productiviteit van ontwikkelaars ondersteunen.

    1. Ad hocTooling is verouderd of inconsistent; er is veel frictie.
    2. In opkomstEr wordt aan verbeteringen gewerkt, maar er zijn nog hiaten.
    3. GedefinieerdOntwikkelaars hebben betrouwbare tools die aan de basisbehoeften voldoen.
    4. BeheerstTooling is gestroomlijnd en efficiënt en wordt consequent verbeterd.
    5. GeoptimaliseerdEen ontwikkelaarservaring van wereldklasse die snel engineeringwerk van hoge kwaliteit mogelijk maakt.

Wanneer dient u deze gezondheidscontrole uit te voeren?

  • Om een nulmeting te doen van de technische volwassenheid van je engineeringteam op het gebied van code, architectuur en samenwerking.
  • In retrospectives per kwartaal of per release, om te volgen hoe engineeringpraktijken zich ontwikkelen.
  • Wanneer een nieuwe engineering lead begint en een eerlijk beeld nodig heeft van de huidige sterke punten en hiaten.
  • Voordat je investeert in tooling, refactoring of procesveranderingen, om te bepalen waar inspanning het meeste oplevert.
  • Wanneer het team groeit en je wilt dat standaarden, kennisdeling en architectuur gelijke tred houden.

Tips en trucs

  • Laat iedereen eerst zelfstandig scoren voordat jullie het bespreken, zodat eerlijke meningen naar boven komen voordat groepsdenken toeslaat.
  • Besteed de meeste tijd aan dimensies met de grootste spreiding in scores. Onenigheid laat vaak zien waar mensen het systeem verschillend zien.
  • Zie de niveaus als stappen, niet als cijfers. Van In opkomst naar Gedefinieerd gaan is echte vooruitgang, dus benoem dat ook.
  • Kies een of twee dimensies om te verbeteren vóór de volgende check, in plaats van alles tegelijk te willen verschuiven.
  • Herhaal de check regelmatig, zodat de voortgang in engineeringpraktijken zichtbaar blijft.

Veelgestelde vragen

Wat is de health check Engineering Excellence?
Het is een assessment op basis van volwassenheid van je engineeringpraktijken op het gebied van codekwaliteit, architectuur en schaalbaarheid, beheer van technische schuld en samenwerking. Elk van de 12 dimensies wordt beoordeeld op vijf niveaus, van Ad hoc tot Geoptimaliseerd, wat het team een gedeelde taal geeft om te bepalen waar het staat.
Waarin verschilt dit van een standaard team health check?
Een standaard team health check brengt in kaart hoe mensen zich voelen. Deze check beoordeelt hoe goed elke praktijk is ingebed, en elke score hoort bij een beschreven niveau. Zo laten de resultaten zien wat er nodig is om het volgende niveau te bereiken.
Wie moet er meedoen?
Engineers, tech leads en engineering managers. Iedereen die dicht betrokken is bij hoe de code wordt geschreven, gereviewd en onderhouden, heeft een waardevolle blik.
Hoe vaak moeten we de check uitvoeren?
De meeste teams doen het elk kwartaal of rond grote releases. Met een vast ritme kun je trends volgen en nagaan of verbeterwerk iets oplevert.
Wat betekenen de volwassenheidsniveaus?
De schaal loopt van Ad hoc via In opkomst, Gedefinieerd en Beheerst naar Geoptimaliseerd. Lagere niveaus staan voor inconsistente of reactieve praktijken; hogere niveaus voor consistente, proactieve praktijken die steeds beter worden.

Gerelateerde gezondheidscontroles