extreme Programming Hvad er XP?

Transkript

1 extreme Programming Ole Monrad Selandia - Center for Erhvervsuddannelse 1 Hvad er XP? Hvad er XP? XP er en letvægts, effektiv, lavrisiko, flexibel, forudsigelige, videnskabelig og morsom måde at udvikle software Kent Beck 2 1

2 Hvad er XP også? Utraditionel måde at gennemføre systemudvikling Første eksempel på en ny familie af metoder de adrætte [agile] Kombinerer ledelse og systemudvikling Ikke nødvendigvis anvendelig til alle typer af projekter Stadig under udvikling 3 Omkostninger Systemændringer Tid 4 2

3 Disposition Praksis gennemgang af 12 dele planning game test refactoring par programmering opsummering Adrætte metoder Sammenligning med de traditionelle Perspektiver Cases 5 Praksis The planning game Kunden på stedet brugerinvolvering Mindre releases Metafor metafor historie [story] Test Simpelt design Refactoring Løbende integration Par programmering Kollektivt ejerskab Kode standarder 37 timers uge 6 3

4 =UdQV_b #'dy]ubcewu CY]`U\dTUcYW^ BUVQSd_bY^W =Y^TbUbU\UQcUc ;_\\U[dYfdUZUbc[QR ;_TUcdQ^TQbTUb < RU^TUY^dUWbQdY_^ 7 =UdQV_b #'dy]ubcewu CY]`U\dTUcYW^ BUVQSd_bY^W =Y^TbUbU\UQcUc ;_\\U[dYfdUZUbc[QR ;_TUcdQ^TQbTUb < RU^TUY^dUWbQdY_^ 8 4

5 =UdQV_b #'dy]ubcewu CY]`U\dTUcYW^ BUVQSd_bY^W =Y^TbUbU\UQcUc ;_\\U[dYfdUZUbc[QR ;_TUcdQ^TQbTUb < RU^TUY^dUWbQdY_^ 9 XP Projekt Historie om det kommende Historie sysem om det kommende Historie sysem om det kommende Historie sysem 12 om det Historie om det Til senere releases Kunde Historie om det kommende Historie sysem om det kommende Historie sysem om det kommende Historie sysem om det kommende Historie sysem om det kommende Historie sysem om det kommende Historie sysem om det kommende Historie sysem om det kommende Historie sysem om det Historier til én release kommende Historie sysem om det Projektleder kommende Historie sysem 12 om det Historie om det Historie om det Historie 12 om det Historie om det Historie om det Historie 12 om det Historie 12 om det Historie om det Historie om det Historie 12 om det Historie om det Historie om det Historie om det Historie om det Udviklere Historier fordelt på iterationer 10 5

6 extreme Programming Projektforløb Release plan Iterationer,1-3 uger Release Release plan Iterationer,1-3 uger Release Releaseplan Iteration 1 Iter. 2 Iter. 3 Iteration 4 11 Kunde og udvikler Skriv en historie Spydspids ved ikke Estimér for stor Opdel historien Sortér 12 6

7 Kunderettigheder Du har ret til en overordnet plan, til at vide, hvad der kan opnås, hvornår, og hvad det koster Du har ret til at følge udviklingen via et kørende system, der har vist dets duelighed gennem gentagne test, som du har beskrevet Du har ret til at ombestemme dig, dvs. at udskifte funktioner og at ændre på prioriteter Du har ret til at blive gjort opmærksom på ændringer i planer, så du tids nok kan vælge, hvordan omfanget reduceres, så den oprindelige tidsplan kan overholdes. Du kan endog vælge at afbryde og alligevel få overladt et brugbart kørende system, der afspejler den hidtil foretagne investering. 13 Udviklerrettigheder Du har ret til at vide, hvad der er behov for, via klare kravorienterede historier med klar angivelse af prioritet Du har ret til at sige hvor lang hver historie vil tage for dig at implementere og at revidere estimater ud fra erfaringer Du har ret til at identificere risikofyldte historier, at få dem prioriteret højere og et eksperimentere for at nedbringe risikoen Du har ret til at lave kvalitetsarbejde til enhver tid. Du har ret til roligt, sjovt samt produktivt og interessant arbejde 14 7

8 The planning game RAD (Rapid Application Development) Kort udviklingscyclus (fx 3-uger) Hyppige opdateringer Forretningsmæssige og tekniske prioriteringer Estimering baseret på historier [stories] 15 Kunden på stedet Skriver historier, prioriterer, fordeler på releases Besvare spørgsmål, afgøre tvivl Skal bruge systemet i produktion Til rådighed for projektgruppen, men kan også lave andet Sikring af at der hele tiden laves det rigtige 16 8

