extreme Programming (XP)

Transkript

1 Høgskolen i Oslo extreme Programming (XP) Hans Gallis hansga@simula.no Stein Grimstad steingr@simula.no sg@objectnet.no Mål for forelesningen Kjennskap til prosessforbedring Kjennskap til Agile Software Development Deltaljert kjennskap til extreme Programming 2

2 3 Innhold Prosessforbedring Garasjebygging med DUPLO-Lego Lettvektsmetodikk extreme Programming Modell vs metodikk Utviklingsmodell: Et abstrakt rammeverk som en metodikk kan baseres på Eks.: Fossefallsmodellen og spiralmodellen Metodikk: Konkretisering av en modell Består av tre elementer: notasjon, verktøy og prosess 4

3 5 Hva er prosess? Framgangsmåte (blå fremmedordbok) The mental and physical activities we use to produce outcomes (Luke Hohmann 1997) Outcome = the result of a process Prosess kan være bevisst eller ubevisst. Når vi lager et produkt følger vi uansett en prosess (når man gjør mer enn én ting). Hensikten med en definert prosess Organisering av oppgaver som gjennomføres systematisk for å oppnå et definert mål Hjelpe alle involverte parter til å gjøre sin del av arbeidet enklere, bedre og/eller mer effektivt slik at sluttproduktet (resultatet av felles innsats) oppnår riktig balanse mellom kost og nytte 6

4 7 Hvorfor prosessforbedring? Markedsmessige problemer Kundene rømmer p.g.a. dårlig kvalitet i produktet Produksjonskostnadene er for høye Endringer i markedet Er nødt til å tilby elektroniske tjenester (f.eks. automatiseringen av banktjenester) Døgnåpen forvaltning Hvorfor prosessforbedring? Endring i utviklingsorganisasjon Outsourcing Vekst Krav om sertifiseringer Sikkerhetssertifiseringer 8

5 9 Forskning ved Simula (SE) Fokus på tekniske, organisasjonelle og menneskelige aspekter ved systemutviklingsprosesser Empirisk forskning (evaluering av effekt) på ulike: Modeller Metoder Teknikker Verktøy Prosessforbedring - eksempel Shinkansen (Japan) versus NSB (Norge) 10

6 11 Shinkansen Kontrollsenteret 12

7 13 Kontrollsenteret Every Bullet Train in Japan is controlled by computers. The computers are kept in a building called the CTC (Central Traffic Control) in Tokyo. The cab of a Shinkansen is connected to computers that operate the train. The automatic train control (ATC) system enhances safety by preventing trains from colliding with each other. If a train is going too fast, the brakes operate automatically. Tokyo-Osaka (500 km): 285 trains a day carrying 360,000 passengers. In 36 years, there has not been a single death due to a train accident. As for reliability, the average delay is 0.4 minutes (average delay on arrival for all trains). Most of this delay is due to natural phenomena such as heavy rain, typhoons and snowfall. Shinkansen maintenance system: At night after train operation has finished, fine adjustments are made to rail positions. Also, rails and overhead catenary showing signs of wear and deteriorated ballast are replaced. During operation, a multiple inspection train (called Doctor Yellow) is run once every 10 days to make a precision check of the condition of the tracks, overhead power catenary, signals and communications. The maintenance of cars consists of daily inspections focusing mainly on the replacement of worn parts, regular inspections which mainly check functions, dismantling inspections for bogies and a general overhaul which includes the inspection of the car body. These inspections are conducted on the basis of kilometers traveled or at set time intervals. Japansk lokfører sovnet i 270 km/h Mens det japanske toget rullet jevnt og rolig videre, sovnet lokføreren stille og fredelig bak spakene. Hastighetsmåleren viste 270 kilometer i timen, opplyste polititalsmenn torsdag. Mannen våknet etter åtte minutter da systemet for automatisk togstopp stanset høyhastighetssettet av typen Shinkansen på en stasjon i provinsen Okayama sør i Japan. De rundt 800 passasjerene om bord i toget merket ingen ting til episoden. I politiavhør har den 33 år gamle lokføreren forklart at han plutselig ble overmannet av tretthet. Ifølge japanske medier må han regne med overføring til annet arbeid eller en annen form for disiplinærstraff, men han mister neppe jobben. (NTB kl. 07:31) 14

8 15 NSB Siste 36 år: Forsinkelser: Trenger vel ingen nærmere forklaring! 16 større ulykker (66 døde, 179 skadd) Åsta-ulykken 4. januar døde, 69 personer skadd Vestby-ulykken 25. januar passasjerer, ingen døde eller skadet! Innen 1. januar 2004 skulle alle skinneoverganger være utbedret og sikret I løpet av fire år er lite eller ingenting skjedd! Garasjebygging med duplo Konkurranse: Trenger 8 frivillige fordelt på to grupper 16

9 17 Garasjebygging med Duplo Oppgave: Bygge en fin garasje til bilen min Garasjen skal være billigst mulig Garasjen skal være ferdig bygget på fire minutter! Agile vs plan-driven methodologies Agile (= smidig på norsk): Ønsker ikke å planlegge for fremtiden Plan-driven: Ønsker å planlegge for fremtiden 18

10 19 I den virkelige verden Krav endrer seg hele tiden Rask time-to-market (Internet) Lite langsiktige planer Dette medfører: Må ha hyppige leveranser Må kontinuerlig endre koden (og designet) Forutsetter at systemet er i en sunn tilstand (hele tiden!) 20

