Distribuerad mjukvaruutveckling med extreme Programming

Transkript

1 Distribuerad mjukvaruutveckling med extreme Programming Jörgen Nilsson, February 22, 2005 Sammanfattning Denna artikel är en djupstudie skriven under en kurs i coaching av XPteam, på Lunds Tekniska Högskola. Den riktar sig primärt till de coacher som går, och kommer att gå, kursen och är menad att skapa en mer nyanserad syn på extreme Programming. Artikeln diskuterar Distributed Software Development (DSD) med paralleller mot XP. Ett ertal experiment från olika artiklar har studerats och har sammanställts för att ge en introduktion till de fördelar och nackdelar som DSD har, samt hur man löser problemen som uppstår när man inte har utvecklingsteamet på samma plats. Som exempel på en metodik för DSD tas bl.a. Distributed extreme Programming upp (DXP). Detta eftersom den har störst relevans för de coacher som artikeln är riktad till. På slutet presenteras även exempel på verktyg man kan ha nytta av när man ska köra DXP.

2 Innehåll 1 Introduktion 3 2 Mjukvaruutveckling över två kontinenter med hjälp av XP och Scrum 3 3 Distributed extreme Programming (DXP) 5 4 XP's practices i DXP Virtuell parprogrammering Planning Game Shared Vision (Metaphor) Continuous Integration On-Site Customer Moomba - ett verktyg för DXP Webbportalen HyperStackXP Moomba's Collaborative Integrated Development Environment (MCIDE) Slutsaster och vidare läsning 11 7 Acknowledgments 12 2

3 1 Introduktion Historiskt sett har mjukvaruutveckling i skett i team placerade på samma plats, men i och med explosionen av nätverkförbindelser som Internet medfört så är det nu fullt möjligt för geograskt distribuerade utvecklingsteam att forma virtuella team. Global Software Development (GSD) är en practice för mjukvaruutveckling som kommer mer och mer. Redan under 90-talet dök ett ertal organisationer för virtuell mjukvaruutveckling upp. Virtuella mjukvaruutvecklingsteam är namnet på geograskt distribuerade utvecklare arbetande på samma projekt där kommunikation, koordination och samarbete sköts via Internet eller intranet. Att vara separerade under utvecklingsprocessen innebär ett stort hinder för projektmedlemmarna. De ekonomiska fördelarna måste vägas mot de nackdelar i kommunikation som Distributed Software Development (DSD) medför. Det krävs mycket mer av den kommunikation som sker mellan utvecklarna för lyckad koordination av arbetet, vilket ökar risken för missförstånd, som i sin tur kan leda till förseningar och därmed högre kostnader. Däremot kan fördelar som minskade utvecklingskostnader, ökad mobilitet och exibilitet för utvecklarna, lättillgänglig kompetent personal, och ökad bekvämlighet för kunden väga upp nackdelarna. Som exempel på DSD kan tas de många Open Source projekt som är igång idag. Linux och Apache Web Server är två av de största Open Source projekt någonsin. Man kan dra paralleller mellan Open Source Communityn's och XP's syn på programkod - alla äger koden och alla får ändra i den. Detta ger oss tanken att XP mycket väl skulle kunna vara lämpat för DSD. För göra extreme Programming (XP) möjligt i ett distribuerat projekt krävs att man har rätt förutsättningar, annars kommer inte alla alla XP's tolv practices att fungera. Vidare följer ett exempel där XP användes i en distribuerad miljö. 2 Mjukvaruutveckling över två kontinenter med hjälp av XP och Scrum Att utveckla mjukvara i projekt där teamet är distribuerat över två kontinenter innebär många svårigheter. Förutom de vanliga svårigheterna man stöter på vid mjukvaruutveckling måste man även ta hänsyn till att teamen benner sig i olika tidszoner. I Danmark, närmare bestämt i Köpenhamn, på SAS Institute - ett multinationellt företag med huvudkontor Cary North Carolina USA - har man under många år utvecklat mjukvara i samarbete med de team företaget har i USA. I en artikel skriven av två utvecklare från kontoret i Köpenhamn får vi följa hur teamet först anammar XP för att sedan plocka in practices från Scrum. Scrum är en agil metod för programvaruutveckling som i stort skiljer sig från XP i sitt sätt att deniera dagliga möten (Scrums) som en del av metodiken, samt genom sitt sätt att följa upp projektförloppet med en Project Backlog och en Sprint Backlog (sprint är det samma som iteration i XP). Scrum har helt enkelt ett annat sätt för kravhantering än XP's Planning Game. I Scrum nns det en ägare av produkten kallad Scrum Master, som har hand om Project Backlog - en lista med det inneliggande arbetet. Ordningen för implementation av programmet följer listan från topp till botten. En delmängd av punkterna i 3

