Eintrag kommentierenErfahrung zum Thema berichtenEintrag bewerten
Dieser Eintrag wurde im Schnitt mit 0 von 5 Punkten bewertet
Verfahren
Risiken des Extreme Programming
Methode/Technik:23132
Externe Quellen zum Thema NEU: Externe Quellen zum Thema suchen 
Beschreibung
Verstehen der Anforderungen und Konvergenz:
Anforderungen werden lediglich als User Stories dokumentiert, eine zusammenhängende Darstellung und Durchdringung eines fachlichen Problems fehlt. Bei komplexen fachlichen Problemen, etwa der Bilanzierung eines Großkonzerns, kann XP an nicht verstandener Fachlichkeit scheitern. Da das Big-Picture nicht dokumentiert ist, kann nicht letztlich sichergestellt werden, dass die Systementwicklung in die richtige Richtung läuft und zu einer vollständigen Lösung führt. Anforderungen werden von den Kunden vor Ort erhoben. Systeme haben aber häufig mehr Stakeholder. Die Anforderungsermittlung ist daher möglicherweise unvollständig und berücksichtigt die Interessen wichtiger Stakeholder nicht.

Verfolgbarkeit der Anforderungen:
Eine weitere wichtige Einschränkung von XP ist, dass Anforderungen nicht verfolgbar sind. Die Anforderungen werden als User Stories aufgeschrieben (einige XP-ler empfehlen, die Karteikarten nach dem Ende des Releases zu zerreißen) und durch den Kunden werden Akzeptanztests formuliert bzw. implementiert. Die Information, welche Komponente, welche Anforderung umsetzt ist nicht vorhanden.

Code-Komplexität:
Komplexe Probleme erfordern komplexen Code, egal wie einfach der Entwickler diesen gestalten möchte. Neue Entwickler haben kaum Informationen außer anderen Teammitgliedern. Sie müssen einen möglicherweise unübersichtlichen, komplexen Code verstehen. In der eigentlichen Wartungsphase wird das Problem verschärft, da der Code meist an andere Entwicklergruppen übergeben wird und der Wissenstransfer von Team zu Team verlustfrei geschehen muss. Teile des Wissens können durchaus sinnvoll in Dokumenten festgehalten werden.

Architektur:
Die Architektur des Systems entsteht evolutionär und wird von Release zu Release angepasst und verbessert, z.B. über Refactoring. Das funktioniert für kleine und leicht änderbare Systeme. Die klassischen Refactorings von Fowler betreffen jeweils nur wenige Klassen. Je größer das System wird, desto teurer werden auch substantielle Änderungen. Für Projekte mit hohen nicht-funktionalen Anforderungen an Verfügbarkeit und Durchsatz sowie großem fachlichen Umfang kann das evolutionäre Vorgehen zu einer nicht geeigneten Architektur führen, da ein Gesamtüberblick und eine Gesamtplanung fehlt.

XP skaliert nicht:
Wegen der intensiven Kommunikation und einer fehlenden Gesamtplanung und –architektur kann XP nur mit kleinen Teams erfolgreich eingesetzt werden.

Kundenverfügbarkeit:
XP Projekte sind auf einen hoch verfügbaren Kunden angewiesen. Sobald Kundenmitarbeiter nicht mehr im geforderten Umfang mitarbeiten, kann die „just-in-time“ Anforderungserhebung und das Feedback nicht mehr stattfinden. XP setzt weiterhin voraus, dass Kunden bereitwillig kurzfristige Entscheidungen im Projekt treffen, dies ist in einigen Organisationen schwierig.

Teamqualifikation:
XP Projekte setzen sehr qualifizierte, erfahrene Mitarbeiter voraus, die eigenständig in der Lage sind, Anforderungen zu analysieren und qualitativ hochwertigen Code zu produzieren. Entwicklungsteams bestehen jedoch häufig aus Mitarbeitern mit wenig Erfahrungen (z.B. Berufseinsteiger) oder mit geringer Qualifikation. Mit einem durchschnittlichen Entwicklungsteam ist XP damit vermutlich schwierig durchführbar.
Externe Quellen zum Thema NEU: Externe Quellen zum Thema suchen 
 Eintrag kommentieren 
 Eintrag bewerten 
 Erfahrung zum Thema berichten 
Zu dieser Seite wurden noch keine Kommentare oder Bewertungen abgegeben.
 
Zum Seitenanfang Top Drucken Impressum AGB
Home

VSEK ©2001-2010