Feature Driven Development (FDD)

Feature Driven Development: in dit artikel wordt Feature Driven Development (FDD) praktisch uitgelegd. Na het lezen begrijp je de basis van deze krachtige tool voor internettechnologie.

Wat is Feature Driven Development (FDD) in project management?

Feature Driven Development (FDD) is een raamwerk voor iteratieve en incrementele softwareontwikkeling. De Agile methode wordt gebruikt voor het ontwikkelen van software met als doel om vaak en efficiënt resultaten te leveren. FDD stimuleert rapportage op alle niveaus, wat helpt om de voortgang en resultaten bij te houden.

In tegenstelling tot andere softwareontwikkeling-methoden, kunnen teams regelmatig en snel fouten en bugs identificeren en oplossen. Daarnaast is er de focus om de klant op elk moment te kunnen voorzien van updates en tussentijdse resultaten.

FDD is een van de favoriete benaderingen voor softwareontwikkeling omdat het twee aspecten aanpakt waarmee veel geworsteld wordt: verwarring en herzien/herbewerking.

FDD is een incrementele tool voor ontwikkeling, wat wil zeggen dat op bestaande software gebouwd wordt. In plaats van het doorvoeren van een grote en allesomvattende update, wordt met FDD stapsgewijs nieuwe functies vrijgegeven. Zo kan er op elk moment prioriteit gegeven worden aan de verzoeken van de klant, en deze tevreden houden.

FDD combineert een aantal van de door de projectsector erkende best practices tot een samenhangend geheel. Alle praktijken worden aangestuurd vanuit het perspectief van de klant.

Het belangrijkste doel is om snel werkende en tastbare software te leveren in overeenstemming met de regels van het Agile Manifesto.

Waar ontstond Feature Driven Development (FDD)?

Feature Driven Development (FDD) werd oorspronkelijk bedacht door Jeff De Luca in 1997 toen hij werkte aan een softwareontwikkelingsproject van 15 maanden, en meer dan vijftig medewerkers.

Deze ervaring leidde tot het opstellen van een reeks van vijf processen die de ontwikkeling van een algemeen model bevatten. Deze beschrijving werd voor het eerst geïntroduceerd aan de wereld in het boek ‘Java Modelling in Color with UML’ uit 1999. Dit boek werd geschreven door Peter Coad, Eric Lefebvre, en Jeff De Luca.

Later, in 2002, werd in een boek van Stephen Palmer en Mac Fesling een meer algemene beschrijving van FDD gegeven, los van Java.

Hoe werkt het Feature Driven Development (FDD)-proces?

FDD is een model gestuurd iteratieproces bestaande uit vijf basisactiviteiten. In de figuur hieronder worden deze activiteiten weergegeven. Tijdens de eerste twee activiteiten wordt een algemene vorm vastgesteld voor het model. De laatste drie activiteiten worden voor elke functie herhaald.

De eerste hoofdactiviteit bestaat uit het ontwikkelen van een algemeen model. Het resultaat van deze eerste activiteit is een objectmodel van hoog niveau, samen met notities over de ontwikkeling, functies en eisen.

De tweede stap is het samenstellen van een functielijst door de verschillende functies te groeperen in verwante functionaliteiten en vakgebieden.

Daarna wordt er gepland op functie, met als resultaat een ontwikkeling of identificatie van eigenaren en functiesets. Het grootste gedeelte van het proces beslaat stap vier en vijf. Deze twee activiteiten omvatten taken als modelleren, programmeren, testen en voorbereiden.

Wat zijn de verschillende activiteiten uit het FDD-proces?

Zoals bij alle Agile methoden, is de eerste stap van het Feature Driven Development-proces het verkrijgen van een goed beeld van de inhoud en de context van het project. Ook moet er een duidelijk en gedeeld begrip zijn van de doelgroep en hun behoeften.

Gedurende deze voorbereidingsfase moeten teams ernaar streven om alles te leren over het project en de beweegredenen. Deze fase van voorbereiding kan gezien worden als fase 0. Hoewel niet meegenomen in het officiële model, kan deze fase niet worden overgeslagen.

