Feature Driven Development (FDD) er Jeff De Luca’s pragmatiske og agile tilgang til udvikling af software. Den kombinerer de største fordele fra andre agile metoder som SCRUM og eXtreme Programming med Eric Evan’s Domain-Driven Design, Desuden indeholder metoden dynamiske teams, revires fra kollegaer samt stort fokus på minimalt design.
Når Feature Driven Development gennemføres rigtigt vil metoden give meningsfuld og præcis rapportering til tiden.
Kernen i Feature Driven Development udgøres af 4 processer. De 5 processer beskriver sammenlagt reglerne for levering og samarbejde og som med andre metoder er reglerne kun en del af en succesfuld udførelse. Elementer som erfaring, disciplin og lederskab er også essentielle. Feature Driven Development er ikke en redning på alt men indeholder gode agile elementer.
1. Beskrivelse af en overordnet model.
Feature Driven Development adskiller sig fra Scrum og eXtreme Programming ved at kræve, at teamet investeret nok tid i starten med at udforske og analysere problemstillingen gennem at bygge en object model for problemets område.
I modsætning til andre mere formelle tilgange til object modellering eller analyse og design i et vandfaldsbaseret projekt er modellering i Feature Driven Development en opgave der varetages af et tværgående team fra forretning, udviklere, arkitekter og drift. De samarbejder i en time boxet tilgang for ikke at bruge for megen tid på et større design.
Det er vigtigt at beskrivelsen af den overordnede model og tiden anvendt lige præcis tillader, at der efterfølgende kan laves en Feature List (Product Backlog i Scrum) og en intielt overordnet release plan.
2. Byg en Feature List
Med udgangspunkt I resultater fra trin 1 laver teamet en overordnet backlog og I stedet for User Stories anvender Feature Driven Development begrebet Feature.
En Feature er en lille funktion som ønskes af brugeren og anvender følgende form. [action] the [result] [by|for|of|to} a(n) [object]; for eksempel ‘beregn totalen af en salgsordre eller ”valider password for en bruger”
Disse aktiviteter er også time boxet med fokus på et tværgående samarbejde. Feature listen i FDD har en niveauinddeling med EPICS, Features og Stories. Hvor SCRUM har en inddeling med EPICS og User Stories.
I standard SCRUM er metoden som standard sat til at Product Owner kommer til det første spring planlægningsmøde med en forberedt backlog. Scrum metoden forklarer intet om hvordan Product Owner gennemfører dette. I Feature Driven Development er dette trinet som beskriver hvorledes der opbygges en backlog.
3. Planlægning per Feature
Det tredje trin i Feature Driven Development er sortering og organisering af alle features i en overordnet plan og tildeling af disse til en lead developer eller lignende. Udviklere er ligeledes allokeret til deres egne specifikke Classses, som de blev identificeret i den overordnede object model. Her er ligeledes en forskel i forhold til eXtreme Programming kollektive ejerskab på koden da Feature Driven Development med sit tværgående dynmaiske team er en alternativ løsning. Scrum har ligeledes fokus på de tværgående teams.
4-5. Design en feature / Byg en feature
Trin 4 og 5 I Feature Driven Development guider et iterativt forløb med et selvstyrende team gennem leverancen. Som tidligere genbruger teamet sin viden opnået fra de forrige trin. En Lead developer (Chief Programmer i FDD) udvælger en lille delmængde af de features som skal udvikles over de næste par dage. Lead Developer identificerer de domain classess son sandsynligvis berøres og de relaterede Class Owners definerer hvilken sammensætning af kompetencer, der er nødvendig i teamet. Afhængigt af omstændighederne kan det være nødvendigt for andre kompetencer, som testere og UX/UI designere at være en del af teamet. Dette feature team arbejder sammen og ledes fagligt af en domainekspert som analyserer og beskriver detaljerne i hver enkelt feature inklusive opsamling i et løsningsdesign. Teamet arbejder individuelt på hver enkelt udviklings og test task. De afslutter med en gennemgang af koden når de er færdige. Når Lead developer er tilfreds med arbejdet kan det sættes som Done/færdigt. De færdige features flyttes til ”build” og teamet opløses.
De 2 processer med Design og byg en feature gentages for andre sæt af mindre features. Lead Developer’s rolle er naturligvis en gennemgående og kritisk rolle I Feature Driven Development. FDD’s Chief Programmer passer fint til de fleste it-organisationers definition af en lead developer og der skulle ikke vær de store problemer her. Dog kan det frekomme svært for nolge Lead Developer at de skal lede et tværgående team. Domæne ekspertens rolle meget vigtig og har mange af de tilsvarende ansvar som ses i SCRUM med Product Owner. Domæne ekspertens rolle skal sikre den rette forretningsmæssige prioritering men også bidrage med forretningsmæssig viden.
Dokumenter, planer og fremdriftsrapporter.
Feature Driven Development er funderet på flere agile principper fra det agile manifest. Det er minimal indsats i forhold til design, planlægning og fremdriftsdokumentation. Burn Down Charts er de samme som ses i Scrum. Efterhånden som design og udvikling bliver til skal feature teamet indsamle alle diagrammer, skitser og notater. Dette udgør design pakken for en feature. Formaliteterne omkring dokumentationskrav kan dog variere i forhold til den enkelte organisations politikker på området.
Feature Driven Development blev udviklet med henblik at optimere samarbejdet på tværs af kompetencer og opgaver. Softwareudviklere kan til tider være svære at håntere pga. deres stærke holdninger til designet eller standarder. FDD adressere i metoden mere detaljeret hvordan disse udfordringer håndteres. Feature Driven Development er bevist at være en meget effektiv metode til at redde meget komplekse projekter som er gået i stå eller som er i fare for at blive standset.
