05 Agile Entwicklung Teil 1: Philosophie, Praktiken und User Stories

January 2026 (7341 Words, 41 Minutes)

1. Einführung: Vom Scheitern zur Agilität

In Teil 2 des Requirements Engineering haben wir untersucht, warum traditionelle Softwareentwicklungsmodelle oft scheitern. Wir haben vier kritische Probleme identifiziert:

1. Spätes Feedback — Funktionierende Software erscheint 6-18 Monate nach den Anforderungsentscheidungen, was bedeutet, dass Fehler viel zu spät entdeckt werden
2. Die Kurve der Änderungskosten — Boehms Forschung zeigte, dass Fehler, die in der Produktion gefunden werden, 30-100x mehr kosten zu beheben als solche, die während der Anforderungsphase erkannt werden
3. Drei falsche Annahmen:
   • “Wir können alle Anforderungen im Voraus kennen”
   • “Wir können vollständig entwerfen, bevor wir programmieren”
   • “Wir können es beim ersten Mal richtig bauen”
4. Das Planungsparadox — Wenn wir mehr planen, verschwenden wir Zeit mit Plänen, die sich ändern werden. Wenn wir weniger planen, bauen wir das Falsche.

Diese Probleme sind nicht nur theoretisch. Sie haben unzählige Projektfehlschläge, Kostenüberschreitungen und frustrierte Entwickler und Benutzer verursacht.

Aber was, wenn das Problem nicht die schlechte Ausführung traditioneller Methoden ist? Was, wenn die Methoden selbst grundlegend fehlerhaft sind?

In dieser zweiteiligen Vorlesungsreihe erkunden wir einen alternativen Ansatz: Agile Entwicklung. Anstatt Unsicherheit mit mehr Planung zu bekämpfen, umarmt Agile die Unsicherheit und baut Prozesse, die sich an Veränderungen anpassen.

Teil 1 (diese Vorlesung) behandelt die philosophische Grundlage, das Agile Manifest, Extreme Programming-Praktiken und User Stories. Teil 2 behandelt das Scrum-Framework, die Sprint-Durchführung und reale Belege für die Einführung von Agile.

2. Lernziele

Am Ende dieser Vorlesung werden Sie in der Lage sein:

1. Die philosophische Grundlage zu erklären von Agile unter Verwendung von Herbert Simons Konzept der begrenzten Rationalität
2. Die vier Werte und zwölf Prinzipien des Agilen Manifests zu artikulieren
3. Extreme Programming (XP) Praktiken anzuwenden einschließlich TDD, Refactoring, Pair Programming und Continuous Integration
4. Menschliches und KI-Pair-Programming zu vergleichen — zu verstehen, wann welcher Ansatz den größten Nutzen bietet
5. Effektive User Stories zu schreiben unter Verwendung des “Als [Rolle] möchte ich [Funktion], damit [Nutzen]”-Formats mit Akzeptanzkriterien
6. User Stories mit GitHub Issues zu verfolgen — Labels, Meilensteine, Aufgabenlisten und Projektboards
7. Agile Praktiken mit Testing zu verbinden — zu verstehen, wie iterative Entwicklung sich mit TDD und CI integriert

3. Herbert Simons Begrenzte Rationalität: Die philosophische Grundlage

Bevor das Agile Manifest 2001 geschrieben wurde, hatte ein Nobel-Preisträger der Wirtschaftswissenschaften bereits erklärt, warum traditionelle Planungsansätze zum Scheitern verurteilt sind.

3.1 Wer war Herbert Simon?

Herbert Alexander Simon (1916-2001) war ein amerikanischer Universalgelehrter, dessen Arbeit Wirtschaftswissenschaften, kognitive Psychologie, Informatik und Organisationstheorie umfasste. Er verbrachte den größten Teil seiner Karriere an der Carnegie Mellon University, wo er half, eine der ersten Informatik-Fakultäten der Welt zu gründen.

Simon erhielt zwei der höchsten Auszeichnungen in verschiedenen Bereichen:

• ACM Turing Award (1975) — für Beiträge zur künstlichen Intelligenz
• Nobelpreis für Wirtschaftswissenschaften (1978) — für seine Forschung zur Entscheidungsfindung in Organisationen

Sein einflussreichstes Werk, Administrative Behavior (1947), führte ein Konzept ein, das revolutionieren sollte, wie wir über menschliche Entscheidungsfindung denken.

3.2 Begrenzte Rationalität erklärt

Die klassische Wirtschaftswissenschaft ging davon aus, dass Menschen perfekt rationale Entscheidungsträger sind — sie sammeln alle verfügbaren Informationen, bewerten alle möglichen Alternativen und wählen die optimale Lösung.

Simon argumentierte, dass dies Fiktion ist. In Wirklichkeit stehen Menschen vor drei grundlegenden Einschränkungen:

Aufgrund dieser Einschränkungen argumentierte Simon, dass Menschen nicht optimieren — sie satisfizieren (ein Wort, das er prägte, aus dem Englischen “satisfy” und “suffice”). Wir finden nicht die beste Lösung; wir finden eine Lösung, die gut genug ist angesichts unserer Beschränkungen.

3.3 Die Verbindung zur Softwareentwicklung

Simons Erkenntnis hat tiefgreifende Auswirkungen auf die Softwareentwicklung:

Wenn begrenzte Rationalität wahr ist, dann sind vollständige Anforderungsspezifikationen unmöglich. Die Wasserfall-Annahme — “wir können alle Anforderungen im Voraus kennen” — ist nicht nur schwer zu erreichen; sie ist philosophisch inkohärent.

