Jämförelse mellan Extreme Programming och andra lättviktsprocessser Av : Fredrik Scheja (d98fsc) Måns Holmstedt Jönsson (d99mhj)
1 Inledning Denna artikel kommer att behandla lättviktsprocesser såsom Scrum, FDD, Crystal och ASD. Sedan skall vi jämföra dessa metoder med Extreme Programming (XP) för att se på vad de olika processerna lägger tonvikt på. Processerna kommer att beskrivas kortfattat och vi kommer att lägga tyngdpunkten på de delar av processen som vi tycker är relevanta för just vårt arbete. Vi kommer att lägga stor vikt på den sociala aspekten hos de olika processerna. I slutändan kommer vi att reflektera över om vi skulle kunna tänka oss att använda någon annan process för att förbättra arbetet i vårt projektarbete i kursen IPT. 2 Agile-metoden 2.1 Bakgrund Ingenjörskonsten har sedan dess begynnelse fungerat på så sätt att en erfaren ingenjör har tillverkat en design av lösningen till ett visst problem, t ex ett brobygge. Vid konstruktionen av en bro tar man sedan hjälp av byggarbetare och konstruktörer som använder ingenjörens design för att bygga bron. Designen i detta fallet är allomfattande, d v s den presenterar totallösningen. Länge har ett sådant synsätt tillämpats på programvaruutveckling. Men under 90-talet började grunderna läggas till ett nytt tankesätt. Tankesättet var att hela källkoden var ett designdokument och konstruktionsfasen i själva verket var användandet av kompilator. Mannen som framförde detta tankesätt var Jack Reeves[7]. Det som skiljer programvaruutvecklingen från traditionella ingenjörskonster är följande. Vid t ex ett brobygge är det ytterst ovanligt att kunden mitt i byggandet skulle vilja att bron även skall kunna bära tåg. Det är däremot inte ovanligt att kraven från kunden ändras i programvaruprojekt. Sådana projekt måste vara smidigare och mer beredda på ändrade förutsättningar. Vi ska nu berätta kortfattat hur denna projektprocess är utvecklad genom ett nytt sätt att tänka när det gäller företagsamhet, Lean Manufacturing. Detta tankesätt har lagt grunden till en ny mer anpassningsbart och lättstyrt sätt att utveckla programvara. Dessa utvecklingsprocesser samlas in inder ett familjenamn, "Agile".
2.2 Lean Programming Under början på 80-talet uppkom ett nytt sätt att se på industriell tillverkning. Denna tillverkningsprocess utvecklades av Taiichi Ohno och den blev senare känd som Lean Manufacturing[10]. För att skapa en effektiv tillverkningsprocess utgick han från arbetarna på golvet istället för att gå och fråga ingenjörerna. Ohno sammanfattade sin process i tio punkter: 1. Eliminate Waste 2. Minimize Inventory 3. Maximize Flow 4. Pull Down Demand 5. Empower Workers 6. Meet Customer Requirements 7. Do it Right the First Time 8. Abolish Local Optimization 9. Partner With Suppliers 10. Create a Culture of Continuous Improvement Man har på senare tid uppmärksammat att Lean Manufactoring kan appliceras på programvaruutveckling och kallas då för Lean Programming och bygger på dessa punkter: #1 Eliminate Waste Detta innebär att man skall göra sig av med så mycket oväsentligt arbete som är möjligt. Detta kan jämföras med en arbetsmetod i XP vid namn Simple Design. Denna metod innebär kortfattat att man implementerar den uppgift man skall lösa, men ingenting utöver detta. #2 Minimize Inventory Grundidén har att göra med att ta bort allt överflödigt som inte tillför någonting till slutprodukten. T ex i programvaruutveckling begränsas tillverkningen av dokument som i första hand inte har med slutprodukten att göra. #3 Maximize Flow (Drive Down Development Time) Detta har att göra med att man vill maximera genomflödet genom att minimera arbetscyklerna. Från att tidigare tagit år mellan programvaruiterationer skall man nu minimera dem till månader alternativt veckor. #4 Pull From Demand (Decide as Late as Possible) När man arbetar med programvaruutveckling har man ingen chans att förutse hur produkten kommer att se ut i slutändan. Därför måste man vara flexibel inför förändringar i kraven från marknaden/kunden.
#5 Empower Workers (Decide as Low as Possible) Utvecklare vill vara med och få feedback om hur det går för projektet i helhet. Detta löser man genom korta iterationer och möten med utvecklarna så att de får en uppfattning om var projektet är på väg och hur det kommer att se ut i slutändan. Detta medför att utvecklarna får mer kunskap och mår bättre. #6 Meet Customer Requirements (Now and in the Future) Kunder vill ofta äta kakan och ändå ha den kvar. D v s kunden vill sällan begränsa sig genom att tidigt i processen göra avgörande beslut i vilken riktning projektet skall gå. Dessa beslut är dock viktiga för utvecklarna för att arbeta effektivt. Lösningen på problemet är att ha korta iterationer och låta kunden ta del av den halvfärdiga produkten efter varje iteration. Det är då lättare för kunden att se vad han egentligen vill ha och denne kan lättare ta avgörande beslut angående projektets riktning. #7 Do it Right the First Time (Incorporate Feedback) Eftersom kunden inte alltid vet vad denne vill ha måste man ha ett säkert och robust system för att kunna göra ändringar som kunden kräver allt eftersom. Detta uppnås i lean programming dels genom att införa test som försäkrar att koden är stabil och dels genom att använda refactoring. Detta innebär att man implemterar och löser det aktuella problemet och sedan, när kunden ändrar sina krav, utför en kontrollerad och effektiv förbättring av designen. #8 Abolish Local Optimization (Sub-Optimized Measurements are the Enemy) Det gör ingenting att programmerarna inte sitter vid sin terminal och kodar fyrtio timmar i veckan. Det är viktigare att se till helheten av vad som produceras i slutändan. Koncentrationen skall inte ligga på antal producerade kodrader, utan hellre på att produkten utvecklas i rätt riktning. #9 Partner With Suppliers (Use Evolutionary Procurement) Detta innebär att man helst vill ha ett fortlöpande kontrakt med beställaren så att han får det bästa mervärdet till det priset. Eftersom kunden oftast inte vet vad den vill ha är det mycket svårt, om inte omöjligt, för utvecklingsteamet att lägga ett bud på kostnaden. #10 Create a Culture of Continuous Improvement Under hela processens gång skall man vara noga med att stanna upp reflektera över hur projektet har gått och försöka lära sig av sina misstag så att kvalitén blir bättre och bättre.
2.3 The agile manifesto De upphovsmakare till de lättviktsmetodiker vi går igenom här i denna skrift har gått samman för att utveckla ett manifest[3]. I detta lägger man fast ett antal principer som lägger ett grundfundament med punkter som alla lättviktsmetodiker har gemensamt. Innehållet i manifestet är följande: Högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerligt levererad, fungerande programvara. Detta sker i korta iterationer om veckor till ett litet antal månader. Utvecklingsteamet måste välkomna ändrade produktkrav, även om de kommer sent i utvecklingen. Detta förbättrar kundens konkurrenskraft. Det måste finnas en god daglig kontakt mellan affärsfolk och utvecklare. Det är viktigt med motiverade människor så ge dem därför den miljö och det stöd de behöver. Lita på att de gör jobbet. Muntlig kommunikation är bästa sättet att framföra information på. Fungerande programvara är det bästa sättet att se hur långt utvecklingen har gått. Utvecklingsteamet bör kunna hålla en någorlunda konstant utvecklingstakt. Kontinuerlig uppmärksamhet på en stabil, bra design förbättrar flexibiliteten. Enkelhet är väsentligt. Försök att minimera onödigt arbete. Den bästa arkitekturen, designen och produktkraven uppkommer från självständiga utvecklingsteam. Utvecklingsteamet skall med regelbundna intervall reflektera över hur man ska kunna uppnå bättre effektivitet och sedan införliva de ändringarna i utvecklingsarbetet.
3 XP vs andra agile metoder 3.1 Crystal Crystal har utvecklats av Alistair Cockburn[1] efter många års erfarenhet av programvaruutveckling och intervjuer med otaliga projektgrupper ända sedan tidigt 90- tal. Crystal består av en hel familj av metodiker att arbeta efter beroende på vad det är för produkt som ska utvecklas. De olika metodikerna kallas Clear, Yellow, Orange och Red. Cockburn ser på projektet med avseende på två aspekter, dels antal anställda och dels konsekvenserna av buggar i systemet. Diagram över Cockburns sätt att karakterisera projekt. På ena axeln har vi antal gruppmedlemmar och på den andra vad man förlorar av buggar i produkten. C-komfort, D-småkostnader, E-väsentliga summor pengar och L-liv Gemensamt för alla i Crystal-familjen är att projektet skall producera användbar och fungerande mjukvara. Detta uppnås genom att hela tiden anpassa själva utvecklingsarbetet så att arbetet och kommunikationen inom gruppen skall flyta bättre. Detta innebär att inget projekt kommer att skötas exakt likadant som ett annat, det gäller att hela tiden vara anpassningsbar. Man stödjer alla kriterier för att vara en lättviktsprocess, t ex korta iterationer, bättre kommunikationer och mer feedback. Crystal-familjen är människocentrerad på så sätt att man anser att alla verktyg och arbetsmetoder är till för att stötta individen, projektets viktigaste resurs. Man är också väldigt tolerant dels mot människors olika sätt att vara och dels mot utvecklingar och anpassningar till arbetssättet, t ex kan man alltid lägga till arbetsmetoder från XP.
Crystal Clear vs XP XP kan jämföras med Crystal Clear, dvs projekt som innefattar D6 och E6-nivåerna. Clear är till för projektgrupper som sitter i ett och samma rum, omkring 6-10 personer. Större grupper än så behöver mer specificerade kommunikationsstrukturer. Cockburns process liknar i många avseenden XP men enligt oss skiljer de sig i två stora punkter: Clear kräver av gruppen att producera teknisk dokumentation, men innehållet lämnas över åt gruppen att själv bestämma efter eget omdöme. Detta är för att hjälpa framtida utvecklare att sätta sig in i projektet. Cockburn talar varmt om whiteboardens oöverträffliga egenskaper i utvecklingsarbetet. Köp in, och snåla inte med whiteboards, för man ritar sällan av vad man kommit fram till (och det är inte sällan man kommer fram till att den informationen var kritisk först långt efteråt) och då är det bra att man inte behöver sudda ut tavlan. Det kan finnas information lite här och var på tavlorna som kan vara viktig att få med i den tekniska dokumentationen. Efter och mellan varje release har man en workshop med projektgruppen där man satsar på att trimma in både produkten och själva utvecklingsarbetet. Man intervjuar utvecklarna och tittar på och reder ut brister i produktionskoden och arbetsmetoderna. Detta gör att projektet blir mer anpassningsbart för ändrade krav än XP. Cockburn har här kommit fram till en arbetsmetod som han tycker är det minsta man bör göra för att kunna arbeta flexibelt och få största möjliga frihet för utvecklarna, och ändå få ett utvecklingsarbete att fungera. Om man försökt med XP och man inte känner att det fungerar kan man alltid falla tillbaka på Crystal Clear, med det tillägget att man måste tillverka teknisk dokumentation. Annars faller alla arbetssätt i XP in i Clear. 3.2 Adaptive Software Development vs XP Jim Highsmith har kommit fram till någonting han kallar Adaptive Software Development (ASD)[7] efter många års arbete med tunga traditionella processer. Hans arbetsmetoder är inte lika hårt specificerade som XP. Men det är inte det som är det viktigaste i Highsmiths arbete, han lägger stor tyngdpunkt på att visa med hjälp av kaosteori på varför ett adaptivt arbetssätt är viktigt ur en organisatorisk synvinkel. ASD har tre faser som arbetsprocessen genomlöper: Spekulation Highsmith menar att en planering är omöjligt att genomföra i ett adaptivt arbete eftersom det är omöjligt att förutse allting. Däremot kan man spekulera i vad som kan ske i det fortsatta arbetet.
Samarbete När man arbetar i en miljö där man måste vara beredd på snabba förändringar måste projektgruppen samarbeta på ett helt nytt sätt. Projektledningens uppgift är i mindre skala att tala om för sin personal vad som ska göras, viktigare är att uppmuntra kommunikation mellan gruppmedlemmar så att de tillsammans kommer fram till vad som skall göras. Lärande I en traditionell processutveckling kommer själva lärandet i skymundan i och med att man bestämmer sig för en design och sedan håller sig till den. I en adaptiv utvecklingsprocess är det viktigt att man efter varje iteration tittar tillbaka på vad som gick bra eller dåligt. Sedan är det viktigt att lära sig av detta inför nästa utvecklingscykel. I och med denna tyngdpunkt i Highsmiths resonemang märks det att han fokuserar mycket på utvecklingsarbetets mer mjukare sidor i allmänhet och samarbete och lärande i synnerhet[14]. Jim Highsmith och Alistair Cockburn har under senare tid arbetat med att sammanföra deras två arbetsmetodiker ASD och Crystal. 3.3 Scrum Scrum är en utvecklingsprocess som byggs på ett antal regler och arbetsmetoder. De sammanfattas enligt följande. Att ta stora problem och bryta ner dem till mindre och mer lätthanterliga problem, som mindre projektgrupper kan klara av att producera inom några månader eller mindre. Processen skall också göra det möjligt för utvecklarna att producera kod även om de inte exakt vet hur designen för hela problemet som skall lösas ser ut. Scrum låter även stora projektgrupper arbeta som små genom att dela upp arbetet i mindre bitar. Dessa mindre problem kan produceras parallellt så att alla grupperna inom projektet kan jobba samtidigt. Men det ställs även krav på kontinuerlig synkronisering och testning för att de olika delarna som produceras skall vara så stabila att de lätt kan slås samman. I punktform kan Scrum beskrivas enligt följande[12]: Små grupper för att ha en hög kommunikation inom projektet. Lätt kunna anpassa sig till nya tekniska och marknadsmässiga lösningar för att få fram de bästa möjliga produkten. Uppdelning av stora problem till mindre. Konstant dokumentering och testning under skapandet av koden. Scrum vs XP Scrum har många gemensamma nämnare med XP. De saker som man tänker först på är att både Scrum och XP är ute efter att ta ett stort och komplext problem och bryta ner det så att det skall bli lättare att hantera[13]. I enlighet med de båda processerna är det också en styrka att arbeta i små team i stället för stora arbetslag. Detta främst för att man lägger större tyngd på den sociala aspekten inom programmvaruutvecklingen. Det skall dock nämnas att det ej enbart är av humanistiskt tänkande som man gör detta. Den största anledningen till att man har små arbetslag är att man snabbare vill sprida kunskapen inom projektet. En annan sak som de två processerna har gemensamt är att de båda stödjer, och
kräver, kontinuerlig testning genom hela projektet även om XP med sin test-firts har ett annat tillvägagångssätt att utföra disciplinen. I stort är Scrum en XP light version där man tagit bort eller tar lättare på vissa av XP s discipliner så som test-first och parprogrammering. Men i slutändan är det ändå fler saker som för de båda processerna samman än som skiljer dem åt. 3.4 Feature Driven Development vs XP Feature Driven Development (FDD) är en process som börjar med att man fastställer helhetsmodellen av det system man skall bygga[17]. När detta är gjort delar man upp modellen i mindre bitar s k features, design by feature, build by feature. Dessa implementerar man över en period av ca två veckor. En feature är inom projektet definierad som en funktion som kunden har nytta av. Man kan punkta upp Feature driven development i 4 punkter: Develop an overall model Build a feature list Plan by feature Design by feature/build by feature Likheterna mellan FDD och XP är många. Båda processerna är designade för att snabbt kunna leverera färdiga resultat till kunden så att man snabbt skall kunna få feedback. De är också mer fokuserade på att överföra kunskap genom människor istället för att som i de stora tungviktprocesserna producera tusentals sidor dokumentation. Även när det gäller rollerna i projektet har de samma synsätt. Det vill säga att det finns ingen fast designgrupp eller någon fast implementeringsgrupp utan alla jobbar tillsammans. Detta gäller även kunderna som båda processerna vill ha med i projektet som en aktiv part i utvecklingen. FDD vs XP Det som skiljer de två processerna åt är främst följande saker: En av de främsta skillnaderna mellan de två olika processerna är storleken på teamen. XP är designad för grupper på ca 10 personer medan FDD är designad för mycket större grupper[15]. Detta anser vi vara en svaghet eftersom ju större grupperna desto mindre blir de sociala fördelarna. Med sociala fördelar menar vi främst den sociala kontakten mellan människor. Med för stora grupper skapas problemet med mångfaldens överflöd. I XP har alla rätt till att ändra i koden. Vem som helst får ändra var som helst. I FDD får man bara ändra koden i den aktuella featuren man håller på att implementera. I FDD har man klassägare som jobbar med en feature. Ägare till angränsande klasser jobbar oftast inom samma featureteam för att på så sätt spridda kunskapen inom projektet. Kunskaperna blir dock bara spridda inom sitt featureteam istället för hela gruppen som i XP där hela teamet vet hur koden fungerar. I FDD används inte parprogrammering, som är en av stöttestenarna i XP. Man använder istället sig av kodgranskning. Detta av tre skäl. Den som granskar koden har inte varit med och skrivit den. Detta gör att personen är mer kritisk och inte släpper igenom någon halvdan kod. Chefprogrammeraren kan tillse att dom sätt som
används för att lösa uppgiften verkligen är en bra lösning, så att inte programmerarna lär varandra dåliga vanor. Detta är annars en sak som lätt kan hända i XP. Den tredje är att man som programmerare kommer bort från terminalen när man granskar koden på papper. Man behöver i FDD inte använda enhetstester som man måste ha i XP. Man utgår istället från att programmerarna kontinuerligt testar koden på olika sätt. Det är dock helt okej att använda enhetstester i ett FDD projekt.
4 Sammanfattning och reflektioner Efter att har gjort denna djupstudie har vi funnit oss reflektera över vissa punkter. Det är märkligt att XP har sådana hårt fastställda discipliner när man vill kalla sig för en anpassningsbar och flexibel metodik. Dock poängterar Beck att man skall utgå från XP och se det som en startpunkt. Men vi tycker att Beck inte berättar tillräckligt utförligt hur denna anpassning skall göras. Vi vill att XP skall lägga mer tonvikt på The agile manifesto s sista punkt: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Bristen på teknisk dokumentation i XP ställer väldigt höga krav på läsbarhet i koden. Vi har märkt i våra projektgrupper som vi coachat under våren 2002 att koden som tillverkas i XP-anda i slutändan inte är så självförklarande som man skulle ha velat. En lösning på detta problem skulle kunna vara att kräva att man lägger in javadoc i koden. En viktig sak som Crystals grundare Cockburn lägger stor vikt på är att ha en yta, t ex en whiteboard, att skissa upp arkitekturen så att den alltid finns till hands när den blir aktuell att diskutera. Utvecklarna bör alltid ha en bild av hur systemet ser ut i bakhuvudet. Detta rekommenderas varmt från våran erfarenhet i IPT-kursen, studenterna får mycket gratis om de har arkitekturen framför sig när de behöver. Vi har också märkt i våra projektgrupper att man drar sig lite för att ändra i kod som någon annan skrivit. En lösning på detta är att den som vill göra en ändring i koden parar ihop sig med den som ursprungligen skrev koden som skall ändras i. I en adaptiv process är all försök till planering och framförhållning nästintill omöjligt. Den enda fördelen är möjligtvis att kunden kan få en antydan till hur mycket han/hon kan få med i nästa iteration. Men eftersom allt kan hända och ställa till det under resans gång i en anpassningsbar miljö kan man aldrig vara säker. Vi tror att det kräver lång erfarenhet innan man kan med någorlunda precision uppskatta arbetsbördan av en viss uppgift. Därför tycker vi att estimeringen i projekten som vi varit en del av under våren känns onödig. Projektgrupperna har ingen chans att komma fram till någon vettig uppskattning eftersom de har för liten erfarenhet. Slutligen anser vi att ingen av de andra lättviktsmetodikerna är mer attraktiv för användning i en kurs i IPT. Men vi ser gärna en liten trimning av XP enligt våra rekommendationer.
5 Referenslitteratur Böcker: [1] Cockburn: Agile Software Development, Pearson Education 2002. [2] Jeffries, Anderson, Hendrickson: Extreme Programming: Installed (2001) Artiklar på internet: [3] Principles behind the agile manifesto - http://agilemanifesto.org/principles.html [4] Cockburn, Agile Software Development Joins the Would-Be Crowd - http://www.agilealliance.com/articles/articles/accitj0102.pdf [6] Feather, Agile Workflow - http://www.objectmentor.com/resources/articles/agileworkflow.pdf [7] Fowler: The new Methodology: - http://www.martinfowler.com/articles/newmethodology.html [ 8 ] M a r t i n, O n A n a l y s i s - http://www.agilealliance.com/articles/articles/onanalysis [9] Martin, ContinuousCare - http://www.agilealliance.com/articles/articles/continuouscare [10] Poppendieck, Lean Programming - http://www.agilealliance.com/articles/articles/leanprogramming.htm [11] Schwaber, Self Organization http://www.agilealliance.com/articles/articles/agile_processes_and_self_organization.p df [12] Schwaber, Controlled Chaos: Living on the Edge, The origins of Scrum - http://www.agilealliance.com/articles/articles/ap.pdf [13] Sutherland, An extension pattern language for hyperproductive software development - http://www.jeffsutherland.org/scrum/index.html [14] Highsmith and Cockburn, " The Business of Innovation" and "The People Factor" in IEEE Computer, Sept & Nov 2001 - http://www.jimhighsmith.com/articles/ieeearticle1final.pdf - http://www.jimhighsmith.com/articles/ieeearticle2final.pdf [15] Coad, Java Modeling in Color with UML: Enterprise Components and Process, Chapter 6 http://www.togethersoft.com/files/services/jmcu/chapter6.pdf [16] Palmer, A Brief History of FDD - http://www.stephenrpalmer.co.uk/fdd/fdd.html [17] Palmer, FDD and XP: - http://www.togethercommunity.com/coad-letter/coad-letter-0070.html