Feature Driven Development (FDD)
Feature Driven Development (FDD) är en process som börjar med att man fastställer helhetsmodellen av det system man ska bygga. När detta är gjort delar man upp modellen i mindre bitar så kallade features, ”design by feature, build by feature”. Dessa implementerar man över en period av cirka två veckor. En feature är inom projektet definierad som en funktion som kunden har nytta av.
Man kan dela upp Feature Driven Development i fyra punkter:
- Develop an overall model
- Build a feature list
- Plan by feature
- Design by feature/Build by feature
Likheterna mellan FDD och XP är många. Båda processerna är designade för att snabbt kunna leverera färdiga resultat till kunden så att man snabbt skall kunna få feedback. De är också mer fokuserade på att överföra kunskap genom människor istället för att som i de stora tungviktprocesserna producera tusentals sidor dokumentation. Även när det gäller rollerna i projektet har de samma synsätt. Det vill säga att det finns ingen fast designgrupp eller någon fast implementeringsgrupp utan alla jobbar tillsammans. Detta gäller även kunderna som båda processerna vill ha med i projektet som en aktiv part i utvecklingen.
Adaptive Software Development (ASD)
Jim Highsmith har utvecklat Adaptive Software Development (ASD) efter många års arbete med tunga traditionella processer.
ASD har tre faser som arbetsprocessen genomlöper:
- Spekulation Highsmith menar att en planering är omöjligt att genomföra i ett adaptivt arbete eftersom det är omöjligt att förutse allting. Däremot kan man spekulera i vad som kan ske i det fortsatta arbetet.
- Samarbete När man arbetar i en miljö där man måste vara beredd på snabba förändringar måste projektgruppen samarbeta på ett helt nytt sätt. Projektledningens uppgift är i mindre skala att tala om för sin personal vad som ska göras, viktigare är att uppmuntra kommunikation mellan gruppmedlemmar så att de tillsammans kommer fram till vad som skall göras.
- Lärande I en traditionell processutveckling kommer själva lärandet i skymundan i och med att man bestämmer sig för en design och sedan håller sig till den. I en adaptiv utvecklingsprocess är det viktigt att man efter varje iteration tittar tillbaka på vad som gick bra eller dåligt. Sedan är det viktigt att lära sig av detta inför nästa utvecklingscykel.
Crystal
”Crystal metoden” även kallad ”Crystal clear” (kristallklart) är en så kallad ”human-powered” metod, alltså att den är driven och centrerad till och av människor. Den här modellen utgår ifrån en väldigt enkel del, nämligen att teamet ska vara och befinna sig väldigt nära varandra och man ska ha möten med varandra och avstämningar med kunden. Det här arbetssättet är även utvecklat för att direkt tolka regler och visa teamet vad man ska göra och vad man ska uppmärksamma. Crystal metoden passar bra då projektet har ett fast pris/budget. Syftet är även att man ska försöka minska ”byråkratin” i projektet och skapa utrymme för att låta teamet göra det dem är bäst på, designa, utforma, skapa eller något annat som de är intresserad av som gynnar projektet.
En annan del är att man förutom avstämningar med kunden låter kunden få vara med i arbetet och ses som en ”expert” eftersom det är de som kommer att använda produkten senare är det inte konstigt eller skadligt om denna får vara med i utvecklandet av produkten.
Crystal-familjen är färgkodad för att beteckna ”vikt” av den metod som behövs. Således skulle ett stort projekt som har konsekvenser som innebär risk för människors liv använda Crystal Sapphire eller Crystal Diamond metoder. Ett litet projekt kan använda Crystal Clear, Crystal Yellow eller Crystal Orange. Clear är till för projektgrupper som sitter i ett och samma rum, omkring sex till tio personer.
- Clear kräver av gruppen att producera teknisk dokumentation, men innehållet lämnas över åt gruppen att själv bestämma efter eget omdöme. Detta är för att hjälpa framtida utvecklare att sätta sig in i projektet. Inom Crystal talar man varmt om whiteboardens oöverträffliga egenskaper i utvecklingsarbetet. Köp in, och snåla inte med whiteboards, för man ritar sällan av vad man kommit fram till (och det är inte sällan man kommer fram till att den informationen var kritisk först långt efteråt) och då är det bra att man inte behöver sudda ut tavlan. Det kan finnas information lite här och var på tavlorna som kan vara viktig att få med i den tekniska dokumentationen.
- Efter och mellan varje release har man en workshop med projektgruppen där man satsar på att trimma in både produkten och själva utvecklingsarbetet. Man intervjuar utvecklarna och tittar på och reder ut brister i produktionskoden och arbetsmetoderna.