Feature Driven Development.

Wat is Feature Driven Development?

Feature Driven Development (FDD) is een ontwikkelmethodiek waarbij het hele proces georganiseerd wordt rondom features — concrete, afgebakende stukken functionaliteit die waarde leveren aan de gebruiker. In plaats van te denken in technische lagen ("eerst de database, dan de API, dan de frontend") denken we in gebruikerswaarde ("eerst kunnen klanten inloggen, dan kunnen ze orders plaatsen").

Elke feature is een verticale snede door de applicatie: database, backend, frontend en tests — alles wat nodig is om die ene feature werkend te krijgen. Het resultaat is dat je na elke iteratie werkende software hebt, niet een half-afgebouwde technische laag.

Waarom features als organisatieprincipe?

Direct demonstreerbaar

Een afgeronde feature kun je tonen aan stakeholders. "Kijk, gebruikers kunnen nu een account aanmaken en inloggen." Dat is concreet en toetsbaar. "De database-schema's zijn af" zegt een opdrachtgever niets.

Flexibel bijsturen

Na elke feature kun je de koers bijsturen. Misschien blijkt na de eerste drie features dat een vierde feature toch niet nodig is, of dat er een vijfde feature is die je niet had voorzien. Door per feature te werken, kun je flexibel reageren op voortschrijdend inzicht.

Meetbare voortgang

Voortgang wordt gemeten in werkende features, niet in geschreven regels code of gewerkte uren. Dit geeft opdrachtgevers een eerlijk beeld van waar het project staat.

Beperkt risico

Als een feature niet bevalt of als prioriteiten verschuiven, heb je maximaal een paar dagen werk verloren — niet maanden. De features die al af zijn, werken en leveren waarde, ongeacht wat er daarna gebeurt.

Software die je niet kunt laten zien, bestaat niet. Features zijn het enige dat telt voor je gebruikers; de rest is overhead.

Hoe werkt het in de praktijk?

Stap 1: Feature mapping

We beginnen met het in kaart brengen van alle features die het product nodig heeft. Elke feature wordt beschreven vanuit het perspectief van de gebruiker: wat kan de gebruiker doen en welk probleem lost het op?

Stap 2: Prioriteren

Niet alle features zijn even belangrijk. We prioriteren op basis van twee criteria: business-waarde (hoeveel impact heeft deze feature?) en afhankelijkheden (welke features moeten eerst bestaan?). De features met de hoogste waarde en de minste afhankelijkheden gaan eerst.

Stap 3: Bouwen per feature

Elke feature wordt als een geheel gebouwd: database-wijzigingen, backend-logica, frontend-interface en tests. De feature wordt op een aparte branch ontwikkeld, getest en via een pull request gereviewed voordat het naar de hoofdtak gaat.

Stap 4: Demo en feedback

Na elke afgeronde feature (of set van features) demonstreren we het resultaat. Je ziet werkende software, geeft feedback en we sturen bij waar nodig.

Stap 5: Deploy

Features worden zo snel mogelijk naar productie gebracht. Hoe eerder echte gebruikers ermee werken, hoe sneller je leert of het de juiste oplossing is.

Het verschil met Scrum

Scrum organiseert werk in sprints van vaste lengte. FDD organiseert werk rondom features van variabele omvang. In de praktijk combineren we elementen van beide: we werken in korte iteraties (vergelijkbaar met sprints) maar de planning is feature-gestuurd, niet tijdsgestuurd.

Het voordeel: we leveren niet "wat er in de sprint paste" op maar "de features die het meest waardevol zijn". Als een feature groter is dan verwacht, besteden we er de tijd aan die nodig is — in plaats van het half-af op te leveren omdat de sprint voorbij is.

Lever niet wat er in de sprint paste, maar wat het meest waardevol is. Dat is het verschil tussen planning en prioritering.

Wanneer werkt FDD het best?

• Bij projecten met een duidelijke set features maar onzekere prioriteiten
• Wanneer stakeholders regelmatig werkende software willen zien
• Bij producten die iteratief groeien op basis van gebruikersfeedback
• Wanneer flexibiliteit belangrijker is dan een strak vooraf gedefinieerd plan

Conclusie

Veel opdrachtgevers kennen de frustratie van een project dat na maanden bouwen nog steeds niets toont wat je kunt gebruiken. Met FDD is dat verleden tijd: na elke iteratie heb je werkende software die je kunt testen, kunt laten zien en waarop je kunt bijsturen. Dat geeft vertrouwen en houdt projecten op koers.

Feature Driven Development zorgt ervoor dat elke uur development direct bijdraagt aan gebruikerswaarde. Het voorkomt verspilling, maakt voortgang transparant en geeft je de flexibiliteit om bij te sturen. Het is de manier waarop wij werken en het is de reden waarom onze klanten altijd weten waar ze aan toe zijn.