Activiteit 1: ontwikkeling algemeen model

Tijdens de eerste echte fase van FDD wordt voortgeborduurd op de resultaten van de eerdere research-fase. De eerste echte schets wordt opgesteld.

Met behulp van de thesis (leidraad) zal het team een gedetailleerd domeinmodel ontwikkeling die vervolgens wordt samengevoegd tot een nieuw algemeen model dat fungeert als blauwdruk voor het systeem. Tijdens het ontwikkelen ervan, en terwijl het team leert en ontwikkelt, worden details toegevoegd.

Activiteit 2: functielijsten ontwikkelen

De tweede fase van Feature Driven Development (FDD) bestaat uit het identificeren van kenmerken die de gebruiker of klant eist en waardeert. Het is belangrijk om te onthouden dat een functie een output is die door de klant gewaardeerd wordt.

Maak een lijst met functies die binnen twee weken voltooid kunnen worden, en besef dat deze functies doelen zijn, in plaats van taken.

Activiteit 3: functieplanning

De derde fase draait om het beheer van alle functies, en de manier waarop deze geïmplementeerd worden. Er wordt rekening gehouden met de werkdruk van het team, verschillende risico’s, en andere belangrijke aspecten om te voorkomen dat problemen ontstaan.

Het team houdt zich hier voornamelijk bezig met het analyseren van de complexiteit van elke functie en het plannen van taken die verband houden met de uitvoering ervan.

Tijdens de planningsfase dienen alle leden van het project deel te nemen aan de verschillende evaluatiemomenten die worden gehouden om de functies van het systeem of model af te stemmen met de eisen en wensen van de klant.

Ook worden er klasse-eigenaren worden vastgesteld. Dit zijn individuele ontwikkelaars die aan bepaalde klassen functies zijn toegewezen. Omdat elke klasse van de functie tot een specifieke ontwikkelaar toebehoort, is er altijd iemand verantwoordelijk voor alle klassen. Als er wijzigingen nodig zijn, is het zaak dat eigenaren van klassen samenwerken.

Activiteit 4: design by feature

De hoofdprogrammeur selecteert met behulp van de eerder opgedane kennis alle functies die het team moet ontwikkelen. Ook identificeert hij of zij de domeinklassen.

Nadat het team begint te werken, houdt de domeinexpert zich bezig met het analyseren en ontwerpen van de oplossingen voor elke functie.

Activiteit 5: build by feature

De laatste activiteit van Feature Driven Development (FDD) bestaat uit het implementeren van alle noodzakelijke elementen die het ontwerp ondersteunen.

Tijdens deze fase wordt bijvoorbeeld een gebruikersinterface gebouwd, of componenten van het systeem die in het technisch ontwerp werden vastgesteld.

Daarna wordt een prototype van de functie gemaakt. Deze wordt getest, geïnspecteerd en goedgekeurd. Na goedkeuring kan de functie worden toegevoegd aan de hoofdversie van het systeem.

Elke functie die langer nodig heeft dan twee weken wordt verder opgedeeld in elementen zodat deze voldoen aan de regel van maximaal twee weken per functie.

Kernprincipes van Feature Driven Development (FDD)?

FDD is gebaseerd op een aantal kernprincipes, of best practices. Een zevental worden hieronder toegelicht.

Inspecties

FDD-teams voeren met regelmaat inspecties uit om ervoor te zorgen dat de kwaliteit gewaarborgd blijft. De nadruk ligt hierbij vooral op het ontwerp en de code van het systeem. Het is belangrijk dat tijdens deze controle de defecten worden geïdentificeerd die anders pas later naar boven gekomen zouden zijn.

Feature-teams

Een feature-team is een dynamisch en klein team dat een kleine feature ontwikkelt. Zij zorgen ervoor dat vanuit meerdere invalshoeken naar elk besluitvormingsmoment gekeken wordt, en dat meerdere ontwerpopties geëvalueerd worden.

Hoewel een enkel persoon verantwoordelijk is voor de prestaties en de kwaliteit van een functie, draagt iedereen bij aan ontwerp- en implementatiebeslissingen.

Configuratiemanagement

