extreme Programming refactored - recension och analys av Kent Becks senaste definition av XP Måns Gunnarsson d01mg@efd.lth.se Sammanfattning Denna djupstudie består av en recension av andra upplagan av Kent Becks bok Extreme Programming Explained: Embrace change, en sammanfattning av vad som har ändrats sen XPs födelse samt en kort analys av vad förändringarna kan innebära för kursen Programvaruutveckling i grupp.
1 Inledning Kent Beck betraktas som skaparen av Extreme Programming, en ung programvaruutvecklingsmetodik som i många fall vänder upp och ned på sedan länge accepterade koncept inom andra metodiker. Han har nyligen skrivit en ny upplaga av sin bok Extreme Programming Explained: Embrace Change. Första upplagan betraktas allmänt som den hittills rådande definitionen av XP. Denna djupstudie kommer att sammanfatta nyheterna i boken samt analysera hur de nya idéerna kan passa in i ett studentprojekt. 2 Bakgrund 1996 anlitade Chrysler Kent Beck för att förbättra prestandan hos ett löneutbetalningssystem som företaget utvecklade. Det visade sig snabbt att projektet hade kört fast och Kent Beck fick uppdraget att med ett mindre utvecklingsteam och nya idéer börja om från början. De nya idéerna bestod enkelt uttryckt i att driva allt som är av värde vid programvaruutveckling till det yttersta. Ett år senare var projektet färdigt, och XP-metodiken hade växt fram. Från att ha haft begränsad kontakt med ledning och kund hade man nu en kundrepresentant på plats och mycket kommunikation med ledningen. Man planerade utveckligen i korta steg och använde metaforer. Utvecklarna valde själva vilka uppgifter de ville utföra istället för att få dessa tilldelade. Man använde enhetstester enligt test-firstprincipen istället för att sporadiskt testa kod som inte ville fungera. All utveckling gjordes i par. Detta och mer därtill skilde sig radikalt från hur man tidigare hade arbetat. Teamet presenterade metodiken som växt fram i en artikel i tidskriften Distributed Computing (oktober 1998). Ett år senare publicerade IEEE Computer Kent Becks artikel Embracing Change with Extreme Programming, där denne sammanfattade idéerna i sin ännu ej utgivna bok Extreme Programming Explained: Embrace Change. I artikeln presenteras XP som ett alternativ till vattenfallsmetoden i form av ett antal deltekniker 1 och för XP grundläggande koncept som stories och tasks. I boken presenteras metodiken utförligare i de tre delarna The Problem, The Solution, och Implementing XP på knappt 150 sidor. I oktober 2004 publicerades andra upplagan av XP Explained. Den innehåller fem års erfarenheter av en metodik som har både lovordats och kritiserats från många olika håll. 3 Extreme Programming Explained: Embrace Change, andra upplagan Boken består av två huvuddelar. Den första delen, Exploring XP, är en genomgång av vad XP är, hur man använder det och varför man ska använda det. I kapitel ett och två förklaras vad XP är. Kapitel tre till nio beskriver vad Kent Beck kallar Values, Principles och Practices. Values är de övergripande värden som XP bygger på. Värdena är abstrakta och leder till 1 eng. practices 2
konkreta deltekniker via principer, som i sig själva inte innebär något konkret men som utgör en bro mellan värden och deltekniker. Grundläggande deltekniker beskrivs i ett kapitel som följs av en förklaring av hur man kan börja använda sig av dessa. I kapitel nio beskriver Beck ett antal mindre centrala (men ändå viktiga) deltekniker som man inte bör ge sig på förrän de grundläggande fungerar smärtfritt. Övriga kapitel i denna del av boken behandlar teamroller, constraintteori, planering, testning, design, en analys av hur XP skulle fungera i större projekt samt en kort intervju med en chef på ett företag där XP införts. Bokens andra del, Philosophy of XP, handlar mer om bakomliggande tankar och ideal och om vad XP egentligen är. Andra upplagan av XP Explained är en välskriven, välplanerad, lättläst och bitvis ganska underhållande bok där allting som beskrivs och förklaras har en direkt och tydlig koppling till XP. I resan från värden till deltekniker gör Kent Beck det svårt för läsaren att inte hålla med om XPs förträfflighet. På liknande sätt använder han sig flitigt av metaforer och anekdoter för att få läsaren på sin sida. Detta är bokens styrka och svaghet. Det är väldigt lätt att acceptera allt Beck skriver, men samtidigt blir nog skeptikern inte mindre skeptisk av bristerna på konkreta bevis. Beck gör dock klart för läsaren att XP varken är lätt att använda eller att det skulle vara en fungerande paketlösning för alla situationer. På flera ställen rekommenderar han istället att man kan testa de delar av XP man tror kan lösa ett visst problem man har än att försöka svälja allt på en gång. Detta ger väldigt mycket mer trovärdighet åt en metodik som många verkar uppfatta som allt eller inget. Förutom de konkreta refaktoriseringar av XP-metodiken som gjorts är en tydlig skillnad mellan första och andra upplagan av boken att Beck nu använder betydligt mer utrymme för att förklara varför XP är en bra metodik. Kent Beck har också märkbart tonat ner sin ganska personliga och ibland överdrivet lättsamma författarstil. 4 XP1 vs. XP2 Här följer en sammanfattning av de förändringar, ytliga såväl som lite djupare, som presenteras i andra upplagan av XP Explained. I resten av rapporten kommer jag att använda beteckningen XP1 för gamla XP, och XP2 för XP som det presenteras i andra upplagan av XP Explained. 4.1 Definitionen av XP I första upplagan av XP Explained gör Kent Beck följande definition: XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements. Fem år senare väljer han istället att beskriva XP på följande sätt: XP is lightweight XP is a methodology based on addressing constraints in software development XP can work with teams of any size 3
XP adapts to vague or rapidly changing requirements Den nya beskrivningen förtydligar att XP inte är någon kompakt snabbmetod men att det väger lätt i den mening att man inte gör något arbete som inte är av värde för kunden. Kent Beck förtydligar också att XP handlar om att arbeta med problem inom programvaruutveckling, och inte allt annat som förekommer i ett projekt som ledning, marknadsföring och försäljning. XP kan användas oberoende av teamstorlek. Det har visat sig att team av väldigt varierande storlekar har lyckats med XP. De värden och priciper som XP bygger på passar team av alla storlekar, men många av delteknikerna måste anpassas. XP anpassar sig till förändringar, men kan även användas i projekt där alla krav är kända från början. 4.2 Värden XP1 baseras liksom XP2 på fem övergripande värden. Dessa är: Kommunikation Enkelhet Feedback Mod Respekt 2 Dessa värden används för att motivera de deltekniker som beskriver själva utförandet av XP. Eftersom dessa utgör grunden till XP är det inte överraskande att de inte har förändrats. 4.3 Principer Värden är för abstrakta för att direkt säga något om hur man gör konkret för att uppnå dem. För att bättre motivera de deltekniker som ingår i XP har Kent Beck beskrivit ett antal principer som som styr XP-processen. Dessa är tänkta att utgöra en bro mellan mycket abstrakta värden och mycket konkreta deltekniker. Centrala principer i XP1: Rapid feedback Assume simplicity Incremental change Embracing change Quality work Mindre centrala principer i XP1 är: Teach learning, Small initial investment, Play to win, Concrete experiments, Open honest communication, Work with peoples instincts - not against them, Accepted responsibility, Local adaptation, Travel light, och Honest measurement. Principerna i XP2 ser annorlunda ut. Här följer en kort sammanfattning: 2 Respekt är egentligen inte ett av de primära värdena i XP1, men det beskrivs som ett djupare liggande värde. I XP2 listas det bland övriga värden. 4
Humanity - För att människor ska fungera bra på arbetsplatsen måste man kunna tillgodose deras behov. Economics - Allt man gör ska vara av ekonomiskt värde för projektet. Mutual benefit - En XP-aktivitet ska vara av värde för alla som berörs av den. Self-similarity - En lösning på ett visst problem kan ofta användas för att lösa ett annorlunda problem. Improvement - Försök att alltid förbättra alla aktiviteter. Diversity - Ett XP-team bör bestå av olika typer av personer med olika färdigheter. Reflection - Analysera och reflektera över sådant som lyckas såväl som sådant som misslyckas. Flow - I stället för att leverera värde i få men stora klumpar ska detta ske med ett konstant flöde. Opportunity - XP handlar om att se möjligheter i stället för problem. Redundancy - Svåra problem kräver ofta flera olika lösningar, exempelvis räcker det sällan med att använda sig av en XP-delteknik för att bli av med ett problem. Failure - Utan misslyckanden lär man sig inget. Quailty - Kvalitét på arbetet bör inte ses som en variabel man kan ändra på för att till exempel öka produktionshastigheten. Baby steps - Gör ändringar i så små steg som möjligt. Accepted responsibility - Ansvar går inte att tvinga på någon, det måste accepteras. Dessa principers syfte är att man ska förstå delteknikerna lättare. De ska också kunna användas för att skapa nya deltekniker när de föreslagna inte räcker till eller passar in i en viss situation. I XP1 är syftet och innehållet i principerna inte helt uppenbart. Flera av principerna är så pass konkreta att de lika gärna hade kunnat vara deltekniker. Principerna i XP2 utgör en bättre och tydligare grund från vilken man kan skapa nya och förstå existerande deltekniker. 4.4 Deltekniker XP1 består av följande 3 deltekniker: Planning game, Small releases, Metaphor, Simple design, Tests, Refactoring, Pair Programming, Continuous integration, Collective ownership, On-site customer, 40-hour week, Open workspace, Just rules, Coding standards I XP2 skiljer Kent Beck på primära och naturligt följande 4 deltekniker. Deltekniker har försvunnit från XP1, vissa har bytt namn, och flera har lagts till. Kent Beck ger ingen direkt förklaring till varför deltekniker som Metaphor och Coding standards har försvunnit. En möjlig förklaring är att det har visat sig att dessa deltekniker växer fram ganska naturligt 3 Denna lista är den som återfinns i artikeln Embracing Change with Extreme Programming 4 eng. corollary 5
ur användandet andra deltekniker. En annan möjlighet är att det inte är helt självklart att användandet av t.ex. metaforer alltid är fördelaktigt. Här följer en sammanfattning av XP2s primära deltekniker och hur de skiljer sig från XP1s motsvarigheter. Sit together Vid första anblicken är detta en omskrivning av Open workspace. En stor skillnad är att det inte längre är ett krav att man ska sitta i samma rum hela tiden. För team som är geografiskt utspridda handlar det om att spendera mer tid ansikte mot ansikte om man har problem. Kent Beck menar dock fortfarande att ju mer man är tillsammans, desto bättre. Whole team Detta är en ny delteknik som innebär att all kunskap som kan tänkas behövas ska finnas inom teamet. Att låta alla inblandade vara en del av teamet ökar också gruppkänslan. När man upptäcker att en viss kompetens saknas låter man en lämplig person bli en deal av teamet. När denne har spelat ut sin roll låter man honom lämna teamet. Informative workspace Det övergripande temat för arbetsplatsen ska vara arbetet. En intresserad besökare ska omedelbart kunna få en uppfattning om hur projektet går genom att titta sig omkring. Ett sätt att genomföra detta är sätta upp storykorten på väggen, exempelvis sorterade efter vilka som är klara, vilka som implementeras just nu och vilka som kommer att påbörjas snart. Arbetsplatsen ska också kunna tillgodose vissa mänskliga behov. Godis och drycker ökar trivseln och öppnar för socialt umgänge. Genom att undvika oordning gör man det lättare för folk att koncentrera sig på att lösa sina uppgifter. Människors behov att få vara för sig själva kan tillgodoses genom att man har små privata rum i närheten, eller genom att man begränsar arbetstiden. Denna delteknik handlar alltså inte bara om att arbetsplatsen ska vara informativ, utan också om hur arbetsplatsen bör vara utformad för att människor ska kunna trivas där. Energized work Arbeta bara när du kan vara produktiv. Jobba inte över för mycket. Gå inte till jobbet sjuk. Poängen med denna delteknik är att det inte är tiden man spenderar på arbetet som räknas, det är hur produktiv man är. Pair programming Parprogrammering är fortfarande centralt och beskrivs på samma sätt som i XP1. 6
Stories Användandet av stories som kunden skriver och prioriterar är centralt. Tillsammans med Weekly cycle ersätter denna delteknik Planning game. Weekly cycle Planera projektet en vecka i taget och börja varje vecka med ett möte. På detta möte går man igenom hur långt man hann förra veckan och hur bra estimeringarna man gjorde stämde med hur lång tid implementationerna tog. Kunden får välja vilka nya stories som ska implementeras denna vecka, och man delar upp dessa stories i tasks som utvecklarna sedan får estimera. Det föreslås att man därefter skriver automatiserade tester som inte går igenom förrän hela stories är implementerade. Anledningen till att cykler på en vecka är bättre än cykler på två eller tre veckor är att fredagen är ett naturligt mål. Quarterly cycle Planera projektet ett kvartal i taget. Reflektera över teamet, projektet, hur projektet går och hur projektet passar ihop med eventuella övergripande mål. Under denna planeringsfas föreslås att man försöker identifiera större problem, påbörjar lösningar på dessa, väljer vilket eller vilka teman nästa kvartal ska ha, väljer stories till dessa teman, fokuserar på helheten. Slack Ta i planeringen med stories som inte behöver bli färdiga. Det motverkar känslan av att allt måste bli färdigt. Man vet att det inte förväntas att allt som ingår i planeringen hinner genomföras. Ten-minute build På tio minuter ska hela systemet kunna byggas och testas. Om det tar längre tid än så kommer man gå miste om feedback eftersom systemet helt enkelt inte kommer att byggas och testas lika ofta. I denna delteknik ingår också att systemet ska kunna byggas automatiskt. Continuous integration Denna delteknik är oförändrad. Test-first programming Denna delteknik är oförändrad. 7
Incremental design Se till att systemets design passar perfekt för systemet som det ser ut idag. Denna delteknik ersätter Refactoring och Simple design och säger inte längre att designen måste vara enkel. Övriga deltekniker Ovanstående är XP2s primära deltekniker. När de fungerar någorlunda smärtfritt kan man börja implementera följande deltekniker som naturligt följer de primära. Real Customer Involvment Denna delteknik ersätter On-site customer. Man kan tycka att Whole team borde täcka in även kunden, men enligt Kent Beck är det få XP-team som verkligen har en riktig kundrepresentant på plats i teamet. Han förespråkar fortfarande fördelarna med att ha en riktig kund på plats, då en låtsaskund kan leda till att onödig funktionalitet implementeras och att de acceptanstester som låtsaskunden skriver riskerar att missa sådant som en verklig kund hade testat. Team Continuity Denna delteknik säger att själva teamet bör betraktas som en enhet bestående av dels dess medlemmar och dels medlemmarnas relationer till varandra, till skillnad från att se varje utvecklare som en enhet som kan flyttas runt och fortfarande vara lika effektiv överallt. Shrinking Teams Gör teamet mindre ju effektivare det blir. Se till så att teamet minskar i storlek men har samma produktivitet. Detta medför att fler team kan skapas. Root-Cause Analysis Rätta till de fel som hittas efter att systemet byggts och levererats, men försök även sträva efter att teamet inte ska göra samma typ av fel en gång till. Följ denna lista då ett fel påträffas: 1. Skriv ett systemtest som visar felet. 2. Skriv ett enhetstest som kapslar in felet så mycket som möjligt. 3. Få enhetstestet att gå igenom. Om systemtestet inte går igenom, gå till punkt 2. 4. Ta reda på varför felet uppstod och varför det inte upptäckts tidigare och vidtag åtgärder för att denna typ av fel inte ska uppstå igen. Shared code Detta är Collective code ownership med ett nytt namn. 8
Code and tests Källkod och tester är det enda som bör sparas permanent. Generera alla andra dokument som behövs från källkoden och testerna. Single code base Att utveckla i flera branches är slöseri. Temporära branches får användas, men de får aldrig leva mer än ett par timmar. Om man måste ha flera versioner av koden bör man sträva efter förbättra processen till dess att man klarar sig med en branch. Daily deployment Ny kod och mjukvara måste integreras med produktionskoden så snart som möjligt. En utvecklare som arbetar med kod som inte är integrerad riskerar att tvingas att ta beslut utan att veta tillräckligt om vilka konsekvenser besluten kommer att få. Negotiated scope contract Skriv kontrakt om hur lång tid projektet får ta, vad det kostar och vilken kvalitet det ska hålla men se till så att exakt vad som ska ingå i systemet kan förhandlas om när som helst. Pay-per-use Låt kunden betala för varje användning av systemet istället för t.ex. varje release som görs. Ofta låter man kunden betala för varje release som görs, men detta medför att den säljande sidan gärna vill göra så många releaser som möjligt med så lite ny funktionalitet som möjligt och att kunden vill ha få releaser med mycket ny funktionalitet i varje. Denna intressekonflikt leder till försämrad kommunikation och mindre feedback. 5 Förändringar för studentprojekten I framtida versioner av projektkursen bör mindre vikt läggas vid att presentera XP som ett antal deltekniker och sedan slaviskt följa dessa vare sig de fungerar bra eller ej. Det är troligen lättare att få studenter att acceptera metodiken om man resonerar sig fram till ett antal deltekniker via principer och värden. En annan förbättring av projektkursen vore att ge teamen större kontroll över vilka deltekniker de kommer att använda sig av, och att ge teamen mer utrymme att hitta på egna deltekniker. Andra upplagan av XP Explained är en självklar del av kurslitteraturen. 9
6 Slutsatser och framåtblickar Det har visat sig att XP kan användas oberoende av storlek på teamet. Det kan också användas av team som är geografiskt spridda. För någon vars definition av XP är de deltekniker som Kent Beck presenterade för nästan tio år sen är detta kanske svårt att smälta. Det blir mycket lättare att förstå varför XP fungerar i fler situationer om man ser XPs deltekniker som en möjlig implementation av XPs principer och värden. Detta är också en tänkbar förklaring till varför vissa deltekniker har försvunnit helt, utan förklaring från Kent Beck. Kent Beck har tidigare beskrivit vad XP är och hur det går till att använda sig av det, men det är först nu som han ordentligt tydliggör varför man gör som man gör. Det verkar inte helt otroligt att XPs värden och principer snart kommer att användas för att skapa metodiker för helt andra områden än programvaruutveckling. 7 Referenser 1. Kent Beck: Extreme Programming Explained: Embrace Change (1st edition). ISBN 0-201-61641-6, Addison-Wesley, 1999 2. Kent Beck: Extreme Programming Explained: Embrace Change (2nd edition). ISBN 0-321-27865-8, Addison-Wesley, 2004 3. Kent Beck: Embracing Change with Extreme Programming, IEEE Computer 32(10): 70-77(1999) 4. Kent Beck, Ron Jefferies, Martin Fowler m. fl.: Chrysler goes to Extremes. http://www.xprogramming.com/publications/dc9810cs.pdf 10