Større systemer og applikasjoner er som regel delt opp i horisontale lag. De øverste lagene er nærmest sluttbrukerne og de nederste lagene er nærmest databasen og de eksterne systemene. Lagene i midten håndterer forretningslogikk. 

Hvordan skal man gå frem for å utvikle et stort system? Vi tar for gitt at fossefallsmetoden er foreldet og at vi ser oss om etter en mer smidig (agile) prosess. I tillegg til Scrum og Extreme Programming (XP) finnes det en metodikk kalt “Feature Driven Development” (FDD) som er utviklet av Jeff de Luca og Peter Coad. 

Hvis man setter funksjonalitet i fokus, kan man tenke seg at funksjonalitet skjærer vertikalt gjennom alle lagene. For å implementere use casen “Registrer ny kunde” trengs det sannsynligvis brukergrensesnitt, forretningslogikk, integrasjon og datalagring.

Tanken bak FDD er at planlegging, design og utvikling styres av funksjoner, og at funksjoner utvikles en etter en selv om de berører alle de horisontale lagene i systemet.

En kort forklaring på hvordan FDD virker:

1. FDD starter med modellering. Domene-eksperter forklarer forretningsdomenet til utviklerne. Dette dokumenteres.

2. Forretningsdomenet deles opp i områder som igjen har aktiviteter. Aktivitenene beskrives som “features” på en formell måte som minner om use cases. Features skal ikke tar mer enn 2 uker å utvikle.

3. Planlegging skjer ved at aktiviteter fordeles på utviklingsteam.

4. Design av en feature.

5. Utvikling av en feature.

Forskjellige utviklingsteam kan jobbe i parallell med forskjellige features. Erfaringer etter at en feature er ferdig mates tilbake til modellen som ble beskrevet i punkt 1.

Fordelen med å jobbe på denne måten er man ender opp med fungerende software, ikke bare moduler som virker i seg selv, men som er avhengig av andre moduler for å anses som komplett. Et utviklingsteam vil også få en eierfølelse og et ansvar for en hel feature, ikke bare en del av av systemet.

Alt dette er vel og bra, og case studies beskrevet av Butler Group viser til store innsparinger ved bruk av denne metodikken.

Jeg kan ikke forstå annet en at denne utviklingsmetodikken vil sette veldig store krav til kommunikasjon mellom de forskjellige utviklingsteamene for å unngå duplisering av arbeid. Jeg vil også tro at en stor grad av refactoring blir nødvendig etter hvert som nye features implementeres. 

Som vanlig er litteraturen som omhandler denne metodikken full av store ord og generelle vendinger, men ikke så veldig mye om eventuelle negative sider eller ting man bør passe på i FDD-prosjekter. 

Hvis noen har erfaringer med bruk av FDD i praksis, så del dem gjerne med andre ved å kommentere dette innlegget.

Mer om Feature Driven Development finner du her:

http://en.wikipedia.org/wiki/Feature_Driven_Development 

http://www.nebulon.com/fdd/index.html

http://www.featuredrivendevelopment.com/