Extreme Programming En bra metod?

Extreme Programming En bra metod? Marcus Olsson D01, Lunds Tekniska Högskola d01mol@efd.lth.se 2004-02-24

Abstract Den kritik som Extreme Programming möter i böcker och artiklar kommer främst från personer som förespråkar äldre metoder. Många motargument känns lite krystade och man anar ibland att personen bakom dem egentligen vet hur bakvänt det låter. En del motargument är å andra sidan väl formulerade och verkar logiska. Det gäller att forma metoderna lite så att de passar in på det projekt man håller på med och det team som ska utveckla det. Det är ändå inte alla metoder inom XP som möter så stark kritik, just eftersom det inte verkar finnas något direkt negativt att säga om dem. För det mesta handlar det inte om att det är metoden som inte passar in utan utvecklarna som inte passar in i metoden. Inledning och bakgrund Extreme Programming, XP, är en i raden av ganska nya programvaruutvecklingsmetoder som kallas för agila metoder. Med agil menas ungefär lättrörlig. XP har, som alla nya idéer, både motståndare och anhängare. Motståndarna är ofta konservativa och anser att de traditionella metoderna fungerar bäst. Ofta vill de inte ens prova metoden eftersom de vet att det inte kommer att fungera ändå. Anhängarna däremot lyfter fram de positiva delarna och ser möjligheterna med metoden. Syftet med denna fördjupningsstudie är att undersöka för- och nackdelarna med XP-metoden. Jag kommer att försöka ta fram nackdelar till metoderna som XP bygger på och se om det finns någon logik bakom dem. Dessa undersökningar grundar jag på både mina egna och andras erfarenheter. Mina egna erfarenheter får jag i och med att jag själv varit med i ett projekt och är i skrivande stund coach för ett team, där XP tillämpas som metod. Andras erfarenheter får jag dels från mina team-medlemmar och dels från böcker och artiklar mm på Internet. Argument från båda parter kommer att vägas mot varandra och försöka forma en slutsats om XP som metod. Jag kommer även att försöka undersöka hur bra XP lämpar sig för ett projekt som det som ingår i kursen programvaruutveckling i grupp på LTH. Kanske är det vissa delar som borde förändras medan andra kanske är som skräddarsydda för ett projekt som detta. Resultatet från denna undersökning bygger främst på svar från de enkäter jag delar ut till en del deltagare i kursen. Där får de svara på vad de tycker om de olika metoderna i XP och vad som skulle kunna förbättras mm. 2

Kritik av Extreme Programming Extreme Programming består av 12 små metoder som kallas lite olika vid olika tillfällen. De kan kännas igen som: The Planning Game Small Releases System Metaphor Simple Design Continuous Testing Refactoring Pair Programming Collective Code Ownership Continuous Integration 40-Hour Work Week On-site Customer Coding Standards The Bullpen En del av dessa metoder, som utgör grundstenarna i XP-metodiken, skiljer sig ganska radikalt mot de traditionella metoderna för att ta fram programvara. Det är också dessa som tas upp när man diskuterar hur effektivt XP egentligen är. Ofta försöker man förklara hur dåligt det fungerar att tänka på XP-vis genom historier och skämtteckningar. Barry Boehm på University of Southern California berättar just en sån historia 1 i en debatt om agila metoder. Denna historia, som är bifogad, är ett utmärkt exempel på hur man kan likna XP:s metoder med en annan situation. Ofta tas dessa liknelser med en nypa salt eftersom det alltid går att berätta en liknande historia som istället bevisar hur bra det är. Small releases Istället för massor med dokumentation till kunden ska man, med jämna mellanrum, kunna släppa små releaser till kunden som då lättare kan ge sina kommentarer till programmet. Många i vårt projekt tyckte att det var lite jobbigt med de små releaserna eftersom det kändes väldigt stressigt. Man hade krav på sig att man ska lämna ut ett fungerande program vid en viss tidpunkt och som hade vissa förbestämda funktioner. Samtidigt kan man tänka sig att det är bättre att lämna små ändringar ofta än att behöva lämna en stor när hela projektet är klart. Simple design När en del läser om XP för första gången kommenterar de ofta att det verkar som att det är viss brist på mjukvaruarkitektur. Man frågar sig om det är bra eller dåligt. En erfaren programmerare som jobbat i projekt med andra metoder försöker ofta tänka framåt när han löser ett problem. Han utvecklar en arkitektur så att de uppgifter han kommer att få senare blir lättare att lösa. I XP är det meningen att man ska försöka fokusera på just den uppgiften man fått och inte tänka på vad som kommer senare, Do the simpliest thing that can possible work. Meningen är att man ska relativt snabbt bli klar med sin uppgift och kunna gå vidare 3