Betrachten Sie unser Road Profile Viewer-Projekt. Selbst bei sorgfältiger Anforderungserhebung können wir nicht voraussehen:

• Wie Benutzer tatsächlich mit der Upload-Funktion interagieren werden
• Welche Randfälle in der Produktion auftreten werden
• Wie sich das zugrunde liegende Dash-Framework ändern könnte
• Welche neuen Funktionen Benutzer anfordern werden, nachdem sie die funktionierende Software gesehen haben

Das ist kein Versagen unseres Anforderungsprozesses — es ist eine fundamentale Eigenschaft der menschlichen Kognition.

flowchart LR
    subgraph Traditional["Traditionelle Annahme"]
        direction TB
        A1[Vollständige Information] --> B1[Optimale Entscheidung]
        B1 --> C1[Perfektes System]
    end

    subgraph Bounded["Begrenzte Rationalität (Realität)"]
        direction TB
        A2[Begrenzte Information] --> B2[Zufriedenstellende Entscheidung]
        B2 --> C2[Aus Nutzung lernen]
        C2 --> D2[Anpassen & Verbessern]
        D2 --> A2
    end

    Traditional ~~~ Bounded

Simons Schlussfolgerung: Anstatt so zu tun, als könnten wir ein perfektes Vorausverständnis erreichen, sollten wir Prozesse aufbauen, die Lernen und Anpassung umfassen. Genau das tut Agile.

4. Übersicht über agile Methoden

4.1 Der Aufstieg von Agile: Historischer Kontext

In den 1980er und frühen 1990er Jahren glaubte die Software-Engineering-Community, dass bessere Software durch sorgfältige Projektplanung, formalisierte Qualitätssicherung und rigorose, kontrollierte Entwicklungsprozesse entsteht. Dieser “plangetriebene” Ansatz wurde für große, langlebige Systeme wie Luft- und Raumfahrt- und Regierungssoftware entwickelt — Projekte, die bis zu 10 Jahre von der Spezifikation bis zur Bereitstellung dauern können.

Als dieser schwergewichtige Ansatz jedoch auf kleine und mittelgroße Geschäftssysteme angewendet wurde, traten Probleme auf:

• Mehr Zeit wurde für Prozesse als für Programmierung aufgewendet — die Dokumentation, wie das System entwickelt werden sollte, verbrauchte Ressourcen, die in die eigentliche Entwicklung hätten fließen können
• Ständige Nacharbeit bei Anforderungsänderungen — wenn sich Anforderungen änderten (was sie unweigerlich taten), mussten Spezifikationen und Entwürfe zusammen mit dem Code aktualisiert werden
• Software wurde zu spät geliefert — bis die Software verfügbar war, hatte sich der ursprüngliche Geschäftsbedarf oft so radikal geändert, dass die Software praktisch nutzlos war

Die Unzufriedenheit mit diesen schwergewichtigen Ansätzen führte zur Entwicklung von agilen Methoden in den späten 1990er Jahren, darunter Extreme Programming (Beck 1999), Scrum (Schwaber und Beedle 2001) und DSDM (Stapleton 2003).

4.2 Was macht eine Methode “agil”?

Alle agilen Methoden teilen drei grundlegende Eigenschaften:

Das Ergebnis: Agile Methoden erstellen neue Releases alle zwei bis drei Wochen, beziehen Kunden ein, um schnelles Feedback zu erhalten, und minimieren Dokumentation durch die Verwendung informeller Kommunikation anstelle formeller Meetings mit schriftlichen Dokumenten.

flowchart LR
    subgraph Plan["Plangetriebene Entwicklung"]
        direction TB
        R1[Requirements<br>Engineering] --> RS[Anforderungs-<br>Spezifikation]
        RS --> D1[Design &<br>Implementierung]
        D1 -.-> RC[Anforderungs-<br>Änderungsanträge]
        RC -.-> RS
    end

    subgraph Agile["Agile Entwicklung"]
        direction TB
        R2[Requirements<br>Engineering] <--> D2[Design &<br>Implementierung]
    end

    Plan ~~~ Agile

4.3 Die fünf Prinzipien agiler Methoden

Während sich verschiedene agile Methoden in ihren spezifischen Praktiken unterscheiden, teilen sie einen gemeinsamen Satz von Prinzipien:

4.4 Wo Agile am besten funktioniert

Agile Methoden waren besonders erfolgreich in zwei Situationen:

1. Produktentwicklung — wo ein Softwareunternehmen ein kleines oder mittelgroßes Produkt zum Verkauf entwickelt. Praktisch alle Softwareprodukte und Apps werden heute mit einem agilen Ansatz entwickelt.

2. Kundenspezifische Systementwicklung — wo es ein klares Engagement des Kunden gibt, sich am Entwicklungsprozess zu beteiligen, und wo es wenige externe Stakeholder und Vorschriften gibt.

Warum funktionieren diese Situationen gut? Weil sie kontinuierliche Kommunikation zwischen dem Produktmanager oder Kunden und dem Entwicklungsteam ermöglichen, und die Software ist eigenständig und nicht eng mit anderen gleichzeitig entwickelten Systemen integriert.

4.5 Die agile Antwort auf Unsicherheit

Anstatt Unsicherheit mit mehr Planung zu bekämpfen, arbeitet Agile mit Unsicherheit:

