Föredrag om eXtreme Programming från 2003 - 2004 som fortfarande innehåller mycket av kärnan i vad agil mjukvaruutveckling går ut på.

1. eXtreme Programming Teknik i Media BITS Peter Antman CTO

2. Extreme Programming Komplexitet

3. Traditional Cost of Change

4. Hur hantera? Abstraktion

5. Disciplin

6. Conceptual integrity

7. Olika modeller Olika modeller Vattenfall

8. Iterationer

9. RUP Men i grunden de samma Prioriterar design (intellekt över materia).

10. Olika modeller Jag har pratat mycket om det. Typiska ord: Ta höjd

11. Generallisera

12. Tänka igenom

13. Planera

14. Olika modeller Men jobbar vi verkligen så?

15. Extreme Programming XP

16. Extreme Programming Vill ta fasta på hur utveckling verkligen sker? Vänder på själva grundförutsättningen. Eftersom mjukvara är så komplext skall man bara göra det man verkligen behöver.

17. Extreme Programming Om programmering är så komplext och dessutom sker i en starkt föränderlig omvärld vet vi att föränding kommer att ske. Den gamla modellen går ut på att motverka förändringen genom att försöka förutse den. Men om det inte går?

18. Extreme Programming XP menar att man skall se det tvärtom. Eftersom förändring (osäker kunskap om framtiden) är en essentiell del av utveckling bör denna göras till grunden för utvecklingsprocessen.

19. Extreme Programming Genom att bygga in möjligheten till förändring kan man förändra kostnaden för förändring.

20. XP – Cost of Change

21. XP – de tolv satserna Vad går XP ut på mer precis? Är det bara att hacka i väg? I själva verket en starkt styrd process. Kan sammanfattas i tolv satser.

22. XP – de tolv satserna Kan delas in i tre grupper av aktiviteter Kodningsaktiviteter

23. Utvecklingsaktiviteter

24. Affärsaktiviteter

25. XP – Kodning 1. Koda och designa enkelt Mål: Att skapa mjukvara som är enkel att förändra 2. Refaktorera hänsynslöst Mål: Att hitta den optimala designen 3. Utveckla kodstandarder Mål: Att tydligt kommunicera ideer via koden 3. Utveckla en gemensam vokabulär Mål:Att tydligt kommunicera ideer om koden

26. XP – Utveckling 1. Använd testdriven programmering Mål: Att bevisa att koden verkligen fingerar 2. Praktiser parprogrammering Mål: Att sprida kunskap, erfarenhet och ideer 3. Set till att koden ägs kollektivt Mål: Att sprida ansvaret för koden genom hela organisationen 4. Integrera kontinuerligt Mål: att minska effekten av nya features

27. XP – Affärer 1. Lägg till en Kund till teamet Mål: Att ta tag i kundönskemål direkt och korrekt 2. Spela “planeringsspelet” Mål: Att schemalägga det viktigaste arbetet 3. Släpp releaser regelbundet Mål: Låta kunden få tillbaka sin investering ofta 4. Arbeta i ett uthålligt tempo Mål: Att gå hem trött, men inte utmattad

28. XP – Händelser Ha en kund Spela planeringsspelet Skriv en historia (Story Card) om varje feature Skriv features för historierna – uppskatta tid Med kunden väljs en eller flera Storys ut som: Är viktiga

29. Går att skapa på 3-4 veckor Börja med en feature Skriv tester för den Implementera den så enkelt som möjligt

30. XP – Händelser Se till att den finns i CVS Se till att den testas/integreras regelbundet Gör direkt återkoppling om det drar ut på tiden. Skapa en release Installera hos kund. Börja om med nya Stories.

31. XP – Processen XP är en komplett process. Förespråkarna hävdar att allt måste vara med – annars är det inte XP. Det ligger mycket i det – men det finns några saker som är mer grundläggande än andra.

32. XP – Processen Utgå från Kodandet. Många säger idag att de kodar XP Finns det ingen riskt att “koda XP” bara blir ett sätt att täcka upp för att man kodar “slarvigt”? JO!

33. XP – Processen Grundpelarna i kodningen (som fått starkt genomslag) Bygg bara det du vet att du skall ha (“ta inte höjd”)

34. Skapa små system som växer inkrementellt

35. Ta aldrig med något du inte vet att behöver

36. Gör det enklaste som överhuvud taget funkar

37. Faktorerar om hela tiden (har du gjort något förut, kolla hur du kan återanvända det)

38. XP – Processen De flesta saker vi bygger blir ganska stora tillslut. XP för med sig att ett system kommer genomgå radikala förändringar under sin utvecklingstid Systemet i konstant flux.

39. XP – Processen Jag har sett massor av system byggas just så (under Internet time). I princip inget har varit XP. Varför?

40. XP – Processen INGA TESTER!

41. XP – Processen Grunden i XP är tester. Tester av kod, funktioner och integration. Utan detta är det inte XP. För det är testerna som gör att förändringen blir kontrollerbar.

42. XP – Processen Ännu hårdare: Man använder bara XP om man FÖRST skriver tester och sedan implementationen.

43. XP – Processen Tester blir nästan aldrig (ordentligt) skrivna om de görs förs i efterhand. Implementationerna innehåller nästan alltid “för mycket” om man inte skriver testen först.

44. XP – Processen Grunden i XP (enligt Antman) Det du inte orkar/kan/förstår hur du skall skriva en test för går under “You aren't gonna need it”.

45. XP – Processen Att koda “XP-stil” utan tester är som att köra “One night stand utan skydd” Vi har alla höra/eller själva kört med ursäkterna:

46. XP – Processen Den övermodiga: - “Jag vet vad jag gör, det händer inte mig” Den slarviga: - “Det gick så snabbt, jag hade inte tid” Den osäkra: - “Jag vågade inte säga ifrån”

47. XP – Processen Vi har alla hört precis samma ursäkter under utvecklingsarbete – eller hur!

48. XP – Processen Men om vi inte kör XP och ändå vill ha kvalitet. Då återstår faktiskt i grunden bara den gamla modellen! Den är dyr, krävande och fast den funnits som modell i 30-år tycks ingen hantera den.

49. XP – Processen Därför XP - seriöst.