1. 5. Widerstände bei der Einführung der Praktiken und Zusammenspiel
1.1. "The Planing Game"
1.1.1. Mögliche Schwierigkeiten
1.1.1.1. Man kann doch nicht immer den Plan überarbeiten
1.1.1.2. Es ist nicht möglich, ein komplexes Produkt herzustellen, wenn man nur ungefähre Vorstellungen hat.
1.1.2. Lösungen
1.1.2.1. Es geht aber trotzdem, wenn die Kunden selbst die Updates machen (in dem sie die Schätzungen des Entwicklungsteams nutzen)
1.1.2.2. Es geht, wenn man kurze Entwicklungszyklen hat, damit kann man Planungsfehler minimieren
1.1.2.3. Und wenn der Kunde im Team dabei ist, kann man Unklarheiten schnell beseitigen.
1.2. Small Releases
1.2.1. Mögliche Schwierigkeiten
1.2.1.1. Man kann doch nicht in kurzen Zyklen neue Releases ausliefern.
1.2.2. Lösungen
1.2.2.1. Doch geht, wenn man durch die Planung sicherstellt, dass man immer das entwickelt, was einen tatsächlichen Nutzen bringt.
1.2.2.2. Wenn man durch Tests abgesichert ist, dass man mit einem neuen Release nichts kaputt macht
1.2.2.3. Es geht, wenn das Design so ist, dass es die aktuellen Aufgabe bewältigt (und nicht für die Ewigkeit halten muss)
1.3. Produkt Vision
1.3.1. Mögliche Schwierigkeiten
1.3.1.1. In einer Metaphor steckt doch viel zu wenig Detail
1.3.2. Lösungen
1.3.2.1. Doch geht, weil man durch schnelles Feedback schnell herausfindet, ob die Vision tatsächlich passt
1.3.2.2. Es geht, wenn der Kunde versteht, worum es geht
1.3.2.3. Und man durch Refactoring die Sichtweise auf die Vision anpasst
1.4. Simples Design
1.4.1. Mögliche Schwierigkeiten
1.4.1.1. Wenn man nur so viel Designed, dass es für jetzt passt, dann landet man doch schnell in einer Ecke, aus der man nicht mehr herausfindet. Es drohen Designfehler!
1.4.2. Lösungen
1.4.2.1. Geht aber doch, weil wir durch das Refactoring ohnehin konstant Dinge ändern
1.4.2.2. Durch die VIsion weiß man, was wichtig ist, und landet so mit einer kleineren Wahrscheinlichkeit bei einem falschen Design
1.4.2.3. Durch Pair Programming betrachtet man Design-Änderungen immer durch 4 Augen. Das reduziert die Gefahr von "dummem" Design (es reicht, wenn es einfach ist)
1.5. Testen
1.5.1. Mögliche Schwierigkeiten
1.5.2. Man kann doch nicht wirklich all diese Tests schreiben. Das dauert doch viel zu lange!
1.5.3. Lösungen
1.5.3.1. Doch geht, wenn das Design simpel ist, dann sind auch die Tests simpel
1.5.3.2. Wenn man Pair-Programming betreibt, dann wird das Schreiben von Tests fester Bestandteil der Entwicklung
1.5.3.3. Man fühlt sich gut, wenn die Tests grün sind
1.5.3.4. Der Kunde findet es toll, wenn das System durch die Tests abgedeckt ist
1.6. Refactoring
1.6.1. Mögliche Schwierigkeiten
1.6.1.1. Man kann doch nicht immer das System verändern!
1.6.2. Lösungen
1.6.2.1. Doch es geht, wenn der Code allen gehört
1.6.2.2. Die Coding-Standards machen es leicht, den Code zu verstehen
1.6.2.3. Das Pair-Programming hilft es, den Mut zu haben, Dinge zu ändern
1.6.2.4. Das Simple Design macht Refactoring einfacher
1.6.2.5. Die Tests verhindern, dass man etwas kaputt macht
1.6.2.6. Continuous Integration sorgt dafür, dass auch verstecke Nebenwirkungen leicht erkannt werden
1.6.2.7. Wenn man nicht unter dem Druck von Überstunden arbeitet, kann man Änderungen mit einer gewissen Gelassenheit angehen
1.7. Pair Programming
1.7.1. Mögliche Schwierigkeiten
1.7.1.1. Man kann doch nicht tatsächlich immer alles zu zweit entwickeln?
1.7.1.2. Das kostet doch die doppelte Menge an Aufwand?
1.7.1.3. Es geht doch schneller wenn zwei Entwickler getrennt an Lösungen arbeiten!
1.7.2. Lösungen
1.7.2.1. Durch die Coding- Standards weiß jeder, wie neuer Code aussehen soll
1.7.2.2. Durch das Schreiben von Tests im Paar-Modus erkennt man viel besser Schwach- stellen in der Implementierung
1.7.2.3. Jeder im Pair weiß durch das simple Design, was gerade passiert
1.7.2.4. Durch die Rollen Driver und Navigator kann man viel besser nach- denken und es geht nichts verloren
1.7.2.5. Man kann sich nicht aus der Verantwortung stehlen; Ein Feature ist erst fertig, wenn beide Entwickler es für fertig halten. Solange man noch einen Test schreiben kann, der fehlschlägt, ist man noch nicht fertig.
1.7.2.6. Die Qualität der Software wird deutlich besser, die "verlorene Zeit" wird durch bessere Qualität mehr als wettgemacht
1.8. Kollektiver Besitz des Quelltextes
1.8.1. Mögliche Schwierigkeiten
1.8.1.1. Wenn jeder permanent alles ändern darf dann herrscht schnell Chaos!
1.8.1.2. Damit geht doch schnell alles kaputt!
1.8.2. Lösungen
1.8.2.1. Durch die Continuous Integration erkennt man Probleme durch Veränderungen schnell
1.8.2.2. Durch die Tests ist die Chance, dass man etwas unbeabsichtigt kaputt macht deutlich reduziert
1.8.2.3. Im Pair-Programming werden die Veränderungen durch 4 Augen bewertet.
1.8.2.4. Coding Standards helfen dabei, den Code so zu ändern, dass er für alle verständlich ist.
1.9. Continuous Integration
1.9.1. Mögliche Schwierigkeiten
1.9.1.1. Das dauert doch viel zu lange, alles permanent zu integrieren. Es gibt dabei viel zu viele Konflikte
1.9.2. Lösungen
1.9.2.1. Tests helfen dabei zu er- kennen, ob etwas kaputt ist.
1.9.2.2. Durch das Pair-Programming muss insgesamt weniger gleichzeitig integriert werden
1.9.2.3. Durch das permanente Refactoring ist die Menge der tatsächlichen Änder- ungen deutlich kleiner als bei lang laufenden Veränderungen
1.10. 40-hour Week
1.10.1. Mögliche Schwierigkeiten
1.10.1.1. Nur wer permanent Überstunden leistet ist ein guter Mitarbeiter!
1.10.1.2. Wir müssen Überstunden ansetzen, weil sonst zu wenig Funktionalität umgesetzt wird.
1.10.2. Lösungen
1.10.2.1. Durch das "Planing-Game" wird klar, was tatsächlich Wert erzeugt
1.10.2.2. Die Schätzungen und die Tests verhindern, dass man Überraschungen erlebt, die ad-hoc Reparaturen erfordern
1.10.2.3. Die Techniken insgesamt führen zu einem optimalen Durchsatz. Durch Überstunden lässt sich das nicht steigern, sondern nur langfristig verschlechtern.
1.11. Kunden im Entwicklungsteam
1.11.1. Mögliche Schwierigkeiten
1.11.1.1. Der Kunde könnte produktiv viel mehr Wert erzeugen!
1.11.2. Lösungen
1.11.2.1. Wenn die Software wirklich einen Nutzen bringen soll, dann ist der direkte Austausch viel wertvoller, weil die Entwickler nicht warten müssen, bzw. nicht nach ihren eigenen Vorstellungen entwickeln.
1.11.2.2. Der Kunde kann bei der Erstellung von Kunden-Tests mitwirken
1.11.2.3. Die Akzeptanz bei der Einführung ist deutlich höher, wenn ein "echter Nutzer" die Entwicklung begleitet hat
1.12. Coding standards
1.12.1. Mögliche Schwierigkeiten
1.12.1.1. Entwickler sind Individualisten, die sich nicht an Standards halten wollen!
1.12.2. Lösungen
1.12.2.1. Das Team lernt schnell, dass die anderen Techniken nur mit den Coding-Standards sinnvoll funktionieren.
1.12.2.2. Jeder Entwickler will lieber in einem Winning Team arbeiten, als an eigenen Vorstellungen festzuhalten.
2. 2. Die vier Werte von XP
2.1. Kommunikation
2.1.1. Techniken wie Pair-Programming, Stand-Up-Meeings, gemeinsame Schätz-Runden, etc.
2.2. Einfachheit
2.2.1. Wie können wir die Funktionalität am einfachsten Umsetzen?
2.3. (Schnelles) Feedback
2.3.1. Gibt es einen Test für die Funktion?
2.3.2. Ist der Kunde mit der Funktionalität zufrieden
2.4. Mut
2.4.1. Mut das richtige zu tun, d.h. Implementierungen "wegzuschmeißen", wenn sie nicht das richtige tun (oder es nicht gut genug tun).
3. 4. Konkrete XP Praktiken
3.1. The Planning Game
3.1.1. Scope (Umfang)
3.1.2. Priorität
3.1.3. Release-Planung
3.2. Small Releases
3.2.1. Alle 1-4 Wochen eine auslieferbare, lauffähige Version der Software.
3.3. Produkt-Vision
3.3.1. Damit wird für alle ersichtlich, was das Produkt leisten soll.
3.3.1.1. For (target customer) Who (statement of the need or opportunity) The (product name) is a (product category) That (key benefit, compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation)
3.4. Simples Design
3.4.1. Alle Tests laufen
3.4.2. Es gibt keine Duplikation von Logik
3.4.3. Enthält nichts überflüssiges (Kein "Das brauchen wir für später")
3.4.4. Entspricht nicht der üblichen Entwicklerhaltung!
3.4.4.1. Normalerweise möchte man schon frühzeitig Probleme lösen, die "sicherlich auftreten werden"
3.4.4.2. In der Regel hat sich bis dahin aber das Programm ohnehin geändert
3.4.4.3. Man entwickelt tatsächlich nur das, was für den jetzigen Anwendungsfall gebraucht wird!
3.4.5. Design-Strategie
3.4.5.1. 1. Erstelle einen Test, der das neue Design testet; dafür muss man in der Regel schon einen Teil als Stub implementieren, zumindest Klassen/Methoden/Interfaces
3.4.5.2. 2. Es wird nur soviel implementiert, bis der Test (und alle vorherigen Tests) grün werden
3.4.5.3. 3. Wiederholen
3.4.5.4. 4. Wenn man etwas sieht, wo man das Design vereinfachen könnte, dann mach es.
3.4.6. Manchmal dauert es auch lange, bis ein existierendes Design einfacher wird. Man verwendet kleine Schritte beim Design-Refactoring.
3.4.7. Was ist "Simple"
3.4.7.1. 1. Das System (der Quelltext und die Tests) "kommunizieren" alles, was man über das System wissen muss
3.4.7.1.1. d.h. es gibt Klassen und Methoden für alle wichtigen Konzepte
3.4.7.2. 2. Es gibt keinen duplizierten Code und keine duplizierte Logik
3.4.7.2.1. Das ist in der Regel schwierig: erst muss man die Duplikate finden, und dann einen Weg, um sie zu eliminieren.
3.4.7.3. 3. Das System sollte nur soviele Klassen beinhalten, wie es für die "Kommunikation" notwendig ist.
3.4.7.3.1. Das bedeutet aber eben nicht, dass man eine "Monsterklasse" mit allen Methoden schafft. Es gilt die Regel, dass jede Klasse (und jede Methode) einen klar definierten Zweck erfüllt.
3.4.7.4. 4. Das System sollte auch nur aus so vielen Methoden bestehen, wie nötig
3.4.8. Design kann durch Bilder beschrieben werden
3.4.8.1. z.B. UML Diagramme
3.4.8.2. aber am Ende ist der Quelltext die "Quelle der Wahrheit"
3.4.9. Es gibt genau soviel Architektur wie nötig, um die aktuellen Aufgaben zu bewältigen.
3.5. Testen
3.5.1. Quellcode ohne Test gilt als nicht existent
3.6. Refactoring
3.6.1. Wie kann man ein neues Feature so einbauen, dass es möglichst "natürlich" und ohne viele Änderungen geht?
3.7. Pair Programming
3.7.1. Zwei Entwickler an einem Computer.
3.7.2. Einer ist der Driver
3.7.3. Der andere der Navigator
3.7.4. Dynamisch innerhalb des Teams, wechselnde Paarungen
3.8. Kollektiver Besitz des Quelltextes
3.8.1. Jeder, der etwas verändern möchte, darf das tun.
3.8.2. Das stärkt das Verantwortungsgefühl und das Gesamtverständnis.
3.9. Continuous Integration
3.9.1. Autmatisches Testen und Bauen, Schnelles Feedback.
3.10. 40-hour Week
3.10.1. Keine dauerhaften Überstunden.
3.11. Kunden im Entwicklungsteam
3.11.1. Ein tatsächlicher Nutzer des Sysstems soll mit dem Team zusammen sitzen. Damit lassen sich Fragen klären und eine tatsächlich nutzbare Software viel leichter entwickeln.
3.12. Coding standards
3.12.1. Möglichst einfache Regeln.
3.12.2. Die einzige Regel, die IMMER gilt: DRY: Don't Repeat Yourself.
4. Menschen mögen Erfolg. Menschen mögen es, Dinge zu lernen. Menschen möchten mit anderen Menschen interagieren. Menschen möchten Teil einer Gruppe sein. Menschen mögen es, etwas gut zu machen. Menschen mögen es, wenn ihre Software funktioniert
5. 1. Motivation
5.1. 1.1. Übliche Probleme (klassischer Ansatz)
5.1.1. Projektplanung wird nicht eingehalten
5.1.1.1. Lösung: Kürzere Release-Zyklen, Tasks dauern maximal 3 Tage. Höchste Prioritäten werden zuerst implementiert
5.1.2. Projekte werden vorzeitig beendet (ohne Ergebnis)
5.1.2.1. Lösung: Wegen der kürzeren Zyklen kann man viel früher absehen, ob das Projekt tatsächlich einen Nutzen bringt.
5.1.3. Die Kosten für Änderungen an Softwaresystemen steigt so stark, dass man nichts mehr ändern möchte
5.1.3.1. Lösung: Test-Suiten und kontinuierliche Integration
5.1.4. Zu viele Fehler
5.1.4.1. Testfälle sowohl auf Entwicklungs- als auch auf Kundenseite. (Automatisierte Tests)
5.1.5. Software liefert zwar eine Lösung, aber leider nicht Lösung für das Problem
5.1.5.1. Kunden sind elementarer Bestandteil des Teams, Spezifikationen werden also permanent dem "Realitätstest" unterzogen
5.1.6. Verändertes Geschäft
5.1.6.1. Kürzere Release-Zyklen, deshalb besser adaptierbar.
5.1.7. Zu viele Features, die zwar schick aussehen, aber beim Kunden kein Geld verdienen
5.1.7.1. Nur die Features mit der höchsten Priorität werden entwickelt.
5.1.8. Personal-Fluktuation -> Programmierer verlassen das Projekt
5.1.8.1. Die einzelnen Entwickler haben mehr Verantwortung für die eigenen Aufgaben. Die Tests helfen; es gibt klare Regeln, wer und was man ändern darf. Insgesamt wird eine Personenwechsel durch XP deutlich leichter.
5.2. 1.2 Allgemeine Variablen in der Softwareentwicklung
5.2.1. Kosten
5.2.1.1. Zu wenig Geld ist schlecht, zu viel ist auch nicht gut.
5.2.1.2. Über Kosten wird häufig gesteuert. (Management-Variable)
5.2.1.3. Kosten sagen häufig etwas über den "Status" aus, aber nicht immer über den tatsächlichen Nutzen (Beispiel: Man besorgt mehr Geld, um mehr Entwickler einzustellen)
5.2.1.4. Geld kann manchmal sinnvoll sein (bessere Computer, bessere Tools, etc.)
5.2.1.5. Die Erfahrung bei "klassicher Entwicklung" hat gezeigt, dass die Kosten für Änderungen exponentiell steigen, je länger das Projekt entwickelt wird
5.2.1.5.1. Das hat dazu geführt, dass man versucht hat, Änderungen so früh wie möglich zu machen, bzw. Änderungen mit der Zeit immer weniger zugelassen hat.
5.2.1.5.2. Das heißt, man musste am Anfang wissen, was man will, denn wenn man es später ändert, war es extrem teuer.
5.2.1.5.3. Das zentrale Versprechen von XP (Agilen Verfahren) ist, dass die Kosten für Änderungen beherrschbar sind, und nicht ansteigen, sondern sich an eine Asymptote annähern.
5.2.1.5.4. Das dreht dann auch "das Denken" um: man entwickelt nur das, von dem man weiß, dass man es unbedingt tun muss. Alle Dinge, die man noch später entscheiden kann, werden erst später entscheiden und erst später umgesetzt.
5.2.1.5.5. Zentrale Techniken für die "kostengünstige" Veränderbarkeit von Systemen sind
5.2.2. Zeit
5.2.2.1. Zu wenig ist definitiv schlecht. Zu viel ist auch nicht gut.
5.2.2.2. Zeit wird häufig von außen vorgegeben (z.B. eine Messe bis zu der eine Version fertig sein muss, etc.)
5.2.3. Qualität
5.2.3.1. Abstriche an der Qualität (um zum Beispiel ein Zeitziel zu halten) kosten üblicherweise hinterher sehr viel mehr!
5.2.3.2. In der Regel führt ein hoher Qualitätsanspruch zu SCHNELLERER Entwicklung. (Testfälle sind vorhanden, Sicherheit bei Änderungen ist deutlich höher).
5.2.3.3. Es gibt einen Unterschied zwischen interner und externer Qualität.
5.2.3.3.1. Interne Qualität wird durch die Entwickler "gemessen"
5.2.3.3.2. Externe Qualität wird durch Kunden gemessen.
5.2.3.4. In der agilen Entwicklung liegt der Fokus auf der "internen" Qualität - Abstriche sind unbedingt zu vermeiden.
5.2.4. Umfang
5.2.4.1. Weniger ist mehr.
5.2.4.2. Diese Variable ist die Wichtigste
5.2.4.3. Meistens hat man am Anfang keine Ahnung, wie der Umfang der "fertigen" Software tatsächlich sein muss.
5.2.4.4. Wenn man den Umfang gut steuert, dann kann man Kosten, Zeit und Qualität darüber definieren!
5.2.4.5. Üblicherweise jammern Entwickler: "Der Kunden sagen gar nicht, was sie wollen. Wenn wir das bauen, was sie sagen, dann mögen sie es nicht!"
5.2.4.5.1. Aber genau darin liegt die Chance: Man lernt inkrementell, man verändert inkrementell. Der Schlüssel liegt in der gemeinsamen Arbeit.
5.2.4.5.2. Voraussetzung ist aber die Beherrschung von Schätzungen und die Wichtigkeit von Prioritäten (die sich natürlich auch ändern dürfen)
6. 6. Vergleich SCRUM und XP
6.1. Planning-Game und Sprints
6.1.1. Ist sehr ähnlich
6.1.2. User Stories enthalten die für den Kunden sichtbaren / beschreibbaren Veränderungen
6.1.3. Die Schätzung wird in Story-Points durch das ganze Team vorgenommen
6.1.4. Die Priorisierung erfolgt durch den Auftraggeber
6.1.5. Unterschied liegt in der Flexibilität
6.1.5.1. In SCRUM wird ein Sprint immer so entwickelt, wie er ursprünglich geplant war
6.1.5.2. Bei XP kann man neue Stories hinzufügen oder existierende zurückstellen oder löschen
6.1.6. Wichtig ist bei beiden Methoden die Velocity und die Planbarkeit von Entwicklungs-Zyklen
6.2. Rollen
6.2.1. Bei SCRUM gibt es klare definierte Rollen (SRUM-Master, Product-Owner, Team)
6.2.2. Bei XP gibt es das Team, (mit einem "echten" Kunden als Team-Mitglied) und es gibt
6.3. SRCUM hat keine festgelegten Techniken, sondern legt den Fokus auf den Entwicklungsprozess mit Sprints, Sprint-Planning, Retrospectives, etc.
6.3.1. Kein "Zwang" zum Pair-Programming
6.3.2. Kein "Zwang" zum Test-Driven Development
6.3.3. etc.
6.3.4. Die Techniken können aber natürlich trotzdem eingesetzt werden
6.4. XP wird durch die festgelegten Techniken definiert. Der Prozess ist Teil der Techniken.
6.4.1. Die wichtigsten Techniken in XP sind:
6.4.2. Pair-Programming
6.4.2.1. Hat viele Facetten
6.4.2.2. Ist für den Einstieg für viele schwierig
6.4.2.3. Erfordert Mut und Offenheit
6.4.2.4. Bringt - wenn man es anwendet - sehr gute Ergebnisse!
6.4.3. Test-Driven-Development
6.4.4. Planning-Game
6.4.5. Refactoring und Contiuous Integration
6.4.6. Simple Design
7. Lernziele
7.1. XP bedeutet die parallele Nutzung von an sich einfachen Basis-Techniken
7.2. Der Mehrwert entsteht dadurch, dass die einfachen Techniken klare Stärken haben, und das die jeweiligen Schwächen durch andere Techniken abgemildert werden.
7.3. XP ist nicht beliebig, sondern erfordert Disziplin!
7.4. Trotzdem ist die Einführung von XP nicht immer Einfach. Es gibt Widerstände, deren Überwindung manchmal nicht einfach ist.
8. 3. Allgemeines Vorgehen
8.1. XP Entwicklung ist wie Autofahren
8.2. Kontinuierliche kleine Adaptionen (Steuern); es geht nicht darum, einmal die Richtung festzusetzen, sondern darum, aufzupassen und durch kleine Änderungen zum Ziel zu kommen.
8.3. 1. Coding
8.3.1. Funktionierender Quelltext ist das Ergebnis von Software-Entwicklung
8.4. 2. Testing
8.4.1. Tests ermöglichen es, zu wissen wann man mit dem Kodieren aufhören kann. Sie geben Sicherheit und Freude.
8.5. 3. Zuhören
8.5.1. Nur so, weiß man, was man bauen muss.
8.5.2. Dem Kunden zuhören, den Kollegen zuhören, Fragen stellen.
8.6. 4. Design
8.6.1. Strukturieren, Module bilden, Funktionalitäten bündeln, Komplexität reduzieren.