Die zentrale Erkenntnis: Feedback ist wertvoller als Vorhersage. Anstatt Monate damit zu verbringen, vorherzusagen, was Benutzer wollen, verbringen Sie Wochen damit, etwas zu bauen und aus ihren tatsächlichen Reaktionen zu lernen.

5. Das Agile Manifest

5.1 Geschichte und Kontext

Im Februar 2001 versammelten sich siebzehn Software-Praktiker in einem Skiresort in Snowbird, Utah. Sie vertraten verschiedene Methodologien — Extreme Programming, Scrum, Crystal und andere — aber teilten eine gemeinsame Frustration mit schwergewichtigen Prozessen.

Über ein Wochenende destillierten sie ihre kollektive Weisheit in vier Werte und zwölf Prinzipien. Das Ergebnis war das Agile Manifest, eines der einflussreichsten Dokumente in der Geschichte der Software.

5.2 Die vier Werte

Manifest für Agile Softwareentwicklung

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

— agilemanifesto.org

Beachten Sie den letzten Satz: Das Manifest lehnt Prozesse, Dokumentation, Verträge oder Pläne nicht ab. Es etabliert Prioritäten.

5.3 Die zwölf Prinzipien

Hinter den vier Werten stehen zwölf Prinzipien, die die agile Praxis leiten:

Lieferungsorientiert:

1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
2. Liefere funktionierende Software regelmäßig, von ein paar Wochen bis zu ein paar Monaten, mit Bevorzugung der kürzeren Zeitspanne.
3. Funktionierende Software ist das wichtigste Fortschrittsmaß.

Veränderung umarmend:

1. Heiße Anforderungsänderungen willkommen, selbst spät in der Entwicklung. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
2. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
3. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.

Menschenzentriert:

1. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.
2. Die effizienteste und effektivste Methode, Informationen zu vermitteln, ist im Gespräch von Angesicht zu Angesicht.
3. Fachleute aus der Wirtschaft und Entwickler müssen während des Projekts täglich zusammenarbeiten.
4. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Qualitätsgetrieben:

1. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
2. Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell.

5.4 Praktische Herausforderungen der agilen Prinzipien

Die Manifest-Prinzipien klingen ansprechend, aber ihre Anwendung in der Praxis wirft schwierige Fragen auf. Reale Organisationen stehen vor Einschränkungen, die eine reine agile Einführung herausfordernd machen können:

5.5 Wann ist Agile am anwendbarsten?

Agile Methoden sind keine universelle Lösung. Sie funktionieren am besten unter bestimmten Bedingungen:

Agile funktioniert gut, wenn:

• Das Produkt von einem kleinen, zusammengestellten Team entwickelt wird, das informell kommunizieren kann
• Das System wenige externe Stakeholder hat (Kunden, Regulierungsbehörden, andere Systeme)
• Anforderungen sich realistischerweise häufig ändern können ohne massive Nacharbeitskosten
• Kundenvertreter verfügbar und bereit sind, teilzunehmen
• Die Organisation iterative Lieferung unterstützt (nicht nur ein Big-Bang-Release)

Agile kann Schwierigkeiten haben, wenn:

• Das System detaillierte Vorabspezifikation erfordert (z.B. Medizinprodukte, sicherheitskritische Systeme)
• Das Team über Zeitzonen verteilt ist, was persönliche Kommunikation unmöglich macht
• Verträge einen festen Umfang erfordern statt flexibler Prioritäten
• Externe Regulierungsbehörden umfassende Dokumentation vor der Bereitstellung verlangen
• Das System sich mit mehreren anderen Systemen integrieren muss, die parallel entwickelt werden

Die Realität: Die meisten Organisationen verwenden heute einen hybriden Ansatz — sie übernehmen agile Praktiken, wo möglich, während sie notwendige Dokumentation und Prozesse für Compliance, Integration oder organisatorische Einschränkungen beibehalten.

6. Extreme Programming (XP): Wichtige Praktiken

6.1 Was ist XP?

Extreme Programming (XP) wurde von Kent Beck in den späten 1990er Jahren entwickelt. Der Name kommt davon, gute Softwareentwicklungspraktiken auf ihr “Extrem” zu treiben:

• Wenn Code-Review gut ist, überprüfe Code ständig (Pair Programming)
• Wenn Testen gut ist, teste zuerst (TDD)
• Wenn Integration gut ist, integriere kontinuierlich (CI)
• Wenn einfaches Design gut ist, suche immer die einfachste Lösung (Refactoring)

XP liefert die technischen Praktiken, die Agile funktionieren lassen. Ohne diese Praktiken wird Agile nur “weniger planen” — was zu Chaos führt, nicht zu Agilität.

6.2 Der XP Release-Zyklus

XP organisiert Arbeit in Releases, Iterationen und Aufgaben:

Zu Beginn eines Projekts erfassen Story Cards die Kundenanforderungen. Der Kunde arbeitet mit dem Team zusammen, um diese Stories zu priorisieren, und jedes Release enthält die Funktionen mit der höchsten Priorität, die in den Zeitplan passen.

Sobald Stories einem Release zugewiesen sind, teilt das Entwicklungsteam sie in Task Cards auf. Jede Aufgabe repräsentiert ungefähr 1-2 Tage Arbeit, was den Fortschritt sichtbar und die Schätzung genauer macht.

Verbindung zur vorherigen Vorlesung: Wir haben User Stories in Kapitel 04: Requirements Engineering eingeführt. Dort haben Sie das “Als… möchte ich… damit…“-Format und die INVEST-Kriterien gelernt. XPs Story Cards sind die physische Darstellung dieser User Stories — eine leichtgewichtige Art, sie zu erfassen und zu priorisieren, ohne schwere Dokumentation. Die digitalen Entsprechungen (GitHub Issues, Jira-Tickets) dienen heute demselben Zweck.