4 listan yttas inför varje sprint över till Sprint Backlog där de delas upp i mindre tasks som sedan estimeras i enlighet med tillgängliga resurser. Estimeringarna uppdateras sedan kontinuerligt under en sprint för att få en inblick i om teamet ligger i fas eller ej. Uppgiften för Scrum Master är även att se till så att arbetet i teamet yter på utan problem. Han ska hjälpa till där det behövs samt försöka förebygga att problem uppstår. I projektet från artikeln bestod teamet av 80+ utvecklare, där 10+ var placerade i just Köpenhamn och majoriteten av de övriga på huvudkontoret i USA. Projektet bestod i att implementera en redan bentlig desktop-mjukvara som webbapplikation, så någon egentlig kund fanns det inte. Teamet på SAS Institute i Köpenhamn hade redan utvecklat mjukvara under många år och kände att mer erfarenhet inte skulle leda till bättre resultat. Kvalitén på slutprodukten berodde rent för mycket på den individuella programmeraren och rent för mycket tid slösades på att rätta buggar istället för att producera kod. Vad som behövdes var ett formellt sätt att granska koden och de bestämde sig därför för att prova XP där granskning sker kontinuerligt genom parprogrammering. De inledde en evalueringsfas innan de bestämde sig för att implementera XP fullt ut. Det hela gjordes i tre iterationer där parprogrammering, enhetstester och dagliga möten ingick i första, kodstandard och kollektivt ägande i andra, och stories, tidsuppskattning och hastighet i den sista. Det var inga problem för dem att implementera XP. Däremot tyckte de inte att XP hjälpte dem att koordinera och prioritera arbete mellan dem och huvudteamet. Efter att ha använt XP under två år bestämde de sig för att prova använda Scrum. På baksidan till boken om Scrum av Ken Schwaber står det Learn how to simplify XP implementation through a Scrum wrapper. Det lät som en bra idé, men problemet var att det inte någonstans i boken nämndes XP. Det var dock inga problem att med bokens hjälp tillämpa Scrum som en slags management del för XP team. Samtidigt som de började använda Scrum, började de även föra dagliga videokonferenser med teamet på huvudkontoret i USA. Eftersom det skiljer sex tidszoner mellan arbetsplatserna ck mötet ske mellan det att amerikanarna började och danskarna slutförde sin dag. Scrum underlättade för teamet att planera, estimera och tracka samtidigt som det genererade samma slutresultat. Scrum's backlog system, tillsammans med de dagliga mötena (The Scrum of Scrums), verkar vara en mer strukturerad och specik metod för kravhantering än XP s Planning Game. Hastighetsmåttet från XP kan tyckas en aning missvisande. Det är svårt att få en överblick av hur mycket som verkligen händer under en dags programmering om arbetet består av många stora stories - det händer inget i trackinglistan förrän en story är klar. Det går naturligtvis att bryta ner större stories i mindre i vissa fall, men inte alltid. De övriga teamen använde en något annorlunda metodik än det i Köpenhamn. Av det kan man dra slutsatsen att det går att utveckla mjukvara i virtuella team utan att följa samma metodik. Dock borde det underlätta om man kunde tala i samma termer, som tex Planning Game, Stories, Tasks etc., vid koordination och planering mellan teamen. Därför är det intressant om en renodlad version av XP kunde köras bland alla teamen. Vidare följer en metodik som föreslogs på XP 2001 konference i en artikel som heter Distributed extreme Programming"[7]. 4

