Extreme programming (XP)

Transkript

1 Extreme programming (XP) Vad är extreme programming samt vilka krav ställs på utvecklare som arbetar med XP HÅKAN ANDERSSON Examensarbete Stockholm, Sverige 2005 TRITA-NA-E05186

2 Numerisk analys och datalogi Department of Numerical Analysis KTH and Computer Science Stockholm Royal Institute of Technology SE Stockholm, Sweden Extreme programming (XP) Vad är extreme programming samt vilka krav ställs på utvecklare som arbetar med XP HÅKAN ANDERSSON TRITA-NA-E05186 Examensarbete i datalogi om 20 poäng vid Programmet för datateknik, Kungliga Tekniska Högskolan år 2005 Handledare på Nada var Björn Eiderbäck Examinator var Yngve Sundblad

3 Extreme Programming Vad är Extreme Programming samt vilka krav ställs på utvecklare som arbetar med XP Sammanfattning Syftet med detta examensarbete är att få en bild av vad systemutvecklingsmetodiken Extreme Programming (XP) är samt att försöka utreda vilka krav som ställs på en systemutvecklare som arbetar med XP. Ett grundantagande inom XP är att det går att reducera risk genom att ha ett körbart system under hela projektet. För att alltid leverera maximalt värde i varje givet ögonblick utvecklas alltid det mest värdeskapande först i projektet. Vad som är mest värdeskapande bestämmer alltid kunden. Verkligheten är dock sällan lika enkel som teorin utan det finns komplexitet som måste hanteras. Ett exempel på detta är att XP förespråkar att kunden ska vara på plats genom hela projektet vilket ofta är svårt i konsultprojekt. Det var generellt enkelt att lära sig förstå hur och varför olika aktiviteter används inom XP. En fördel med att använda XP är dess fokus på effektivitet samt förmåga att hantera risk och förändring. Andra fördelar är att parprogrammeringen verkar kunna ha bra mentoreffekter på sikt, ett bra sätt att introducera nya systemutvecklare. I enlighet med teorin är den kanske viktigaste egenskapen för att lyckas med XP god kommunikationsförmåga. Det gäller bland annat att kunna förstå och översätta kundens behov i tekniska lösningar. Några av aktiviteterna, såsom refactoring, enkel design och testning, var svåra att använda i praktiken. Detta är dock viktiga aktiviteter för konsultföretag som arbetar med långa kundrelationer. Eftersom systemen utvecklas över lång tid är det nödvändigt att hela tiden jobba med att förenkla och hålla systemdesignen enkel.

4 Extreme Programming What is Extreme Programming and what is required from a developer trying to adapt XP Abstract The purpose of this thesis is to examine what the software methodology Extreme Programming (XP) is and also try determining what is required from a developer trying to adopt XP. A major assumption of XP is that it is possible to reduce risk by always having a system runnable. To maximize the value from the system the most valuable parts are always developed first in the project. The customer decides on what is most valuable. The reality however, is not as simple as theory and you have to be able to cope with the complexities that exist. An example of this is that XP proclaims that you should have the customer on site throughout the entire project; this is not always possible. The activities of XP are easy to learn and understand how to use. Focus on efficiency and risk reduction is important aspects on why to choose XP. Another positive effect of XP is that pair programming gives mentoring effect, a good way to introduce new employees. According to theory, one of the most important abilities is good communication skills. It is necessary to understand the client and to be able to translate business needs into technical solutions. Some of the activities, such as refactoring, simple design and testing are hard to use in practice. Still, the activities are very important for a consultancy firm having long customer relations. The activities are necessary to keep the system design simple enough to be maintainable.

5 Innehåll Inledning... 1 Metod... 3 Avgränsning... 4 Generaliserbarhet... 5 XP enligt teorin... 6 XP i ett större sammanhang XP i praktiken Analys Slutsatser Litteraturlista... 24

6 Inledning Vi lever i en föränderlig värld där globalisering och teknisk utveckling leder till ett allt högre tempo. Timing är en kritisk faktor för att IT ska kunna skapa verkliga konkurrensfördelar eller undvika konkurrensofördelar (Keen 1991). Därför är det viktigt att systemutvecklingen inte försenas och drar ut på tiden. System som utvecklas idag måste: utvecklas fort vara lätta att underhålla innehålla få buggar kunna vidareutvecklas till en låg kostnad Extreme Programming (nedan kallat XP) försöker adressera samtliga dessa krav. Jag vill med mitt exjobb reda ut vilka krav som finns för en utvecklare som arbetar med XP. Mål Målet med detta exjobb är att komma fram till några av de krav som ställs på en systemutvecklare som arbetar med XP samt få en bild av hur XP är att arbeta med. Viktiga frågeställningar som jag önskar besvara är: Vad är viktigt att tänka på för ett företag som funderar på att börja jobba med XP? Hur fungerar XP för att utveckla webbaserade verksamhetsnära system? Hur är XP anpassat för systemutveckling på konsultföretag? Vilka egenskaper och färdigheter är viktiga för att en systemutvecklare ska kunna arbeta effektivt med XP? Syfte Syftet med detta examensarbete är att få en bild av vad XP är samt att utreda vilka krav som ställs på en systemutvecklare som arbetar med XP. Fokus ligger på verksamhetsnära webbprojekt utvecklade på Mira Network där exjobbet utförs. Ett syfte med exjobbet är att sammanfatta viktiga erfarenheter utifrån arbetet med ett XP-baserat projekt. Detta ska resultera i generella slutsatser som förhoppningsvis är giltiga både för Mira Network men även för utvecklare som arbetar med XP under andra förutsättningar. Om Mira Network Mira Network AB (nedan kallat Mira) är ett konsultföretag med inriktning på IT- och verksamhetsutveckling. Företaget startades i augusti 1998 av Magnus Bratt och Johan Wennström. Företaget har idag drygt 10 anställda. Fokus ligger på uppdrag med systemutveckling som är starkt kopplad till företagets verksamhet, exempelvis införande av intranät, extranät och e-businesslösningar. Några av de större kunderna är Handelshögskolan i Stockholm Executive Education, Karolinska Institutet, Norges Handelshögskola, Helsingfors Tekniska Högskola, JKL och Folkpartiet. 1