6.3 Kern-XP-Praktiken

6.4 Testgetriebene Entwicklung im Detail

Testgetriebene Entwicklung (TDD) kehrt die traditionelle Entwicklungssequenz um. Anstatt Code zu schreiben und dann Tests zu schreiben, tun Sie:

1. Schreiben Sie einen fehlschlagenden Test, der das erwartete Verhalten definiert
2. Schreiben Sie den minimalen Code, um den Test zu bestehen
3. Refactoren Sie, um das Design zu verbessern, während die Tests grün bleiben

Dieser Ansatz hat einen entscheidenden psychologischen Vorteil: Er zwingt Sie, darüber nachzudenken, was der Code tun soll, bevor Sie darüber nachdenken, wie er implementiert wird.

Das Testverzögerungsproblem

In der Praxis haben viele Teams Schwierigkeiten, die Disziplin aufrechtzuerhalten. Unter Zeitdruck schreiben Entwickler Tests nach dem Code — oder überspringen Tests ganz. Dies erzeugt Testverzögerung: eine wachsende Lücke zwischen Produktionscode und Testabdeckung.

Sobald sich Testverzögerung entwickelt, stehen Entwickler vor einem Dilemma:

• Tests für bestehenden Code zu schreiben fühlt sich verschwenderisch an (der Code funktioniert bereits)
• Aber ungetesteter Code akkumuliert technische Schulden
• Schließlich verlangsamt die Angst, ungetesteten Code zu brechen, jede Entwicklung

XP adressiert dies, indem Test-First zu einer Teamnorm gemacht wird, nicht zu einer individuellen Entscheidung. Pair Programming hilft, die Disziplin durchzusetzen, weil Ihr Partner es bemerkt, wenn Sie den Testschritt überspringen.

Beispiel: Test-First für Profilvalidierung

# Step 1: Write the failing test
def test_profile_name_too_long_raises_error():
    """Names over 100 characters should be rejected."""
    long_name = "A" * 101
    with pytest.raises(ValidationError, match="Name must be 1-100 characters"):
        validate_profile_name(long_name)

# Step 2: Write minimum code to pass
def validate_profile_name(name: str) -> str:
    if len(name) > 100:
        raise ValidationError("Name must be 1-100 characters")
    return name

# Step 3: Refactor (add more validation rules)
def validate_profile_name(name: str) -> str:
    if not name or len(name) > 100:
        raise ValidationError("Name must be 1-100 characters")
    return name.strip()

6.5 Pair Programming im Detail

Pair Programming ist vielleicht die kontraintuitivste XP-Praktik. Zwei Entwickler arbeiten zusammen an einem Computer:

• Driver: Tippt den Code, konzentriert sich auf die unmittelbare Aufgabe (taktisches Denken)
• Navigator: Überprüft jede Zeile beim Tippen, denkt über das große Ganze nach (strategisches Denken)

Partner wechseln häufig die Rollen (alle 15-30 Minuten) und tauschen über den Tag die Paare.

Vorteile:

• Kontinuierliche Code-Überprüfung — Fehler werden sofort erkannt
• Wissensaustausch — keine Single Points of Failure
• Mentoring — Junior-Entwickler lernen von Senior-Entwicklern in Echtzeit
• Fokus — schwieriger, sich ablenken zu lassen, wenn jemand zuschaut

Was sagt die Forschung?

Pair Programming wurde umfangreich untersucht:

• Williams et al. (2000) fanden heraus, dass Paare Code mit 15% weniger Fehlern produzierten als Einzelpersonen, während sie nur 15% mehr Personenstunden benötigten. Die Qualitätsverbesserung rechtfertigte die scheinbaren Kosten.

• Arisholm et al. (2007) führten ein kontrolliertes Experiment mit 295 professionellen Entwicklern durch. Ihre Erkenntnisse waren differenzierter:

  • Für einfache Aufgaben waren Einzelpersonen effizienter
  • Für komplexe Aufgaben zeigten Paare signifikante Qualitätsvorteile
  • Junior-Junior-Paare schnitten schlecht ab; Pairing funktioniert am besten mit mindestens einem erfahrenen Entwickler

Die Forschung legt nahe, dass Pair Programming nicht universell vorteilhaft ist — es ist ein Werkzeug, das am besten auf komplexe, risikoreich oder lernintensive Arbeit angewendet wird.

Wann Pair Programming nutzen:

• Komplexer oder unbekannter Code
• Kritische Systemkomponenten
• Einarbeitung neuer Teammitglieder
• Wenn man bei einem schwierigen Problem feststeckt

Wann alleine arbeiten:

• Einfache, routinemäßige Aufgaben
• Exploratives Prototyping
• Wenn Pair-Müdigkeit einsetzt (es ist mental intensiv)
• Gut verstandene Änderungen mit geringem Risiko

6.6 KI als Ihr Pair-Programming-Partner: Der neue Navigator?

Seit Vorlesung 1 haben Sie GitHub Copilot als Teil Ihrer Entwicklungsumgebung verwendet. Ob Sie es erkannt haben oder nicht, jedes Mal wenn Copilot Code vorschlug und Sie bewerteten, ob Sie ihn akzeptieren — waren Sie in einer Form von Pair Programming mit einem KI-Partner engagiert.

