What’s in a name?
De Peer Estimations zijn een afgeleide van Peer Reviews. Laten we daar eerst kort op inzoomen.
Het begrip “Peer Review” ken je wellicht.
Naast de IT zie je Peer Reviewing ook terug in de medische wereld, het notariaat en de wetenschap. Binnen de IT betekent dit zoveel als dat de ene developer het werk van de ander toetst op een opbouwende, collegiale manier.
Dit is mogelijk omdat alle programmacode wordt bijgehouden in een versiebeheersysteem (Git) waarmee alle wijzigingen die aan de code gemaakt worden met een druk op de knop inzichtelijk zijn.
Developer A biedt zijn of haar wijzigingen aan de broncode van de webshop aan aan developer B in de vorm van een Merge Request (MR). Deze merge request bestaat uit changes (de daadwerkelijke code wijzigingen) en een beschrijving van de uitgevoerde werkzaamheden, vaak ondersteund door een stukje functionele en technische toelichting of documentatie.
Waar dienen die reviews eigenlijk voor?
Soms zit je zo diep in de materie dat er een blinde vlek ontstaat en je een edge-case over het hoofd ziet. Een andere keer heb je een goede oplossing gebouwd, maar blijkt er nog een robuustere of elegantere oplossing te zijn. Of nog weer anders: dat die specifieke klant zijn business logica net even anders heeft ingericht dan gebruikelijk waardoor de vlieger niet opgaat. In alle gevallen zorgt een tweede paar ogen met een frisse blik, een vers perspectief of die nieuwe invalshoek voor betere code, een beter resultaat.
Het werkt ook de andere kant op: de developer die de code onder ogen krijgt, komt in aanraking met die nieuwe technologie, een nieuw stukje functionaliteit of een verre uithoek van Magento die nog niet eerder door ons verkend is (soms vinden we er nog 1). Hiermee delen we de kennis die we in huis hebben en versterken we de kracht van ons collectief, ook weer met als resultaat om de kwaliteit van ons team en daarmee de dienstverlening aan onze klanten
te verbeteren.
Helder, maar wat zijn dan die Peer Estimates?
Peer Reviews vinden plaats aan het eind van het uitvoeren van de werkzaamheden. Peer estimates vinden plaats nog voordat we aan de werkzaamheden beginnen.
In een Peer Estimation Session sparren we over een vraagstuk, bepalen we als team de juiste oplossingsrichting en schatten vervolgens als team de werkzaamheden in.
We geven daarbij gezamenlijk antwoord op vragen zoals:
- Is het duidelijk wat de probleemstelling is?
- Wat zijn de implicaties: zitten er haken en ogen aan?
- Welke behoefte zit er eigenlijk achter het vraagstuk?
- Welke kennis en ervaring hebben we reeds in huis? Hebben andere klanten dit vraagstuk of probleem al eens gehad en hoe hebben we dat toen opgelost?
- Wat is functioneel en technisch de juiste aanvliegroute? Zijn er reeds bestaande oplossingen binnen Magento zelf of van derden of moeten we iets maatwerken? Zo ja, hoe gaan we dat dan aanpakken?
Bij ons bestaat zo’n Peer Estimation Team uit een frontend developer, backend developer, consultant en een projectmanager, die elk vanuit hun expertise en discipline een bijdrage leveren aan de dialoog. Bij het samenstellen van het team voor de sessie rouleren we steeds de collega’s die deelnemen. Kruisbestuiving.
Is zo'n sessie met vier personen niet heel kostbaar?
Het klopt dat de spreekwoordelijke meter vier keer loopt. We zien echter dat we dit in de praktijk dubbel en dwars terugverdienen, want:
-
Inschattingen zijn nauwkeuriger
Vaak omvatten werkzaamheden meerdere disciplines, zoals bijvoorbeeld een stukje admin configuratie door een consultant, een nieuw API-endpoint door een backender en de nodige javascript en styling door een frontender. Doordat iedereen vanuit z’n eigen vakgebied bijdraagt aan de inschatting, is de uitkomst veel scherper. -
De oplossingsrichting is beter
De werkzaamheden zijn voor aanvang beter uitgedacht en gespecificeerd en de oplossing kan trefzeker ontwikkeld worden omdat doodlopende paden en valkuilen kunnen worden vermeden. -
De oplossing zelf is beter
Als je in plaats van individueel als team van knappe koppen je over een kwestie buigt, is de oplossing vaak vollediger (en daardoor beter) dan initiële uitvraag en verwachting. -
We voorkomen overbodig, dubbel werk
Soms hoeven we weinig tot niets te bouwen omdat we een (soortgelijk) issue bij een andere shop al getackeld hebben of kunnen we een bestaande extensie adviseren omdat die bij een andere klant zo fijn werkt. Of we voorkomen dat een backender iets gaat maatwerken omdat een consultant meldt dat in de nieuwe release van Magento die voor de deur staat daar al standaard ondersteuning voor is.
Daarbovenop blijft domein- en klantspecifieke kennis niet in het hoofd van 1 persoon steken, maar delen we de wensen, problemen en gekozen oplossingen met het team. Hiermee verkleinen we de afhankelijkheid op 1 of enkele personen.
Waarom zijn inschattingen belangrijk?
We denken op strategisch niveau mee met onze klanten. Daarbij is het vaak wenselijk dat we een ook ondersteunende rol hebben bij de kosten-baten analyse en de Return on Investment (hoewel natuurlijk lang niet alles direct geldelijk te verantwoorden hoeft te zijn). Doordat je zicht hebt op wat de investering van een bepaald stukje functionaliteit is ontstaat er meer bewustzijn en kun je weloverwogen, slimme keuzes maken: moeten we dit wel of niet doen? Of doen we dit wel, maar op een later moment?
Klinkt goed! Wat zijn jullie verder nog van plan?
Dat vinden wij ook. Wij zijn zelf heel enthousiast over deze manier van werken en we merken dat het enorm heeft bijgedragen aan het proces, onze efficiëntie en kwaliteit.
De volgende stap is dat ook de Product Owners van onze klanten gaan aanhaken bij de Estimation Sessions: dit ook weer in het kader van kennisdeling. De PO zal zo meer feeling krijgen bij de materie, inhoudelijk beter snappen wat we doen en waarom we bepaalde keuzes maken. Daarnaast houden we zo de lijntjes heel kort en kunnen we het gas erop houden: bij vragen of onduidelijkheden kunnen we meteen knopen doorhakken en dóór. We smeden graag ijzer als het heet is.
Meer leesvoer:
https://jacobian.org/2021/may/20/estimation/