Programmierung Lernhilfe

1. Extreme Programming (XP)

Werte und Prinzipien

XP basiert auf einer Reihe von Werten und Prinzipien, die das Vorgehen des Teams leiten.

Werte:

Kommunikation: Face-to-Face-Kommunikation wird bevorzugt, um Missverständnisse zu vermeiden.
Einfachheit: Es wird nur das getan, was notwendig ist, um die aktuellen Anforderungen zu erfüllen.
Feedback: Kontinuierliches Feedback von Kunden und Teammitgliedern wird gesucht.
Mut (Courage): Mut, die Wahrheit über den Fortschritt zu sagen und überflüssige Arbeit zu verwerfen.
Respekt: Jedes Teammitglied respektiert und schätzt die Arbeit der anderen.

Prinzipien:

Humanity: Fokussiert auf das Wohlbefinden und die Entwicklung der Menschen im Team.
Economics: Priorisiert die Features, die den größten wirtschaftlichen Nutzen bringen.
Quality: Strebt nach hoher Qualität, um die Wartbarkeit zu sichern.
Baby Steps: Große Probleme werden in kleine, handhabbare Schritte zerlegt.

Planungsregeln

User Stories werden geschrieben: Anforderungen werden in Form von User Stories formuliert, die aus der Perspektive des Endbenutzers geschrieben sind.
Release Planning erstellt den Release-Zeitplan: Das Team und der Kunde entscheiden gemeinsam, welche User Stories in einem Release enthalten sein sollen und wann es veröffentlicht wird.
Kleine Releases: Die Software wird in kleinen, funktionsfähigen Paketen häufig veröffentlicht.
Das Projekt wird in Iterationen unterteilt: Iterationen sind feste Zeiträume (oft 1-4 Wochen), in denen das Team an einer bestimmten Anzahl von User Stories arbeitet.
Iteration Planning startet jede Iteration: Zu Beginn jeder Iteration plant das Team, welche User Stories es umsetzen wird.

Verwaltungsregeln

Dem Team wird ein eigener, offener Arbeitsbereich gegeben: Ein offenes Büro fördert die direkte Kommunikation.
Ein Stand-up-Meeting beginnt jeden Tag: Ein kurzes tägliches Treffen zur Synchronisierung und zum Teilen von Fortschritten und Hindernissen.
Ein nachhaltiges Tempo festlegen: Das Team arbeitet in einem Tempo, das es langfristig durchhalten kann, um Überlastung zu vermeiden.
Die Projekt-Velocity wird gemessen: Die Menge an abgeschlossenen User Stories pro Iteration wird gemessen, um zukünftige Planungen zu erleichtern.
Menschen bewegen (Wissensaustausch): Teammitglieder wechseln die Paare und Aufgaben, um Wissen zu verbreiten und neue Fähigkeiten zu lernen.
XP reparieren, wenn es kaputt ist: Das Team muss seine Prozesse kontinuierlich reflektieren und verbessern.

Entwurfsregeln

Einfachheit: Das Design sollte so einfach wie möglich sein und nur die aktuellen Anforderungen erfüllen.
Eine Systemmetapher wählen: Eine einfache, gemeinsame Geschichte über das System, um das Verständnis zu verbessern.
CRC-Karten für Design-Sessions verwenden: Klassen, Verantwortlichkeiten und Kollaborateure werden auf Indexkarten entworfen, um die Interaktionen zu visualisieren.
Spike Solutions (Prototypen) erstellen, um Risiken zu reduzieren: Kleine, einfache Programme, um eine technische Frage oder ein Risiko zu klären.
Keine Funktionalität wird zu früh hinzugefügt: Features werden erst dann implementiert, wenn sie wirklich benötigt werden.
Refactoring, wo und wann immer möglich: Der Code wird kontinuierlich umstrukturiert und vereinfacht, um ihn sauberer und wartbarer zu machen.

Testregeln

Jeder Code muss Unit-Tests haben: Jede Code-Einheit wird durch automatisierte Tests abgedeckt.
Jeder Code muss alle Unit-Tests bestehen: Code wird nur eingecheckt, wenn alle Tests erfolgreich durchlaufen.
Wenn ein Bug gefunden wird, werden Tests erstellt: Für jeden entdeckten Fehler wird zuerst ein automatisierter Test geschrieben, der diesen Fehler reproduziert.
Akzeptanztests werden oft ausgeführt: Tests, die die Funktionalität aus Kundensicht überprüfen, werden regelmäßig ausgeführt.

Codierungsregeln