Configuratiebeheer omvat het identificeren van de broncode voor alle functies die voltooid zijn tot een bepaald moment in de tijd. Ook gaat configuratiebeheer over het bijhouden van een geschiedenis van wijzigingen aan het systeem in verschillende klassen naarmate het project vordert.

Individuele klassen

Individueel eigendom betekent dat verschillende stukken werk, of een stuk code wordt toegewezen aan een eigenaar. Hij of zij is verantwoordelijk voor de uitvoering ervan, en staat garant voor de kwaliteit en de prestaties.

Domein modelleren

Domeinobjectmodellering bestaat uit het oplossen van problemen. Teams ontwikkelen verschillende diagrammen om objecten in een domein en de relatie tussen de objecten te beschrijven. Dit proces zorgt ervoor dat tijdens de uitvoering van latere werkzaamheden veel tijd bespaart wordt.

Functie-ontwikkelen

Een functie of tool die zo complex is dat de ontwikkeling ervan meer dan twee weken nodig heeft wordt opgedeeld in kleinere functies totdat elk deelprobleem klein genoeg is om het binnen twee weken op te lossen. Dit maakt het makkelijker om de juiste functionaliteiten te leveren en om het systeem aan te passen.

Voortgangsrapporten

Managers sturen een project met regelmatig opgestelde voortgangsrapporten van alle niveaus binnen en buiten het project.

De leden van het Feature Driven Development-team

Een modelleringsteam dat FDD gebruikt omvat in ieder geval de volgende rollen:

Projectmanager

De projectmanager, zoals in alle projecten, houdt toezicht op het hele project. Ook is de projectmanager tevens de schakel tussen sponsor of eigenaar en het team. FDD staat erom bekend nauw contact met de klant te stimuleren. Dit is een belangrijke verantwoordelijkheid voor de projectmanager.

Hoofdarchitect

De hoofdarchitect houdt zich bezig met het ontwerpen van het algemene ontwerp en de modellering van het nieuwe systeem. Tijdens de ontwikkelingsfase werkt de hoofdarchitect nauw samen met andere ontwikkelaars.

Ontwikkelingsmanager

De ontwikkelingsmanager leidt en begeleidt het volledige ontwikkelingsteam. Tevens houdt hij of zij toezicht op de dagelijkse programmeeractiviteiten, en dient als aanspreekpunt voor teamleden.

Hoofdprogrammeur

De hoofdprogrammeur helpt bij het ontwerp en de analyses en wordt soms ook aangesteld om kleinere ontwikkelteams te begeleiden en aan te sturen.

Klasseneigenaar

De klasseneigenaar is lid van een kleiner ontwikkelteam dat geleid wordt door de hoofdprogrammeur. De verantwoordelijkheden van een klasseneigenaar omvatten ontwerp, codes, testen en documenteren van functies.

Domeinexpert

De domeinexpert is onderdeel van een team dat het probleem oplost door analyses en klantcontact. De ontwikkelaars vertrouwen op de kennis en vaardigheden van de domeinexpert, en zorgen ervoor dat functies werken en leveren wat de klant verwacht.

Voor- en nadelen van Feature Driven Development (FDD)?

Het gebruik van FDD kent zowel voor- als nadelen. Hieronder volgt een overzicht van de belangrijkste uit beide categorieën.

Voordelen

• Gestructureerd gebruik van FDD voorziet het team van een goed begrip van de reikwijdte en context van het project en de doelstellingen
• FDD vereist minder langdradige vergaderingen dan alternatieven gebaseerd op Scrum. FDD stimuleert het gebruik van documentatie om te communiceren
• FDD is een gebruikersgerichte benadering voor software/systeemontwikkeling
• FDD is compatibel met grote, kleine, korte en lange projecten
• De vijf activiteiten maken het gemakkelijk voor nieuwe teamleden om snel op de hoogte te komen van het project en de doelstellingen
• FDD breekt grote hoeveelheden werk op in kleinere sets waardoor het makkelijker wordt om fouten op te sporen en te herstellen
• Hierdoor wordt het risico op vertraging kleiner, en wordt er een snelle doorlooptijd gegarandeerd