Dies wirft eine wichtige Frage auf: Gelten die Forschungsergebnisse über menschliches Pair Programming aus den Jahren 2000 und 2007 noch im Zeitalter der generativen KI? Oder hat KI die Gleichung grundlegend verändert?

6.6.1 Der Aufstieg der KI-Pair-Programmer

Die Landschaft verschob sich rapide:

• 2021: GitHub Copilot wurde als “KI-Pair-Programmer” eingeführt
• 2022: ChatGPT demonstrierte konversationsbasierte Programmierunterstützung
• 2023: Claude und GPT-4 brachten anspruchsvolleres Code-Verständnis
• 2024-2025: KI-Programmierassistenten wurden zu Mainstream-Entwicklungswerkzeugen

Diese Werkzeuge funktionieren als ein immer verfügbarer Navigator — sie schlagen Code-Vervollständigungen vor, beantworten Fragen und helfen beim Debuggen. Sie bleiben der Driver; die KI bietet Navigationsvorschläge.

6.6.2 Was sagt die Forschung?

Forscher haben begonnen, Mensch-Mensch-Pair-Programming mit Mensch-KI-Pair-Programming zu vergleichen. Die Erkenntnisse sind differenziert:

6.6.3 Das Produktivitätsversprechen

Die Produktivitätsgewinne sind real und gut dokumentiert:

• GitHubs kontrollierte Studie (2023): Entwickler erledigten Aufgaben 55% schneller mit Copilot
• Zeitersparnis: Bis zu 50% bei Dokumentation, 30-40% bei repetitiven Programmieraufgaben
• Entwicklererfahrung: 90% der Entwickler berichteten, sich erfüllter zu fühlen; 70% erlebten reduzierten mentalen Aufwand bei repetitiven Aufgaben (Accenture-Studie)

Diese Gewinne sind am ausgeprägtesten bei Boilerplate-Code, Syntax-Nachschlagen und Routine-Implementierungen — genau die Aufgaben, bei denen der Pair-Programming-Overhead am schwersten zu rechtfertigen ist.

6.6.4 Die Qualitätsfrage

Das Qualitätsbild ist jedoch komplizierter. Forschung aus 2024 präsentiert widersprüchliche Belege:

Positive Erkenntnisse (GitHub-gesponserte Forschung):

• Entwickler mit Copilot bestanden 56% wahrscheinlicher alle Unit-Tests
• Code-Lesbarkeit verbesserte sich um 3,6%, Wartbarkeit um 2,5%

Besorgniserregende Erkenntnisse (unabhängige Forschung):

• GitClear 2024: KI-generierter Code hat 41% höhere Churn-Rate — was bedeutet, dass er häufiger überarbeitet oder gelöscht wird
• Uplevel Data Labs: “Entwickler mit Copilot-Zugang sahen eine signifikant höhere Fehlerrate, während ihr Issue-Durchsatz konstant blieb”

Interpretation: KI tauscht möglicherweise anfängliche Geschwindigkeit gegen spätere Nacharbeit ein. Der Code wird schneller geliefert, erfordert aber möglicherweise mehr Wartung.

6.6.5 Eine differenzierte Erkenntnis für Lernende

Eine 2025er Studie auf der ACM Learning@Scale-Konferenz fand heraus, dass die Vorteile von KI-Pair-Programming ungleich verteilt waren unter den Studierenden:

• Studierende mit starken metakognitiven Fähigkeiten (Fähigkeit, das eigene Denken zu überwachen und zu bewerten) erzielten verbesserte Leistung mit KI
• Studierende mit schwachen metakognitiven Fähigkeiten wurden negativ beeinflusst durch KI-Unterstützung

Dies legt eine kritische Erkenntnis nahe: KI verstärkt bestehende Fähigkeiten, anstatt sie zu ersetzen. Wenn Sie nicht verstehen, warum Code funktioniert, wird KI Sie nicht lehren — sie wird nur mehr Code generieren, den Sie nicht verstehen.

Dies verbindet sich direkt mit unserer Betonung von TDD und Testing: Ihre Tests verifizieren, dass KI-Vorschläge tatsächlich korrekt funktionieren. Sie müssen den Code immer noch gut genug verstehen, um aussagekräftige Tests zu schreiben.

6.6.6 Was KI nicht ersetzen kann

Forschung identifiziert konsistent Fähigkeiten, die einzigartig menschlich bleiben:

• Projekthistorie und das “Warum”: KI weiß nicht, warum Ihr Team diese Architektur gewählt hat, was vorher gescheitert ist oder welche Einschränkungen vergangene Entscheidungen geformt haben
• Impliziter Wissenstransfer: Senior-Entwickler teilen Instinkte und Intuitionen, die nirgendwo dokumentiert sind
• Teamkultur und gemeinsames Verständnis: Vertrauen aufbauen, Meinungsverschiedenheiten navigieren und kollektives Eigentum entwickeln
• Echte Herausforderung aus Erfahrung: Ein menschlicher Navigator sagt “Ich habe dieses Muster vorher scheitern sehen” mit Überzeugung aus gelebter Erfahrung
• Ethisches und kontextuelles Urteilsvermögen: Organisationspolitik, Benutzerbedürfnisse und gesellschaftliche Auswirkungen verstehen

Wie eine 2025er Studie bemerkte: Studierende “schätzten LLM-basierte Werkzeuge als wertvolle Pair-Programming-Partner”, hatten aber “unterschiedliche Erwartungen im Vergleich zu menschlichen Teamkollegen”.

