Djupstudie i parprogrammering Abstrakt P. Abrahamsson D05, Lunds Tekniska Högskola dt05pa1@student.lth.se P. Norlander D07, Lunds Tekniska Högskola dt07pn3@student.lth.se 2011-02-25 Denna studie handlar om parprogrammering, när två personer sitter tillsammans vid en dator och programmerar. Intervjuer har genomförts på studenter som läser en kurs i extreme Programming och handlade mycket om vilka förväntningar studenterna hade på parprogrammeringen, som skulle vara en del av kursen ifråga. Efter att studenterna fått erfarenhet av metoden utfördes en andra intervju där frågorna var mer av en utvärderande natur. Exempelvis hur studenterna upplevde parprogrammering när de programmerade med andra som hade mera eller mindre erfarenhet av programmering. Andra frågor rörde studentens intresse av att använda parprogrammering i sitt framtida arbetsliv. Tidigare forskning behandlas också där de olika aspekterna tas upp och kopplas till vad studenterna uttryckt. Tidigare forskning har framförallt påvisat ökad kodkvalité vid parprogrammering. Detta har även studenterna själva uttryckt. Studenterna har enat uttryckt en positiv bild av parprogrammering där de framförallt påpekar att det är ett säkrare sätt att utveckla. 1. Inledning Att skriva säker, välfungerande, snabb, läsbar eller helt enkelt högkvalitativ kod är det programmeringsdisciplinen handlar om. När det rör sig om ett stort system blir det snabbt komplext och med ökande tidspress smyger det gärna in fel i koden. En metod som har diskuterats i flera år (sedan 1998 [5]) för att skapa mera högkvalitativ kod är parprogrammering. Denna metod går ut på att två utvecklare sätter sig tillsammans vid en dator och löser uppgifterna tillsammans som en enhet, i motsats till den traditionella metoden, soloprogrammering, där varje utvecklare sitter vid sin egen dator och löser uppgifter var för sig. Det finns flera studier på att parprogrammering ökar kodkvalité [3] men frågan är på hur stor bekostnad av utvecklingshastigheten. Kan parprogrammerare lösa ett problem på halva tiden av vad en soloprogrammerare kan?
Huvudanledningen till att parprogrammering inte används mer i näringslivet är att företag inte finner det ekonomiskt försvarbart att anställa två programmerare för att lösa en uppgift som kan lösas av en programmerare. Är parprogrammering effektivitetsmässigt en fördelaktig utvecklingsmetod? Hur upplevs parprogrammering som utvecklingsmetod bland civilingenjörsstudenter? Skulle de vilja arbeta på detta sättet i rollen som utvecklare? För att svara på ovanstående frågor utfördes intervjuer med en grupp på tolv studenter på kursen Programvaruutveckling I Grupp, där de utbildades i extreme Programming (XP) och parprogrammering. Intervjuerna utfördes enskilt i början på projektet för att respektive student fritt skulle kunna uttrycka sina initiala uppfattningar om parprogrammering. I mitten av projektet utfördes ytterligare en till intervju där de fick berätta mer om sina erfarenheter om parprogrammering under kursen. Intervjuerna visade att både vid första och andra intervjun hade studenterna en mycket positiv bild av parprogrammering. Att studenter har en positiv attityd mot parprogrammering har tidigare konstaterats i [2]. Vissa studenter var mindre positiva till XP processen men när det kom till parprogrammering var de ändå klart positiva. Studenterna upplevde framförallt att det var en ökad trygghet att programmera tillsammans med någon annan. De kunde då lita mera på sin egen kod och fick större förtroende för parets lösningar vilket också konstaterades i [2]. Undersökningen visar att studenter vill ha parprogrammering på sina framtida arbetsplatser, under förutsättningen att de har någon erfarenhet av utvecklingsmetoden. Kapitel 2 beskriver bakgrundskunskapen som behövs för att förstå resten av rapporten. Kapitel 3 tar upp tidigare forskning som finns kring parprogrammering. Mycket av diskussionen handlar om fördelarna med parprogrammering. Kapitel 4 behandlar resultaten från de intervjuer som gjorts. Kapitel 5 tar upp de slutsatser som kan dras med hjälp av resultaten från intervjuerna och den tidigare forskningen som har studerats. Kapitel 6 ger en sammanfattning och tankar kring parprogrammering medans kapitel 7 behandlar svagheter i denna undersökning, vilket skulle kunna vara framtida arbete. 2. Bakgrundsavsnitt 2.1 Parprogrammering Parprogrammering utförs genom att två stycken programmerare paras ihop och tar på sig en uppgift som de löser gemensamt vid en dator. Parprogrammering går ut på att medans en kodar, den så kallade föraren (driver) [6]. Kan den andra personen, navigatören (navigator) [6], konstant granska koden som skrivs men även planera för vad som skall komma. Genom att en person konstant granskar den kod som den andra skriver upptäcks småfel i koden som annars hade varit svårt att hitta för den ensamma utvecklaren. Navigatören tänker även mycket på hur designen som växer fram interagerar med och påverkar resten av systemet och kan hela tiden överväga ifall det finns en bättre lösning. På så sätt uppmanar navigatören föraren att förklara hur denne tänker för att undvika designmissar och på så sätt komma fram till den
bästa designen. Detta kommer också mycket från att de hela tiden kan diskutera igenom alla lösningar de gör eftersom de är två som utvecklar. Föraren och navigatören byter roller hela tiden under utvecklingsfasen. Detta för att hålla en bra utvecklingstakt och personerna får då växla mellan att ha detaljsynen och den övergripande synen. 2.2 extreme Programming extreme Programming [7] eller XP är en agil utvecklingsprocess som innefattar många olika utvecklingsmetoder däribland parprogrammering. Metoden handlar om att vara ett litet ihopknutet arbetslag som utvecklar tillsammans. XP innehåller även en del andra metoder som: Enkel design, som innebär att göra precis den design som behövs för problemet och skapa den minsta möjliga lösningen. Regelbundna releaser görs kontinuerligt under utvecklingen, på detta sättet kan programmet utvärderas regelbundet. Kontinuerlig integration är att alla i utvecklingsgruppen kontinuerligt ska integrera sin kod i kodbasen (repositoryt). Test-driven utveckling, innebär att enhetstester skrivs innan man skriver produktionskoden. Refaktorisering. Handlar om att regelbundet omstrukturera koden och designen. Detta för att koden ska bli bättre och mera lättförstålig. Samma funktionalitet bibehållas av en refaktorisering. Kollektivt kodägande, alla i arbetslaget har rätt att ändra i all kod. T.ex. vid en refaktorisering. Dessa tillsammans med en hel del andra metoder är XP. 3. Tidigare forskning Det finns mycket tidigare forskning kring parprogrammering, där den största delen tillkommit de senaste tio åren [5]. Majoriteten av forskningen är dock genomförd på studenter och behandlar inte hur parprogrammering fungerar i näringslivet på företag. En av de största exemplen från företagsvärlden gällande parprogrammering gjordes på Chrysler med deras Comprehensive Compensation System [3]. Ett löneutbetalningssystem utvecklades för att hantera löneutbetalningen till ca 10 000 anställda. Utvecklandet av programmet led av stora problem i början men efter att projektet startades om och företaget började använda sig av utvecklingsprocessen XP gjordes stora framsteg. Dessa framsteg tillskrevs mestadels parprogrammering då t.ex. nästan de enda felen som lyckades ta sig igenom enhetstester och funktionstester var skrivna av soloprogrammerare.
3.1 Effektivitet En av de största anledningarna till att inte flera företag använder sig av parprogrammering är att utvecklare är en dyr och tidskritisk resurs. Det anses inte ekonomiskt försvarbart att sätta två programmerare på att lösa ett problem som kan lösas av en, speciellt om programmeringsuppgifterna inte anses vara väldigt svåra. Enligt både [1] och [3] är ökningen i utvecklingstid (kostnad i timmar) endast 15% för vana parprogrammerare, alltså långt ifrån antagandet om en ökning på 100% i utvecklingstid. Utvecklingshastigheten är dock inte fullt lika snabb för nya parprogrammerare, en instegsperiod behövs för varje par. Denna ökningen i utvecklingstid på 15% ger i gengäld en ökad kodkvalité som ska överväga kostnaden för den extra tiden som behövs. 3.2 Kodkvalité Den ökade kodkvalitén, som är huvudargumentet för parprogrammering, visas på två väsentliga sätt. Koden som skrivs är generellt kortare än den som är skriven av en ensam utvecklare men framförallt är koden som skrivs av par mer korrekt och stabil. I [1] kommer de fram till att parprogrammerarna skapar kortare program vilket visar på en bättre design jämfört med soloprogrammerare. I alla de rapporter som tog upp kodkvalité, [1] [3] [4] [5], konstaterades det att koden som var producerad av parprogrammerare var av högre kvalité jämfört med den som var producerad av soloprogrammerare. [1] och [3] gjorde kodkvalitétstester genom att koden som producerats av parprogrammerarna och soloprogrammerarna kördes genom en samling testfall. Programmen som var skrivna med hjälp av parprogrammering klarade alltid av en högre andel av testfallen. I [1] framhävs det att utvecklarna som använder sig av parprogrammering producerar 15% (vilket är statistiskt signifikant) mindre fel i sin kod jämfört med soloprogrammerare. Med hjälp av dessa och föregående siffror (15% mindre fel men 15% ökad utvecklingstid för parprogrammerare) skapar de i [1] ett räkneexempel där de jämför utvecklingskostnaden i timmar för ett program skapat av parprogrammerare jämfört med soloprogrammerare. De jämför två fall, antingen hittas de extra introducerade felen (de som är skapade av soloprogrammerarna) först hos kunden eller hos testavdelningen. Så jämförs tiden det skulle ta att hitta och åtgärda felen i jämförelse med den extra tiden som parprogrammering kräver. Om de skulle hittas först hos kunden skulle kostnaden för felen vara 60 gånger högre än den extra utvecklingstiden som skulle behövts för parprogrammering. I det andra fallet med att de skulle upptäckts av testavdelningen, vilket finns hos de flesta större mjukvaruföretag, skulle kostanden fortfarande vara 15 gånger högre än den extra utvecklingstiden för parprogrammering.
3.3 Motivation och tillfredsställelse Utvecklare säger sig även bli mera motiverade vid parprogrammering än vid soloprogrammering. Enligt [3] beror detta mycket på att en person som parprogrammerar inte vill svika sin partner. Det är också mycket mindre sannolikhet att den ena börjar göra annat som att svara på e-mail eller surfa på internet. I [1] har det visats att en soloprogrammerare som är van vid att arbeta själv kan vara svår att övertyga om att parprogrammering kan vara mer givande. Men då soloprogrammeraren prövat på parprogrammering, övergår han oftast till att föredra det som arbetssätt. De flesta programmerare i undersökningen tyckte det var ett mer givande och roligare sätt att utveckla. Studenter uppskattade speciellt parprogrammering då de tyckte det var mycket roligare och mera tillfredställande jämfört med soloprogrammering enligt både [2] och [4]. I [4] visade de även att studenter som använde sig av parprogrammering för att lösa uppgifter i en kurs hade större sannolikhet att klara av tentamen i kursen. Detta visar att parprogrammering kan ge en ökad förståelse för hur det fungerar när personerna som programmerar alltid har någon att diskutera med. 3.4 Problemlösning I [3] uppmärksammades det vidare att soloprogrammerare frågade mycket mera tekniskt relaterade frågor (ca två till tre gånger mer) än vad parprogrammerarna gjorde. Detta visar mycket på att paren hade större kapacitet till att klara av tekniskt svåra problem själva, och inte behövde söka hjälp utifrån. Paren kunde då också hålla sig produktiva medans soloprogrammeraren var oproduktiv när denne sökte hjälp. 3.5 Spridning av kunskap Genom att jobba tillsammans med personer från olika delar av projektet lär sig varje person mer om hela systemet och blir på så sätt inte bara insatt i en liten del. På det sättet är hela utvecklingsgruppen mycket mer insatt i hela systemet, och det är mer än en person som är insatt i varje del av systemet. Utvecklingsgruppen får då ett högre, vad de kallar truck number i [1], vilket benämner hur många personer gruppen kan bli av med innan det finns en del i systemet som ingen kan, och gruppen blir då svårt hindrade i fortsatt utveckling. Parprogrammerare lär sig inte bara hur systemet fungerar utan lär sig även generella tips och trix från varandra som andra använder sig av när de utvecklar. Olika kunskapsnivåer bland studenter kan påverka deras intryck av parprogrammering. Undersökningen i [2] visar att en kunnig programmerare kan känna sig hämmad av att jobba med en mycket mindre kunnig programmerare. I undersökning [1] å andra sidan har den erfarena utvecklaren uttryckt sig mycket positivt och påpekat att de oerfarna kunnat bidra till
utvecklingen. För mindre kunniga programmerare som jobbar ihop har det visats sig ge en positiv effekt på resultat och på hur roligt det är att utveckla. 4. Undersökningen 4.1 Intervjun Det gjordes en separat undersökning för att verifiera den data och de referenser som använts i djupstudien. Undersökningen var också tänkt att bidra med nya intressanta diskussionpunkter som kunde undersökas närmare i framtiden. Målet med undersökningen var att klargöra åsikter kring parprogrammering bland studenter med en programmeringsutbildning och som då sannolikt kommer fortsätta med programmering i sitt yrkesverksamma liv. Undersökningen har utförts på en grupp bestående av tolv studenter som hade som mål att tillsammans utveckla en programvara med hjälp av utvecklingsprocessen XP. Under projektets gång roterades konfigurationen av paren generöst för upprätthålla god kommunikation och jämn distribution av kunskap mellan studenterna. Det utfördes två individuella intervjusessioner med alla studenter: en i början och en i mitten av projektet. Detta för att få bekräftelse på trender och konsekventa åsikter kring parprogrammering bland studenterna. I resultaten fann vi att det inte var lönt att bidra med kvantitativa mått eftersom vi endast hade 12 stundenter med i undersökningen. Det är dock tillräckligt för att kunna fastställa trender i åsikter kring parprogrammering som lyfts fram när det introduceras till studenter. Ur intervjufrågorna har det valts ut ett par citat från svaren som representerar medianen av de svar som gavs av studenterna. Dessa svar kan utläsas i Tabell 1 i nästa kapitel. Frågorna som ställdes vid första intervjun var följande. 1. Tror du att det blir jobbigt att arbeta tillsammans med någon som har mycket mer eller mindre erfarenhet inom programmering?. 2. Hur bra anser du dig att vara på att samarbeta? 3. Hur ser du på metoden att parprogrammera? Frågorna som ställdes vid andra intervjun var följande. 4. Var det jobbigt att arbeta tillsammans med någon som har mycket _mer_ erfarenhet inom programmering? 5. Var det jobbigt att arbeta tillsammans med någon som har mycket _mindre_ erfarenhet inom programmering? 6. Hur ser du på metoden att parprogrammera? 7. Syn på parprogrammering, skulle du vilja jobba på detta sättet i arbetslivet? 8. Hade du varit mera produktiv om du fått arbeta själv?
4.2 Resultat Fråga: Typsvar 1: Typsvar 2: 1 Känner ett vettigt utbyte oberoende av delad kunskapsnivå Kan vara frustrerande att jobba ihop med en mindre kunnig, men känner ett vettigt utbyte om den andra kan mer. 2 Har samarbetat mycket Bra på sammanbeta 3 Har sina för och nackdelar, Gillar idén med att det finns ett par ögon extra som håller koll på koden och vad som behövs göras. Reflektionen sins i mellan är också mycket givande. 4 Känner att det är bra utbyte av kunskap. 5 Kul att få någon annan att förstå och lära ut. Man för bättre insikt i det man gör när man förklarar vad man själv gör. 6 När man fastnar kan oftast den andre hjälpa en Det krävs att båda kan samarbeta på hög nivå, mycket kommunikation Inga problem, var viktigt att se till så att man hänger med hela tiden. När någon frågar måste man tänka igenom vad man gjort Funkar bra, mindre fel och ful kod 7 Ja Ja, speciellt i början av en anställning. För att sätta in sig i projektet för att enklare kunna bilda sig en uppfattning 8 Antal rader/minut varit bättre men mycket flera fel och fulare kod Tabell 1. Två olika typsvar på intervjufrågorna. Delar som man kan går bra själv, men så fort man kommer in på osäkra områden har det gått bättre som ett par Fråga 1, 4, 5 Det fanns en klar uppdelning i svaren på fråga ett. En delmängd av studenterna fann det i allmänhet svårt att arbeta med andra, och resterande studenter hade inga problem med det alls. Det fanns två olika typiska svar till denna frågan Känner ett vettigt utbyte oberoende av delad kunskapsnivå och Kan vara frustrerande att jobba ihop med en mindre kunnig, men känner ett vettigt utbyte om den andra kan mer. Under kursens gång verkade dock denna uppdelning av åsikter skifta mot det mer positiva, och när frågan sedan följdes upp i intervju 2, svarade de flesta att det inte var något problem med sammarbete, att det till och med var Bra att få
veta hur de [kollegan] tänker. De fastslog även att Inom olika områden kan man komplettera varandras kundskap. Fråga 2 Ur svaren till intervjufråga 2 i början av projektet fastställdes att det fanns en majoritet av stundenter som kände sig produktiva och hjälpsamma med att jobba med andra. Ur svaren kunde vi dock inte fastställa hurvida studenterna föredrog att jobba som par eller enskilt. Det var inte förrän efter ett par iterationer som studenterna blev mer säkra på vad de föredrog. Fråga 3, 6 I intervjufråga 3 var det en klyvning mellan studenterna som betonade de positiva och negativa synerna på parprogrammering. Den positiva delen hade typiska kommentarer som Känns bra att kunna verifiera med den andra och Hjälper en att reflektera. Den negativa delen hade många som kände att det skulle krävas en hög nivå av kommunikation för att parprogrammering skulle kunna fungera och att det var svårt att parprogrammera i början. Efter ett par iterationer så betonade nästan alla studenterna i intervjufråga 6 istället de mera positiva aspekterna i parprogrammering med kommentarer som När man fastnar kan oftast den andre hjälpa en och Funkar bra, mindre fel och ful kod. Studenterna lade ofta till i sina kommentarer att det fanns en kompletterande förkunskap för att lösa uppgiften de fått. Fråga 7 På frågan (intervjufråga 7) om de hade velat ha parprogrammering på deras arbetsplats så svarade de flesta studenterna ett klart Ja. Ungefär en femtedel kommenterade också att de framförallt skulle vilja ha det i början på sin anställning eller i början på ett nytt projekt. Fråga 8 I intervjufråga 8 så var ett typiskt svar från studenterna Hade kanske producerat mer kod men koden hade inte blivit lika effektiv och felsäker och Delar som man kan går bra själv, men så fort man kommer in på osäkra områden hade det gått bättre som ett par. 5. Slutsatser Resultaten från intervjufråga 1, 4 och 5 kan jämföras med några av slutsatserna i [2] och [4] vilka visar att studenter generellt uppskattar parprogrammeringsmetodiken. Intervjuerna stödjer också mer det Cockburn kommit fram till än i [2] gällande utvecklare med olika kunskapsnivå. Då de i intervjuerna påpekar att de även har utbyte av partnerskapen även vid olik kunskapsnivå. Sammanställning av intervjufråga 2 och 8 visade att en majoritet av studenterna tyckte att de producerade mera kod själva men när det kom till att producera bra kod så var parprogrammering ett bättre sätt att utveckla, detta överensstämmer med tidigare forskningar. Ytterligare från intervjufråga 2 och 8 ser man att det blev mycket roligare utvecklingsmiljö för programmerarna, vilket i sig är positivt.
Efter att paren hade fått jobba ihop ett tag började de positiva delarna av parprogrammering komma fram. Undersökningen visade att studenterna gillade att ha en granskare bredvid sig som kunde säga till att koden höll god kvalitet. Då föraren fastnade kunde navigatören omedelbart hjälpa till med att reflektera kring problemet. Det finns många goda skäl till varför företag bör införa parprogrammering på sin arbetsplats. En anledning som vår undersökning kan visa är att programmerare som har erfarenhet av parprogrammering gärna skulle vilja ha det på sin arbetsplats, men även att programmerarna känner sig säkrare och själva säger att de producerar mer korrekt och bättre kod. Tidigare forskning har visat att ökningen i utvecklingstid som parprogrammering ger kompenserar det i en ökad kodkvalité som ska överväga kostnaden för den extra tiden som behövs för utvecklingen av en mjukvara. Detta är i sig nog för att införa det på en arbetsplats i företag. Om företaget redan har en mycket godartad utveklingsprocess som är svår att förbättra så kan det vara mindre lönt att införa parprogrammering. 6. Sammanfattning Det finns forskning som tydligt visar de märkbara fördelarna med parprogrammering. Utvecklare verkar också i stor grad uppskatta att arbeta enligt parprogrammeringsmetoden. Därför hoppas vi att parprogrammering sprider sig mer i näringslivet. Eftersom parprogrammering är ett uppskattat arbetssätt av utvecklare. Både för att de känner sig mera säkra i sina lösningar men framförallt för att de tycker det är ett roligare utvecklingssätt. Detta borde vara en tydlig indikation till företag att parprogrammering är värt att satsa på. Framförallt för att företag vill behålla sina anställda då utvecklare kan vara en svårersättlig resurs. De har mycket kunskap om systemet de arbetar med, är dyra att ersätta i form av förlorad arbetstid och det kostar mycket att sätta in nyanställda i pågående projekt. Vår förhoppning är att parprogrammering kommer spridas till flera företag. Då många verkar gilla detta som utvecklingssätt och en högre kvalité på koden, Särskilt när fler nyutbildade personer kommer ut i arbetslivet med en positiv bild av och kunskap om parprogrammering. Från det vi har skrivit ser det ut som om detta borde införas i alla företag världen över. Det kan dock finnas fall där parprogrammering inte kommer ge lika verkande effekt. Detta beror på hur företaget har lagt upp sin utvecklingsprocess. Om företaget har en välintegrerad och bra process för kodgranskning kan de positiva effekterna som parprogrammering bidrar med bli mindre betydande. Koden granskas hela tiden av navigatören och de flesta av felen upptäckas ändå. Detta orsakar att den separata kodgranskningsfasen blir då redundant. Eftersom kodgranskningsfasen redan är välintegrerad i företagets utvecklingsprocess blir det parprogrammering som är redundant. Därav inte lönt att införa.
7. Vidare Undersökningar Den andra intervjun hölls redan i mitten av projektet. Detta på grund av att denna rapport var tvungen att vara färdig innan utvecklingsprojektet som intervjuerna utfördes hos var slut. Svaren från de intervjuade kanske hade varit annorlunda om de fått parprogrammera till slutet på projektet. En sådan här undersökning skulle kunna vidare förstärkas om man gör det på en större skala. Detta hade kunnat ge en mer kvantitativ mätning på åsikter kring parprogrammering. Flera undersökningar där de jämför parprogrammering mot soloprogrammering med en separat kodgranskning. Både i kvalité men även hur de två olika metoderna påverkar totaltkostanden för utvecklingen. Resultatet från dessa undersökningar bör kopplas med frågan om parprogrammering är bra att införa i företagets utvecklingsprocess. Vi tror att en studie som behandlar kvantitativa mätningar på ett företags utvecklingsprocess som kan avgöra om det är lönt att införa parprogrammering eller ej. Detta tror vi hade kunnat ge ett stort mot argument till företag som tycker att deras utvecklingsprocess är unik och bra nog för att inte behöva införa det. 8. Tack till Ett självklart tack till Team09 (läsår 2010-2011) för att ni ställde upp på våra frågor. Tack till granskarna (Christian Holmgren, Sara Nilsson och Lars-Olof Rydgren) för bidragande kommentarer till denna rapport. Tack till Vanja Maslo för språklig granskning av rapporten. 9. Referenser 1. Cockburn A, Williams L. The Costs and Benefits of Pair Programming, in Extreme Programming Examined, in Addison Wesley- Longman, (2001). 2. Thomas L, Ratcliffe M, Robertson A. Code warriors and code-a-phobes: a study in attitude and pair programming. SIGCSE Bull. 35, 1. (2003). 3. Williams L, Kessler R.R, Cunningham, Jeffries R. Strengthening the case for pair programming, in Software, IEEE. 17, 4. Sidorna 19-25. (2000). 4. McDowell C, Werner L, Bullock H, Fernald J, The Impact of Pair Programming
on Student Performance of Computer Science Related Majors, 25th International Conference on Software Engineering 2003, Portland, OR, (2003). 5. Dybå T, Arisholm E, Sjoberg D.I.K, Hannay J.E, Shull F. Are Two Heads Better than One? On the Effectiveness of Pair Programming. In Software, IEEE. 24, 6. Sidorna 12-15. (2007). 6. chromatic. Extreme Programming Pocket Guide. O'Reilly 2003. ISBN: 0-596-00485-0 7. Beck K. Embracing change with extreme programming. In Computer, IEEE, 1999, 32, 10. Sidorna 70-77.