Der Kunde ist immer verfügbar: Der Kunde oder eine Kundenvertretung ist jederzeit für Fragen erreichbar.
Code muss nach vereinbarten Standards geschrieben werden: Eine einheitliche Kodierungspraxis erleichtert die Zusammenarbeit.
Zuerst den Unit-Test schreiben: Vor der Implementierung eines Features wird der Test geschrieben (Test-Driven Development).
Der gesamte Produktionscode wird im Pair-Programming geschrieben: Zwei Entwickler arbeiten an einem Computer zusammen.
Nur ein Paar integriert Code gleichzeitig: Das verhindert Konflikte beim Einchecken.
Häufig integrieren: Code wird in kurzen Abständen in den Hauptzweig integriert.
Einen dedizierten Integrationscomputer einrichten: Ein separater Computer führt kontinuierlich alle Tests aus, um Integrationsfehler frühzeitig zu erkennen.
Kollektiven Besitz fördern: Jedes Teammitglied ist dafür verantwortlich, jeden Teil des Codes zu verstehen und zu verbessern.

2. Theory of Constraints (TOC) angewendet auf Agile

Die Theory of Constraints (TOC) ist eine Management-Philosophie, die darauf abzielt, die Leistung eines gesamten Systems zu verbessern, indem sie sich auf dessen Hauptengpass (Constraint) konzentriert. Sie ist kein Bestandteil von Extreme Programming, ist aber sehr kompatibel, da sie einen systematischen Weg bietet, die in XP angestrebte kontinuierliche Verbesserung umzusetzen. Der Fokus von XP auf schnellem Feedback und nachhaltiger Geschwindigkeit macht es zu einem idealen Kandidaten für die Anwendung der TOC.

Die 5 Fokusschritte der TOC

Den Engpass identifizieren: Finden Sie den einzelnen Teil des Prozesses, der die Geschwindigkeit, mit der das Team Wert schafft, am meisten einschränkt. In einem agilen Kontext könnte dies ein überlasteter Entwickler, ein langsamer Code-Review-Prozess oder eine fehlende Ressource sein.
Den Engpass ausnutzen: Machen Sie das Beste aus dem Engpass, indem Sie sicherstellen, dass er immer produktiv ist. Wenn der Engpass beispielsweise der Code-Review-Prozess ist, stellen Sie sicher, dass immer Code zur Überprüfung bereitsteht, ohne dass der Reviewer auf die Arbeit anderer warten muss.
Alles dem Engpass unterordnen: Passen Sie alle anderen Prozesse und Aktivitäten so an, dass sie den Engpass unterstützen. Das bedeutet, dass der Rest des Teams langsamer arbeiten kann, um Qualität zu sichern, oder sich auf Aufgaben konzentriert, die dem Engpass zuarbeiten.
Den Engpass beseitigen: Wenn die ersten drei Schritte nicht ausreichen, um das Problem zu lösen, investieren Sie in die Beseitigung des Engpasses. Dies kann Schulungen, die Automatisierung von Prozessen oder die Vergrößerung des Teams umfassen.
Den Prozess wiederholen: Wenn der ursprüngliche Engpass beseitigt ist, wird ein neuer entstehen. Das Team sollte den Zyklus von Inspektion und Anpassung fortsetzen, um den nächsten Engpass zu finden und zu verbessern.

3. Software-Wiederverwendung

Wiederverwendungsarten

Design Reuse: Wiederverwendung von Architekturmodellen.
Vorteile: Frühzeitige Identifizierung von Problemen. Nachteile: Schwierig, Auswirkungen auf Kosten und Qualität abzuschätzen.
Code Reuse: Wiederverwendung von Quellcode oder APIs.
Vorteile: Einfache Kostenschätzung. Nachteile: Mögliche Probleme mit geringer Codequalität und Code-Klonen.
Process Reuse: Wiederverwendung von Produktions- und Verteilungsmodellen.
Vorteile: Schnelle Übernahme von Tools. Nachteile: Herausfordernd, mit lokalen agilen Praktiken in Einklang zu bringen.

Messung der Wiederverwendbarkeit

Die Wiederverwendbarkeit von Software kann anhand mehrerer Dimensionen gemessen werden:

Reuse: Häufigkeit und Umfang der Wiederverwendung.
Adaptability: Anpassbarkeit an Programmiersprachen und Schnittstellen.
Price: Monetärer Wert.
Quality: Vorhandensein von Tests und Fehlern.
Complexity: Größe und Kopplung.

4. Open-Source Software

Open-Source-Projekte wie der Apache Server und Mozilla bieten Einblicke in alternative Entwicklungsmodelle.

Apache Server

Breite Beteiligung bei der Fehlerbehebung.
Geringe Fehlerdichte vor dem Systemtest.
Kein strikter Codebesitz, basierend auf gegenseitigem Vertrauen.

Mozilla

Strikter Codebesitz durch Modul-Eigentümer.
Längere Lösungsintervalle aufgrund strukturierterer Prozesse.
Umfangreiche Test- und Inspektionsphasen.

"Given enough Eyeballs, All bugs are Shallow" - Linus Torvalds