7 Mira är också ett drivhus för internetrelaterade affärsidéer. Inom ramen för detta har bland annat en produkt för virtuella nätverk/alumninätverk utvecklats en kontaktbaserad nätverkstjänst som gör det lättare för högskolor och företag att hålla kontakten med sina tidigare studenter respektive medarbetare. Denna produkt är idag marknadsledande för den svenska marknaden och används idag av ett 20-tal universitet och högskolor i Norden. Mira Network har blivit prisbelönt i en amerikansk tävling, arrangerad av Jakob Nielsen, om världens 10 bäst designade intranät Mira Network var den enda svenska representanten bland de prisbelönta. Listan över de vinnande bidragen bestod i övrigt av bland annat Wal-Mart, Deloitte & Touche, Lonely Planet, Världsbanken och ABB. 2

8 Metod För att förstå XP och systemutvecklingsmetodik generellt genomfördes inledande en litteraturstudie. Utifrån teorierna genomfördes en del praktiskt arbete i form av ett större projekt. Efter projektet genomfördes intervjuer och diskussioner med de inblandade. Intervjuerna och diskussionerna har legat till grund för den analys som gjorts och mina slutsatser. Litteraturstudie Eftersom fokus ligger på system med stark koppling till företags verksamhet genomfördes en litteraturstudie med litteratur både om XP och systemutveckling generellt men också litteratur med mer verksamhetsinriktade frågor kring systemutveckling. Att arbeta med XP i praktiken Inom ramen för exjobbet har ett större helt XP-baserat projekt genomförts för att få praktiska erfarenheter. Delar av XP, främst user stories och parprogrammering, har också testats andra projekt på Mira. Intervju och diskussioner För att kunna förstå de krav som ställs på XP-utvecklare har intervjuer genomförts med olika inblandade personer i projekten. Jag har även vid ett antal olika tillfällen fört diskussioner kring systemutvecklingsfrågor. Analys Analysen baserar sig till största delen på det praktiska arbetet som genomförts men även på de intervjuer och diskussioner som förts kring dessa frågor. Min förhoppning är att analysen och slutsatserna kommer att kunna koppla tillbaka till teorin. 3

9 Avgränsning De avgränsningar jag gjort i detta arbete är bland annat att fokusera på verksamhetsnära webbaserade system. Karaktäristiskt för dessa system är att de är gränssnittsintensiva och ej speciellt beräkningstunga eller tekniskt komplicerade. Projekten har utvecklats med små projektgrupper vilket också påverkar hur en utvecklingsmetodik fungerar. Jag avser inte komma fram till om XP gör systemutveckling på Mira mer effektiv eftersom detta är ett alltför omfattande arbete för detta examensarbete. Det är dessutom svårt att definiera vad effektiv systemutveckling är eftersom det inbegriper så mycket mer än till exempel hur mycket kod en systemutvecklare kan producera per dag eller hur få buggar ett system innehåller. Under andra förutsättningar går det säkert att komma fram till andra slutsatser än vad jag gör i mitt arbete. XP handlar om samspelet mellan människor och det är naturligt att de enskilda individerna även påverkar hur XP fungerar. 4

10 Generaliserbarhet Då Mira är ett relativt litet företag och detta är ett begränsat arbete kan jag bara dra vissa avgränsade slutsatser utifrån det praktiska arbetet. Det kan också finnas specifika karaktäristiska av konsultverksamhet, såsom många parallella projekt, som påverkar hur XP fungerar och därmed även mina slutsatser. Det är också svårt att veta om det är objektiva eller subjektiva resultat, till exempel skulle det kunna vara så att det upplevs som mer effektivt att parprogrammera för att det är roligare att arbeta två än var och en enskilt. 5

11 XP enligt teorin Varför behövs en metodik? I en doktorsavhandling från Handelshögskolan sammanfattar Werr (1999) forskning inom området systemutvecklingsmetodik 1 för IT-konsulter. Bland annat tar han upp en studie av Rhenman som beskriver problemlösning som en intiutiv process och inte en strukturerad process. Systemutveckling beskrivs som en problemlösningsprocess där erfarenhet är den enskilt viktigaste faktorn. Även studier av Alvesson och Risling (sammanfattade av Werr 1999) pekar på att metoder inom systemutveckling inte är en linjär process som direkt stödjs av metoder utan snarare bygger på praktiskt arbete där erfarenhet och tyst kunskap 2 styr de underliggande besluten och arbetet. Metoden ses istället som ett sätt att stödja administration samt att styra hur olika processer ska ordnas. De pekar även på att metoder påverkar kultur, normer och värderingar i företaget. Lättviktsmetodiker Under senare år har det vuxit fram en ny kategori utvecklingsmetodiker, så kallade agile -metodiker 3. Fowler (2003) beskriver två skillnader mellan agile-metoder och traditionella metoder. Agile-metoder är anpassande snarare än förutsägande. Ingenjörsmetoder tenderar att försöka planera mycket i systemutvecklingsprocessen för en lång tid framåt, vilket fungerar bra tills förändring måste hanteras. Därför ligger det i deras natur att förhindra förändring. Agile-metoder däremot välkomnar förändring. De försöker vara processer som anpassar sig till förändring, även till den grad att de anpassar sig själva. Agile-metoder är även personorienterade snarare än processorienterade. Målet med ingenjörsmetoder är att definiera en process som kommer att fungera för vem som helst som ska använda den. Agile-metoder hävdar att ingen process kan mäta sig med skickligheten hos personerna som arbetar i projektet, därför blir rollen för processen att istället stödja personerna i deras arbete. XPs historia XP utvecklades i början av 90-talet av Kent Beck. Kent fokuserade på aktiviteter som drev utvecklingen av projekt framåt, dessa förenade han i en metodik han kallade Extreme Programming. En metafor han hade för detta var ett mixerbord där varje aktivitet var en spak som vreds upp till max, to the extreme (Beck, Fowler 2000). XPs fokus Enligt en studie från Standish Group genomförs endast 16% av alla projekt inom budget och fastställda tidsramar. 31% av projekten läggs helt ner och de resterande 53% av projekten går över budget med i genomsnitt 189% (Standish Group 1994). 1 Även om doktorsavhandlingen i huvudsak är inriktad på managementkonsultation använder sig Andreas Werr av systemutvecklingsmetodik som ett närliggande område till managementkonsultation och baserar därför en del av sin grund på just systemutvecklingsmetodik 2 Tacit knowledge är den engelska termen 3 En svensk översättning skulle kunna vara lättviktsmetodiker. 6