5 3 Distributed extreme Programming (DXP) För att XP ska fungera som metodik vid mjukvaruutveckling ställs det höga krav på kommunikationen inom teamet. Detta menar traditionell XP kräver att teamet är placerat på samma plats. I många situationer är detta inte möjligt eller ens något man vill. Ett företag eller ett projekt kan enligt [7] vara i följande situationer som kräver DXP: Globalt distribuerat företag: Ett företag kan vara multinationellt eller helt enkelt ha kontor på era ställen. Ibland behövs kanske kompetens som endast nns inom en annan del av företaget än den där huvudteamet benner sig. Individuella begränsningar: En person kan ha svårt att arbeta på samma plats som huvudteamet under delar av projekttiden. Det är då viktigt att inte denna person utesluts från teamet under perioden för sin frånvaro. Det nns även vissa fördelar som kan locka ett företag att köra DXP: Kostnadsbesparingar: Om man kollar på industrin idag så är trenden tydlig. Outsourcing av delar av verksamheten i ett företag som kräver speciell kompetens till marknader med billigare arbetskraft blir allt vanligare. Indien och Kina har formligen exploderat de senaste åren och mycket ITverksamhet yttas nu från västvärlden och dit. Kundens inblandning: Traditionell XP kräver att kunden ska nnas på plats tillsammans med utvecklingsteamet. Med DXP blir det lättare att integrera kunden utan att den är On-Site. Detta medför att kunden inte längre behöver klippas av från sitt vanliga arbete. Mobilitet: Mobilitet blir allt viktigare idag när vi reser mycket mer än förr, men fortfarande måste klara av våra dagliga uppgifter. En person från utvecklingsteamet kan behöva åka på möte eller konferens, men måste ändå hållas integrerad med teamet. Denna person kan då hålla kontakten med huvudteamet genom att ha en laptop med uppkoppling mot Internet, och kanske även en liten webbkamera för att kunna hålla videokonferens. 4 XP's practices i DXP Kravet i XP är att utvecklingsteamet benner sig på samma plats för att kommunikationen inom teamet ska vara tillräcklig. XP kräver ingen omfattande dokumentation, utan tanken är att kunskapen ska spridas från huvud till huvud genom att kommunicera extremt mycket. Därmed behöver DXP något sätt att kompensera för bristen i kommunikation som avståndet mellan teammedlemmarna medför. Vanliga sätt att kommunicera över långa avstånd är idag bland annat e-post, Instant Messenger program och chat. Dessa medium för kommunikation saknar dock en del viktiga kanaler, och dessa är i huvudsak ansiktsuttryck, kroppsspråk och röstläge. Genom att inte kunna bedöma en annan persons reaktioner från dessa kommunikationskanaler kan missförstånd lätt uppstå. Arbetet mellan i synnerhet parprogrammerare kan hämmas betydligt. Utvecklarna behöver 5

6 därför en del kommunikationsverktyg för att kompensera för avståndet mellan dem. Förutom e-post och chat så kan teamet behöva använda videotelefoni eller någon form av videokonferensmjukvara. Detta skulle kunna underlätta något för parprogrammering. Men för att kunna köra parprogrammering distribuerat krävs mer än att man kan se ansiktet på sin partner, man måste även ha mjukvara som stödjer att man kan samarbeta på samma arbetsyta (se virtuell parprogrammering). Om utvecklarna benner sig i olika tidszoner kommer de att arbeta på olika tider. Det kan även vara så att någon av utvecklarna är involverade i era projekt samtidigt. Någon annan utvecklare kan t ex få personliga förhinder under en tid. För att synkronisera arbetet mellan utvecklare i DXP krävs alltså någon form av formell schemaläggning. Man skulle kunna tänka sig att samtliga utvecklare utväxlade dag- eller veckoschema med varandra via e-post, och att det i dessa scheman stod vilka tider de var tillgängliga och vad de planerar att jobba med. Utefter detta kan utvecklare sedan hitta partner för parprogrammering. Dock vore en bättre lösning något slags gemensamt verktyg för informationsutväxling tillgängligt över webben, t ex en wiki-wiki eller någon form av portalapplikation. I stora team ökar kravet på formalisering av schemaläggning och något specialbyggt verktyg kan vara av nytta. Förslag på ett sådant är HyperStackXP i Moomba-modellen, vilket beskrivs i kapitel 6. I ett virtuellt team så är det inte säkert att projektledaren nns på plats, i synnerhet inte när det gäller Open Source utveckling där de esta medlemmarna ur teamet faktiskt inte benner sig på samma plats. När det gäller kommersiell mjukvaruutveckling måste det nnas ett oerhört förtroende mellan de olika parterna i teamet. Projektledning över stora avstånd kräver någon slags strategi för att fungera. T.ex. skulle det kunna vara krav på veckorapporter från utvecklarna, och att projektledaren hela tiden gav feedback på utfört arbete. Ytterligare stöd för att öka medvetenheten inom teamet skulle skapa en högre närvarokänsla mellan utvecklarna och därmed stärka teamkänslan. Videotelefoni eller videokonferens är extremt behändigt för att skapa en slags större närhetskänsla. Moomba-modellen stödjer medvetenhet på ett ertal olika plan och är ett utmärkt verktyg för DXP (kapitel 6). För att DXP över huvudtaget ska kunna fungera ställs höga krav på infrastrukturen, både i form av nätverkskopplingar men även på den mjukvara och hårdvara som används. En dålig infrastruktur kan göra det omöjligt att kompensera för de svårigheter i kommunikation som en distribuera miljö medför. Teammedlemmarna måste under alla omständigheter ha möjlighet att koppla upp sig mot varandra genom Internet eller företagets intranet. Vidare måste det nnas stöd för kongurationshantering, vilket för visso redan är ett krav i XP, men i DXP ställs det större krav på åtkomlighet. I en globalt distribuerad miljö där kanske några utvecklare hindras av brandväggar eller proxys. För att kunna realisera DXP krävs alltså att en mängd villkor är uppfyllda, men även att rätt verktyg nns tillgängliga. Givet detta är det endast fem av XP's tolv practices som behöver tas hänsyn till. Dessa är parprogrammering, Planning Game, Customer On-Site, Contuinuos Integration och Shared Vision (Metaphor). 6

