Agil programutveckling

Agil programutveckling Pontus Evertsson D00, Lunds Tekniska Högskola d00pe@efd.lth.se Anna Jennerheim D00, Lunds Tekniska Högskola d00aj@efd.lth.se 2003-05-15 1

1. Inledning 3 2. Extreme Programming (XP) 3 3. Feature Driven Development (FDD) 5 4. Jämförelse mellan XP och FDD 6 5. Unified Process (UP) 8 6. Agile UP 10 7. Jämförelse mellan XP och UP 10 8. Sammanfattning 11 Referenslista 12 2

Abstract Vår djupstudie beskriver tre lättviktsmetoder, XP, Agile UP och FDD samt jämför de två sista med XP. 1. Inledning Agil är ett annat ord för lättvikt. Som studenter vid LTH har vi endast sett XP som lättviktsmetod vid programvaruutveckling i våra kurser. Därför är det intressant att se att det finns alternativ till XP som kanske i vissa situationer till och med kan passa bättre. Här tar vi upp två andra, Agile UP (Agile Unified Process) och FDD (Feature Driven Development). Vi beskriver vilka delar som ingår i dem och gör en jämförelse med XP. De som är tänkta att läsa vår djupstudie är andra studenter vid LTH som vill se att det finns andra sätt att utveckla mjukvara än med XP-metodiken. 2. Extreme Programming (XP) Extreme programming är en lättviktsmetodik som är optimerad för projekt med ca 2-10 projektmedlemmar. XP bygger på att man har många korta iterationer där varje iteration leder till ett fungerande program som sedan byggs ut i nästa iteration. Tack vare de korta iterationerna och den nära kundkontakten, on-site customer, som man utnyttjar i XP är, man inte rädd för förändringar av problembeskrivningen. XP Practices I XP finns ett antal practices att följa. Dessa är följande: Planning Game Small Releases Metaphor Simple Design Testing Refactoring Pair Programming Collective Ownership Continuous Integration 40-hour Work Week On-site Customer Nedan följer en kort beskrivning av dessa practices. Planning Game Planning game är det första som sker i varje iteration i ett XP-projekt. Det går ut på att så snabbt som möjligt komma upp med en grov plan över vad som skall göras under kommande iteration. Arbetsmetoden under Planning game går till så att kunden kommer med ett antal index cards där det står ett krav, i form av en story, på varje. Utvecklarna diskuterar sedan igenom dessa, tidsestimerar 3

dem samt tar på sig ansvaret för en story. Small Releases Small releases innebär att man har väldigt korta iterationscykler. Detta för att kunden hela tiden skall ha en aktuell upplaga av programmet så att man kan veta att utvecklingen drivs åt rätt håll, dvs att programmet blir som kunden vill ha det. Metaphor I XP har man en metafor som beskriver hela systemet. Alla utvecklare och kunder känner till och förstår denna metafor vilket gör att det blir lättare att kommunicera då kunder och utvecklarna garanterat förstår varandra om de använder sig av metaforen. Simple Design XP använder sig av Simple design vilket innebär att alla test ska fungera, det får inte finnas duplicerad kod, koden skall vara tydlig och lätt att förstå samt innehåller så få klasser och metoder som möjligt. Testing Då en ny enhet skall implementeras skrivs först testerna och sedan implementerar man enheten så att alla testerna går igenom. Detta sätt att jobba på kallas Test first. Refactoring I XP är man aldrig rädd för att ändra i koden och gör refaktoreringar så fort det finns ett behov av detta till exempel om man upptäcker duplicerad kod, onödigt invecklad kod eller liknande. Pair Programming All produktionskod utvecklas i par. Detta medför många fördelar. Exempelvis är det alltid minst två programmerare som känner den aktuella koden väl och kunskaperna om klasserna sprids i projektgruppen om man kontinuerligt byter par. Dessutom minskar risken för missar och slarvfel markant eftersom koden hela tiden granskas. Collective Ownership Collective ownership innebär att alla äger all kod gemensamt. Det gör att alla kan ändra överallt i koden och man behöver därför inte vänta på att någon annan ska få tid att göra ändringen åt en. Continous Integration Så fort en delenhet är testad och färdig integreras denna med hela projektet för att minska mergeproblem. 40-hour Work Week I XP jobbar man aldrig övertid förutom kortare perioder undantagsvis. Detta för att alla hela tiden skall vara utvilade och motiverade. Detta höjer kvaliteten på den kod som produceras. 4

