eXtreme Programming – nytænkning eller anarki ?

eXtreme Programming – nytænkning eller anarki ?
maj 2003 eXtreme Programming – nytænkning eller anarki ? Captator Tlf: Carsten Juel Andersen Softwarearkitekt Mobil: maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Agenda Motivationen bag eXtreme Programming Fra fastpris- til variabel funktionalitets-projekt eXtreme Programming XP navnet, XP’s værdier De 12 XP praktikker Et XP projekts livscyklus Referencer maj 2003 eXtreme Programming – nytænkning eller anarki ?

Motivationen bag eXtreme Programmering
eXtreme Programming – nytænkning eller anarki ? maj 2003 Motivationen bag eXtreme Programmering maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Hvorfor XP ? Overskridelse af budgetter Planen skrider For dårlig kvalitet Umuligt at opdatere hen ad vejen For høj fejlrate ved frigivelse Ikke hvad der var brug for Misforståede specifikationer Forældede specifikationer Mange forkerte features For stor udskiftning i medarbejderstaben Projektet må opgives undervejs maj 2003 eXtreme Programming – nytænkning eller anarki ?

Simpelt design kontra up-front design
eXtreme Programming – nytænkning eller anarki ? maj 2003 Simpelt design kontra up-front design Omkostningerne ved fejl stiger eksponentielt med tiden, hvor fejlen dentificeres Dette har medført vægt på omfattende kravspecs, analyse- og designdokumentation Projekter skrider stadig pga. ændringer i specs etc. I XP forsøger vi at udjævne denne kurve Så behøver vi ikke lave så hæftigt et forarbejde Simpelt design: Designet skal på simpelst mulig vis afspejle de implementerede funktioner ! maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Det skal være sjovt ... Recognizing that the cost of changing a program no longer grows exponentially over time, XP relies on the complex interaction between simple development practices to reduce project risk, improve responsiveness to business and technical learning, and make programming fun. Kent Beck & Ward Cunningham maj 2003 eXtreme Programming – nytænkning eller anarki ?

Fra fastpris- til variabel funktionalitets-projekt
eXtreme Programming – nytænkning eller anarki ? maj 2003 Fra fastpris- til variabel funktionalitets-projekt maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Et projekts 4 variable Omfang Hvilken funktionalitet skal systemet indeholde ? Pris Hvad skal det koste, og dermed indirekte hvor mange projektdeltagere ? Tid Hvornår skal systemet releases ? Kvalitet Hvilke kvalitetskrav er der til systemet ? Omfang Kvalitet Pris Tid maj 2003 eXtreme Programming – nytænkning eller anarki ?

De 4 variable i et fastpris projekt
eXtreme Programming – nytænkning eller anarki ? maj 2003 De 4 variable i et fastpris projekt Fastlås omfang, pris og tid ud fra en kravspecifikation Der er klare linier Leverandøren ved, hvad der skal leveres Kunden kender prisen, tidspunktet og hvad der leveres Men går det altid godt ? Omfang Kvalitet Pris Tid maj 2003 eXtreme Programming – nytænkning eller anarki ?

De 4 variable i et fastpris projekt
eXtreme Programming – nytænkning eller anarki ? maj 2003 De 4 variable i et fastpris projekt Kvaliteten er ikke låst Det første der skrider Kommer projektet i problemer Så udskydes projektet ofte som første skridt I mange tilfælde kan kunden være låst til leverandøren Øget pris og måske endnu flere udskydelser af projektet Omfang Kvalitet Kvalitet Pris Tid Pris Tid maj 2003 eXtreme Programming – nytænkning eller anarki ?

De 4 variable i et XP projekt
eXtreme Programming – nytænkning eller anarki ? maj 2003 De 4 variable i et XP projekt Et XP projekt fastlåser kvalitet, tid og pris og lader omfang være variabelt Omfang tilpasset løbende Løbende (daglig/ugentlig) planlægning tilpasser omfanget til det, der er muligt og det kunden ønsker Omfang Kvalitet Pris Tid maj 2003 eXtreme Programming – nytænkning eller anarki ?

