Feature Driven Development
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.
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.
Hvorfor fejler nogle agile transformationer ?
Vi har har kortlagt hvilke barrierer de fleste organisationer skal imødegå ved en agil transformationVi har interviewet 98 organisationer i deres arbejde med en succesfuld agil transformation. I forbindelse med vores survey identificerede vi, at der grundlæggende er...
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,...
Hvis du glemmer “T” i Agilt Team får du aldrig en agil kultur.
Hvordan medarbejdere skal ledes i den agile kultur og organisation. Agile organisationer er karakteriseret ved det forhold at værdi er skabt af små teams, som opererer mere eller mindre uafhængigt af hinanden. Små teams er betragteligt bedre til at omstille sig til...
Agile organisationer og virksomhedskultur
Organisationsstruktur og virksomhedskultur spiller en vigtig rolle i en succesfuld implementering af agile metoder. Arbejdsopgaverne i den moderne agile organisation er placeret forskelligt sammenlignet med en traditionel organisation. Softwareudvikling er...
Hvordan motiverer du et team der er modstander af agile principper?
Når organisationen praktiserer kontinuerlig forbedring i det agile miljø er den eneste konstant forandring. For de teams der har opnået en moderat og forudsigelig succes ved, at følge de mest elementære principper i fx SCRUM/KANBAN kan det være svært at omstille sig...
4 ting du skal have på plads for, at få succes med agile metoder
Din succes afhænger af 4 elementer Du får ikke det bedste resultat med det team som kan alle de agile metode regler og principper. Du får de bedste resultater med det team som arbejder bedst sammen, har et agilt mindset, tager et kollektivt ansvar og som har lyst til...
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
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
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...
Hvad er Design Thinking?
Design Thinking er en metode og en iterativ proces. Design Thinking er ikke en eksklusiv rettighed for designere. Så hvorfor kalde det design thinking? Design Thinking er en metode og en iterativ proces, hvor vi søger at forstå brugeren, udfordre antagelser, og...