12 Dessa siffror bekräftar att utvecklingen av system är mycket riskfylld. En av XPs grundidéer är att reducera risk i projekten. Några av de riskelement (Beck 1999) tar upp är: försening av projektet projektet avbryts i förtid behov eller problem missförstås och systemet löser därför inte några problem kundens verksamhet utvecklas så att systemet som utvecklas inte längre tillför något värde för kunden systemen degenererar och blir till slut för dyra att underhålla och vidareutveckla XP hävdar att det går att reducera risk genom att alltid se till att ha ett körbart system som levererar ett visst värde till kunden. För att alltid leverera maximalt värde i varje givet ögonblick utvecklas alltid det mest värdeskapande först i projektet. Vad som är mest värdeskapande bestämmer alltid kunden (Beck 1999). Ett antagande som ofta görs är att kostnaden för att göra en förändring sent i ett projekt ökar exponentiellt, figur 1. Givet detta antagande är det viktigt att minimera antalet förändringar som behöver göras sent i projektet eftersom ändringar då är extremt kostsamma. Ett sätt att hantera detta brukar vara att försöka planera så mycket som möjligt i förväg. Kostnad för en förändring Projektets genomförande Figur 1 Cost of change enligt traditionell syn Enligt Beck går kurvan att plana ut genom att hela tiden använda sig av ett antal aktiviteter som minskar komplexiteten och garanterar kvaliten i systemet, figur 2 (Beck 1999). 7

13 Kostnad för en förändring Projektets genomförande Figur 2 Cost of change enligt XP Givet detta antagande får systemutvecklingsprocessen helt andra förutsättningar. Det är möjligt att hantera stora ändringar sent i projektet och göra designval sent i processen. Denna utplanade kostnadskurva leder också till att det inte behövs göras någon förstudie för att komma fram till en exakt systemspecifikation och design. Istället läggs tid på aktiviteter som för projektet framåt. Istället för att planera systemdesignen i förväg så utvecklas den evolutionärt under projektet. Problemet att försöka planera för en design i förväg är att det är svårt att veta var flexibilitet behövs i designen och var den inte behövs (Fowler 2002). Inom XP betonas hur pass viktig kommunikationen är för att lyckas i ett projekt. Utan kommunikation mellan programmerare, projektledare och kunder kan ett projekt aldrig lyckas. XP försöker stimulera kommunikation genom användandet av aktiviteter som inte fungerar utan kommunikation (Beck 1999). En annan grundpelare inom XP är feedback. Feedback från enhetstester talar om att systemet fungerar. Feedback från acceptanstester talar om att det gör rätt saker. Ju mer feedback, desto lättare är det att kommunicera (Beck 1999). För att kunna arbeta med XP krävs att designen av systemet hela tiden utvecklas krävs mod. Du måste våga kasta bort kod, ändra systemarkitektur eller testa nya idéer som kan reducera komplexitet i projekten (Beck 1999). En grundidé inom XP är att alltid utveckla det enklaste som löser problemet eller behovet. Du får inte planera framåt och försöka gissa vad du kommer att behöva imorgon. Det är svårt att inte försöka blicka framåt mot det du tror dig behöva implementera imorgon, i nästa vecka eller i nästa månad (Beck 1999). XP gör en chansning där du slår vad om det är bättre att göra en enkel sak idag och betala lite mer imorgon, om du kommer att behöva det, än att utveckla lite mer idag för något du kanske aldrig kommer att behöva (Beck, Fowler 2000). 8

14 XP-aktiviteter XP prioriterar de saker som driver projektet framåt. De aktiviteter som utförs kontinuerligt under hela projektet är 4 : Planeringsmöten Möten där kunden bestämmer vad som ska utvecklas och vad som ska prioriteras. Utvecklarna avgör hur omfattande en uppgift är samt hur den ska utvecklas. Testning All kod i ett system ska ha automatiska tester som garanterar att systemet fungerar som det ska, testerna skrivs innan koden utvecklas. Det skrivs även tester på en högre nivå som garanterar att systemet gör det som det förväntas göra, kunden skriver dessa tester. Allt som utvecklas måste vara testbart. Parprogrammering All kod skrivs i par om två utvecklare. Den ena tänker strategiskt hur problemen ska lösas och den andra skriver koden. Inom paren byts arbetsfunktion ofta. Refactoring För att konstant hålla nere komplexiteten i ett system krävs att utvecklaren arbetar med refactoring. Refactoring är att förenkla koden vilket till exempel kan vara att bryta ut gemensam kod i funktioner, omstrukturera kod eller förenkla funktioner. Enkel design Systemet ska alltid designas så enkelt som möjligt. Ingen onödig komplexitet får finnas i designen. Gemensamt ägande av kod Alla utvecklare äger all kod gemensamt och alla får ändra i all kod i ett system. Kontinuerlig integrering Alla utvecklare ska integrera den kod de skriver så fort som möjligt för att säkerställa att den nya koden fungerar med all annan redan skriven kod. Efter varje integrering av kod ska alla tester köras och det är utvecklarens ansvarar att rätta till kod som eventuellt inte längre fungerar. Kund på plats För att snabbt kunna få svar på frågor så krävs det att kunden alltid är på plats. Små lanseringar Nya versioner släpps ofta till användarna. 40-timmarsvecka Ingen ska jobba mer än 40 timmar per vecka eftersom detta påverkar kvaliteten på systemet. Regeln är att aldrig arbeta övertid två veckor i rad. Kodstandarder För att alla ska kunna jobba gemensamt med all kod så krävs att alla formaterar kod på samma sätt. Systemmetafor För att beskriva systemet försöker man finna en metafor från något annat välkänt område vilket underlättar att förklara systemet. Aktiviteterna är inte unika i sig men enligt XP uppkommer det synergieffekter 5 av att arbeta med aktiviteterna ihop då de förstärker varandra i många olika kombinationer. Detta ger effekten på riskkurvan så att den kan planas ut. Figur 3 visar hur de olika XP-aktiviteterna samverkar. 4 De engelska termerna är: planning meeting, testing, pair programming, refactoring, simple design, collective code ownership, continuous integration, on-site customer, small releases, 40-hour week, coding standards och system metaphor. 5 Den den totala nyttan av aktiviteterna ihop överstiger summan av nyttan för varje enskild aktivitetet. 9

