Herbruikbare componenten?

Tijdens Sprintplanning en Backlog Refinement sessie’s ben je als Product Owner veelal aanwezig bij technische discussie’s van het Team. Hierbij kan het gebeuren dat je Team voorstelt om een herbruikbaar component te maken.

Spits dan als Product Owner je oren en hou wat controle vragen gereed.

Software ontwikkelaars hebben een natuurlijke aandrang tot automatiseren en efficiënt werken. Ze zijn tijdens het ontwikkelen voortdurend alert of bepaalde gedeeltes van de reeds geschreven software niet opnieuw ingezet kunnen worden. Dat is goed.

Sommige ontwikkelaars gaan verder en menen reeds bij het schrijven van een nieuw stukje software te weten dat dit in de toekomst herbruikt gaat worden. Ze stellen dan voor om dit direkt in ‘herbruikbare’ of ‘generieke’ vorm te gieten. Het pleidooi kan gepaard gaan met argumenten dat andere teams of ontwikkelaars hier ook plezier van kunnen hebben.

Dat is het moment waarop je even moet challengen, of zoals dat vroeger heette, zeuren. Er zijn namelijk drie potentiële problemen met het à priori herbruikbaar maken:

• je weet bij Scrum nooit 100% zeker of de toekomstige User Story waarin het component herbruikt kan worden ook echt gebouwd wordt.
• omdat toekomstige User Stories minder goed of nog niet ontworpen zijn, weet je ook nog niet hoe het component precies herbruikt gaat worden.
• Herbruikbare software schrijven is altijd aanzienlijk meer werk dan een implementatie voor één gebruiksscenario.

Investeer dus pas in de herbruikbaarheid van een component op het moment dat je het herbruikt, en dan ook alleen wanneer het een besparing oplevert, of het de kwaliteit van de software aanzienlijk verhoogt.

Het klinkt zo logisch.