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

5. Disciplin

6. Conceptual integrity

8. Iterationer

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

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.

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

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!

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.

51. CVS

52. Tim BigBrother

53. XP – Processen Bacon Skapar en gemensam standard för hur projekt ser ut En massa viktiga targets redan färdiga. Anpassad för Tim BigBrother Eller skall vi byta till Maven?

54. XP – Processen Bacon mkdir myproj cd myproj bacon -p [pra@pra myproj]$ ls bin doc lib local.properties properties src build.xml jars libexec project.xml resources

55. XP – Processen Bacon – att bygga cd bin ./build.sh compile ./build.sh javadocs ./build.sh jar ./build.sh test

56. XP – Processen Bacon – att skriva tester Inbyggt test-target. Bara att skriva JUnit baserade tester. Vilka klasser som identifieras som tester styrs i project.xml av: <property name=&quot;test.include&quot; value=&quot;**/test/*Test.java&quot;/> <property name=&quot;test.exclude&quot; value=&quot;&quot;/>

57. XP – Processen Bacon – att skriva tester Enkelt att skriva tester. Klass som är identifierbar via namnet, t.ex MyClassTest.java

58. XP – Processen Bacon – att skriva tester Importera Junit: import junit.framework.TestCase; import junit.framework.TestSuite; import junit.framework.Assert;

59. XP – Processen Bacon – att skriva tester Utöka TestCase: public class MyClassTest extends TestCase{ public MyClassTest (String name){ super(name); } }

60. XP – Processen Bacon – att skriva tester Varje metod som börjar med test, inte returnerar något och inte tar några argument kommer köras. Klassen instantieras på nytt för varje testmetod som körs.

61. XP – Processen Bacon – att skriva tester Behöver man göra något innan testen körs implementerar man protected void setUp() throws Exception { } Och om något måste göra efter: protected void tearDown() throws Exception { }

62. XP – Processen Bacon – att skriva tester Skriv en test för varje feature som den klass som testas skall ha. Använd assertions.

63. XP – Processen Bacon – att skriva tester public void testSomething() trows Exception { MyClassToTest test = new MyClassToTest(); String returned = test.methodToTest(); Assert.assertEquals(“Did not work”, “expected”,returned); }

64. XP – Processen Checka in i CVS - TIDIGT

65. XP – Processen Använd Tim-BigBrother Är dokumenterad