till nästa. Ett tecken på lathet och dumhet i mångas öron, de menar att man inte bara kan fokusera på en uppgift i taget för då kommer hela projektet att falla. Barry Boehm säger Att endast arbeta på ett problem i taget är aldrig en bra idé. Detta efter sin historia om apan och elefanten 1. Continiuous testing En av de stora skillnaderna mellan XP och traditionella metoder är att det inte finns några roller inom teamet. Alla är ansvariga för allt, detta även för testningen. Man ska testa allt man gör och detta innan man gör det, vilket kallas test first. Programvaran är inte godkänd för release eller ens för att sättas samman med den övriga programvaran förrän alla testfall gått genom. För att releasen ska bli godkänd måste även alla acceptanstester, som skapas av kunden, gå igenom. Med andra ord är det enda man strävar efter är att bli godkänd på ett test som man själv har skrivit. I boken The Case against Extreme Programming tar Matt Stephens upp detta. Han menar på att syftet med en klass inte är att uppfylla ett krav utan bara att klara ett test. Detta uttalande har han senare fått kritik för, eftersom testerna är representationer av de krav man har på programmet. Det verkar mer som om Stephens letar efter nackdelar, men har svårt att få fram några riktigt bra argument. Refactoring Refactoring är en stor del av XP-metodiken. När man har ändrat på koden ska man refaktorisera den och se till så det inte finns några dubbletter eller onödig kod. Uppenbarligen ser många detta som om man nästan inte gör något annat än att ändra på den befintliga koden. Detta ses som tidsödande och överdrivet petigt. Kommentarer från människor som praktiserat XP under flera år säger annorlunda. De menar på att den tid man lägger ner på att refaktorisera koden tjänar man sedan igen. Pair programming Parprogrammeringen är nog den del som möter mest kritik. Det är för många svårt att tänka sig att man skulle kunna tjäna på att sätta två personer tillsammans framför en dator mot om de hade varsin och jobbade var för sig. Tanken är ju att en av dem ska vara driver, han som sitter vid tangentbordet, medan den andra analyserar, felkorrigerar och kritiserar. Det blir också lättare att diskutera problem som dyker upp och få olika synsätt på det hela. Tester visar på att par är 40% mer effektiva än enskilda programmerare och koden som produceras innehåller 15% färre fel. Matt Stephens säger om parprogrammering att Det är som att stoppa huvudet i en hink med skit, jag behöver inte testa för att veta att jag inte gillar det. Stephens förlöjligar metoden i sin bok och jämför det med ett giftermål, till death do us part. Det låter som om Stephens inte riktigt läst på ordentligt om XP, eftersom det är meningen att man ska byta par flera gånger under dagen och inte alltid jobba med samma person. Han har även i sin bok små förlöjligande sånger om att man inte kan programmera ensam utan måsta ha någon med sig 2. Vad gör man om en utvecklare i teamet ringer och sjukanmäler sig på morgonen? Detta är ett av de stora problemen med parprogrammering och ett av Stephens starkaste motargument. 4

