Der On-Site Customer

XP forderte ursprünglich einen On-Site Customer – einen echten Nutzer oder dessen Vertreter, physisch beim Team anwesend.

Warum so extrem?

Softwareentwicklung ist ständige Entscheidungsfindung:

• Wie soll sich dieser Sonderfall verhalten?
• Welches dieser beiden Designs ist besser für Nutzer?
• Lohnt es sich, diesen Bug zu beheben, oder ist es eine bekannte Einschränkung?
• Was ist wichtiger: Feature A oder Feature B?

Wenn der Kunde nicht verfügbar ist, raten Entwickler. Sie raten falsch. Sie bauen das Falsche. Oder sie warten und blockieren den Fortschritt, bis sie eine Antwort bekommen können.

Verfügbare Kunden:

• Lösen Entscheidungen in Minuten statt Tagen
• Fangen Missverständnisse früh ab
• Treffen Prioritätsentscheidungen im Kontext
• Bauen Vertrauen durch enge Zusammenarbeit auf

Die XP-Kundenrolle bringt sowohl Rechte als auch Pflichten mit sich.

Kundenrechte:

• Die geschätzten Kosten jeder Story kennen
• Die Velocity des Teams kennen und wissen, wann Dinge fertig sein werden
• Prioritäten jederzeit ändern (innerhalb von Iterationsgrenzen)
• Das Projekt abbrechen und ein funktionierendes System erhalten (was auch immer fertig ist)
• Fortschritt durch funktionierende Software sehen, nicht nur durch Berichte

Kundenpflichten:

• Verfügbar sein, um Fragen schnell zu beantworten
• Prioritätsentscheidungen treffen, wenn gefragt
• Akzeptanzkriterien für Stories bereitstellen
• Kompromisse akzeptieren, wenn der Umfang die Kapazität übersteigt
• Feedback zu ausgelieferter Software zeitnah geben

Das ist eine Partnerschaft. Der Kunde ist kein entfernter Stakeholder, der Anforderungen über die Mauer wirft. Er ist ein Teammitglied, das täglich Entscheidungen trifft.

In der Praxis ist der „echte Kunde" oft nicht verfügbar. Sie haben Jobs. Sie können nicht den ganzen Tag bei Entwicklern sitzen.

Hier kommt der Product Owner als Stellvertreter ins Spiel – jemand, der den Kunden repräsentiert:

• Produktmanager
• Business Analysten
• Product Owner (Scrum-Terminologie)
• Interne Fachexperten

Das Stellvertretermodell funktioniert, wenn:

• Der Stellvertreter die Nutzerbedürfnisse wirklich versteht
• Der Stellvertreter die Befugnis hat, Entscheidungen zu treffen
• Der Stellvertreter wirklich verfügbar ist (nicht doppelt verplant)
• Echte Kunden regelmäßig Input geben (Demos, Feedback-Sessions)

Das Stellvertretermodell scheitert, wenn:

• Der Stellvertreter die Domäne nicht versteht
• Der Stellvertreter keine Entscheidungen ohne Eskalation treffen kann
• Der Stellvertreter zu beschäftigt ist, um verfügbar zu sein
• Echte Kunden die Software nie sehen

Akzeptanztests sind die Art, wie Kunden und Entwickler überprüfen, dass sie einander verstehen.

Für jede Story definiert der Kunde Akzeptanzkriterien:

• Gegeben [dieser Kontext]
• Wenn [diese Aktion passiert]
• Dann [sollte dies das Ergebnis sein]

Diese werden zu ausführbaren Tests. Wenn die Tests bestehen, ist die Story fertig. Keine Debatte darüber, ob sie „wirklich fertig" ist.

Vorteile:

• Eindeutige Anforderungen (wenn der Test besteht, funktioniert es)
• Lebende Dokumentation (Tests beschreiben, was das System tut)
• Regressionssicherheit (Tests fangen ab, wenn sich Verhalten ändert)
• Kundenengagement (Kriterien zu schreiben erfordert Nachdenken)

Im modernen XP werden Akzeptanztests oft in Zusammenarbeit zwischen Kunde und Entwicklern geschrieben. Der Kunde beschreibt das Verhalten; Entwickler helfen bei der Übersetzung in testbare Form.

Moderne Teams sind oft verteilt. Der „On-Site"-Kunde ist ein Slack-Channel, ein Zoom-Call oder eine asynchrone Nachricht.

Remote zum Funktionieren bringen:

• Überkommunizieren (nichts als offensichtlich annehmen)
• Video für persönliche Interaktion nutzen, wenn möglich
• Reibungsarme Wege schaffen, um Fragen zu stellen (Chat statt E-Mail)
• Entscheidungen aufzeichnen, damit sie später auffindbar sind
• Zeitzonen respektieren (keine sofortigen Antworten um 3 Uhr morgens erwarten)

Asynchrone Kundeneinbindung:

• Klare Fragen mit Kontext schreiben
• Optionen anbieten statt offene Fragen
• Erwartungen für Antwortzeit setzen
• Dokumente für komplexe Entscheidungen nutzen (einfacher asynchron zu prüfen)

Das Prinzip bleibt: Minimiere die Zeit zwischen Frage und Antwort. Remote-Arbeit macht das schwieriger, aber nicht unmöglich.