6.6.7 Praktische Anleitung: Wann was verwenden

Basierend auf der Forschung hier eine aktualisierte Anleitung für das KI-Zeitalter:

KI-Pair-Programming verwenden für:

• Boilerplate-Code und repetitive Implementierungen
• Syntax, die Sie nicht erinnern (API-Aufrufe, Bibliotheksnutzung)
• Schnelles Prototyping und Exploration
• Späte Solo-Arbeit, wenn kein menschlicher Partner verfügbar ist
• Dokumentation und Code-Kommentare

Menschliches Pair Programming verwenden für:

• Komplexe Design-Entscheidungen, die architektonisches Urteilsvermögen erfordern
• Neue Domänen lernen (der Mensch kann das “Warum” erklären)
• Einarbeitung in ein Team und seine Codebasis
• Kritische Systemkomponenten, wo Fehler kostspielig sind
• Wenn Sie herausgefordert werden müssen, nicht nur geholfen

Der kompetente Entwickler von 2025 und darüber hinaus wird wahrscheinlich beides strategisch nutzen — erkennen, wann Geschwindigkeit und Verfügbarkeit (KI) gebraucht werden versus wann Weisheit, Herausforderung und Wissenstransfer (Mensch) gebraucht werden.

Das beste Pairing-Setup könnte sein: ein menschlicher Navigator, der weiß, wann er Sie fahren lässt — und wann er vorschlägt, Copilot um eine Syntax-Erinnerung zu bitten.

6.7 Wie XP-Praktiken sich gegenseitig verstärken

XP-Praktiken sind nicht unabhängig — sie bilden ein sich gegenseitig verstärkendes System:

• User Stories definieren, was zu testen ist
• TDD stellt sicher, dass Tests vor dem Code existieren
• Refactoring hält das Design einfach
• Einfaches Design ermöglicht schnelle Integration
• CI ermöglicht kleine, häufige Releases
• Kleine Releases generieren Feedback für neue User Stories
• Pair Programming verbessert die Qualität aller Aktivitäten

7. User Stories für den Road Profile Viewer

Wenden wir XP-Praktiken auf unser Kursprojekt an: den Road Profile Viewer.

7.1 User Story Format

Aus Kapitel 04 erinnern Sie sich an das User-Story-Format:

Als [Rolle] möchte ich [Funktion], damit [Nutzen].

Dieses Format erfasst:

• Wer die Funktion will (die Rolle)
• Was sie wollen (die Funktion)
• Warum sie es wollen (der Geschäftswert)

7.2 Story Cards und Task Cards

Im traditionellen XP werden User Stories auf physische Story Cards geschrieben — Karteikarten, die klein genug sind, um Kürze zu erzwingen. Die Einschränkung ist beabsichtigt: Eine Story, die nicht auf eine Karte passt, ist zu groß und muss aufgeteilt werden.

Was auf eine Story Card kommt:

• Story-Titel
• Kurze Beschreibung (1-2 Sätze)
• Priorität (vom Kunden festgelegt)
• Aufwandsschätzung (vom Team festgelegt, oft in “Story Points”)

Sobald eine Story zur Implementierung ausgewählt wurde, teilt das Entwicklungsteam sie in Task Cards auf. Jede Aufgabe repräsentiert ein bestimmtes Stück Arbeit (maximal 1-2 Tage):

Warum physische Karten?

In den frühen Tagen von XP dienten physische Karten mehreren Zwecken:

• Sichtbarkeit: Karten auf einem Board zeigen den Projektstatus auf einen Blick
• Taktile Manipulation: Das physische Bewegen von Karten erzeugt ein Gefühl des Fortschritts
• Einschränkung: Kleine Karten erzwingen prägnante Anforderungen
• Zusammenarbeit: Karten können arrangiert, priorisiert und als Gruppe diskutiert werden

7.2.1 Von physischen Karten zu digitalen Werkzeugen

Heute verwenden die meisten Teams digitale Werkzeuge anstelle von physischen Karten. Die Umstellung erfolgte aus praktischen Gründen:

• Remote-Arbeit: Verteilte Teams können sich nicht um ein physisches Board versammeln
• Durchsuchbarkeit: Eine bestimmte Story unter Hunderten zu finden ist sofort möglich
• Integration: Werkzeuge verbinden sich mit Versionskontrolle, CI/CD und Dokumentation
• Verlauf: Jede Änderung wird verfolgt — wer hat was wann und warum bewegt

Für diesen Kurs empfehlen wir GitHub Issues, weil:

• Sie GitHub bereits für Versionskontrolle verwenden
• Issues verlinken direkt zu Commits und Pull Requests
• Es ist kostenlos und für die meisten Projekte ausreichend
• Ein Werkzeug gründlich zu lernen ist besser als viele oberflächlich zu lernen

Das Werkzeug ist egal — die Praktik zählt. Ob Sie Haftnotizen, GitHub Issues oder Jira verwenden, die Prinzipien bleiben gleich: Stories klein halten, sie in Aufgaben aufteilen und Fortschritt sichtbar machen.

7.3 Road Profile Viewer Funktionsanforderungen

Das Projekt erfordert:

• Dropdown-Selektor für mehrere Straßenprofile
• Upload-Seite mit JSON-Datei-Upload
• Datenbankpersistenz (SQLite oder TinyDB)
• Pydantic-Datenvalidierung
• 90%+ C1-Testabdeckung

7.4 Beispiel User Stories

7.4.1 Story 1: Profilauswahl