7 4.1 Virtuell parprogrammering För att på ett eektivt sätt kunna köra virtuell (distribuerad) parprogrammering, krävs att utvecklingsmiljön har stöd för delad arbetsyta. Brian Hanks på University of California, Santa Cruz, har i en studie [5] undersökt möjligheterna att köra distribuerad parprogrammering i en introduktionskurs för programmering. Erfarenheter från hans arbete kan komma målgruppen för denna artikel väl till pass. Att kunna arbeta tillsammans på programmeringsprojekt utan att behöva färdas långa sträckor för att träas, för att sedan ändå bara sitta och stirra på skärmen, kan tyckas användbart och önskvärt. Verktyget för virtuell parprogrammering som B har använt är en egenutvecklad modikation av Virtual Network Computing (VNC). Som underlag för sin studie har han använt följande observationer: Vid parprogrammering byter man driver ofta men utan några särskilda formaliteter. Ibland tar co-drivern helt enkelt bara över. Paren pratar väldigt mycket under parprogrammering, men de spenderar inte mycket tid med att titta på varandra. Deras fokus är på skärmen. Man pekar ofta mot skärmen för att poängtera vad man syftar på när man vill anmärka på eller fråga om något. För att klarlägga vad VNC är för den oupplysta så är det ett verktyg som används för att koppla upp sig mot en annan dator där man sedermera kan arbeta som om man satt på plats. De modikationer B har gjort tillåter två simultana uppkopplingar mot samma VNC server. Vidare antar de båda uppkopplade användarna rollerna som driver och co-driver genom att en tilldelas muspekare som endast kan ytta runder medan den andra kan använda musen som vanligt. Dessutom fungerar det så att endast den som är driver kan ge input från tangentbordet. Co-drivern kan när som helst ta över rollen som driver, vilket i någon mån kan liknas vid vanlig parprogrammering. Utöver den modierade versionen av VNC använde testgruppen ett program för Voice Over IP (VoIP) för att skapa en närhetskänsla som kan liknas vid den för vanlig parprogrammering. Studenterna som deltog i experimentet var mycket nöjda och tyckte att parprogrammeringsmiljön fungerade bra. Virtuell parprogrammering är intressant för det möjliggör XP för distanskurser, samt för de studenter som av olika anledningar har svårt att närvara fysiskt vid en utbildning. Det kan röra sig om funktionshindrade eller helt enkelt folk som bor långt bort. I ett större perspektiv skulle virtuell parprogrammering kunna verka som ett eektivt sätt att driva samman organisationer över gränserna för att kunna nå de resurser som man kan tänka sig behöva i ett projekt för mjukvaruutveckling. I Moomba-modellen har man tagit fram en utvecklingsmiljö väldigt lik Eclipse 1 som tillåter att två till åtta simultana utvecklare samarbetar. 4.2 Planning Game För att utöva XP's Planning Game distribuerat är det nästan ett krav att videokonferensverktyg och applikationsdelning nns tillgängligt. På något sätt måste 1http:// 7

