Tema: Test First Positivist: Det som ikke kan måles, eksisterer ikke! Reduserer sjanser for defekter Gir en oppdatert ”TODO-liste” Gir trygghet til å gjøre.

Presentasjon om: "Tema: Test First Positivist: Det som ikke kan måles, eksisterer ikke! Reduserer sjanser for defekter Gir en oppdatert ”TODO-liste” Gir trygghet til å gjøre."— Utskrift av presentasjonen:

1 Tema: Test First Positivist: Det som ikke kan måles, eksisterer ikke! Reduserer sjanser for defekter Gir en oppdatert ”TODO-liste” Gir trygghet til å gjøre senere endringer Tvinger fram et lavere koblet design  Forbedrer designet rett ut fra startgropen Gir ”Just-in-Time” Analyse

2 Tema: Tester De beste testene tester enheter Dersom testene ikke har fanger nok feil: Oppnevn en prosjekt-sabotør (test testene) Dersom feil oppstår i senere i prosessen Kartlegg hvilken enhet som oppfører seg feil Introduser tester som verifiserer mot dette Påvis feilen med enhetstest før rettning For å teste at en klasse kaller de riktige metodene på en annen: Bruk ”Mock objects” for å teste rekkefølgen på kallene

3 En enkel test /** Verify that modify updates indexes. */ public void testModifyKeyField() throws DatabaseException { populateDatabase(10, "hello", "world"); final String oldKeyName = "hello8"; final String newKeyName = "goodbye7"; DataInfo record = db.find(oldKeyName); assert(record != null); record.getValues()[0] = newKeyName; db.modify(record); assert(db.find(oldKeyName) == null); assert(db.find(newKeyName) != null); }

4 Tema: Spikes Hva gjør man dersom man skal estimere hvor lang tid det vil ta å lage et hull i isen? Slår en tynn stake gjennom den Spike er et lite program som lages for å teste noe og som så kastes Typer: Performance Spike (gjør 20000 kall mot webserveren) Arkitektur Spike Estimerings-spike (for å vite mer om hvor lang tid noe kommer til å ta)

5 XP & Design XP gjør ikke en stor designjobb på forhånd XP fokuserer på Enkelhet Betyr dette at XP er ”imot design”? NEI!: Istedet designer man når man vet hva man skal designe Et enkelt program betyr det dette er mulig Grundig testing gir trygghet Et design som ikke er uttrykket i kode eksisterer ikke! Et design som ikke utvikles kontinuelig smuldrer opp

6 Tema: Refactoring Ideal: Programmet skal: Passere alle tester Si alt som må sies Ikke gjenta seg selv Ha færrest mulig klasser og metoder Refactoring beskriver en bevegelse i denne retningen Understøttes av enhetstestene Angriper ”code-smells” (Ender ofte opp på Patterns)

7 Tema: Planlegging User Stories gir en uformell beskrivelse Samtale med kunden gir mer utfyllende info Akseptanse-tester verifiserer forståelsen Dette er primær tilbakemelding til kunden Forrige iterasjoner gir Project Velocity (Starter på 1 User Story enheter/3 person- uke) Engineering Tasks gir uformelle TODO Daglige Stand-up møter viser status Et prosjektmedlem bør være ”Tracker”

8 Tema: XP og CMM CMM er ikke en prosess, men et prosess- forbedrings rammeverk XP fokuserer på mange av de samme tingene som CMM: Kvalitetsikring, metoder, måling, forbedring XP passer relativt bra inn i CMM rammeverket For mer info – se http://www.xprogramming.com/xpmag/xp_and_cmm.htm http://www.xprogramming.com/xpmag/xp_and_cmm.htm

9 Tema: XP og CMM, level 3-5 SEI Level Three – Defined XP Passer som hånd i hanske 12 extreme practices User Stories + Tester SEI Level Four – Managed Flere kvantitive målinger og mål kan trenges SEI Level Five – Optimizing Når defekter oppstår, skriver man tester for å demonstrere dem

10 Cost of Anticipatory Design Invested Cost and Design Complexity Time ’A’ needed’B’ needed Cost of A Cost of B

11 Tema: Parvis Programmering To programmere sitter ved samme maskin Den med tastaturet tenker kortsiktig (sjåfør), den andre tenker langsiktig og gir konstant review (kartleser) Rollene byttes ofte Parene rokeres ofte (oftere enn daglig)

12 Tema: The Agile Alliance Fra http://www.agilealliance.org/ We 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 Stiftet 11-13 februar i år Samler blant annet SCRUM, FDD, DSDM, XP, Crystal under en paraply

13 Tema: XP og dokumenter Et dokument som produseres må enten: La utviklingen gå raskere, (eksempel: Kommuniserer programmet til nye prosjektmedlemmer), eller Være ønsket av kunden, og satt av tid for i iterasjonsplanen Det vil si: Dokumentasjon stiller på samme linje som program som en leverbar enhet

14 Tema: Iterativ utvikling Mange prosjekter er 90% ferdig i 90% av sin levetid Integrasjon og testing er uforutsigbare – dvs. høy risiko Generelt: Mangel på feedback -> høy risiko I XP er en iterasjon en timebox på 1-4 uker (2 uker anbefales) Funksjonalitet som ikke er levert fullstendig ved slutten av en iterasjon regnes som ikke levert Brukes til tracking og estimering Synliggjør prosjektutviklingen

15 Tema: Akseptansetester Tester at en User Story er levert Formål: Kunden må ha tillit til at ønsket funksjonalitet faktisk er tilstedet Kan være manuelle, men automatiske tester er alltid et stort pluss! Kan skrives av: Kunde Programmerere under kundes kontrol Et eget QA team under kundes kontrol

16 Ting som ikke er med XP som Just-In-Time metodikk Er XP nytt (naturligvis ikke) Er XP stabilt (naturligvis ikke – f.eks. The planning game er nå vurdert til å være for kompetiv) Steve McConnell: Lack of quality is what is driving the cost up! Steve McConnell: Good people is an important driver for project success?

17 The Planning Game Kunder og utviklere finner ut hva som skal lages ”Business people make business decissions, technical people make technical decissions” Resultat: Release-plan Ved hver iterasjon bestemmer kunden hva som skal være med User Stories: Estimerbare biter funksjonalitet