9 Mindre releases Tingene bliver færdiggjort Hyppig feedback Release og releasemoden [releasable] Omkostninger ved en release installering, træning, omstilling 17 Metafor Simpel historie af systemet som helhed for kunde, udvikler, leder Fælles opfattelse af systemet Fælles begreber Fortæller en del om systemarkitekturen Modner under udviklingsprocessen Grundlag for inspiration, analogier 18 9

10 Eksempler på metaforer Kundeservice er som et samlebånd Skrivebord for grafisk brugerflade System der kombinerer det dobbelte bogholderi og et regneark Editor: kort (hulkort), tabel m/linjer, gigantisk streng, sekvens af strenge Start med en naiv metafor sammensat af de vigtigste begreber 19 =UdQV_b BUVQSd_bY^W #'dy]ubcewu CY]`U\dTUcYW^ DUcd ;_\\U[dYfdUZUbc[QR ;_TUcdQ^TQbTUb < RU^TUY^dUWbQdY_^ 20 10

11 Test Løbende automatisk test Livscyklus: lyt (krav) test kod design Unit test giver programmører tillid Functional test giver kunder tillid Test skrives før koden Tester produktionskode 21 JUnit oversigt JUnit javax.swing extensions TestDecorator swingui TestRunner awtui TestRunner runner BaseTestRunner textui TestRunner ui TestRunner framework Assert Assertion- FaildError Test TestCase TestFailure TestListener TestResult TestSuite java.awt 22 11

12 JUnit og egen test TestResult wassuccessfull Assert errors failures TestFailure failedtest «Interface» Test run(testresult) counttestcases * Composite:Component Adapter EgenTest runtest TestCase TestSuite Composite Template Method run setup runtest teardown runtest Composite:Leaf 23 Eksempel fra: articles/junit/junitstarterguide.html 24 12

13 Trin 1 Opret nogle objekter Trin 2 Brug metode(r) Trin 3 Kontrollér resultat Trin 1 Money class + constr. Trin 2 Tilføj add-metoden Trin 3 Tilføj getvalue-metode incl. returværdi 25 Første assertequals fejler. Class Money rettes nødtørftigt, så kontrollen kan passeres. Anden assertequals fejler. Class Money må tilføjes en attribut, så objektet husker værdien

14 Class Money er rettet med en attribut, overførsel af værdi i constructor samt returnering af værdi med getvalue(). Fejler samme sted som første gang. 20 er money1 s værdi inden add. Constructor og getvalue virker, men ikke add. 27 Unit test er gennemført uden fejl. OK den befriende udskrift

15 Unit test gennemført med tre forskellige testmetoder. 29 atestrunner atestsuite pass: TestCase error: TestCase failure: TestCase run() Et test resultatsæt oprettes til opsamling af resultater fra testene. atestresult Testsuiten eksekverer alle TestCases. En succesfuld TestCase returnerer normalt. run() run(atestresult)) Hvis TestCase n kaster en exception tilføjes en fejl til resultatsættet. run(atestresult)) «exception» adderror()) En værdi testes ved at kalde en assert. Hvis assert en fejler kastes en Assertion Failed exception og fejlen tilføjes til resultatsættet. run(atestresult)) adderror()) Assert() «exception» Assertion Failed 30 15

16 Simpelt design Lave det bedst mulige design, der imødekommer behovene netop nu Ingen potentielle fremtidige funktioner Skørt at spekulere om en usikker fremtid Mål: Gennemfører alle test, ingen duplikeret logik, beskriver alt der er vigtigt for programmørerne 31 Refactoring Er en ændring i programmets interne struktur for at gøre det lettere at forstå og billigere at ændre. Ændringen foretages uden at ændre på programmets opførsel udadtil. Martin Fowler software lettere at forstå og ændre observerbart resultat ændres ikke forbedring i overskuelige skridt test et centralt element forbedring og ændring holdes adskilt 32 16