On-site Customer I XP är kunden hela tiden närvarande vilket minskar chansen att utvecklingen går i fel riktning. Ingen behöver gissa på vad de tror är rätt utan det är bara att fråga kunden om det är några oklarheter. 3. Feature Driven Development (FDD) FDD, som står för Feature Driven Development, är en modelldriven process med korta iterationer. Processen bygger på att man först gör en grov modellering av hela problemet och detta efterföljs sedan av en serie med korta design by feature, build by feature-iterationer. FDD består av följande fem olika delprocesser: 1. Develop an Overall Model 2. Build a Features List 3. Plan by Feature 4. Design by Feature 5. Build by Feature Delprocess ett, två och tre utförs bara en gång i ett projekt, därpå följer iterationer innehållandes de sista två delprocesserna. 1. Develop an Overall Model I denna första fas av projektet arbetar utvecklingslaget under ledning av chefsarkitekten med att skapa ett grovt programskelett. Under det arbetet går man till väga på följande sätt: Först utvecklar designers en väldigt grov modell av hela problemet för att sedan presentera detta för resten av utvecklingslaget. Därefter producerar designers ett programskelett och presenterar återigen modellen för hela utvecklingslaget, fast denna gång lite mer djupgående. Nu när programskelettet finns delas utvecklingslaget in i mindre grupper för att sedan, lett av chefsarkitekten, arbeta parallellt med att designa mindre delar av modellen. Detta presenteras sedan och slås samman med den totala designen med stöd av chefsarkitekten. 2. Build a Feature List Denna del i utvecklingen går ut på att sätta samman en feature list, som är en lista med alla saker som kunden sagt att programmet skall kunna göra. Ett exempel, då programmet som skall utvecklas är en ordbehandlare, kan vara: Beräkna det totala antalet tecken i dokumentet. Om inte kunden har specificerat problemet med hjälp av användarfall och sådana här funktionella krav får utvecklarna själva försöka ta fram features under aktivitet 1. Under denna fas grupperas även features med närliggande funktionalitet ihop. 3. Plan by Feature I denna tredje fas görs en högnivåplanering över hela projektet. Grupperna av features sorteras i ordningsföljd och delas ut till chefsprogrammerare som blir ansvariga för en eller flera featuregrupper. Med hjälp av programskelettet som utvecklades i fas 1 delas även ägandet av de olika 5

klasserna ut till de olika utvecklarna. Alla utvecklarna äger sina egna klasser. 4-5. Design by Feature / Build by Feature Under fas fyra och fem görs själva programmet. En chefsprogrammerare väljer först ut ett par av sina features som är lämpliga att utveckla under de närmsta 1-2 veckorna. Därefter undersöker chefsprogrammeraren vilka klasser som troligen kommer att vara involverade då dessa features skall göras. Ägarna till dessa klasser tillsammans med den aktuella chefsprogrammeraren bildar ett feature team. Det är normalt att en chefsprogrammerare leder två till tre feature-team parallellt samt att en klassägare ingår i två till tre olika feature-team samtidigt. Design by Feature Feature-teamet börjar sedan med den detaljerade designen för att bygga sina features. Designen består av att laget först gör detaljerade sekvensdiagram över alla features som laget skall utveckla. Då detta är gjort gör respektive klassägare beskrivningar av vad de klasser och metoder, som kommer att implementeras, skall utföra. Innan teamet går in i Build By Feature-fasen genomgår designen en inspektion. Build by Feature I denna fas skriver respektive klassägare koden som skulle implementeras i deras klasser. Detta innefattar kod och enhetstestning samt att hålla i en kodinspektion då det är klart. När chefsprogrammeraren är helt nöjd med en feature adderas denna nya kod till den kod som senare skall bli den som levereras till kunden. 4. Jämförelse mellan XP och FDD XP och FDD skiljer sig mest i följande avseenden: Storlek på projektgrupperna XP är i huvudsak designat att lämpa sig för projekt med två till tio utvecklare. FDD var från början designat att fungera för en grupp av ca 16-20 utvecklare varav fyra är chefsprogrammerare och 16 stycken är klassägare (programmerare). Det har dock visat sig att FDD fungerar bra även för betydligt större projekt. Den största begränsande faktorn är antalet tillgängliga chefsprogrammerare i projektet. Metafor och modell I XP börjar man med att skriva stories till exempel med hjälp av index cards. Därefter tidsestimeras dessa och kunden väljer ut vilka man vill ha med i nästa release. Dessa stories beskriver saker som programmet skall kunna utföra. För att förbättra helhetsbilden av programmet använder man sig av en metafor som beskriver hela programmet och som alla känner till och kan använda sig av. 6

