Extreme Programming IEEE-Special von Michael Glögl Gehalten am 09.01.2003.

Präsentation zum Thema: "Extreme Programming IEEE-Special von Michael Glögl Gehalten am 09.01.2003."—  Präsentation transkript:

1 Extreme Programming IEEE-Special von Michael Glögl Gehalten am 09.01.2003

2 Inhalt Lightweight vs. Heavyweight Probleme von Heavyweight-Prozessen XP – Radikale Ansätze Prinzipien von XP Zusammenspiel der Prinzipien Probleme bei XP

3 Kein XP - Projekt Ein leider typisches Beispiel

4 Light-/Heavyweight Heavyweight: –Viele Prinzipien –Komplexe Regeln –Viel Disziplin nötig –Zeitaufwendig Lightweight: –Wenige Prinzipien –Simple Regeln –Wenig Disziplin nötig –Wenig zusätzlicher Zeitaufwand

5 Probleme bei Heavyw. Schwer zu befolgen –Behindern den Entwickler –Werden vom Entwickler umgangen Komplexe Prozeduren –Schlecht verstanden –Halbherzig befolgt

6 Probleme bei Heavyw. Zuviel Abstraktion –Zu viele Dokumente in abstrakter Notation –CASE-Tool Wucherung Over-Engineering –Entwurf passt nicht zum Problem –Entwurf schwer einzuhalten –Entwurf zu komplex

7 Probleme bei Heavyw. Kommunikationsprobleme –Kunde ändert seine Wünsche –Entwickler entwickeln am Kunden vorbei Probleme im Team –Truck-Faktor –Cowboy-Coder

8 XP – Radikale Ansätze XP als Leichtgewichtiger Prozess Vier Bereiche der XP-Praktiken: –Planning –Coding –Testing –Designing

9 XP – Radikale Ansätze 4 Kern-Werte: –Einfachheit –Kommunikation –Feedback –Mut

10 XP – Radikale Ansätze Embrace change Design when needed As simple as it possibly works Frequent integration Pair programming Short releases Collective Code ownership

11 Planning XP Wie wird geplant in einem XP- Projekt?

12 Planning XP User Stories –Der Kunde formuliert in kurzen „Geschichten“ was das Produkt können soll –Ca. 3 Sätze –Nur einzelne Teilaspekte des Projekts –Wenig Details – nur zur Zeitabschätzung –Kein Technobabble

13 Planning XP Release Planning –Zeitplan wird erstellt –Entwickler schätzen den Zeitbedarf der Stories bei idealen Entwicklungsbedingungen –Kunde priorisiert die Stories –Der Umfang der ersten Iteration wird festgelegt

14 Planning XP Small Releases

15 Planning XP Im Release Planning Meeting Festgelegt Möglichst oft Releasen Teilfunktionalitäten Wichtigstes zuerst zum Kunden

16 Planning XP Projektgeschwindigkeit messen

17 Planning XP Keine umfangreiche Metrik Iterationsgeschwindigkeit: –Summe der Aufwandsschätzungen für die während der Iteration abgearbeiteten Stories –Gummibären - Methode

18 Planning XP Iterationen –Aufteilung in 1-3 Wochen lange Iterationen –Neuplanung der Aufgaben zu jeder Iteration –Nichts für weitere Iterationen vorausplanen –Iterations-Abschnitte einhalten

19 Planning XP Iteration Planning Meeting

20 Planning XP Zu Beginn jeder Iteration Kunde sucht Stories für Iteration aus Umfang: Durchschnittliche Iterationsgeschw. Evtl. Aufteilen der Stories in Tasks

21 Planning XP Metapher: –Einfaches Leitbild für Gestaltung der Software –Basis für Designentscheidungen

22 Planning XP Stand-Up-Meeting –Am Anfang des Tages –Nur das Team –Stehend –Probleme, Lösungen, Fokusierung –Kurz

23 XP Developement Entwickeln in einem XP Projekt

24 XP Developement Simple Design

25 XP Developement You ain‘t gonna need it As simple as it possibly works Kein „Upfront Design“ Prioritäten: –Verständlichkeit –kein duplicate Code –so wenig Klassen wie möglich –so wenig Methoden wie möglich

26 XP Developement Pair Programming

27 XP Developement Immer 2 Entwickler zusammen Driver / Reviewer wechseln ständig Reduzieren des „Truck-Faktors“ Kontrollieren von Cowboy-Codern Gesteigerte Konzentration Alleine programmiertes kommt nicht ins Projekt

28 XP Developement Collective Code Ownership –Keine „Arbeitsbereiche“ –Unbequeme Klassen ändern –Keine Blockaden durch Klassen anderer

29 XP Developement Refactoring –Ständiges Refactoring –Schlechtes Design sofort beheben –Kein „Never Change a Running System“ –ALLES ändern was die interne Struktur verbessert –nur Minuten pro Refactoring

30 XP Developement Coding Standards –Gemeinsames Regelwerk –Beispiel JCC –Ziel: Nicht unterscheidbar wer Code geschrieben hat –Ziel: Gute Lesbarkeit fremden Codes

31 XP Developement Continuous Integration –Ständige Integration –mindestens einmal täglich pro Entwicklerpaar –Ziel: 10-20 tägliche Integrationen pro Team –Unterstützung durch Entwicklungswerkzeuge!

32 XP Developement On-Site-Customer –Ein Vertreter des Kunden ist vor Ort –Schnelle Möglichkeit für fachliche Rückfragen –Vertreter der Anwender des Systems

33 XP Developement Dokumentation –Sourcecode als einzige teaminterne Doku –Keine Umfangreichen Papierwüsten

34 XP Developement 40 Hour Week Spikes Sprints CRC-Cards

35 XP = Testing Testen, Testen, Testen – und dann nochmal Testen

36 XP = Testing

37 Automatisches Testen Konstantes Testen Komponententest Akzeptanztests

38 XP = Testing Test-Driven-Developement

39 XP = Testing Komponententest (Unit-Test) –Test-Driven-Developement –Test First –Test – Framework nötig –Fast Feedback –Alle Entwickler schreiben Tests –„Untestbarkeit“ gibt es nicht

40 XP = Testing Akzeptanztests –Testen die Funktionalität –Werden vom Kunden geschrieben –Entwickler unterstützen nur wenn nötig –Decken die User-Stories ab

41 XP = Testing Everything that can possibly break

42 XP = Testing Bug handling

43 How XP works Wie alles zusammenspielt

44 How XP works

45

46

47

48

49 Problems with XP Die dunkle Seite der Macht

50 Problems with XP Nicht für große Teams (4-16) Gerade Anzahl Entwickler Nicht für räumlich getrennte Teams On-Site-Customer Psychologie / Politik „Kommunismus-Problem“ technische Probleme

51 Problems with XP Problemanzeichen: –„Es ist viel besser erst Story C als Story B zu machen, auch wenn der Kunde anders priorisiert hat“ –Deadlines verschieben anstatt Funktionalität reduzieren –„Ich als Programmierer schreibe meine Klasse, und probiere ob sie tut was ich will. Danach schreibe ich keine Tests mehr. Warum auch?“

52 Problems with XP Problemanzeichen: –„Das Refactoring lässt sich nicht zerlegen“ –Fortlaufende Integration ohne automatische Tests –„Routineaufgaben muss man nicht im Paar programmieren“ –„Dazu muss erst XXX installiert/geschult werden“ –„Da muss erstmal ein ordentliches Konzept gemacht werden“

53 Ende