17 Parameterize Method Flere metoder udfører den samme ting men med forskellige værdier i metodens kode Udarbejd en metode der bruger en parameter til de forskellige værdier 33 Introduce Explaining Variable Man har et kompliceret udtryk Anbring udtrykkets resultat, eller del deraf, i en midlertidig variabel med et navn, der forklarer formålet if ( (platform.touppercase().indexof("mac") > -1) && (browser.touppercase().indexof("ie") > -1) && wasinitialized() && resize > 0 ) { // do something } final boolean ismacos = platform.touppercase().indexof("mac") > -1; final boolean isiebrowser = browser.touppercase().indexof("ie") > -1; final boolean wasresized = resize > 0; if (ismacos && isiebrowser && wasinitialized() && wasresized) { // do something } 34 17

18 Pull Up Method Man har metoder med identiske resultater i subklasserne Flyt dem til superklassen 35 Type Refactorings» Rename Class» Move Class» Add Parent Class» Add Child Class» Remove Class» Extract Interface Method Refactorings» Push Up Method» Push Up Abstract Method» Push Down Method» Rename Parameter» Extract Method Field Refactorings» Rename Field» Push Up Field» Push Down Field UML diagram 36 18

19 1. Højreklik på getname() i Salesman og valg af Method Refactoring Push Up 2. Bekræft at metoden både i Salesman og Engineer skal flyttes. 3. Metoden getname() er fjernet fra Salesman og Engineer og findes i stedet i Employee. Klassernes kode er justeret. 37 Push Down Method Adfærd i superklassen er kun relevant for nogle af dens subklasser Flyt den til disse subklasser 38 19

20 Replace Conditional with Polymorphism En betingelse som vælger forskellig adfærd afhængig af et objekts type Flyt hver betingelsesdel til en overstyrende metode i en subklasse. Gør den oprindelige metode abstrakt double getspeed() { switch (_type) { case EUROPEAN: return getbasespeed(); case AFRICAN: return getbasespeed() - getloadfactor() * _numberofcoconuts; case NORWEIGIAN_BLUE: return (_isnailed)? 0 : getbasespeed(_voltage); } throw new RuntimeException ("Should be unreachable"); } 39 Refactoring Løbende redesign Forbedre mulighederne for ændringer Konstant ønsker om ændringer Gøre programmet simplere og stadig gennemføre alle tests Gennemføres i mindre trin 40 20

21 Kilde: 41 Sammenhæng med mønstre Flere refactorings indeholder kendte mønstre, fx strategy Anvendes på bagkanten Ofte af mindre omfang Opstilles i skabelonform Enkeltelementer, der kan kombineres på mange måder (hypertekst-form) 42 21

22 Integration Integration mindst dagligt Feedback cyklus: udvikl testcase kod integrer test Et sæt ændringer integreres ad gangen Tydeligt feedback 43 =UdQV_b BUVQSd_bY^W #'dy]ubcewu CY]`U\dTUcYW^ DUcd ;_\\U[dYfdUZUbc[QR ;_TUcdQ^TQbTUb < RU^TUY^dUWbQdY_^ 44 22

23 Par programmering To personer om en maskine Løbende software inspektion Samarbejde, hurtig indlæring, afdækker fejl Programmerer og lærer at programmere bedre Forhindrer introduktion af fejl 45 Par progr. resultater Figur 1. Sammenligning af færdiggørelsestider for par programmørers og individuelles projekter

24 Kollektivt ejerskab Alle har ansvar for at øge kodens kvalitet Alle har kendskab til enhver del Gør projektet og systemet mindre sårbart 47 Kodestandarder Nødvendighed som følge af kollektivt ejerskab og parprogrammering i skiftende par Al kode ser ens ud Accepteret af alle 48 24

25 Kodestandard i Java Kilde: timers uge Møde frisk, udhvilet og entusiastisk Ingen kan lave kvalitetsarbejde med 60 timers arbejdstid uge efter uge Overarbejde er symptom på problemer i projektet 50 25

26 Værdier og filosofi Kommunikation Simpelthed Feedback Mod Kvalitetsarbejde 51 Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Beck, Beedle, Bebbekum, Cockburn, Cunningham, Fowler, Grenning, Highsmith, Hunt, Jeffries, Kern, Marick, Martin, Mellor, schwaber, Sutherland & Thomas Uddybning: Fowler & Highsmith: The Agile Manifesto

27 Agile Software Development extreme Programming Adaptive Software Development Jim Highsmith Crystal methodology family Alistair Cockburn Scrum Software Development DSDM Dynamic Systems Development Method Feature-Driven Development Peter Coad 53 Agile traditionelle Lære og beherske Udgangspunkt i kode, dokumentation Tidlige resultater Øget kvalitet af koden Har stor bevågenhed Kræver meget af projektdeltagerne Problemer omkring skalering Ikke alle opgaver kan deles op i iterationer 54 27

28 Perspektiver Bevidstgøre metodeanvendelsen én metode til alt Det menneskelige aspekt individ kontra ressource Udviklingstakt Nye måder test før kode kode før design løsninger før dokumentation 55 Chrysler Lønningssystem til ansatte Erstatning for flere lønsystemer Kuldsejlet forsøg på anvendelse af standardsystem Kent Beck startede forfra med XPteam fra 1996, sidste del i 1999 Ref: Distributed Computing, oct. 98. Kilde:

29 Web-løsning integreret eksisterende system og layout fra eksterne web designere 6-8 udviklere, 5 måneder -> udvik.gruppe parprogrammering: spredning af ny teknologi, få misforståelser historier: web designere brugte use cases kundens involvering: tid til tilpasning, sen fokus på central funktion: olielotteri releases: produktion efter 4 måneder design: brug af design sessioner Kilde: 57 Q8 / Bankdata Kommunikation fremmes i åbne arbejdsmiljøer Kundeinvolvering er alfa og omega Kunden skal tage et ansvar Refactoring er risikabel uden test Ændringer er dyre uden brug af refactoring Parprogrammering giver kollektivt ejerskab, vidensdeling og ensartede regler Man bør benytte alle elementerne Kilde:

30 Home Information System, , kalender, opgaveliste, gui, web og db-server Hurtig udvikling parprogrammering, test, planning game, 37 timer, refactoring Fulgte med ændrede krav planning game, mindre releases, refactoring Afleverede til tiden planning game, mindre releases, integration Få fejl parprogrammering, 37 timer, refactoring, test Kilde: bestbrains.dk 59 Speakanet Kilde: speakanet.dk 60 30

31 Litteratur, bøger Kent Beck: Extreme Programming Explained: Embrace Change. Addison Wesley, 2000 Kent Beck & Martin Fowler: Planning Extreme Programming. Addison-Wesley, 2001 Martin Fowler: Refactoring. Improving the design of existing code. Addison Wesley, 1999 Ron Jeffries, Ann Anderson & Chet Hendrickson: Extreme Programming Installed. Addison-Wesley, 2001 William C. Wake: Extreme Programming Explored. Addison-Wesley, Litteratur, Agile metoder Coad, P: Feature-Driven Development. Cockburn, A: Crystal Clear: A Human-Powered Methodology for Small Teams. Members.aol.com/humansandt/crystal/clear Highsmith, J: Adaptive Software Development. Dorset House, Schwaber, K: Scrum online: Stapleton, J: DSDM Dynamic Systems Development Method. Addison-Wesley,

32 Litteratur, tidsskrifter Chrysler Goes to Extremes, by the C3 Team. Distributed Computing, october Jim Highsmith: Extreme Programming. e- business application delivery, feb Light Methodologies, redigeret af Ed Yourdon. Cutter IT-journal, nov The Great Methodologies Debate: Part 1 & 2. Cutter IT-journal, dec 2001 & jan Laurie A. Williams and Robert R. Kessler: All I really need to know about Pair-programming, I learned in kindergarten. Communication of the ACM, may Net referencer God tutorial om XP /more.html har gode referencer videre, herunder gode artikler om emnet Samling af information og henvisninger, indeholder bl.a. JUnit Indholdsrig artikel om XP af Jim Highsmith v/martin Fowler, indeholder bl.a, et on-line katalog over refactorings computer.org/seweb/dynabook/whatis.html. Korte noter om XP (bl.a. af Kent Beck) samt tre artikler om XP fra IEEE Software, july/aug

33 Litteratur på www I extreme Programming Extreme Programming: A gentle introduction. Løbende opdatering, XP Exchange. Løbende opdatering, William Wake: Xploration. Løbende opdatering, Martin Fowler: The New Methodology. Adrætte metoder (agile methods) Manifesto for Agile Software Development. Bibliography for Agile Methodologies and Practices. collaboration.csc.ncsu.edu/agile/bibliography.htm Par programmering Laurie A. Williams and Richard L. Upchurch: In Support of Student Pair- Programming. Laurie A. Williams et al: Strengthening the Case for Pair Programming. IEEE Software, jul/aug Værktøjer JUnit. Ant. jakarta.apache.org/ant JRefactory. jrefactory.sourceforge.net/chrisdown.html 65 Litteratur på www II Test Malcom Davis: Incremental development with Ant and Junit. 2000, www-4.ibm.com/software/developer/library/j-ant/index.html Martin Fowler: A UML Testing Framework. April 1999, Refactoring Catalog of Refactorings: Flere eksempler på Refactorings from Writing Efficient Programs Refactoring: An Example Refactoring: An Example, Extended From 0 to Composite (and Back Again) Simpel design Martin Fowler: Is Design Dead? Kodestandard Løbende integration Martin Fowler: Continuous Integration. JUnit Mike Clark: JUnit Primer. Diaspar Software Services: JUnit:: A Starter Guide