CINQby Quinten Stekelenburg
De laatste jaren is "Developer Experience", soms afgekort als DX, een steeds populairder onderwerp geworden. Developer experience omschrijft vooral hoe software developers het gebruik van hun tools ervaren, zoals een IDE of de API van een te implementeren stuk software. Hoe makkelijker een tool in gebruik is, hoe beter de developer experience. Echter, software development omvat meer dan alleen het schrijven van code. Van begin tot eind moet er worden gepland, ontworpen, geprogrammeerd, gedeployed, en uiteindelijk moet de software onderhouden worden. Al deze stappen zijn beter bekend als de Software Development Life Cycle (SDLC). In deze blogpost wil ik uitleggen waarom ik de SDLC belangrijker vind dan DX, en hoe de kwaliteit van een SDLC gemeten kan worden.
De developer experience zoals hij tegenwoordig bekend is, focust volledig op het schrijven van software, waarbij alles draait om de developer. Hoe blij is de developer met zijn IDE? Hoe snel kan een developer benodigde informatie vinden? Hoe snel is de feedback loop voor een developer? En hoewel dit hele goede vragen zijn om te stellen is het een kortzichtige manier van kijken naar de bouw van software.
De bouw van software gebeurt niet alleen door developers, maar door een compleet team. In mijn werk als software engineer heb ik altijd meerdere rollen om mij heen:
Afhankelijk van bij welk bedrijf of in welk team gewerkt wordt, kunnen er meer of minder rollen aanwezig zijn. Mijn punt hierbij is dat ik, samen met mijn mede-software engineers, afhankelijk ben van mijn teamleden. Als in deze context gekeken wordt naar de DX kan het prima zo zijn dat de DX erg goed is, terwijl de werkervaring van mijn team nog steeds beter kan. Ik kan immers een fijne laptop hebben, een goede IDE, en een framework met goede tooling. Dit verzekert alleen niet dat mijn team net zo fijn kan werken, noch dat dit gemeten kan worden via een DX meting.
De SDLC kan meerwaarde leveren doordat het een heel team omvat, en niet alleen de developers. Er bestaat soms variatie in hoe de SDLC omschreven wordt, maar globaal gezien omschrijft de SDLC vijf fasen van software development:
Varianten van de SDLC zijn beter bekend als de waterval methode, iterative development, of Agile. Van deze varianten is Agile tegenwoordig de meest gebruikte. Voor een operator zal het zwaartepunt van de SDLC liggen bij Deployment en Maintenance. Een informatieanalist zal eerder focussen op de eerste twee fasen. Voor mij als software engineer zit het zwaartepunt van de SDLC in de Implementatie & Testen fase. In het geval dat er aandacht wordt besteed aan het verbeteren van de DX dan zou je alleen maar de Implementatie & Testen fase gaan verbeteren. Door te kijken naar de volledige SDLC en te verbeteren waar mogelijk kan de werkervaring voor het hele team worden verbeterd, met daarmee een toename in efficiëntie en productiviteit tot gevolg.
Het bepalen van de kwaliteit van een SDLC gaat het beste aan de hand van de vijf fasen, door naar de kern van elke fase te kijken. Welke rollen zijn essentieel? Wat hebben deze rollen nodig, en krijgen zij ook wat zij nodig hebben? Het lastige aan deze vragen (en in mijn ogen, ook het mooie) is dat er nooit een enkel, definitief, antwoord gevonden kan worden. Geen enkel team werkt op dezelfde wijze, en daarmee hebben geen twee teams hetzelfde antwoord. Echter, door kritisch te blijven, kunnen er in elk team verbeteringen gevonden worden.
Om theorie in praktijk te brengen wil ik een typisch scenario schetsen. Jeff Bezos heeft ooit voor Amazon bepaald dat een team niet groter mag zijn dan tien man, ondertussen bekend als een "2-pizza team". Dit zou de samenwerking verbeteren en het team efficient houden. Laten wij uitgaan van deze grootte en een team van tien personen nemen; 1 product owner, 4 developers, 2 testers, 2 informatieanalisten, en 1 data analist. Per fase zal ik aangeven wat ik denk dat de primaire rollen zijn voor die fase, eventuele secundaire rollen, en een toelichting waarom. Ook zal ik een aantal vragen formuleren als voorbeeld van waar de focus voor de fase op ligt.
De eerste fase is Planning. De primaire rol hierbij is de product owner. Secundair zijn de analisten en de developers. Tijdens de planning is het belangrijk om te kijken naar wat er gebouwd moet gaan worden voor de klant, en wanneer dit klaar moet zijn. De product owner is representatief voor de klant en heeft de beslissende stem in wat er gebouwd wordt en wat prioriteit heeft. Uiteraard zijn de analisten en developers van belang om in te schatten of zij de wensen van de product owner realiteit kunnen maken, maar het uiteindelijke besluit is aan de product owner om te nemen. Voor de analisten is het relevant om te kijken naar hoe een gevraagde functionaliteit moet werken en hoe de werkzaamheid na oplevering geverifieerd kan worden. De verificatie kan in een later stadium door de testers opgepakt worden. De developers moeten een inschatting maken over hoe zij de gevraagde functionaliteit kunnen bouwen. Vragen die belangrijk zijn bij deze fasen:
De tweede fase is het Definiëren van Requirements. Hierbij zijn de analisten en de developers van primair belang. De testers kunnen ondersteunend zijn door mee te denken over hoe een functionaliteit getest kan worden. De gevraagde functionaliteit is duidelijk door de Planning fase, maar hoe de functionaliteit er uit gaat zien wordt in deze fase bepaald. De analisten zijn belangrijk voor het functionele deel, de developers voor het technische deel. Vragen die gesteld kunnen worden:
De derde fase gaat om het Implementeren & Testen van de functionaliteit. Hierin zijn de developers en testers het belangrijkste. Secundair zijn de analisten om de developers en testers te ondersteunen wanneer informatie niet duidelijk is en meer toelichting nodig heeft. De developers moeten de functionaliteit bouwen naar de vastgestelde acceptatiecriteria. Testers kunnen toetsen of de acceptatiecriteria daadwerkelijk gehaald worden nadat de developers een eerste of opvolgende implementatie hebben gemaakt. Vragen die gesteld kunnen worden:
De vierde fase is de Deployment van de applicatie. In deze fase komt de applicatie op de productieomgeving terecht met de nieuwe functionaliteit. Primair hierin zijn de developers om de deployment uit te voeren. Secundair zijn de analisten en eventueel ook de testers (hoewel testen op productie zwaar afgeraden wordt). De developers zorgen voor een goede deployment, via eventueel een geautomatiseerde pipeline. Daarna kunnen de analisten kijken of de functionaliteit aanwezig is en naar behoren werkt. Dit proces kan uiteraard eerst uitgevoerd worden op een acceptatieomgeving die gespiegeld is aan de productieomgeving om problemen met de productie applicatie te voorkomen. Vragen die gesteld kunnen worden:
Als laatste is er de fase Maintenance. Hierin wordt de applicatie onderhouden en wordt er gezorgd dat de applicatie functioneel blijft. Functionaliteit kan worden verbetert, eventuele bugs worden opgelost, en processen kunnen worden gestroomlijnd. Uiteraard allemaal via een nieuwe development cyclus. Primair hierin zijn de developers, en secundair zijn de product owner en de analisten. De developers moeten voor het onderhoud zorgen, waar de product owner en de analisten bevindingen kunnen doen voor verbeteringen. Vragen die gesteld kunnen worden:
Ik hoop dat via deze blogpost mijn blik op development duidelijker is geworden. Hoe belangrijk de developer experience ook wordt bevonden de laatste tijd, software ontwikkelen draait om meer dan alleen developers. Het vereist een toewijding van het hele team waarbij in elke fase van software development verbeteringen mogelijk zijn, weergegeven via de SDLC. Als elke fase gestroomlijnd is, zal het hele team tevredener en productiever zijn in hun werk. Dit bevordert uiteindelijk ook de experience voor developers. Ik zou daarmee ook willen pleiten om niet alleen naar "developer experience" te kijken maar om dit breder te nemen - noem het een "software development experience".