I FDD har man istället features som kan jämföras med XPs stories eller tasks. Den största skillnaden mellan XP och FDD i det här avseendet är att man har en objektmodell, dvs klassdiagram och liknande dokumentation. Detta har man enligt förespråkare för FDD för att få en bättre överblick över systemet. Det ska också förhindra att utvecklarna skapar en egen, individuell design i huvudet och istället se till att alla har samma bild. Dessutom är objektmodellen till för att minska antalet refactorings, eftersom det är lättare att göra en bra design när man vet hur allt ska se ut. Kollektivt ägandeskap eller ägande av klasser I XP har man kollektivt ägande av klasserna. Fördelarna med detta är enligt XP-förespråkarna bland annat följande tre punkter: 1 Utvecklingen går snabbare än om man har en person som ägare till varje klass. Man slipper då vänta på att ägaren ska ha tid att införa ändringarna i koden man behöver, de kan man skriva dit själv. 2 Eftersom alla får ändra all kod måste den vara lätt att sätta sig in i. Av den anledningen strävar utvecklarna mot så okomplicerad kod som möjligt. 3 Kollektivt ägandeskap sprider kunskap om hela systemet i utvecklingslaget. I FDD utnyttjar man istället ägande av klasser. Alla utvecklarna äger sina egna klasser. Några av fördelarna med detta kan vara följande: 1 I FDD är alla som äger en klass med i samma feature-team. Detta innebär att all kod som behöver ändras för att implementera en feature ägs av teamet. Även detta gör att man inte behöver vänta så mycket på att andra ska ändra i koden. 2 All lågnivådesign görs inom feature-teamet vilket innebär att alla är överens om och använder samma design. Om det är någon i teamet som inte följer den överenskomna designen upptäcks detta vid kodinspektionen och det får korrigeras. Även onödigt komplex kod upptäcks vid kodgranskningen. 3 Klassägarna känner sin egen klass perfekt, men eftersom de ofta kommer att hamna i samma team som klasser med närliggande funktionalitet kommer de även att känna till dessa bra. Varje utvecklare känner till det den behöver veta. Kodgranskning och parprogrammering I XP tillämpar man parprogrammering vilket innebär att designen och koden hela tiden granskas av en person utöver programmeraren själv. Detta leder självklart till ökad kodkvalitet. I FDD har man mer formella kodgranskningar. Detta tar mer tid men samtidigt får hela teamet en chans att gå igenom all ny kod. Testning I XP testar man programmets korrekthet genom enhets- och acceptanstester. I FDD finns inte specificerat hur testningen skall genomföras utan det är upp till chefsprogrammeraren att bestämma vad som är lämpligt. 7

5. Unified Process (UP) Unified Process är en risk-driven, iterativ utvecklingsprocess. Iterationerna är korta och innehåller var för sig kravanalys, design, implementation och testning. Efter varje iteration har man ett fungerande system som växer efter varje iteration man lämnar bakom sig. UP:s practices UP har följande practices som beskrivs närmare en bit ner: Iterativ utveckling Högrisk- och prioritetskrav tidigt Tidigt fokus på kärnarkitekturen Tillämpa use cases Modellera programvara visuellt Kontinuerligt verifiera kvalitet Hantera krav omsorgsfullt Hantera, kontrollera förändringar Iterativ utveckling Att dela in hela processen i iterationer är det viktigaste med UP. Den rekommenderade längden på en iteration är två till sex veckor, men om teamet är riktigt stort kan en iteration vara, som mest, upp till sex månader. Högrisk- och prioritetskrav tidigt UP sägs vara riskdriven. Det innebär att man tar hand om krav som man bedömer har hög riskfaktor eller är viktiga för kunden i de tidiga iterationerna. Detta gör att projektet, som är dömda att misslyckas, kan få misslyckas så tidigt som möjligt. Tidigt fokus på kärnarkitekturen Att implementera kärnarkitekturen tidigt i projektet hänger samman med föregående practise eftersom det både är viktigt och riskfyllt att få arkitekturen på plats. Tillämpa use cases Use cases är skrivna historier om hur systemet används. De är till för att utforska och dokumentera funktionaliteten hos de givna kraven. Modellera programvara visuellt Detta görs exempelvis med UML-diagram. Kontinuerligt verifiera kvalitet Detta görs genom tester. Testningen ska börja tidigt, utföras ofta och vara realistisk så att man får feedback på det man har byggt. 8