11 21 The Agile Manifesto Individer og interaksjon fremfor prosesser og verktøy Fungerende software fremfor utstrakt (omfattende) dokumentasjon Kundemedvirkning fremfor kontraktsforhandlinger Reagere på endringer (fleksibilitet) fremfor å følge en plan Se og NB! Uthevede verdier er vektlagt, men verdiene til høyre i setningene er også viktig! The Agile movement hva finnes av metodikker? Scrum Dynamic Systems Development Method (DSDM) Crystal family of methodologies Extreme Programming (XP) Feature Driven Development Adaptive Software Development Open Source Software development 22

12 23 extreme Programming (XP) Utviklet av Kent Beck og Ward Cunningham (1996) En kodenær disiplin for programvare-utvikling 4 verdier 12 prinsipper/praksiser 4 kjerneaktiviteter Best practises satt i sammenheng De fire verdiene Kommunikasjon Enkelhet Tilbakemelding Mot 24

13 25 De 12 prinsippene 1. Planning game 2. Små releaser 3. Metaforer 4. Enkelt design 5. Testing 6. Refactoring 7. Parprogrammering 8. Kollektivt eierskap 9. Kontinuerlig integrasjon timers uke 11. On-site kunde 12. Kodestandarder Planning game Klarlegge hva er ønskelig (forretningshensyn) hva er mulig (tekniske hensyn) Estimere Prioritere Planlegge 26

14 27 Små releaser Minst mulig kode Mest mulig forretningsverdi 1-2 måneder (mellom hver gang systemet settes i produksjon) Risikoreduserende Metaforer Få et vokabular (et sett felles begreper) for tekniske ting uten å bruke tekniske termer La prosjektet være styrt av én metafor Datamaskin skrivebord Ordresystem kunder og ordrer Gjør det lettere å kommunisere og utarbeide arkitekturen 28

15 29 Enkelt design Det riktige designet kjører alle testene har ikke duplikat logikk kommuniserer godt har færrest mulig klasser og metoder Testing Funksjonalitet uten automatiske tester finnes ikke Programmerere skriver enhetstester (test-first) gir programmereren tillit til programmet Kunder skriver funksjonelle tester gir kunden tillit til programmet 30

16 31 Refactoring Under implementasjon kan koden endres for å gjøre det enklere å implementere denne funksjonaliteten? Etter implementasjon kan koden skrives om til et enklere design, uten at testene ødelegges? Parprogrammering 32

17 33 Samarbeid og kommunikasjon Opptil 70% av totaltiden i et IT-prosjekt går med til kommunikasjon designmøter, oppklaring av misforståelser etc. (Rapid Software Development through Team Collocation Teasley et al. 2002) En utvikler bruker generelt (Peopleware DeMarco and Lister 1999): 30% av sin tid til individuelt arbeid, 50% av sin tid til å arbeide med en annen person, og 20% av sin tid til å arbeide med to eller flere personer Det er vanlig å bruke 30-70% av totaltiden til å lokalisere og rette feil (Gibson Managing Computer Projects) Kollektivt eierskap Alle er ansvarlig for hele systemet Alle har rett til å endre all kode Likevel, ikke alle kjenner alle deler like godt 34

18 35 Kontinuerlig integrasjon Kode integreres og testes hver dag Skal hele tiden ha et stabilt system Skal finne feil tidligst mulig Hvis integrasjon feiler har det å rette opp dette høyeste prioritet On-site kunde Kunden Sitter sammen med utviklerne Svarer på spørsmål Gjør prioriteringer (på lavt nivå) Deltar i diskusjon av løsninger Ikke nødvendigvis 100% stilling 36

19 37 40-timers uke XP er krevende Intensivt med korte leveranser Ekstremt mye kommunikasjon Mye tenking Viktig å være uthvilt 40-timers uke skal være normalen (ingen overtid!) Kodestandarder Nødvendig for Parprogrammering Kollektivt eierskap Skal være enkel men dekkende 38

20 39 De fire kjerneaktivitetene 1. Koding 2. Testing 3. Lytting 4. Design Koding Den eneste uunnværlige aktiviteten Gir forståelse av design Bruk kode til å prøve ut idéer til å skrive tester 40

21 41 Testing Kan det ikke måles så finnes det ikke Finnes ikke testene, finnes ikke koden Lar deg fokusere på hva du ønsker Uten tanke på hvordan det skal implementeres Gir tillit til koden for programmerer for kunde Lytting Programmerere vet ingenting som forretningsfolk synes er interessant Derfor må man spørre noen og lytte 42

22 43 Design Lage struktur for å organisere logikken i systemet Godt design har kontrollerte avhengigheter i systemet sikrer at samme logikk bare finnes ett sted gjør systemet utvidbart plasserer logikk nær data den opererer på Når kan man benytte XP? Criticality Prioritized for legal liability Prioritized for productivity and tolerance Life (L) L6 L20 L40 L100 L200 L500 Essential money (E) E6 E20 E40 E100 E200 E500 Discretionary money (D) D6 D20 D40 D100 D200 D500 Comfort (C) C6 C20 C40 C100 C200 C Alistair Cockburn, 2002 Number of People Involved ± 20% 44

23 45 Når kan man benytte XP? Ut ifra modellen på forrige side; diskutér to og to hvor XP kan benyttes Når kan man benytte XP? Criticality Prioritized for legal liability Prioritized for productivity and tolerance Life (L) L6 L20 L40 L100 L200 L500 Essential money (E) E6 E20 E40 E100 E200 E500 Discretionary money (D) D6 D20 D40 D100 D200 D500 Comfort (C) C6 C20 C40 C100 C200 C Alistair Cockburn, 2002 Number of People Involved ± 20% 46

24 47 Når kan man benytte XP? Diskutér: Hvorfor passer ikke XP til prosjekter med mer enn 20 personer og Life-critical systems? Hvordan kan XP tilpasses prosjekter med mer enn 20 personer? XP web-ressurser

25 49 Takk for oppmerksomheten