De 4 variable i et XP projekt
eXtreme Programming – nytænkning eller anarki ? maj 2003 De 4 variable i et XP projekt Omfanget Kan blive større eller mindre end det forventede Det er prioriteret udfra kundens ønsker, så det vigtigste vil altid være med! Men der leveres altid til den givne tid, kvalitet og pris Omfang / Omfang Kvalitet Pris Tid maj 2003 eXtreme Programming – nytænkning eller anarki ?

XP navnet og XP’s værdier
eXtreme Programming – nytænkning eller anarki ? maj 2003 XP navnet og XP’s værdier maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Hvorfor hedder XP XP ? Med udgangspunkt i koden koden er det vigtigste produkt Med fokus på konstant projektstyring Med udgangspunkt i sunde sw disipliner lad os gøre det 100 % maj 2003 eXtreme Programming – nytænkning eller anarki ?

Værdierne som XP værdsætter
eXtreme Programming – nytænkning eller anarki ? maj 2003 Værdierne som XP værdsætter Kommunikation Mangel på samme er ofte en fejlkilde XP er en team-process med konstant kommunikation Enkelthed design ikke for imorgen, men kun for idag Feedback Optimisme er en fare, feedback er medicinen :-) MOD Frygt ikke følgefejl, men hav mod til at turde lave ændringer ! maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 De 12 XP praktikker maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 De 12 XP praktikker Simpelt design Refaktorering Test Programmering Metafor Kode standarder Kort tid mellem releases Kollektivt ejerskab Fortløbende integration Programmering i par 37-timers arbejdsuge Team praktikker Kunde involvering ”The Planning Game” Kort tid mellem releases Test Proces maj 2003 eXtreme Programming – nytænkning eller anarki ?

Programmerings praktikkerne
eXtreme Programming – nytænkning eller anarki ? maj 2003 Programmerings praktikkerne Simpelt design Refaktorering Test Programmering Metafor Kode standarder Kort tid mellem releases Kollektivt ejerskab Fortløbende integration Programmering i par 37-timers arbejdsuge Team praktikker Kunde involvering ”The Planning Game” Kort tid mellem releases Test Proces maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Simpelt design Forbered aldrig noget for i morgen, men arbejd kun for idag Lav det til enhver tid simpleste mulige, der kan virke En af de mest ”provokerende” regler i XP Vi har altid lært at man skal gøre forarbejdet grundigt, Simpelt design er et opgør med dette Simpelt design indebærer i sin yderste konsekvens Selvom du ved du vil få brug for en feature i morgen, så skal du ikke lave noget af denne funktionalitet i dag, medmindre det er en del af den funktionalitet du er igang med lige nu ! maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Refactorering Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after is has been written Martin Fowler ... eller sagt lidt kortere refactoring (restrukturering) er rettelser i et program, der ikke ændrer funktionaliteten, men kun tjener til af forbedre designet maj 2003 eXtreme Programming – nytænkning eller anarki ?

