Voorbeelden van uitgewerkte schattingen
In het schattingsgesprek komen van begin tot eind praktijkvoorbeelden aan bod (inloggen, betalingen, migraties, pieken), evenals de vragen die moeten worden beantwoord voordat er over een getal wordt gestemd.
Hoe u een inlogfunctie kunt beoordelen: de verborgen aspecten (wachtwoordherstel, tweefactorauthenticatie, federatie, rate limiting, sessies) en de vragen die moeten worden beantwoord voordat er gestemd kan worden.
Hoe u een SSO-integratie kunt inschatten: het werk speelt zich niet af in uw codebase, maar in de eigenaardigheden van de identiteitsprovider. De vragen die u moet beantwoorden voordat u een schatting maakt.
Hoe u een betalingsintegratie kunt inschatten: sandbox versus live, terugbetalingen, webhooks, idempotentie, PCI-toepassingsgebied. Het gesprek dat moet plaatsvinden voordat er ook maar één cijfer wordt vastgesteld.
Hoe u een zoekfunctie kunt inschatten: relevantie, rangschikking, faceting en wie de eigenaar is van de index. De vragen die van ‘een zoekbalk toevoegen’ een daadwerkelijke inschatting maken.
Hoe u een meldingssysteem kunt inschatten: kanalen, voorkeuren, ontdubbeling en leveringsgaranties. Waarom ‘een e-mail versturen’ stilletjes uitgroeit tot een project van zes weken.
Hoe u een bestandsupload kunt inschatten: maximale bestandsgrootte, virusscan, hervatbaarheid, opslag en bewaartermijn. Het slepen en neerzetten is het makkelijke gedeelte; de onderliggende processen vormen de echte uitdaging.
Hoe u een dashboard kunt beoordelen: gegevensbronnen, verversingsfrequentie, tijdzones, drill-down, machtigingen. De grafiek is eenvoudig; de gegevenspijplijn erachter is het echte werk.
Hoe u een onbetrouwbare test kunt inschatten: waarom het om twee schattingen gaat, en niet om één, en waarom een tijdslimiet de voorkeur verdient boven discussies over punten wanneer het antwoord afhangt van wat u ontdekt.
Hoe u een bug kunt inschatten als deze niet kan worden gereproduceerd: u kunt de omvang van de oplossing niet inschatten, alleen die van het onderzoek. Hoe u een tijdslimiet kunt stellen aan het onderzoek in plaats van te stemmen over een story die niemand kan inzien.
Hoe een prestatieverlies kunt inschatten: het gaat hierbij vooral om de diagnose, niet om de oplossing. Hoe kunt u de omvang ervan inschatten wanneer de oorzaak onbekend is en een SLO op het spel staat?
Hoe schat u een door een klant gemelde bug in: de omschrijving op het ticket bepaalt de omvang. Hoe maakt u onderscheid tussen een oplossing van één regel en een reactie die de hele sprint in beslag neemt?
Hoe u een databasemigratie kunt inschatten: backfill, vergrendelingsduur, uitrol en terugdraaiing. ‘Een kolom toevoegen’ is één regel SQL; de schatting betreft de tweede klok.
Hoe een gegevensmigratie in te schatten: het overzetten van gegevens tussen systemen, afstemming en omschakeling. De transformatie duurt een uur; het opschonen duurt een kwartaal.
Hoe u een framework-upgrade kunt inschatten: waarom een grote versie-upgrade een project is en geen ticket, en hoe u dit kunt opsplitsen in stories waarvan u de omvang daadwerkelijk kunt inschatten.
Hoe u een upgrade van een afhankelijkheid kunt inschatten: de langdurige toename die N pieken in één ticket verbergt. Lees eerst de changelogs en maak vervolgens een inschatting van wat u hebt gevonden.
Hoe u de omvang van een CI/CD-herziening kunt inschatten: aangezien er voor het werk aan de pijplijn geen demo bestaat, verdeelt u het in delen op basis van wat kan worden geschrapt. Het project dat een heel kwartaal in beslag neemt en op de backlog staat vermomd als een refactor.
Hoe u de impact van een API-overstap naar een derde partij kunt inschatten: semantische hiaten, gelijktijdige werking en de aannames die verweven zijn met de eigenaardigheden van de oude leverancier. De nieuwe API lijkt slechts identiek.
Hoe u de invoering van een rate limit kunt inschatten: drempelwaarden, testperiodes, communicatie met klanten. Het programmeren neemt een halve dag in beslag; het bepalen van limieten waar niemand over klaagt, is het echte werk.
Hoe u de impact van een wijziging in het ontwerpsysteem kunt inschatten: de uitrol van tokens, verouderingstrajecten, de dekking van Codemod en de 200 aanroepplaatsen die de oude component gebruiken. Breng de gevolgen voor de downstream in kaart.
Hoe u de omvang van een aanpassing op het gebied van toegankelijkheid kunt inschatten: a11y-problemen zijn functies die u de eerste keer niet hebt geïmplementeerd. Waarom u de omvang van de probleemgroep moet inschatten, en niet die van een enkel geval.
Hoe u de uitrol van een feature-flag kunt inschatten: gefaseerde percentages, kill-switches, gating-statistieken en de opruimwerkzaamheden die niemand inplant. Een flag is een klein product, geen implementatie.
Hoe u een onderzoeksspike kunt inschatten: een spike is een tijdsblok met een te leveren resultaat, geen story. Hoe u kunt voorkomen dat deze stilletjes uitgroeit tot het werk dat oorspronkelijk in de scope was opgenomen.
Hoe u een prototype moet beoordelen: het is een opleverbaar product dat bedoeld is om van te leren, niet om te gebruiken. Hoe u kunt voorkomen dat het wegwerpbare prototype uitgroeit tot de productiecode waar niemand op had gerekend.
Hoe u een ML-experiment inschat: het is onderzoek in combinatie met techniek. Het model is eenvoudig, het werk zit hem in de gegevens. Hoe u de omvang van een budget bepaalt, niet een prognose.