Tema: Test First

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

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 ’A’ needed ’B’ needed Invested Cost and Design Complexity Cost of B Cost of A Time

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