Hva er XP ? Ikke ekstrem, men heller meget forsiktig

Presentasjon om: "Hva er XP ? Ikke ekstrem, men heller meget forsiktig"— Utskrift av presentasjonen:

1 Ekstrem Programmering - XP Trond Johansen, Proxycom AS 22 november 2001

2 Hva er XP ? Ikke ekstrem, men heller meget forsiktig
Ikke bare programmering, men en systemutviklingsmetode XP er en forsiktig systemutviklingsmetode

3 Forskjeller i forhold til andre metoder
Legger vekt på å realisere kundens behov i små trinn Baserer seg på at kundens behov stadig endres Produsert kode skal kontinuerlig kontrolleres med automatiske tester Produsert kode skal gjøres vedlikeholdsvennlig Koding utføres som parprogrammering Kollektivt eierskap til programkoden.

4 XP utviklingsprosess

5 Organisering av XP-prosjekt
Roller: Kunde, som skal delta på heltid Prosjektleder Designer Programmerer Tester QA

6 Kartlegging av kundebehov
Kunden skriver behovskort, utvikler kommenterer og estimerer Kortfattet, ca. 3 setninger Omfang ca. 1-3 ukeverk per behovskort Turnusplan Når man skal lage en turnusplan, så skal det være mulig å velge en mal som inneholder de vanlige trinnene som inngår. Valg av mal gjøres med en knapp i skjermbildet. 2 ukeverk

7 Planlegging av leveranser
Kunden prioriterer og fordeler behovskortene på en eller flere leveranser. Bør være hyppige leveranser, f.eks en gang pr måned Planleggingsmøtet tar vanligvis under en dag

8 Planlegging av en iterasjon
Kunden prioriterer fra leveranseplanen og velger behovskort som skal inngå i en iterasjon. Hvert behovskort transformeres til utviklingsoppgaver Utviklere velger sine oppgaver og estimerer omfang En utviklingsoppgave bør ha varighet på 1-3 dagsverk Akseptansetester som gikk feil skal også inkluderes En iterasjon bør ha fast varighet på 1-3 uker

9 Hierarki

10 Design Hovedprinsipper: Enklest mulig design
Fremtidige krav og ekstra funksjonalitet tas ikke med Benytter tre teknikker: Objektkort Refaktorisering Parprogrammering

11 Objektkort Hvert kort dekker et objekt, og man utarbeider alternative løsninger for oppdeling i objekter og meldingsutveksling mellom objektene. Utviklingsgruppen samarbeider om design

12 Refaktorisering Ikke behold spaghettikode, men refaktoriser !
Refaktorisering betyr at de indre delene av en programmodul forbedres uten å endre de eksterne egenskapene Refaktorisering består i å: Fjerne redundans Fjerne ubrukt kode Forbedre upraktiske løsninger Refaktorisering bidrar til enklere vedlikehold av koden Finnes regler og maler for refaktorisering.

13 Eksempel på refaktorisering -1
Add Parameter A method needs more information from its caller. Add a parameter for an object that can pass on this information.

14 Eksempel på refaktorisering -2
Extract Class You have one class doing work that should be done by two. Create a new class and move the relevant fields and methods from the old class into the new class.

15 Eksempel på refaktorisering - 3
Move Field A field is, or will be, used by another class more than the class on which it is defined. Create a new field in the target class, and change all its users.

16 Refaktorisering av databaser
XP fokuserer på OO systemer, og lite på relasjonsdatabaser Kan bli arbeidskrevende å refaktorisere databaser hyppig Databasestrukturer bør antakelig utarbeides på leveranse- eller systemnivå

17 Lag testprogram Etabler opplegg for automatisk enhetstest
Hver programmodul skal ha et testprogram Testprogram lagres i programkodebasen

18 Skriving av programkode
Parprogrammering Det hevdes at kodekvaliteten vil øke uten at leveringstiden forsinkes Skift parsammensetning Sprer kunnskap på flere Kollektiv eierskap til programkoden Reduserer sårbarhetet når nøkkelpersoner slutter/har for mye å gjøre Daglige møter gir god kommunikasjon Prosjektdeltakerne skal stå i en sirkel Ingen overtid Ved forsinkelser flyttes oppgaver til neste iterasjon, mens dato beholdes

19 Integrering av programmer
Fortløpende integrasjonstest Utviklere bør integrasjonsteste og lagre kode i programkodebasen gjerne flere ganger pr dag. Oppdatering av programkodebasen gjøre i sekvens etter at integrasjonstestene er gjennomført

20 Akseptansetest Utarbeides for de behovskort som inngår i en iterasjon
Skal verifisere at hvert behovskort er korrekt realisert Kunden bør helst spesifisere testene Akseptansetestene bør være automatiske slik at de kan kjøres ofte

21 Fordeler med XP-metoden
God kundemedvirkning Tilpasset kontinuerlig endringer av kundekrav Gir rask levering av prioriterte kundekrav God kvalitet basert på automatiske tester Gir god oppfølging av fremdrift Gir god vedlikeholdbarhet av programkoden

22 Ulemper med XP-metoden
Vanskelig å få kunden med på heltid Mangler kravspesifikasjon, så tilbud blir usikkert Er objektorientert, og antakelig ikke helt tilpasset systemer med relasjonsdatabaser. Passer ikke for store prosjekter. Argumenterer ikke med tids- eller kostnadsbesparelser

23 Passer XP for Proxycom ? Jo, nyttige ting er:
Dele prosjekter i små trinn Baserer seg på at kundens behov stadig endres Automatiske tester Refaktorisering Parprogrammering bør prøves Kollektivt eierskap til programkoden.