8 man kunna samarbeta för att skriva stories, tidsbestämma och tilldela uppgifter. Planning Game kräver medverkan från så många projektdeltagare som möjligt. I större projekt gäller det i stort sett bara de projektledare som nns samt naturligtvis kunden. Det är viktigt att så många som möjligt deltar så att en gemensam vision kan förmedlas bland alla projektdeltagare. Videokonferensverktyg förenklar kommunikationen under de diskussioner som naturligt följer med Planning Game. Deltagarna kan se varandras ansikten och misstolkningar kan i större omfattning undvikas vilket snabbar upp processen. Moomba-modellen har stöd för att arbeta fram stories från dess delade utvecklingsmiljö, vilka sedan hamnar sedan på den gemensamma portalen (Hyper- StackXP), där utvecklarna kan teckna sig för dem efter hand. Moomba-modellen har inga krav på videosamtal, men det skulle förmodligen eektivisera hela processen. 4.3 Shared Vision (Metaphor) Utan en strategi för att förmedla en gemensam vision får ett distribuerat projekt av större omfattning en mängd olika krafter dragandes på sitt eget håll. Detta kan bara sluta i missförstånd och i förlängningen många arga ord. I [1] berättas skräckhistorier om hur managementdelen av projektet började gå bakom ryggen på varandra för att de var oense om det sätt på vilket de skulle angripa programmeringsproblemen. Det hela slutade med att produktiviteten gick ner till nära noll. Allt pga att de saknade, eller snarare vägrade anta, en gemensam vision. 4.4 Continuous Integration Utvecklarna måste kunna integrera sitt arbete i en gemensam repository, förslagsvis CVS. Det ända kravet utöver de XP redan har, är att alla måste ha tillgång till CVS:en var de än må benna sig i världen. Detta ställer väldigt höga krav på tillgänglighet och tillförlitlighet. Utan CVS blir Continuous Integration ett mycket omfattande arbete där de distribuerade utvecklarna t.ex skickar sin kod till koordinator som får integrera den med programmet. Med större delen av teamet på en och samma plats skulle denna modell kanske hålla. Åtminstone om det rör sig om korta perioder. 4.5 On-Site Customer I ett distribuerat team är det omöjligt att ha en kund On-Site. Han kan inte längre kallas On-Site utan får ta namnet Virtual On-Site Customer. För att integrera en kund är det nästan krav på videokonferensstöd för att åtminstone någon gång under dagen få tala ansikte mot ansikte. Det ställs väldigt höga krav på tillgängligheten hos en virtuell kund som inte är On-Site för någon del av teamet. Han måste vara tillgänglig under alla av utvecklarnas arbetstimmar. Skiljer det i tidszon mellan utvecklarna och kunden, dyker det upp ytterliggare komplikationer som kan vara svåra att komma förbi. Unika lösningar för varje scenario kan behöva skapas, t ex kan det behövas en ställföreträdare till kunden som kan ta över när denne inte är tillgänglig. 8

9 5 Moomba - ett verktyg för DXP Moomba är ett verktyg för sammarbete i ett distribuerat team. Det är byggt för att realisera DXP i en global utvecklingsmiljö. Moomba är fortfarande under utveckling på The University of Queensland, Australia, men kommer slutligen att släppas som Open Source. På XP 2004 conference presenterades för första gången materialet om Moomba [6]. Målet med verktyget är att skapa en slags community på Internet för ett distribuerat utvecklingsteam. Moomba är uppbyggt i en trelagersmodell, vilken i sin tur är utökning av en bentlig modell kallad TUKAN's medvetandemodell. I TUKAN nns det tre olika samband mellan artefakter (eg. klasser, stories): Strukturella: Samband så som ärvning och liknande Användande: Samband så som metodanrop. Version: Samband mellan artefakter med samma version. Baserat på dessa samband används en slags avståndsfunktion för att beskriva hur nära två artefakter är varandra. Ett färgschema används sedan för att visualisera avståndet till närmaste teammedlem utifrån användarens aktuella position i arbetsytan. På detta sätt kan man få information om användare som arbetar på samma eller liknande artefakter, vilket kan uppmuntra till parprogrammering. Samma avståndsfunktion kan användas för att identiera möjliga konikter rörande kongurationshantering (eg. mergekonikter). Utbyggnaden av TUKAN i Moomba består i stort sett av stöd för kunskap om arbetsytor och ökad medvetenhet rörande gruppstrukturer och sociala samband. Detta är saker som är mycket viktiga för DXP. Moomba består alltså av en trelagermodell: Processlagret, Användarlagret och Artefaktlagret. Modellen presenteras bäst i form av kuben i Figur 1. Figur 1: Moomba's trelagersmodell Processlagret består av allt som rör medvetande kring gruppstrukturer och sociala samband. Inkluderat i detta lager är sådana saker som vilka ansvarsområde olika personer har, vilka användare som nns på samma arbetsplats och 9

