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

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

Kein XP - Projekt Ein leider typisches Beispiel

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

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

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

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

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

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

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

Planning XP Wie wird geplant in einem XP- Projekt?

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

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

Planning XP Small Releases

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

Planning XP Projektgeschwindigkeit messen

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

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

Planning XP Iteration Planning Meeting

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

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

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

XP Developement Entwickeln in einem XP Projekt

XP Developement Simple Design

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

XP Developement Pair Programming

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

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

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

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

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

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

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

XP Developement 40 Hour Week Spikes Sprints CRC-Cards

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

XP = Testing

Automatisches Testen Konstantes Testen Komponententest Akzeptanztests

XP = Testing Test-Driven-Developement

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

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

XP = Testing Everything that can possibly break

XP = Testing Bug handling

How XP works Wie alles zusammenspielt

How XP works

Problems with XP Die dunkle Seite der Macht

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

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?“

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“

Ende