Hantera krav omsorgsfullt Att hantera krav omsorgsfullt innebär att inte vara slarvig vid exempelvis prioriteringar och uppföljningar. Hantera, kontrollera förändringar När ett nytt krav tillkommer måste man ta reda på hur det kommer att påverka det som redan finns implementerat och hur mycket extra arbete som måste läggas ner. UP:s faser En utvecklingscykel, dvs hela processen från början till färdig produkt, består av fyra olika phases (faser). Dessa är: 1. Inception (början) - Inledningsfasen där man tittar på vad som ska göras, gör vaga estimeringar samt bygger preliminära modeller. 2. Elaboration (utveckling) - Den först utvecklingsfasen där kärnarkitekturen, och andra delar med hög risk, implementeras. Modellerna arbetas om. 3. Construction (konstruktion) Den andra utvecklingsfasen där implementation av resten av systemet utförs. I slutet av fasen förbereds leverans till kunden. 4. Transition (övergång) Den sista fasen där systemet beta-testas och levereras till kunden. UP:s discipliner UP har nio olika discipliner, listade nedan, som finns till viss del i samtliga faser. Dock är modellering koncentrerad till de två första och implementation till de två i mitten. Business modeling Requirements Design Implementation Test Deployment Configuration & change management Project management Environment Disciplinerna sägs bestå av ett antal artefakter. En artefakt är något man tillverkar under projektet. Som exempel utgörs disciplinen Design av artefakterna designmodell, arkitekturdokumentation och datamodell. 6. Agile UP UP är tänkt att användas som en lättviktsmodell, agile UP. Detta uppnås eftersom man endast väljer några av artefakterna till sitt projekt, givetvis de man tycker passar bäst. UP gör att man kan anpassa sig när förutsättningar och krav ändras eftersom man inte gör all design och planering i början utan använder sig av iterationer. 9

7. Jämförelse mellan XP och UP De största skillnaderna mellan XP och UP: Teamstorleken XP är byggt för mindre projekt medan ett projekt i UP kan ha upp till hundratals utvecklare samtidigt. Dock delas dessa in i mindre subteam som arbetar parallellt. Design och modeller I UP ritar och skriver man mer för att beskriva systemet, till exempel med UML-diagram. I XP kommer mycket av designen efter hand när man implementerar. Lättillgänglig kund I XP finns on-site customer för att man lätt ska kunna reda upp eventuella oklarheter. Detta saknas i UP. Samarbete UP har inte specificerat vilka konstellationer man ska ha inom teamet när man arbetar, i XP programmerar man alltid i par. De största likheterna mellan XP och UP: Iterationer Båda delar upp arbetet i iterationer och planerar en iteration, max två i taget. Testning I båda varianterna ska man testa tidigt, ofta och på vettiga saker för att få värdefull feedback. Dock saknar UP XP:s Test first. 8. Sammanfattning Det hade varit intressant att delta i projekt som använder sig av agile UP och FDD för att få testa dem ordentligt, då hade man även kunnat göra en mer utförlig jämförelse. Vad vi kommit fram till är att det finns olika sätt att genomföra programmeringsprojekt och de har sina respektive fördelar och nackdelar. Därför får man välja vilken metod som passar bäst i den givna situationen och vilken man tycker bäst om personligen. Det är viktigt att man kommer överens om vilken metod man ska använda så att alla är med på det, det vill säga att ingen motverkar resten av gruppen och drar ner disciplinen som behövs för att följa den valda metodens regler. 10

Referenslista Titel Författare Internetadress Feature-Driven Development Stephen Palmer http://www.informit.com and Extreme Programming FDD Overview Presentation Agile Software Development using Feature Driven Development (FDD) www.nebulon.com/articles/fdd/ download/fddoverview.pdf www.nebulon.com/fdd/index.html Applying UML and patterns Craig Larman 11