Als Straßeningenieur möchte ich aus mehreren gespeicherten Straßenprofilen per Dropdown auswählen, damit ich schnell zwischen verschiedenen Straßenmessungen wechseln kann.

Akzeptanzkriterien (Given-When-Then):

Scenario: Select a different profile
  Given the application has 3 stored profiles
  And the dropdown shows "Highway A1" as the default
  When I click the dropdown and select "Rural Road B7"
  Then the chart updates to show the "Rural Road B7" profile
  And the intersection calculation uses the new profile data

Scenario: Default selection on startup
  Given the application has stored profiles
  When the application starts
  Then the dropdown pre-selects the first profile alphabetically
  And the chart displays that profile

7.4.2 Story 2: Profil-Upload

Als Straßeningenieur möchte ich neue Straßenprofile über JSON-Dateien hochladen, damit ich Messungen aus Felduntersuchungen zum System hinzufügen kann.

Akzeptanzkriterien:

Scenario: Upload valid JSON profile
  Given I am on the upload page
  And I have a valid JSON file with 100 road points
  When I select the file and click "Upload"
  Then the system displays a preview chart
  And I can enter a custom name for the profile
  And clicking "Save" stores the profile in the database
  And I receive a success confirmation

Scenario: Upload invalid JSON format
  Given I am on the upload page
  When I select a file that is not valid JSON
  Then the system displays "Invalid JSON format" error
  And the profile is NOT saved to the database

Scenario: Upload mismatched coordinates
  Given I am on the upload page
  When I select a JSON file where x_coordinates has 50 items but y_coordinates has 45 items
  Then the system displays "Coordinate arrays must have equal length" error
  And the profile is NOT saved

7.4.3 Story 3: Datenvalidierung

Als Systemadministrator möchte ich, dass hochgeladene Profile gegen Schemaregeln validiert werden, damit ungültige Daten die Datenbank nicht beschädigen können.

Akzeptanzkriterien:

Scenario: Valid profile data
  Given a JSON file with name "Test Road" (10 chars)
  And x_coordinates and y_coordinates each have 25 float values
  When the system validates the file
  Then validation passes
  And the profile can be saved

Scenario: Name too long
  Given a JSON file with name exceeding 100 characters
  When the system validates the file
  Then validation fails with "Name must be 1-100 characters"

Scenario: Empty coordinate arrays
  Given a JSON file with empty x_coordinates array
  When the system validates the file
  Then validation fails with "Minimum 2 coordinate points required"

7.4.4 Story 4: Profilvorschau

Als Straßeningenieur möchte ich das Profildiagramm vor dem Speichern in der Vorschau sehen, damit ich überprüfen kann, dass ich die richtigen Daten hochlade.

Akzeptanzkriterien:

Scenario: Preview before save
  Given I have uploaded a valid JSON file
  When the system accepts the file
  Then I see a graph showing the road profile
  And the graph axes are labeled correctly
  And I can still cancel without saving

7.4.5 Story 5: Datenbankpersistenz

Als Straßeningenieur möchte ich, dass meine Profile Anwendungsneustarts überdauern, damit ich meine Daten nicht verliere, wenn ich die Anwendung schließe.

Akzeptanzkriterien:

Scenario: Profiles survive restart
  Given I have saved 5 profiles to the database
  When I restart the application
  Then all 5 profiles appear in the dropdown
  And each profile loads correctly when selected

7.5 User Stories in der Praxis verwalten

Die oben genannten User Stories sind auf dem Papier gut strukturiert, aber wie verfolgen Teams sie tatsächlich während der Entwicklung? Sehen wir, wie man diese Stories in GitHub Issues übersetzt — das Werkzeug, das Sie bereits für diesen Kurs verwenden.

7.5.1 GitHub Issues für User Stories verwenden

GitHub Issues bietet alles, was Sie brauchen, um User Stories zu verwalten:

Labels kategorisieren Issues nach Typ und Priorität:

• story — Eine User Story (vs. bug oder task)
• priority:high, priority:medium, priority:low
• sprint:1, sprint:2 — Welcher Sprint für die Story geplant ist
• feature:upload, feature:validation — Funktionsbereich

Meilensteine gruppieren Stories in Releases:

• “MVP Release v1.0” — Erste nutzbare Version
• “Sprint 1” — Für aktuelle Iteration geplante Arbeit

Aufgabenlisten innerhalb von Issues verfolgen Unteraufgaben:

• Checkboxen für jede von der Story abgeleitete Aufgabe
• Fortschritt auf einen Blick sichtbar (3 von 6 abgeschlossen)

Verlinkung verbindet Stories mit der Implementierung:

• Issues in Commit-Nachrichten referenzieren: Fixes #12
• Pull Requests schließen automatisch verwandte Issues

7.5.2 Beispiel: Profil-Upload als GitHub Issue

So würde Story 2: Profil-Upload als GitHub Issue aussehen:

Warum diese Struktur funktioniert:

1. User Story oben — Jeder kann verstehen was und warum
2. Akzeptanzkriterien als Checkboxen — Klare Definition von “fertig”
3. Aufgaben als Checkboxen — Implementierungsfortschritt verfolgen
4. Labels zum Filtern — Alle hochprioritären Stories finden, alle Upload-Features usw.

7.5.3 GitHub Projects für Sprint-Planung

Für Planung auf Sprint-Ebene verwenden Sie GitHub Projects (das neuere “Projects V2”):