15 KUND PÅ PLATS SYSTEMMETAFOR 40-TIMMARSVECKA PLANERINGSMÖTEN REFACTORING ENKEL DESIGN PARPROGRAMMERING TESTNING SMÅ LANSERINGAR GEMENSAMT ÄGANDE AV KOD KODSTANDARDER KONTINUERLIG INTEGRERING Figur 3 Hur de olika aktiviteterna i XP samverkar med varandra (från Extreme Programming Explained) XP-processen XP är egentligen inte en processmetodik i den bemärkelsen att den beskriver ett antal olika aktiviteter som ska utföras i en viss sekvens. Istället förespråkar XP att alla aktiviteter kontinuerligt utförs. Det finns dock ett visst processflöde även i XP, se figur 4 nedan. Processen utnyttjar feedback i en stor utsträckning vilket är nödvändigt i en iterativ metodik. I centrum finns processen iteration i vilken all utveckling sker. Testscenarior USER STORIES ARKITEKTUR- TEST Systemmetafor Behov Releaseplan RELEASE- PLANERING ITERATION Buggar Senaste versionen ACCEPTANS- TEST Godkänt av kund LITEN RELEASE Osäkra uppskattningar Säkra uppskattningar Nästa iteration TEST Figur 4 Schematisk bild över XP-processen (från Centralt i XP är user stories. En user story beskriver något som ska utvecklas i systemet som har ett värde för kunden, den möjliggör för systemutvecklaren och kunden att dela upp systemet så att det kan levereras i delar (Beck, Fowler 2000). User stories ska vara beskrivna med naturligt språk och inte vara någon teknisk specifikation. Alla user stories ska vara oberoende av varandra (Beck, Fowler 2000). Kunden äger rätten att välja ut vilka user stories som ska ingå i en iteration och programmerarna avgör storleken eller omfattningen på en user story (Beck 1999). En anledning till att user stories ska vara relativt små är att de ska vara enkla att bedöma omfattningen av. Ett problem när mer komplexa uppgifter bedöms är att vissa 10

16 aktiviteter utelämnas när omfattningen bedöms. De utelämnade aktiviteterna kan summera upp till 20-30% extra tid (McConnel 1996). XP hanterar problemet med att underskatta user stories genom att kontinuerligt följa upp alla uppskattningar. Projektledaren utvärderar kontinuerligt om någon under- eller övervärderar user stories. Beck skriver du kan ge vilka uppskattningar du vill, men om du aldrig mäter verkligheten mot dina uppskattningar kommer du aldrig att lära dig (Beck 1999). 11

17 XP i ett större sammanhang IT- och verksamhetsutveckling Det är viktigt att förstå att ett IT-system i sig sällan skapar något egentligt värde för ett företag. Bara om systemet kan stödja arbetet eller helt förändra hur företaget driver sin verksamhet kan verklig nytta skapas med IT. Davenport (1993) skriver bland annat att Beslutsfattare som försöker att maximera nyttan med IT-satsningar måste se förändringar i företagets processer som länken mellan IT och den ekonomiska avkastningen. Vi kan inte längre tro att en IT-investering i sig själv ska kunna skapa något värde. Vi måste förstå att rollen IT spelar är att stödja förändringsarbetet. Konsultverksamhet De flesta konsultföretag har liknande mål med sin verksamhet. Maister (1997) beskriver de flesta konsultföretags mission statement som Att leverera enatsående service till kunderna, att erbjuda karriärermöjligheter till de anställda samt att uppnå ett finansiellt resultat för att kunna växa. Maister (1997) beskriver två karaktäristika för konsultföretag; att kunna hantera specialanpassning i projekten och att i kundkontakten erbjuda överlägsen service gentemot kunderna. Det är viktigt att förstå att varor konsumeras medan tjänster upplevs. Ett konsultföretag måste hantera kundens upplevelse både vad gäller service och att hantera de tekniska problemen. Vidare skriver Maister: Eftersom teknisk kvalitet är något oklart för många kunder väljer de därför att fokusera mer på kvalitén på servicen än kvalitén på det tekniska hur ologiskt det än kan tyckas. Det finns enligt Maister (1997) tre olika inriktningar för konsultförtag: Brains: Hög specialanpassning och hög risk. Fokus ligger på att kunna hantera risk och förändringsprojekt. Grey hair: Fokus på att vara experter inom ett begränsat område och lösa liknande problem för många kunder inom samma bransch eller med samma problemområde. För denna typ av konsultföretag är det viktigt att sprida kunskap mellan medarbetare. Procedure: Lågkostnadsprojekt med fokus på effektiva interna processer. Automatisera och förbättra interna processer för att skapa ytterligare konkurrensfördelar. Det höga kravet på service för konsultföretag i kombination med vilken typ av projekt som genomförs ställer naturligtvis en del krav på den utvecklingsmetodik som används. För ett företag inom kategorin brains är det viktigt att kunna hantera mycket anpassning, förändring och osäkerhet medan det för ett företag inom procedure är mycket viktigare att utvecklingen är så effektiv som möjligt. Mycket av teorin kring XP handlar om avgränsade projekt som utvecklas internt i en dataavdelning eller som renodlade systemutvecklingsprojekt. Ett exempel som Keen (1991) tar upp är det är själva förmågan att förstå fördelarna med IT som skapar verkliga konkurrensfördelar med IT. XP betonar vikten av kommunikation mellan projektledare, programmerare och kund men tar helt bort affärsrelaterade beslut från systemutvecklarna. För att kunna se hur IT kan skapa konkurrensfördelar för kunden måste de som förstår IT även ha en förståelse för verksamheten. 12

18 Använt Kritik som ofta framförs mot XP handlar om usability och gränssnitt. Usability är något som knappt berörs av XP-litteraturen. En artikel av Adams (2003) sammanfattar den kritik som framförs mot XP. Adams menar att Beck har en ganska naiv inställning till usability i den bemärkelse att Kent anser att slutanvändaren är den person som bestämmer hur systemet ska fungera. I denna bemärkelse tillskriver Kent slutanvändaren expertkunskaper inom usability vilket ofta inte är fallet. Det är självklart viktigt att slutanvändaren får testa systemet och ge feedback på vad som fungerar bra och dåligt men sällan vet slutanvändaren själv vad som behöver ändras för att göra systemet mer lättanvänt. 13

19 XP i praktiken För att ge en bättre bild av hur XP passar in i Miras utvecklingsmetodik inleds detta kapitel med en kort beskrivning av den utvecklingsfilosofi som finns på Mira. Detta följs av en beskrivning hur XP har använts på Mira i detta arbete. Miras filosofi om systemutveckling Miras syn på hur system bör utvecklas visas i figur 5. Pilen symboliserar projektets genomförande med tre dimensioner som löper parallellt genom hela projektet, målet är positiva effekter på affärsnivå. Strategi rätt system utvecklas som motsvarar de behov som systemet ska uppfylla. Utveckling ett bra system måste utvecklas. Med bra menas att det är lättanvänt, lätt att underhålla, går lätt att vidareutveckla samt att det innehåller förhållandevis få buggar. Införande systemet måste bli använt för att det ska bidra till positiva effekter. Figur 5 illustrerar att strategi, utveckling och införande är aktiviteter som genomförs kontinuerligt genom hela projektet i varierande omfattning. Det går emot den traditionella synen att en förstudie först genomförs som ligger till grund för det system som utvecklas och som slutligen införs. Figur 5 Strategi, utveckling och införande genomförs parallellt genom hela projektet (Magnus Bratt, Johan Wennström 1999) Krav och behov förändras under projektets gång och det är viktigt att kunna ta hänsyn till och anpassa sig utifrån det. Utvecklingen och användning av systemet startar i princip dag ett. Användandet av ett system leder i sig till större förståelse för behov och krav vilket ökar chansen att utveckla det som skapar mest värde. Systemutvecklingen på Mira Network sker iterativt, oftast med små projektgrupper. Ett normalstort projekt består av en projektledare och en systemutvecklare som oftast även är systemansvarig. Varje större system som utvecklas har en systemansvarig samt en assisterande systemansvarig. Intensiteten i projekten är varierande under olika faser. Vissa perioder sker intensiv utveckling och under andra perioder i princip uteslutande förvaltning. För att kunna bidra till positiva effekter på affärsnivå är kundrelationerna oftast långa. Systemen utvecklas i takt med att kundernas verksamhet utvecklas. Viktigt är att 14

20 involvera många personer från kunden och helst någon eller några från högsta ledningen. För att införandet av system ska bli lyckat krävs att ledningen ser systemet som viktigt. För att ett system ska bli använt måste slutanvändarna förstå hur de ska använda systemet. För att skapa lättanvända system krävs att man prioriterar usability genomgående. De system som utvecklas ska vara enkla att använda och anpassade för målgruppen. Om detta misslyckas är chanserna små att systemen verkligen kommer att användas. XP-baserat projekt Inom ramen för exjobbet genomfördes ett XP-baserat projekt 6. I projektet användes de flesta centrala delarna av XP. Iterationsmöten med kunden hölls veckovis och projektet genomfördes under ett halvår varav fyra månader med intensiv systemutveckling. All utveckling i projektet skedde med parprogrammering. Iterationsmötena hölls regelbundet varje vecka och under varje iterationsmöte gick igenom revideringar från tidigare ej godkända user stories samt diskuterade de nya user stories som utvecklats under den senaste iterationen. Systemet som utvecklades var relativt databas och gränssnittsintensivt. De få problem som var av teknisk karaktär kunde lösas genom att applicera lösningar från andra system som utvecklats tidigare. Ett antal liknande system hade utvecklats tidigare och mycket erfarenhet från dessa utnyttjades i detta projekt. En central del av XP som inte användes i projektet var automatiserade enhetstester och acceptanstester då vi saknade bra program och verktyg för detta. Istället fick kunden varje vecka, inför varje iterationsmöte, gå igenom alla tidigare user stories som skulle revideras samt alla nya user stories som utvecklats under iterationen. All funktionalitet som utvecklades beskrevs i enkla user stories. Kunden valde i vilken ordning som olika funktioner skulle utvecklas. Detta ledde till att systemet utvecklades i en något annorlunda ordning och saker som form, navigering och säkerhet utvecklades först i slutet av projektet. 6 Utveckling av en CV och jobbdatabas 15

21 Analys Generellt fungerade XP bra som utvecklingsmetodik på Mira. En styrka med XP är enkelheten att kunna anpassa till situationen. Just behovet av anpassning är kanske extra viktigt för ett litet företag där alla projekt har olika karaktär beroende på storlek, målgrupp och funktionalitet. XP visade sig väl lämpat för konsultföretag eftersom det är naturligt att ha en tät och intensiv kundkontakt vilket är en förutsättning för att kunna erbjuda bra service och kontinuerligt lyssna efter nya behov. XP hanterar dessutom risk, kunskapsspridning och effektivitet bra varför det lämpar sig väl för alla tre kategorier av konsultföretag som beskrevs i teoridelen. Första delen av analysen är uppdelad utifrån de 12 olika aktiviteterna inom XP samt ett extra avsnitt om user stories, som inte är en XP-aktivitet men som motiverar ett eget avsnitt eftersom det är en central del av XP. Den andra delen av analysen återkopplar till Miras perspektiv Rätt, Bra och Använt. Planeringsmöten I avsaknad av automatiserade tester fick kunden gå igenom alla utvecklade user stories inför varje iterationsmöte. På iterationsmöten gick vi igenom alla förslag på förändringar och bedömde vad som skulle ingå som revideringar samt vad som var ny funktionalitet och som skulle brytas ut till nya user stories. Detta ledde till att mycket av tiden på möten ägnades åt att återkoppla till föregående iteration och inte så mycket tid på att prioritera och diskutera kommande utveckling. Det hade varit bra att kunna lägga mer tid på att diskutera vilken funktionalitet som skulle prioriteras i nästa iteration. I projektet lyckades vi inte riktigt att prioritera tiden på ett bra sätt och en slutsats är att det är viktigt att i förväg bestämma hur lång tid av mötet som ska ägnas åt respektive del. En aspekt av att träffa kunden så pass ofta och regelbundet är att man får hårda deadlines i projektet att följa. Det ger en kontinuerlig indikation om projektet ligger i fas eller ej, något som kan vara svårt om man bara har en deadline långt fram i tiden. Testning Eftersom testning är en av grundstenarna inom XP och den aktivitet som Beck anser står för sig själv så är det motiverat att förklara varför vi valde att inte arbeta med testning, det vill säga med testdriven utveckling och automatisering av acceptanstester. I enskilda konsultuppdrag är tekniska fel relativt enkla att rätta till eftersom spridningen av felet är begränsat till en instans av ett system. Varje system har automatiserad övervakning som fångar upp alla tekniska fel och loggar dessa. Det är inte de tekniska buggarna som är dyra att rätta till utan misstag i databasmodellen eller systemdesignen. Den typen av designfel är svåra att testa innan systemet verkligen börjar användas. Naturligtvis är det önskvärt att systemet innehåller så få fel och buggar som möjligt men det är viktigt att förstå varför tester valdes bort. 16

22 Ytterligare ett skäl till att vi inte valde att arbeta med testning var att vi inte hittade några bra testverktyg för den miljö som vi arbetade i 7. De flesta verktyg var anpassade för objektorienterade miljöer som Java eller.net. Acceptanstestning genomfördes däremot så att kunden fick testa all ny funktionalitet inför varje iterationsmöte. En anledning till att dessa inte automatiserades var att bibehålla en flexibilitet i testningen och att inte lägga allt för mycket av utvecklingstiden på att sätta upp tester av gränssnitt. Det var ganska få problem som var enkla att testa ur aspekten att de gjorde rätt saker. Istället handlade det mer om problem av karaktären kommer slutanvändarna att förstå hur detta moment genomförs. Denna typ av användbarhetsproblem är naturligtvis mer problematisk att automatisera. Ett problem med de automatiserade tester som XP förespråkar är att de är väldigt inriktade på beräkningsproblem. Givet att information X matas in i systemet så ska information Y returneras. I många verksamhetskritiska system automatiseras och omdesignas processer och det är mycket svårare att skapa tester som mäter om organisationen verkligen effektiviseras av en funktion. Gränssnittslösningar visade sig vara svårt att diskutera per telefon och det blev istället nödvändigt att utvärdera funktioner på varje iterationsmöte. Att hålla reda på vilka delar av systemet som var godkända var tidsödande och hade kunnat gjorts mer effektivt. Ett exempel hade kunna varit att skriva ut screenshots och markera dessa som godkända, vilket hade underlättat att hålla reda på vad som verkligen behövde testas inför varje iteration. Att behålla utskrifter på alla sidor i systemet går emot ett av XPs mål att ha så lite dokumentation som möjligt men kanske hade varit ett bra alternativ trots det extra arbetet. Parprogrammering Parprogrammeringen var något som inte använts tidigare annat än till att lösa enstaka problem gemensamt. Erfarenheterna från parprogrammering var generellt mycket positiva och det upplevdes inte som komplicerat att parprogrammera. Vi fann dock att alla uppgifter inte var effektiva att lösa i par. Detta gällde främst enklare uppgifter som att ändra copy, flytta eller ändra storlek på inmatningsfält. I utvecklingsarbetet av systemet arbetade bara två systemutvecklare varför det inte blev möjligt att rotera utvecklare mellan olika par. Något som minskade nyttan av parprogrammeringen var att det fanns skillnader i erfarenhet mellan dem som utvecklade. Det gjorde att det blev svårt att helt koncentrera sig bara på den ena uppgiften, att skriva kod eller att tänka strategiskt. Det märktes en viss skillnad i effektivitet beroende på vem som skrev kod och vem som tänkte på helheten. Detta är naturligtvis bara ett kortsiktigt problem eftersom mentorseffekten bör leda till att nivån jämnas ut snabbare än om parprogrammering inte använts. Den tekniska kvalitén blev hög eftersom vi behövde diskutera lösningarna, de blev automatiskt kommunikativa eftersom båda i paret var tvungna att förstå lösningen. 7 Den utvecklingsmiljö vi arbetade med var Microsoft Active Server Pages 3.0 och Microsoft SQL Server

23 Parprogrammeringen fungerade bäst till att designa gränssnitt i systemet. För systemdesign och systemutveckling blev effekterna ganska små på grund av skillnaden i erfarenhet. Vad gäller lösning av mer komplexa tekniska problem så ger parprogrammering troligen ännu mer om båda systemutvecklarna är erfarna eftersom båda då kan komma på fler lösningar. I mina intervjuer framkom att parprogrammering fungerat bra för att lära sig designmönster, systemdesign och utvecklingsmiljö. Då många av projekten på Mira normalt utvecklas i små grupper har det blivit ett begränsat utbyte av erfarenhet mellan olika systemutvecklare. Detta är något som förbättrades genom parprogrammering. Refactoring Refactoring var den XP-aktivitet som var svårast att arbeta med kontinuerligt. Det krävs mycket arbete för att fundera igenom hur designen kan hållas enkel och enhetlig genom hela projektet. Erfarenhet från tidigare system spelade en stor roll i detta arbete. Den utvecklingsmiljö vi arbetade med hade inte heller något bra stöd och det blev svårt att hinna göra större refactoring i projektet. Det är lätt att inse att en funktion eller ett system är tekniskt komplicerat men det är ofta svårt att reducera denna komplexitet. För att kunna förenkla krävs att den som systemutvecklar kan skapa sig en bild av en förenklad design samt förstå hur man kan nå dit. Det kräver att man kan skapa sig en strukturerad bild av systemdesignen. Råd som att kod inte ska upprepas är dock enkla att följa. Refactoring underlättas troligen av att enhetstester finns, detta kunde inte testas eftersom vi avstod från tester. Enkel design Erfarenheter från liknande projekt var mycket värdefulla för hur systemdesignen kom att se ut. För att kunna arbeta strukturerat och minska komplexiteten med refactoring krävs erfarenhet av utveckling. Det krävs att man vet hur man bäst förenklar och skapar struktur i system. För att en systemutvecklare, eller ett team av systemutvecklare, ska kunna hålla en evolutionär design enkel och hanterbar krävs viss erfarenhet av systemutveckling. Enkel design var en av de svårare XP-aktiviteterna att jobba med. För att kunna jobba effektivt måste ibland små avsteg göras från den design som valts. Ofta faller bitarna på sin plats senare i projektet och man ser hur man kan förenkla delar av systemet man skrivit tidigare. Det svåra är att förstå när designen blivit för spretig eller komplexiteten för stor. Ett flertal gånger under XP-projektet förstod vi att vi senare skulle behöva skriva om en funktion för att reducera komplexiteten. Även enkel design kunde ha unerlättats genom användandet av enhetstester. Enligt teorin ska testdriven utveckling per automatik ge enkelhet i designen, något som vi alltså inte kunde undersöka. Gemensamt ägande av kod Denna aktivitet var inte så relevant. Eftersom projektgrupperna på Mira är små blir det naturligt med gemensamt ägande av kod. Själva principen är dock viktig eftersom det snabbt måste kunna göras ändringar utan att behöva vänta på någon annan. 18

24 Kontinuerlig integrering All utveckling gjordes direkt mot utvecklingsservern. Eftersom den utvecklingsmiljö vi använde inte krävde någon form av kompilering hade vi snarare en form av omedelbar integrering. Kund på plats Ett problem som ofta uppstår i konsultprojekt, och förmodligen generellt i systemutvecklingsprojekt, är att det är svårt att få tillräckligt med resurser från kunden, som ofta har andra arbetsuppgifter att sköta parallellt med att driva systemutvecklingsprojekt. Att ha kunden på plats konstant är nästan alltid uteslutet men ibland kan det till och med vara svårt att bara få tag i kunden per telefon. I projektet utnyttjade vi iterationsmötena till att ställa frågor samt diskutera funktionalitet. Det finns också svårigheter med att definiera vem som är kund eftersom det i nästan alla projekt finns många intressenter. Det kan i vissa fall vara befogat att kalla slutanvändarna för kund och ibland kan det vara en person i egenskap av en viss befattning som är relevant att kalla kund. En slutsats var att det hade varit bra att involvera fler personer i projektet. Att vi inte hade kunden på plats ledde till att snabb feedback ibland uteblev från kunden vilket i ett antal fall ledde till att en user story följde med ett antal iterationer. Detta gav onödigt mycket administration och det hade varit bra att komma på ett annat sätt att hantera detta. Vid utvecklandet av ny user story är det viktigt att få kunden att förstå hur det kommer att fungera i praktiken. Vid ett flertal tillfällen under projektet hade vi haft olika bild av hur en user story skulle fungera. Små lanseringar I projektet lanserades nya funktioner veckovis. För webbaserade system, som har en server- klientstruktur är det enkelt att jobba med små lanseringar eftersom allt finns samlat centralt och det är enkelt att lägga till funktionalitet. 40-timmarsvecka I Sverige är detta inte ett väldigt stort problem även om utbrändhet är ett aktuellt ämne. Vi upplevde inte denna aktivitet som någon av XPs viktigare även om det såklart är viktigt att komma utvilad till jobbet. Kodstandarder Webbaserade system har generellt lite kod och den är uppdelad på olika sidor som har olika funktion. Vi använde oss av mallsidor för att strukturen skulle bli enhetlig och det fungerade bra. Systemmetafor En viktig egenskap för att kunna arbeta med XP är att hela tiden fundera på hur en lösning passar in i det stora mönstret. För att hålla designen ren genom hela projektet är det viktigt att fundera på hur varje ny lösning fungerar i den struktur som valts. Vi hade ingen uttalad systemmetafor från något annat område men beskrev olika delar utifrån respektive målgrupp. Det är oklart om vi hade haft nytta av en mer uttalad systemmetafor. 19

25 User stories När ett estimat på en user story ges är det lätt att falla i fällan att underskatta risk. Den mest optimistiska bedömningen av hur lång tid något tar att utveckla ges som uppskattning. För att kunna ge en korrekt bedömning krävs att den som utvecklar även förstår hur en ändring i funktionalitet påverkar systemet i stort. Generellt vid estimering är det enkelt att fastna i bästa scenariot -fällan, det vill säga att man funderar hur lång tid det tar om inget går fel och inte ta höjd för justeringar och problem man inte tänkt på. För att kunna ge bra estimat på en user story krävs att man kan relatera till liknande problem som lösts och dra slutsatser om omfattning utifrån detta. Inte bara från samma projekt. Det är viktigt att förstå hur en ny user story passar in i helheten. Ett problem med att verkligheten är mer komplex än teorin är att hålla user stories oberoende av varandra. Det är möjligt till en viss gräns men nästan aldrig praktiskt möjligt i ett lite större projekt. Detta upplevde vi i ett flertal tillfällen då valet av en viss user story påverkade många andra. Vid ett flertal tillfällen ändrades komplexiteten av en user story beroende på att nya infördes som påverkade den tidigare. Detta var relativt svårt att förklara gentemot kunden som enbart såg det som ytterligare funktionalitet som infördes. Det svåra med att jobba med user stories förutom att minska beroenden sinsemellan var att hitta en bra nivå på detaljrikedomen. Det var nyttigt att försöka beskriva funktioner så noga som möjligt ur ett behovs- och verksamhetsperspektiv. Det var sedan var upp till systemutvecklarna att realisera detta i systemet. User stories fungerade väldigt bra som ett stöd i att planera och driva projektet. Systemet bryts automatiskt ner i hanterbara delar. Ett problem vi hade i projektet var att vi och kunden ibland hade olika bild av vad som skulle utvecklas. Eftersom vi inte hade kunden på plats fick vi inte feedback på detta förrän en vecka senare. En intressant reflektion om user stories var att dessa kunde användas som ett sätt att dokumentera. XP hävdar att man ska slänga bort alla user story-kort så fort de är klara. Vi använde alla user stories som en sammanställning av alla beslut som fattats samt en systemdokumentation över hur systemet ska fungera. Rätt, bra och använt För att system ska bli använda och skapa affärsnytta krävs att alla tre dimensioner i figur 6 uppfylls. XP fokuserar mycket på nivå ett och två med enhetstester, acceptanstester samt att kunden finns på plats för att svara på frågor och sköta prioriteringar i projektet. Eftersom det i de allra flesta fall är människor som kommer att använda system som utvecklas så måste även dimension tre vara prioriterad genom hela projektet. 20

26 3 2 ANVÄNDAREN FÖRSTÅR HUR SYSTEMET SKA ANVÄNDAS (USABILITY OCH GRÄNSSNITTSTESTNING) SYSTEMET GÖR RÄTT SAKER (ACCEPTANSTESTER) 1 SYSTEMETS KOD FUNGERAR (ENHETSTESTER) Figur 6 Tre olika dimensioner av ett system XP föreslår att om det blir konflikt eller diskussion kring användbarheten i ett system så får man tillkalla en usabilityexpert som avgör huruvida systemet är tillräckligt väl designat. Detta skulle förmodligen aldrig fungera för intranät, extranät samt många andra webbaserade system där stort fokus ligger just på usability. Det är ett arbete man måste jobba med kontinuerligt och inte något som kan utvärderas mot slutet av ett projekt. Eftersom det inte finns någon naturlig plats för usability i XP blev detta en del av acceptanstestningen. Kunden fick avgöra om en funktion var intuitiv och lättanvänd. Det bästa hade varit att kontinuerligt kunna testa av användbarheten mot slutanvändarna men det var inte möjligt inom projektets budgetramar. Parprogrammeringen visade sig vara väldigt användbar för att diskutera fram bra och enkla funktioner. Trots att det gick bra att arbeta med user stories i den ordning som kunden ville och att form, säkerhet och navigering lades till först i slutet av projektet så har vi i andra projekt märkt att kunderna kan ha svårt att förstå hur en funktion verkligen kommer att se ut och fungera innan formen läggs på. Detta leder till onödigt många diskussioner kring användbarhet. En annan negativ aspekt av att inte arbeta med formen direkt var att det tog lång tid att lägga till alla sidor eftersom det inte gick att skapa en mall som bara applicerades på alla sidor samtidigt. En slutsats är därför att det kan vara bra att föreslå för kunden att lägga på form direkt. IT-oerfarna kunder kräver ibland vägledning i beslut om vad som bör prioriteras för att skapa mest nytta av IT. Kombinationen av att förstå både IT och verksamheten är oerhört viktig. XP menar att kombinationen av IT och verksamhet kan komma fram i kommunikationen mellan kund och utvecklare. Eftersom det i praktiken i konsultuppdrag är praktiskt taget omöjligt att ha kunden på plats hela tiden begränsas kommunikationen mellan kund och utvecklare. Det är därför en fördel om utvecklaren förstår kundens verksamhet och kan koppla samman detta med kunskaper om IT och systemutveckling. För att införskaffa sig denna förståelse är det viktigt att man trots begränsningen att man inte kan ha kunden på plats försöker att maximera kommunikationen med kunden. Utifrån diskussioner som förts har vi konstaterat att det är enklare att nå ett bra resultat när man verkligen förstår kundens verksamhet. Detta märks extra tydligt i de längre kundrelationer där nyutveckling av funktionalitet i nästan alla fall motsvarar kundens förväntningar utan kompletteringar. Det går dessutom ofta snabbare att utveckla än i liknande system för andra kunder. 21

27 Slutsatser Vad är viktigt att tänka på för ett företag som funderar på att börja jobba med XP? XP var lätt att komma igång med och även om enskilda aktiviteter var svåra att jobba med så var helheten och modellen enkel att förstå. En styrka med XP var att det var enkelt att anpassa XP till de behov och förutsättningar som fanns på Mira, det var enkelt att förstå hur och varför olika aktiviteter används. Verkligheten är sällan lika enkel som teorin utan det finns komplexitet man måste kunna hantera. Det är till exempel orimligt att anta att man i varje projekt kommer att kunna ha en kund på plats under hela utvecklingsprocessen. För att minska riskerna vid projektet bör man inte se definitionen av kund som en person utan involvera flera personer från kunden. Det är viktigt att man försöker att hitta personer att involvera från alla tilltänkta målgrupper för att få en så heltäckande bild som möjligt. En viktigt slutsats är att man måste förstå att verkligheten är mer komplex än teorin, och att man måste kunna hantera detta på bästa sätt. Parprogrammering är i vissa situationer ett utmärkt hjälpmedel för att lösa svåra tekniska problem och designa bra system. Däremot finns det situationer då parprogrammering inte är att föredra, till exempel vid repetitiva eller väldigt enkla arbetsuppgifter. Man måste också ta hänsyn till vilken erfarenhet de har som parprogrammerar. Det gav en ganska liten effekt tidsmässigt och designmässigt av parprogrammeringen när paren var ojämna. Däremot gav parprogrammeringen positiva effekter i ett knowledge management -perspektiv, det vill säga vad gäller spridning av kunskap och best practices. Trots att XP inte direkt tar upp usability så är det en viktig dimension att ta hänsyn till vid utvecklandet av de flesta typer av webbaserade verksamhetskritiska system. Att försöka rätta till detta på slutet kan bli väldigt tidskrävande och därför är det bra att jobba med detta kontinuerligt. Det är viktigt att inte lämna över ansvaret att designa bra användbara gränssnitt till kunden men däremot är kunden den som ska avgöra om ett gränssnitt är tillräckligt enkelt att använda. Hur är XP anpassat systemutveckling på konsultföretag? Som beskrevs i teoridelen är det viktigt att kunna erbjuda bra service och att ha en utvecklingsmetodik som hanterar de speciella kraven för konsultföretag. Den täta kundkontakten och att kunden var involverad i arbetet möjliggjorde att vi utan extra arbete kunde erbjuda god service gentemot kunderna och vara lyhörda för nya behov. Det var också en fördel att vi kunde göra stora förändringar genom hela projektet eftersom detta gjorde att kunden kände sig engagerad och kunde påverka. Detta påverkade antagligen den upplevda servicegraden. Just XPs fokus på effektivitet samt förmåga att hantera risk och förändring var väldigt viktigt. För de konsultföretag som arbetar med långa kundrelationer där systemen utvecklas över lång tid är det nödvändigt att hela tiden jobba med att förenkla och hålla systemdesignen enkel. Det är lätt att systemdesignen med tiden bryts ner och systemen blir dyra att underhålla. XPs aktiviteter för att reducera komplexiteten passar väl för detta. 22