Nadelen

• Feature Driven Development (FDD) is minder geschikt voor zeer kleine projecten, en werkt niet voor projecten met slechts een enkele ontwikkelaar
• FDD zorgt voor een sterke afhankelijkheid van de hoofdprogrammeur
• FDD biedt weinig schriftelijke documentatie aan de consument zelf, ondanks de hoeveelheid documentatie tussen groepsleden onderling
• Stimuleert individualisme in plaats van collectivisme

Feature Driven Development (FDD) vs. Scrum

FDD heeft veel overeenkomsten met Scrum, maar in plaats van op levering gericht, is FDD functiegericht. Functies vormen een belangrijk component binnen FDD. Voor FDD zijn functies wat gebruikersverhalen betekenen voor Scrum ontwikkelaars. Ook gebruikersverhalen zijn kleine functies die door de klant gewaardeerd worden.

Tijdens het FDD-proces hoort een functie elke twee tot tien dagen geleverd te worden. In Scrum zijn de sprints vaak enkele weken. Ook hecht de FDD-benadering meer waarde aan documentatie voor intern gebruik dan andere methoden zoals Extreme Programming (XP) en Scrum. Hierdoor ontstaan ook verschillen in het nut en de rollen in vergaderingen.

Bij Scrum komen teams elke dag bij elkaar. Met FDD vertrouwen de teamleden op de interne documentatie die wordt uitgewisseld als onderdeel van de projectstrategie. Er vinden dus niet veel vergaderingen plaats wanneer Feature Driven Development (FDD) ingezet wordt.

Een ander belangrijk verschil tussen beide methoden, is dat bij FDD de persoon die het systeem uiteindelijk gaat gebruiken als eindgebruiker wordt gezien. In Scrum is het doorgaans de product owner die wordt gezien als de eindgebruiker.

Nu is het jouw beurt

Wat denk jij? Herken jij de uitleg over Feature Driven Development (FDD)? Wat zijn jouw persoonlijke succesfactoren voor het succesvol implementeren van softwareoplossingen of andere functies? Wordt FDD gebruikt in projecten binnen jouw omgeving? Geef jij de voorkeur aan Scrum of andere Agile-benaderingen? Heb jij tips of opmerkingen?

Deel jouw kennis en ervaring via het commentaar veld onderaan dit artikel.

Meer informatie

1. Arbain, A. F., Ghani, I., & Jeong, S. R. (2014). A systematic literature review on secure software development using feature driven development (FDD) agile model. Journal of Internet Computing and services, 15(1), 13-27.
2. Chowdhury, A. F., & Huda, M. N. (2011, December). Comparison between adaptive software development and feature driven development. In Proceedings of 2011 International Conference on Computer Science and Network Technology (Vol. 1, pp. 363-367). IEEE.
3. Firdaus, A., Ghani, I., & Jeong, S. R. (2014). Secure feature driven development (SFDD) model for secure software development. Procedia-Social and Behavioral Sciences, 129, 546-553.
4. Firdaus, A., Ghani, I., & Yasin, N. I. M. (2013). Developing secure websites using feature driven development (FDD): a case study. Journal of Clean Energy Technologies, 1(4), 322-326.

Citatie voor dit artikel:
Janse, B. (2020). Feature Driven Development (FDD). Retrieved [insert date] from Toolshero: https://www.toolshero.nl/informatie-technologie/feature-driven-development/

Oorspronkelijke publicatiedatum: 27/09/2020 | Laatste update: 24/05/2023

Wilt u linken naar dit artikel, dat kan!
<a href=”https://www.toolshero.nl/informatie-technologie/feature-driven-development/”>Toolshero: Feature Driven Development (FDD)</a>

Article by:

Ben Janse

Ben Janse is een young professional en werkzaam als Content Manager bij Toolshero. Daarnaast houdt hij zich binnen zijn studie International Business aan de Hogeschool Rotterdam bezig met het analyseren en ontwikkelen van managementmodellen. Dankzij zijn theoretische en praktische kennis weet hij hoofd- en bijzaken goed te onderscheiden waardoor de essentie van elk artikel goed naar voren komt.