e Xtreme Programming nytnkning eller anarki Captator Tlf

e. Xtreme Programming – nytænkning eller anarki ? Captator Tlf: 8748 0202 www. captator. dk Carsten Juel Andersen Softwarearkitekt juel@captator. dk Mobil: 2348 0003 maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 1

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

Motivationen bag e. Xtreme Programmering maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 3

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 e. Xtreme Programming – nytænkning eller anarki ? 4

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 e. Xtreme Programming – nytænkning eller anarki ? 5

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 e. Xtreme Programming – nytænkning eller anarki ? 6

Fra fastpris- til variabel funktionalitets-projekt maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 7

Et projekts 4 variable Omfang Kvalitet Pris maj 2003 Tid 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 ? e. Xtreme Programming – nytænkning eller anarki ? 8

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

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

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 Kvalitet Pris maj 2003 Tid Løbende (daglig/ugentlig) planlægning tilpasser omfanget til det, der er muligt og det kunden ønsker e. Xtreme Programming – nytænkning eller anarki ? 11

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! / Omfang Kvalitet Pris maj 2003 Tid Men der leveres altid til den givne tid, kvalitet og pris e. Xtreme Programming – nytænkning eller anarki ? 12

XP navnet og XP’s værdier maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 13

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

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 e. Xtreme Programming – nytænkning eller anarki ? 15

De 12 XP praktikker maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 16

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

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

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 e. Xtreme Programming – nytænkning eller anarki ? 19

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 e. Xtreme Programming – nytænkning eller anarki ? 20

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 print. Owning(double amount) { print. Banner(); print. Details(amount); } // print details System. out. println(“name : ” + _name); void print. Details(double amount) { System. out. println(“amount: ” + amount); System. out. println(“name } : ” + _name); System. out. println(“amount: ” + amount); } maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 21

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 e. Xtreme Programming – nytænkning eller anarki ? 22

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 e. Xtreme Programming – nytænkning eller anarki ? 23

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

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 e. Xtreme Programming – nytænkning eller anarki ? 25

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

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

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 e. Xtreme Programming – nytænkning eller anarki ? 28

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 e. Xtreme Programming – nytænkning eller anarki ? 29

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 e. Xtreme Programming – nytænkning eller anarki ? 30

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 1. 2. 3. 4. 5. 6. maj 2003 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 !! e. Xtreme Programming – nytænkning eller anarki ? 31

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 e. Xtreme Programming – nytænkning eller anarki ? 32

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 e. Xtreme Programming – nytænkning eller anarki ? 33

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

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

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 e. Xtreme Programming – nytænkning eller anarki ? 36

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 e. Xtreme Programming – nytænkning eller anarki ? 37

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 maj 2003 Udviklerne bestemmer • Estimater • Konsekvenser • Den detaljeret planlægning e. Xtreme Programming – nytænkning eller anarki ? 38

Release planlægning - Story Card 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 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 maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 39

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 e. Xtreme Programming – nytænkning eller anarki ? 40

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 antal. Iterationer = point. Sum / 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 e. Xtreme Programming – nytænkning eller anarki ? 41

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 R R R 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 maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 42

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

Spørgsmål www. captator. dk nyheder, artikler, information, . . . maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 44

Referencer til bøger og websteder om XP maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 45

Artikler om XP Chrysler Goes to Extremes Distributed Computing, oktober 1998 http: //www. Distributed. Computing. com 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. 26 -29, 44. http: //archive. creport. com/9905/html/from_pages/feature. shtml Experiences in Applying Extreme Programming to a Java. Based Project Fred George, Rob Billington Erfaringsindlæg fra OOPSLA’ 99 maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 46

Junit / XUnit referencer Extreme Testing Ron Jeffries, Software Testing & Quality Engineering, V 1 I 2, March/April 1999, pp 22 -27. , http: //www. xprogramming. com/software_testing. htm Simple Smalltalk Testing: With Patterns Kent Beck, original artikel om XP test. http: //www. xprogramming. com/testfram. htm JUNIT: A Cook’s Tour Erich Gamma & Kent Beck; Java Report, Maj 1999 XP test framework for Java (JUnit) og. NET (NUnit) http: //www. junit. org, http: //www. nunit. org Andre XUnit frameworks http: //www. xprogramming. com/software. htm maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 47

Web XP ressourcer Ward Cunninghams Wiki om XP http: //c 2. com/cgi/wiki? Extreme. Programming. Roadmap Ron Jeffries XP site http: //www. xprogramming. com Don Wells XP site http: //www. extremeprogramming. org Martin Fowler http: //martinfowler. com Agile Alliance http: //www. agilealliance. org maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 48

Bøgerne i XP serien Extreme Programming Explained Kent Beck; ISBN 0 -201 -61641 -6 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 0 -201 -71091 -9 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 0 -201 -70842 -6 Fra 3 af de oprindelige C 3 projektdeltagere/konsulenter er her bogen, der prøver at give en mere grunding praktisk indgang til de enkelte XP principper. maj 2003 e. Xtreme Programming – nytænkning eller anarki ? 49

Bøgerne i XP serien Extreme Programming Examined Giancarlo Succi, Michele Marchesi; ISBN 0 -201 -71040 -4 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 0 -201 -73397 -8 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 e. Xtreme Programming – nytænkning eller anarki ? 50

Bøger om XP og beslægtede metoder Refactoring: Improving the Design of Existing Code Martin Fowler, Kent Beck m. fl. ; ISBN 0 -201 -48567 -2 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 0 -201 -49834 -0 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 e. Xtreme Programming – nytænkning eller anarki ? 51

Bøger om XP og beslægtede metoder The Pragmatic Programmer Andrew Hunt, David Thomas; ISBN 0 -201 -61622 -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 e. Xtreme Programming – nytænkning eller anarki ? 52