Ett annat problem som kan dyka upp i de flesta projekt är att inte personkemin stämmer mellan utvecklarna. Detta gör det mycket svårt att få ut något bra av att parprogrammera. En del personer passar helt enkelt inte ihop och en del passar inte för parprogrammering alls. I ett forum på Internet berättade en programmerare att han testat parprogrammering ett tag och kommit fram till att han var 15 % mer effektiv när han jobbade ensam. Han menade också på att hans kod höll högre kvalitet än den kod hans medarbetare producerade. Denna person ingår antagligen i den grupp Stephens kallar most programmers eftersom han anser att de flesta programmerare har ett egoistiskt tänkande och helt enkelt inte passar in i parprogrammering. 40 hour work week Detta låter direkt dumt i mångas öron. En kommentar som ofta dykt upp lite varstans är: Om folk i ett projekt packar ihop och går hem klockan 17:00 när det är release om en dag och den inte är färdig, skulle jag inte vilja vara deltagande i det projektet. Argumentet i detta fallet verkar vettigt, men är det verkligen så i praktiken? I och med att man släpper små releaser ofta så tar man med så långt man hunnit än så länge. Mina egna erfarenheter från projektet säger mig att det ibland kan vara svårt att hålla denna regel. Om det är dags för release och allt som ska komma med i releasen ännu inte är färdigt, vill man gärna sitta över tills det är klart. Det är ju inte så gärna som man släpper iväg ett ickefungerande program. Detta tror jag är ett problem som löser sig med mer erfarenhet bara. Man lär sig efterhand hur lång tid det tar att packa ihop releasen och hur mycket man kommer att hinna med. On-site Customer Detta kan ibland vara svårt att genomföra på det sätt som XP förespråkar. Kunden kanske inte har den tid eller möjlighet att sitta med teamet eller alltid kan vara tillänglig för frågor. Det blir i så fall upp till teamet att försöka forma ett annat tillvägagångssätt. Ute på arbetsplatserna är de sällan ett projektteam har den förmånen att de verkligen kan ha kunden på plats i projektet. Istället har man ofta en projekt- eller produktmanager som agerar kund. 5

Resultat från enkätstudien Övervägande verkar de flesta tycka att XP fungerar bra. Många tror dock att de flesta metoderna fungerar sämre i kursen än vad de hade gjort om det var ett projekt i verkliga livet. Antagligen beror detta på att i kursen är det nytt och ingen som riktigt hinner komma in i det förrän projektet är över. En annan orsak kan vara att skillnaden mellan programmeringskunskaper antagligen är större här än om det hade varit på en arbetsplats. Parprogrammering verkar vara den metod som är mesta uppskattad bland kursdeltagarna. Jag fick många kommentarer om att det var bra samarbete och man lär sig mycket av de andra deltagarna. Några enstaka tyckte dock att parprogrammeringen var ett hinder och att det hade gått snabbare om de fick programmera ensamma. Någon ansåg att det hade fungerat bättre om projektet varit större och uppgifterna svårare. En sak som förvånade lite var att många var väldigt positiva till test-first. Att kunna förlita sig på de test man har skrivit tidigare känns som en trygghet. Det verkar inte som om någon kände något direkt besvär av att behöva skriva testen före själva programkoden. Det som uppfattats som mindre bra i projektet är de små releaserna. Många tycker att det blir för stressigt och för ofta. Naturligtvis beror stressen mycket på att de flesta är ganska oerfarna och pga. att det är en kurs med begränsad tid så försöker man ju klämma in flera releaser ganska nära in på varandra. De som deltog i enkätstudien var 40 st. D-teknologer som går andra året på LTH. När de fick enkäten utdelad hade de genomfört hälften av det projekt som ingår i kursen Programvaruutveckling i grupp, där XP tillämpas som metod. Kursen är obligatorisk för D2. Det allmänna intrycket av XP var hos de flesta gott. Det var bara någon enstaka som ansåg att metoden inte fungerade så bra. Figuren nedan visar vilket betyg, de utvecklare som fått fylla i enkäten, satte på XP som metod. XP som helhet Antal i procent 50 45 40 35 30 25 20 15 10 5 0 1 2 3 4 5 Betyg Projektdeltagarnas betyg på XP i skala 1-5 där 1 är dåligt och 5 är mycket bra. 6