10 kunskap om vilka användare som delar arbetsyta. Man kan få information när en potentiell partner för parprogrammering gått online eller när en domänexpert blivit tillgänglig. Det går även att få information när en task som matchar en utvecklares skicklighetsnivå blivit tillgänglig samt mycket mer. Användarlagret innehåller allt som rör medvetande kring interagering och samarbete användare emellan. Man kan säga att lagret är en förenkling av TUKAN's modell. Moomba ger information om användares interaktion med mjukvaruartefakter. På så sätt kan användare undvika potentiella kongurationskonikter. Om en användare upptäcker att någon annan manipulerar en artefakt som berör det den håller på med så kan de båda samarbeta för att lösa upp eventuella konikter. Kunskap om användare som arbetar på samma eller nära besläktade artefakter uppmuntrar till parprogrammering. Artefaktlagret lägger fokus på interaktion mellan mjukvaruartefakter. I lagret inkluderas sådana händelser som ligger närmast varje enskild artefakt - exempelvis att en användare modierar en artefakt i den delade workspace. Moomba-modellen realiseras med i huvudsak två verktyg: HyperStackXP: En webbportal för koordination av arbete och tracking. Moomba Collaborative Integrated Development Environment (MCIDE): En utvecklingsmiljö som stödjer parprogrammering. Både webbportalen och samarbetsmiljön är integrerat med CVS, som lagrar inte bara programkod utan även storykort. Det nns även en server som har hand om att koordinera manipulering och handhavande av delade artefakter. Moombas arkitektur illustreras i Figur 2. Figur 2: Arkitekturen för Moomba Collaborative Environment. 5.1 Webbportalen HyperStackXP Denna delen av miljön används för tracking och Planning Game. I trackingdelen hittas information rörande aktuell release och iteration. Stories och tasks är i sin tur knutna till en specik release och iteration. Detta är viktigt för att nya användare snabbt ska kunna sätta sig in i projektet. De stories och tasks som inte blivit tilldelade någon iteration listas i en speciell del för releaseplannering. Här kan användare välja att lägga in stories och tasks i aktuell eller en framtida iteration. Användare kan också se vilka stories och tasks de blivit tilldelade. När en story med stark anknytning till en aktuell story läggs in i portalen meddelas de användare som håller på med den aktuella storyn om att en ny story, med hög relevans för användaren, har anlänt. Detta är användbart i projekt där användarna själva tecknar sig för stories. 10