1. Projektboard erstellen, das mit Ihrem Repository verknüpft ist
2. Spalten hinzufügen für Ihren Workflow: Backlog → Sprint → In Bearbeitung → Review → Fertig
3. Issues ziehen zwischen Spalten, während die Arbeit voranschreitet
4. Filter verwenden, um nur den aktuellen Sprint zu sehen: milestone:"Sprint 1"

Das Board gibt dem Team einen visuellen Überblick — das digitale Äquivalent der physischen Kartenwand, die XP-Teams in den 1990er Jahren verwendeten.

7.5.4 Wenn Teams GitHub Issues entwachsen

Für größere Teams oder Unternehmensumgebungen bieten Werkzeuge wie Jira:

• Erweitertes Reporting: Burndown-Charts, Velocity-Tracking, Forecasting
• Sprint-Analytik: Wie viel Arbeit abgeschlossen vs. geplant
• Workflow-Anpassung: Prozesse durchsetzen, erforderliche Felder
• Integration mit Confluence: Stories mit Dokumentation verknüpfen

Die Prinzipien bleiben gleich, unabhängig vom Werkzeug. Wenn Sie User Stories, Aufgabenaufteilung und Sprint-Planung mit GitHub Issues beherrschen, werden Sie sich schnell an jedes andere Werkzeug anpassen.

7.6 User Story Aufschlüsselung

8. Zusammenfassung

8.1 Wichtige Erkenntnisse

1. Traditionelle Modelle scheitern, weil begrenzte Rationalität vollständige Vorausplanung unmöglich macht.
2. Agile akzeptiert Unsicherheit und baut Prozesse um kurze Feedback-Schleifen herum.
3. XP-Praktiken (TDD, Refactoring, CI) liefern die technische Grundlage, die Agile funktionieren lässt.
4. KI Pair Programming ergänzt, ersetzt aber nicht menschliche Zusammenarbeit — nutzen Sie beides strategisch.
5. User Stories mit Akzeptanzkriterien transformieren Anforderungen in ausführbare Testspezifikationen.
6. GitHub Issues bietet alles, was Sie brauchen, um User Stories zu verfolgen, mit enger Integration zu Ihrem Code.

9. Reflexionsfragen

1. Herbert Simons Erkenntnis: Wie erklärt begrenzte Rationalität, warum sich Ihre Road Profile Viewer-Anforderungen während der Entwicklung ständig geändert haben? Geben Sie ein konkretes Beispiel aus der Erfahrung Ihres Teams.

2. Manifest-Interpretation: “Funktionierende Software mehr als umfassende Dokumentation” — bedeutet das keine Dokumentation? Welche Dokumentation würden Sie trotzdem für den Road Profile Viewer schreiben?

3. XP-Abwägungen: Pair Programming erfordert zwei Entwickler für eine Aufgabe. Wann würden die Vorteile (kontinuierliche Überprüfung, Wissensaustausch) die scheinbaren Kosten von zwei Personen an einem Computer überwiegen?

4. KI vs. menschliches Pairing: Basierend auf der präsentierten Forschung, wann würden Sie menschliches Pair Programming gegenüber KI-Unterstützung wählen? Geben Sie ein konkretes Beispiel aus Ihrer Road Profile Viewer-Arbeit.

5. User-Story-Übung: Schreiben Sie eine User Story mit Akzeptanzkriterien für eine Funktion, die NICHT in den aktuellen Anforderungen ist — zum Beispiel “Profil als PDF exportieren” oder “zwei Profile nebeneinander vergleichen.”

6. GitHub Issues-Übung: Nehmen Sie eine Ihrer User Stories und erstellen Sie ein GitHub Issue nach der Struktur in Abschnitt 7.5.2. Fügen Sie Labels, Akzeptanzkriterien als Checkboxen und eine Aufgabenaufteilung hinzu.

10. Weiterführende Literatur

10.1 Bücher

• Kent Beck: Extreme Programming Explained (2. Auflage) — Das Original-XP-Buch, heute noch relevant
• Mike Cohn: User Stories Applied — Praktischer Leitfaden zum Schreiben und Verwenden von User Stories
• Herbert A. Simon: Administrative Behavior (1947) — Die philosophische Grundlage zum Verständnis begrenzter Rationalität

10.2 Artikel und Ressourcen

• Agile Manifesto — Das Originaldokument
• Agile Principles — Die 12 Prinzipien hinter dem Manifest
• Stanford Encyclopedia of Philosophy: Bounded Rationality — Akademischer Überblick über Simons Arbeit
• Wikipedia: Herbert A. Simon — Überblick über Simons Leben und Beiträge
• GitHub Issues-Dokumentation — Offizieller GitHub-Guide

10.3 Werkzeuge

• GitHub Issues — Eingebautes Issue-Tracking, integriert in Ihr Repository
• GitHub Projects — Kanban-Boards für Sprint-Planung
• Jira — Enterprise-Grade Sprint-Management (behandelt in Teil 2)
• Linear — Modernes, entwicklerfreundliches Projektmanagement

11. Wie geht es weiter?

In Teil 2: Scrum Framework und praktische Anwendung werden wir behandeln:

• Das Scrum-Framework — Rollen, Events und Artefakte
• Sprint-Durchführung — Planung, Daily Standups, Reviews und Retrospektiven
• Reale Belege — wie das US-Militär Agile für missionskritische Systeme einführt
• Praktische Anwendung — einen Sprint für den Road Profile Viewer durchführen

Mit der Philosophie, den Praktiken und User Stories aus Teil 1 sind Sie bereit zu lernen, wie Scrum diese Elemente in einen wiederholbaren Prozess organisiert.