Eksempel – Extract Method
eXtreme Programming – nytænkning eller anarki ? maj 2003 Eksempel – Extract Method En af de simpleste og hyppigst anvendte refactoreringer er Extract Method Motiv Der er et kode fragment, der kan grupperes Løsning Lav fragmentet til en metode, hvis navn forklarer hvad formålet med kode fragmentet er void printOwning(double amount) { printBanner(); printDetails(amount); } void printDetails(double amount) { System.out.println(“name :” + _name); System.out.println(“amount:” + amount); void printOwning(double amount) { printBanner(); // print details System.out.println(“name :” + _name); System.out.println(“amount:” + amount); } maj 2003 eXtreme Programming – nytænkning eller anarki ?

Refaktorerings katalog
eXtreme Programming – nytænkning eller anarki ? maj 2003 Refaktorerings katalog “Refactoring – Improving the Design of Existing Code” beskriver et katalog af 72 refaktoreringer Der er beskrevet et motiv og en løsning for hver Ofte går en refaktorering begge veje alt efter omstændighederne ex: Pull Up Field kontra Push Down Field Eksempler fra bogen Collapse Hierarchy, Encapsulate Field, Extract Class, Inline Class, Introduce Assertion, Introduce Null Object, Move Field, Move Method, Pull Up Field, Push Down Field, Replace Constructor with Factory Method, Replace Inheritance with Delegation, Replace Magic Number with Symbolic Constant maj 2003 eXtreme Programming – nytænkning eller anarki ?

Hvornår skal man refaktorere ?
eXtreme Programming – nytænkning eller anarki ? maj 2003 Hvornår skal man refaktorere ? Når koden lugter ! (bad smell), som ex. Duplikeret kode Lange metoder Store klasser Lange parameter lister Divergerende ændringer (klasse er blevet ændret mange gange med forskellig fokus) Haglgeværskirurgi (en rettelse = ændringer mange steder) Switch statements Doven klasse Spekulativ generalisering Mellemmand maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Unit tests XP’s regel for unit tests Dette giver sikkerhed, tiltro til ens kode og MOD til at lave ændringer i designet ! Enhver funktionalitet uden test eksisterer ikke ... maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Unit tests Udviklerne skriver unit tests (hele tiden) En automatisk unit test skrives før funktionen Hvis et interface til en metode er uklart Hvis interfacet er indlysende, men implementationen formodes (lidt) indviklet Hvis der er en usædvanlig måde at benytte metoden på (testen kommunikerer så denne brug af metoden) En automatisk unit test skrives senere Når der findes en fejl isoleres den i en test Ved refactoreringer af et område der ikke har tilstrækkelige tests Alle disse tests skal kunne afvikles automatisk i løbet af nogle ganske få minutter maj 2003 eXtreme Programming – nytænkning eller anarki ?

Junit/NUnit/XUnit – et testværktøj
eXtreme Programming – nytænkning eller anarki ? maj 2003 Junit/NUnit/XUnit – et testværktøj Keep the bar green to keep the code clean ... Citat fra maj 2003 eXtreme Programming – nytænkning eller anarki ?

Programmerings praktikkerne
eXtreme Programming – nytænkning eller anarki ? maj 2003 Programmerings praktikkerne Simpelt design Refaktorering Test Programmering Metafor Kode standarder Kort tid mellem releases Kollektivt ejerskab Fortløbende integration Programmering i par 37-timers arbejdsuge Team praktikker Kunde involvering ”The Planning Game” Kort tid mellem releases Test Proces maj 2003 eXtreme Programming – nytænkning eller anarki ?

En dag i et XP projekts ”liv”
eXtreme Programming – nytænkning eller anarki ? maj 2003 En dag i et XP projekts ”liv” En normal projektdag Morgenmøde Den enkelte “teamer op” med en kollega 2 arbejdsrunder pr. dag Den ansvarlige for det givne task foretager integrationen maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Programmering i par Alt produktionskode (og unit tests) skrives i par ! Programmering i par er to programmører, der begge er engagerede, og hjælper hinanden mod et fælles mål Par programmering giver bedre vidensdeling indenfor projektteamet hurtigere oplæring af nye medarbejdere Nedsat produktivitetstab, når en medarbejder forlader teamet maj 2003 eXtreme Programming – nytænkning eller anarki ?

Parprogrammering i praksis
eXtreme Programming – nytænkning eller anarki ? maj 2003 Parprogrammering i praksis En udvikler har et task, der skal laves Han beder om hjælp hos en anden i teamet De sætter sig sammen ved en computer og går i gang med programmeringen. Cyklus for dette er design, skriv test, kod, afprøv test, skriv ny test, kod ... integrer Rollerne i parret Den der har tastaturet arbejder på test/kode Den anden har fokus på: om det vil fungere om der er testcases, der burde skrives om koden “lugter” (trænger til refactoring) Rollerne kan byttes vilkårligt maj 2003 eXtreme Programming – nytænkning eller anarki ?

Fortløbende integration
eXtreme Programming – nytænkning eller anarki ? maj 2003 Fortløbende integration Når en programmeringsopgave afsluttes Sætter den taskansvarlige sig ved integrationsmaskinen Det sikrer at check-in serialiseres Det checkes på en “clean” maskine Herefter testes rettelserne og rettelsen checkes ind i versionssystemet Clean maskine Nyeste version hentes ud fra versionsstyringssystemet Egne rettelser lægges ind på maskinen Compiler og afvikl’ alle unittests - skal give grønt lys Rettelserne checkes ind i versionsstyringssystemet PAUSE  !! maj 2003 eXtreme Programming – nytænkning eller anarki ?

Fortløbende integration
eXtreme Programming – nytænkning eller anarki ? maj 2003 Fortløbende integration Et task bør ikke tage mere end ½ dag ! Fra man sætter sig sammen til tasket er afsluttet bør der ikke gå mere end ½ dag Herved undgås en masse integrationsproblemer Lykkedes det ikke at afslutte indenfor en ½ dag Kan man tillade sig at smide rettelserne væk og starte forfra – en ½ dags arbejde er jo ikke meget Eller overlade det til andre at lave det givne task maj 2003 eXtreme Programming – nytænkning eller anarki ?

Fortløbende integration – nightly build
eXtreme Programming – nytænkning eller anarki ? maj 2003 Fortløbende integration – nightly build Sørg for at projektet altid kan passere alle tests med grønt lys ! Der findes værktøjer til at lave en fuldautomatisk build og testafvikling Kør den hver nat Få resultatet når I møder på arbejde om morgenen maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Proces praktikkerne Simpelt design Refaktorering Test Programmering Metafor Kode standarder Kort tid mellem releases Kollektivt ejerskab Fortløbende integration Programmering i par 37-timers arbejdsuge Team praktikker Kunde involvering ”The Planning Game” Kort tid mellem releases Test Proces maj 2003 eXtreme Programming – nytænkning eller anarki ?

Kunde involvering ”on site customer”
eXtreme Programming – nytænkning eller anarki ? maj 2003 Kunde involvering ”on site customer” Der skal være en kunde tilstede blandt udvikler teamet Kundens ansvar Vurdere og prioritere “Stories” løbende Afklare alle tvivlstilfælde overfor udviklerne Skrive releasetest specifikationer Et XP projekt bygger på tillid og indbyrdes forståelse mellem kunde og leverandør maj 2003 eXtreme Programming – nytænkning eller anarki ?

Kort tid mellem releases
eXtreme Programming – nytænkning eller anarki ? maj 2003 Kort tid mellem releases I XP tilstræbes der mod kort tid mellem releases Kunden får noget værdifuldt tidligt Udviklerne får værdifuld feedback fra et system i drift Den anbefalede længde er 3 måneder Mulig modstand mod korte releases: “Men jeg kan umuligt dele mit system op i releases – det er alt eller intet” Er det et legacy system der skal erstattes, så start med kun at erstatte en lille del (og skriv wrappere mellem det nye og det eksisterende system) Der er stort set altid en “udvej” – det er blot et spørgsmål om at være kreativ :-) maj 2003 eXtreme Programming – nytænkning eller anarki ?

Planlægningsfilosofi i XP
eXtreme Programming – nytænkning eller anarki ? maj 2003 Planlægningsfilosofi i XP En plan er kun et bud på forløbet af resten af projektet idet vi har lavet planen ved vi allerede at det med garanti ikke vil være sådan det forløber ”Yesterdays weather” Planen afspejler fremtiden, men den baserer sig på projektets fremdrift i fortiden (den foregående iteration) Hele forløbet planlægges overordnet, kun den kommende iteration er detailplanlagt Estimaterne foretages af dem, der skal føre de enkelte dele ud i livet Overordnede plan estimeres af udviklerne i fællesskab De enkelte tasks estimeres af den ansvarlige udvikler maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Release planlægning Formål At planlægge perioden frem til næste release, således at kunden opnår mest muligt Resultat Et sæt af stories, der beskriver funktioner i systemet og deres estimat Hele projektgruppen og kunden samles Kunden bestemmer Omfang (scope) Prioritet Release datoer Udviklerne bestemmer Estimater Konsekvenser Den detaljeret planlægning maj 2003 eXtreme Programming – nytænkning eller anarki ?

Release planlægning - Story Card
eXtreme Programming – nytænkning eller anarki ? maj 2003 Release planlægning - Story Card En historie (Story) - er skrevet på et kartotekskort, hvorpå der står en overskrift på den givne historie et estimat samt eventuelle yderligere kommentarer, som var vigtige for kunden eller udviklererne i det, den blev påført kortet En historie er ikke en fuldkommen specifikation, men blot et løfte om en senere samtale mellem kunde og udvikler om hvad denne historie indebærer maj 2003 eXtreme Programming – nytænkning eller anarki ?

Release planlægning - points
eXtreme Programming – nytænkning eller anarki ? maj 2003 Release planlægning - points Hver historie estimeres efter et pointsystem Et point = en effektiv mandeuge Der kan gives 1, 1.5, 2, 2.5 og 3 points En historie må aldrig være større en 3 points så skal den splittes til mindre historier En historie kan ikke være mindre end 1 point klips flere små historier sammen til 1 historie så den opnår 1 point til sammen maj 2003 eXtreme Programming – nytænkning eller anarki ?

Release planlægning - omfang
eXtreme Programming – nytænkning eller anarki ? maj 2003 Release planlægning - omfang Med de givne estimater kan man herefter udregne den nødvendige projektudstrækning antal iteration af (normalt) 3 ugers udstrækning antalIterationer = pointSum / projekthastighed Projekthastigheden (velocity) bestemmes udfra følgende Ved starten på projekt (1. iteration) - 1 point pr. udvikler efterfølgende - antal points nået i foregående iteration maj 2003 eXtreme Programming – nytænkning eller anarki ?

Release planlægning - resultat
eXtreme Programming – nytænkning eller anarki ? maj 2003 Release planlægning - resultat Resultat af release planlægning er 3 stakke af kort 1 stak til første iteration 1 stak til øvrige historier i denne release 1 stak til alle de andre historier Nu ved vi: Hvad der er med i første release og hvornår projektet er færdigt (selvom vi godt ved det ikke holder i længden ... :-) Dette er bedre en et gantkort hvor detaljeringen har en tendens til at forplumre billedet R R R R R R maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 De 12 XP praktikker Simpelt design Refaktorering Test Programmering Metafor Kode standarder Kort tid mellem releases Kollektivt ejerskab Fortløbende integration Programmering i par 37-timers arbejdsuge Team praktikker Kunde involvering ”The Planning Game” Kort tid mellem releases Test Proces maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Spørgsmål nyheder, artikler, information, ... maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Referencer til bøger og websteder om XP maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Artikler om XP Chrysler Goes to Extremes Distributed Computing, oktober Embracing change with Extreme Programming Kent Beck, IEEE Computer, Oktober 1999 Extreme Programming: Flatten the change-cost curve by using XP in project planning and testing Kent Beck, C++ Report, May 1999, pp , 44. Experiences in Applying Extreme Programming to a Java-Based Project Fred George, Rob Billington Erfaringsindlæg fra OOPSLA’99 maj 2003 eXtreme Programming – nytænkning eller anarki ?

Junit / XUnit referencer
eXtreme Programming – nytænkning eller anarki ? maj 2003 Junit / XUnit referencer Extreme Testing Ron Jeffries, Software Testing & Quality Engineering, V1I2, March/April 1999, pp , Simple Smalltalk Testing: With Patterns Kent Beck, original artikel om XP test. JUNIT: A Cook’s Tour Erich Gamma & Kent Beck; Java Report, Maj 1999 XP test framework for Java (JUnit) og .NET (NUnit) Andre XUnit frameworks maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Web XP ressourcer Ward Cunninghams Wiki om XP Ron Jeffries XP site Don Wells XP site Martin Fowler Agile Alliance maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Bøgerne i XP serien Extreme Programming Explained Kent Beck; ISBN Den oprindelige bog om XP skrevet af idemanden bag: Kent Beck. Bogen gennemgå de grundlæggende elementer af XP og forsøger at give en baggrund for hvorfor de enkelte dele af XP er vigtige. Planning Extreme Programming Kent Beck, Martin Fowler; ISBN Bogen om “the planning game”. Her beskrives dette ene princip i XP til bunds. Mange af delene af planlægning kan benyttes også uden at benytte de øvrige XP principper. En god bog hvis man vil vide mere om at planlægge og styre sine projekter. Extreme Programming Installed Ron Jeffries, Ann Anderson, Chet Hendrickson; ISBN Fra 3 af de oprindelige C3 projektdeltagere/konsulenter er her bogen, der prøver at give en mere grunding praktisk indgang til de enkelte XP principper. maj 2003 eXtreme Programming – nytænkning eller anarki ?

maj 2003 Bøgerne i XP serien Extreme Programming Examined Giancarlo Succi, Michele Marchesi; ISBN I maj 2000 blev den første konference om XP afholdt på Sardinien, Italien. Denne bog er de redigerede “conference proceedings”. Den indeholder alle de bedste artikler fra konferencen. Extreme Programming Explored William C. Wake; ISBN Herfra er opdelingen af de enkelte praktikker i 3 kategorier: Programmering, Team praktikker og process hentet. Bogen holder sig til at beskrive praktikkerne. Den giver også nogle gode råd på hvilke praktikker, der kan benyttes selvom man ikke ønsker en 100% XP process. Der er flere bøger i denne serie, men der er (for) meget overlap mellem dem til at jeg vil anbefale nogle af dem maj 2003 eXtreme Programming – nytænkning eller anarki ?

Bøger om XP og beslægtede metoder
eXtreme Programming – nytænkning eller anarki ? maj 2003 Bøger om XP og beslægtede metoder Refactoring: Improving the Design of Existing Code Martin Fowler, Kent Beck m.fl.; ISBN Dette er en utrolig god bog om disiplinen Refactoring. Den indeholder en længere introduktion om hvad refaktorering er, men den vigtigste del er et katalog af refaktoreringer. Her er beskrevet fordele og ulemper ved de enkelte løsninger. Ofte kan en refaktorering gå begge veje, i nogle tilfælde er en løsning bedste - i andre den modsatte. Dette katalog giver gode regler for hvornår man bør bruge det ene, og hvornår man bør benytte det andet. Surviving Object-Oriented Projects Alistair Cockburn; ISBN En bog om Alistair Cockburn’s egen familie af letvægts metoder: Crystal. Bogen beskriver også en række projekter. Vil man vide noget om hvad der gør et oo-projekt sucessfuldt, og hvad der får det til af fejle er dette en god bog at læse. Alistair Cockburn er også en af dem der gennem de senere år har slået hårdt på at det er det personlige aspekt, der udgår den største del af et projekts success. Det er i god tråd med XP’s filosofi. maj 2003 eXtreme Programming – nytænkning eller anarki ?

Bøger om XP og beslægtede metoder
eXtreme Programming – nytænkning eller anarki ? maj 2003 Bøger om XP og beslægtede metoder The Pragmatic Programmer Andrew Hunt, David Thomas; ISBN X Hvordan bliver man en bedre programmør? Ved at læse denne bog! Bogen giver en masse råd - lidt al’a XP’s principper - om hvordan man kan blive en bedre programmør. Denne bog er også for den enkelte, dvs. at man kan bruge mange af rådene herfra uden nødvendigvis at skulle overbevise alle man arbejder sammen med for at kunne bruge dem. maj 2003 eXtreme Programming – nytænkning eller anarki ?

eXtreme Programming – nytænkning eller anarki ?

Lignende præsentationer

Præsentationer af emnet: "eXtreme Programming – nytænkning eller anarki ?"— Præsentationens transcript:

Lignende præsentationer

Om projektet

Feedback

Log ind

Logge ind via sociale netværk:

eXtreme Programming – nytænkning eller anarki ?

Lignende præsentationer

Præsentationer af emnet: "eXtreme Programming – nytænkning eller anarki ?"— Præsentationens transcript:

Lignende præsentationer

Om projektet

Feedback