Personlig Reflektion Jag tycker att XP har fungerat bra. Precis som allt annat har den sina små brister, men jag anser att den har betydligt fler fördelar. En del av metoderna inom XP är lite extrema, därav Extreme Programming, och ibland kan det vara svårt att verkligen praktisera dem enligt reglerna. Som jag tidigare sagt så kommer den mesta kritiken från människor som inte testat XP på riktigt utan bara läst om det och skapat sig en uppfattning om det. Eftersom jag själv inte fått tillfälle att få testa några andra metoder på riktigt i ett projekt är det lite svårt att säga att någon annan metod är bättre eller sämre. Det enda jag kan konstatera är att XP är en metod som håller i ett litet/medelstort projekt. Slutsats Det verkar som om det är ganska svårt att få fram riktigt bra kritik mot Extreme Programming. Det mesta jag har hittat har mest varit dåliga skämt och frampressade motargument. De bästa argumenten för varför XP inte lämpade sig som metod gällde främst parprogrammeringen. Det är inte alla som passar att jobba med alla, vilket kan göra det svårt att genomföra alltid. För de tillfällen då det verkligen fungerar verkar det som om man har mycket att tjäna på det. Den kritik mot XP som framgick av enkätundersökningen grundas främst på att en del deltagare har mindre programmeringsvana än andra. De som har mer erfarenhet känner att de hålls tillbaka och inte kan jobba så fort som de hade kunnat annars. Delar som parprogrammering och collective code ownership är de som fått mest kritik i de fallen. XP verkar, förutom mindre detaljer, vara en bra metod som passar för mindre projektgrupper med upp till 20 personer. Jag avslutar denna djupstudien om kritik mot XP med ett citat som är hämtat från ett forum på Internet. I have noticed that the debate about XP is invariably conducted between two types of people: * those who will never do XP because they know it can never work, and * those who know it does work because they have done it. 7

Referenser Böcker Pete McBreen: Questioning Extreme Programming Barry Boehm, Richard Turner: Balancing Agility and Discipline Ron Jeffries, Ann Anderson, Chet Hendrickson: Extreme Programming Installed Matt Stephens: the case against Extreme Programming Artiklar Donald J. Reifer: How good are agile methods? Kent Beck, Barry Boehm: Agility through Discipline Internet http://www.softwarereality.com/lifecycle/xp/ http://www.jera.com/techinfo/xpfaq.html http://c2.com/cgi-bin/wiki?pairprogrammingergonomics 8

Bilaga 1 Barry Boehm berättar en historia Once upon a time, in the land of Metaphor, there lived a monkey and an elephant. They both lived on one side of a wide, swiftly flowing river. On both sides of the river there were many fruit trees. The monkey was very agile. He could climb to the top of the fruit trees and eat as much fruit as he needed. The elephant was very tall. He could reach up with his trunk and eat as much fruit as he needed. But the trees grew taller. Soon the elephant could not reach nough fruit to eat. But he was strong and self-sufficient. He found that when he was hungry, he could just pull down a tree and have fruit to eat. The monkey watched the elephant pull down most of the fruit trees. He was not happy. He said to the elephant, Don t do that! I will climb up the trees and get fruit for you. The elephant said, I am hungry. I am strong. I can do things for myself. The monkey said, You dumb elephant. Soon there will be no trees or fruit for you either. The elephant said, I only work on one problem at a time. Things may change. Maybe more fruit trees will come. Or maybe the trees will get shorter. If they don t, I ll work out a solution then. The monkey had to agree. He only worked on one problem at a time too. Soon there were no more fruit trees left on their side of the river. The elephant said, I have a solution. I will go across the river and pull down trees over there. The monkey said, You dumb elephant. That didn t work on this side of the river, and it won t work on the other side of the river. You will starve us both. Let s duke it out. I am agile and will run rings around you. The elephant said, That is fine with me. I am big and strong and I will pulverize you. So they began to duke it out. The monkey ran rings around the elephant. But he was not able to stop the elephant from trying to pulverize him. The elephant thrashed around with his strong trunk and legs, trying to pulverize the monkey. But the monkey was too agile, and the elephant missed every time. It was a hot day. Soon the monkey and the elephant got tired. They sat down and tried to figure out what to do next. The monkey said, I am agile. I will just scamper across the river and bring back some fruit. He got a running start toward the river and went scamper, scamper, scamper splott! The river started to carry him away. That dumb monkey! said the elephant. He waded into the river, picked up the monkey, put him on his back, and waded back to shore. They sat and thought for a long time while the monkey dried out. Finally the monkey said, Maybe this is a solution. You can carry me across the river on your back. When we get across, I can climb the trees and get enough food for us both. The elephant thought for a moment and then answered, That sounds like it is worth a try. So they tried it, and it worked. And they lived happily ever after, until the end of their days. Some morals to the story: Monkeys can do things elephants can t do. Elephants can do things monkeys can t do. Working on one problem at a time may not be a good idea. Duking it out may not be a good idea. Finding a collaborative win-win solution may be a good idea. Barry Boehm 9