11 Varje person i teamet har en egen användarprol i portalen. Under prolen nns information rörande användarens programmeringsintressen, ambitioner, tillgänglighet, projektschema, tidszon, prestationsbedömning från andra användare, samt vilka stories och tasks som den färdigställt. I portalen nns även en sökmotor för att hitta parprogrammerare. Denna har i sin tur väldigt stark koppling till användarprolen. Man kan använda sökmotorn för att hitta en användare med annan kompetensnivå, programmeringsroll eller andra programmeringsintressen. Detta är oerhört användbart när en ny utvecklare ska integreras i teamet - man kan då para ihop denna med en mera erfaren utvecklare. Detta ser i sin tur till att balansera kunskapen som bärs i huvudet av utvecklarna i teamet. 5.2 Moomba's Collaborative Integrated Development Environment (MCIDE) Editorn i Moomba ser ut som vilken annan modern utvecklingsmiljö - eg. Eclipse. Den stora skillnaden är dock att den har stöd för era simultana användare, eller närmare bestämt mellan två och åtta. Detta skapar möjlighet för parprogrammering men ger även stöd för distribuerad Planning Game. Utvecklingsmiljön är baserad på modellen WYSIWIS (What You See Is What I See). Input från en användare distribueras omgående till alla deltagare. De som deltar kan arbeta på olika ställen samtidigt. En person kan alltså scrolla runder för att kolla någon metod i en annan klass medan en annan kodar. På så sätt kan arbetet eektiviseras. Detta kan tyckas ta bort fokus från parprogrammering, men det nns en bra funktion för att öka uppmärksamheten. Man kan nämligen välja att färga användarnas input med olika bakgrundsfärg och kan på så sätt lätt checka av vad som skrivits av vem. Miljön har dessutom ett välutvecklat stöd för att köra debugging tillsammans. Varje deltagare har möjlighet att kontrollera programmets exekvering. Detta kan vara ett mycket användbart verktyg som ytterligare ökar möjligheten för att lyckas med virtuell parprogrammering. 6 Slutsaster och vidare läsning Svårigheten med att driva ett mjukvaruutvecklingsprojekt i en distribuerad miljö ligger i hur man ska lösa det tomrom i kommunikationskanaler som uppstår när inte längre hela utvecklingsteamet sitter bredvid varandra. Ju er utvecklare som deltar i projektet och ju större avstånd, både geogrask och kulturmässigt, det är mellan dem, desto svårare blir projektet att administrera. Stora krav ställs på hur managementdelen av gruppen sköter sitt jobb. Det gäller att i så stor mån som möjligt sprida en gemensam vision och få teamet att känna en slags virtuell teamkänsla. Dessutom krävs det maximalt utnyttjande av de hjälpmedel för kommunikation som nns till hands. Det nns mycket att tjäna ekonomiskt sett, om man kan lyckas med distribuerad mjukvaruutveckling. Outsourcing till länder med billigare arbetskraft erbjuder stora kostnadsbesparingar. Detta skapar också en oro hos utvecklare i västvärlden; att bli utkonkurrerade av utvecklare från Indien och Kina. Detta är naturligtvis ett problem men inte en del av denna artikel. 11

12 Förutom outsourcing kan företag göra kostnadsbesparingar på DSD genom en eektivare resurshantering. Rätt kompetens nns kanske på en annan geogra- sk plats inom företaget och man kan på så sätt slippa hyra in eller nyrekrytera personal. Det nns ingen anledning att tro DSD endast är lämpat för Open Sourceliknande utveckling. Kan de så kan minsann kommersiella företag göra detsamma. DSD är här för att stanna och DXP är bara en metodik i mängden som på inga sätt är den kompletta lösningen. Varje distribuerat projekt har sina specika behov och behöver noggrann planering för att lyckas. Denna artikel har i huvudsak behandlat problem som uppstår vid distribuerad mjukvaruutveckling mha DXP. För vidare läsning om hur man skalar XP till stora projekt kan den intresserade läsaren titta i [9]. 7 Acknowledgments Bilderna i beskrivningen av Moomba-miljön är tagna från [6]. Tack för synpunkter från granskare Josef Granqvist, Mats Wilson, Lina Hallmér samt Görel Hedin. Referenser [1] Distributed Product Development Using Extreme Programming, Charles J. Poole, XP 2004, LNCS 3092, pp [3] Maurer F., Supporting Distributed Extreme Programming, in Proceedings of Extreme Programming and Agile Methods - XP/Agile Universe 2002, Lecture Notes in Computer Science Chicago, IL, USA: Springer-Verlag Heidelberg, pp [4] Bent Jensen and Alex Zilmer, Cross-Continent Development Using Scrum and XP, SAS Institute A/S Denmark [5] Brian F. Hanks, Virtual Pair Programming, University of California, Santa Cruz, brianh/ [6] Michael Reeves and Jihan Zhu, Moomba - A Collaborative Environment for Supporting Distributed extreme Programming in Global Software Development, School of Information Technology and Electrical Engineering, The University of Queensland, Australia [7] Kircher M., et al, Distributed extreme Programming, in Proceedings of Second International Conference on extreme Programming and Agile Processes in Software Engineering (XP2001)", Cagliari, Sardinia, Italy: Addison Wesley, pp. pages [8] Beck K.,Extreme Programming Explained: Embrace Change, Addison- Wesley Publishing Company, [9] Agila processer och storskalig programvaruutveckling, Frida Boström & Per Skarin 12