Introduktion til Feature Driven Development. 

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.

De 5 processer i Feature Driven Development

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.

Feature Driven Development

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.

Fordelene ved Feature Driven Development

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.

Hvad er SCRUM

Hvad er SCRUM

Introduktion til SCRUM  SCRUM-metoden er udviklet med udgangspunkt i de principperne for agil udvikling (læs om andre agile metoder her eller det agile manifest her). Agil udvikling er baseret på en trinvis og iterativ tilgang. I stedet for omfattende analyse,...

Hvad er Servant Leadership?

Hvad er Servant Leadership?

Ledelse er ikke hvad det har været – der er behov for Servant Leadership. Vi går fra en - lang - periode med hierarki mod en periode, hvor ledelse kan betegnes ved ord som empati, parathed, fleksibilitet - og evnen over alt andet: evnen til at inspirere og skabe...

Agil projektledelse og SCRUM

Agil projektledelse og SCRUM

Agil projektledelse er ikke lig med SCRUM. For mange tror fejlagtigt tror at SCRUM også leverer en metode til agil projektledelse. SCRUM indeholder nogle ledelses- og arbejdsprodukter som Produkt Vision, Release Plan, Product Backlog og Burn Down Chart. SCRUM har dog...

Agile metoder – et overblik

Agile metoder – et overblik

4 niveauer af agile metoder. Agile metoder har vundet stort indpas i danske IT-organisationer. Der er mange begreber og filosofier og vi vil her guide dig til en bedre forståelse. Vi har inddelt metoderne i forhold til Porteføljestyring, Projektledelse,...

Scrum Product Owner – opgaver og ansvar

Scrum Product Owner – opgaver og ansvar

Product Owner rollen i Scrum. Product Owner rollen kan betragtes i 2 overordnede dele Forberedende aktiviteter som udarbejdelse af Produkt Vision, Produkt Roadmap og Releaseplan. Eksekverende aktiviteter som prioritering og vedligeholdelse af Produkt Backlog, Sprint...

Pin It on Pinterest

Share This