Bilaga 2 Från kapitel 6 Pair programming i The case against Extreme Programming av Matt Stephens I Can t Code Alone... Cause I Need My Pair (Sing to the tune of Ticket to Ride by The Beatles) I guess I d better go home It s time to go play, yeah That pair programmer I had Called in sick today, yeah I can t code alone Cause I ve tried Gotta have my pair by my side I can t really write any code Cause I need my pair Cause I need my pair When I m refactoring code He always sits right, always sits right by me When we re runnin our unit tests He always sits right, always sits right by me I can t code alone Cause I ve tried Gotta have my pair by my side I can t really write any code Cause I need my pair Cause I need my pair Your Pair Will Hold Your Hand (Sing to the tune of I Want to Hold Your Hand by The Beatles) When you re coding something That you don t understand You don t Have to worry Your pair will hold your hand Your pair will hold your hand Your pair will hold your hand And when you re coding you feel happy inside The joy of coding is just one you can t hide People say We need requirements They always make a fuss We think That requirements Should be in C Plus Plus Should be in C Plus Plus And when you re coding you feel happy inside The joy of coding is just one you can t hide When you re unit testing And you find a bug You don t have to feel bad Your pair will give you a hug 10

Bilaga 3 Enkät Hur bra tycker Du att de metoder som XP bygger på är? Hur bra lämpar de sig för projektet i denna kursen? För just detta projektet Som metod i annat projet The Planning Game dåligt mycket bra dåligt mycket bra Small Releases dåligt mycket bra dåligt mycket bra System Metaphor dåligt mycket bra dåligt mycket bra Simple Design dåligt mycket bra dåligt mycket bra Continuous Testing dåligt mycket bra dåligt mycket bra Refactoring dåligt mycket bra dåligt mycket bra Pair Programming dåligt mycket bra dåligt mycket bra Collective Code Ownership dåligt mycket bra dåligt mycket bra Continuous Integration dåligt mycket bra dåligt mycket bra 40-Hour Work Week dåligt mycket bra dåligt mycket bra On-site Customer dåligt mycket bra dåligt mycket bra Coding Standards dåligt mycket bra dåligt mycket bra The Bullpen dåligt mycket bra dåligt mycket bra XP som helhet dåligt mycket bra dåligt mycket bra Finns det någon metod Du skulle vilja ta bort? I så fall vilka och varför? Har Du kommit på någon metod som Du skulle vilja lägga till? I så fall vilken och varför? Vilka nackdelar har Du stött på med XP-metoden under projektet? Vilka stora fördelar med XP-metoden har Du stött på under projektet? Skulle Du kunna tänka dig att använda dig av XP-metoden i ett annat projekt? Om inte varför? Har Du deltagit i andra programmeringsprojekt? Vilken metod använde man sig av då? För och nackdelar jämfört med XP. 11