Extreme Programming / Diskussion
 
StartSeite | ExtremeProgramming/ | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Vorteile von Extreme Programming:

XP löst das Problem zusätzliche sich ändernder Anforderungen elegant. Der Kunde hat jederzeit das Recht zu Änderungen und Erweiterungen. Er muss nicht schon vorher wissen was er am Ende genau will! Allerdings ist auch institutionalisiert, dass eine Änderung nicht einfach irgendwo "eingeschmuggelt" wird; Sie muss explizit als AnforderungsGeschichte geschrieben werden, unterliegt einer Kostenschätzung und verteuert das Projekt (es sei denn der Kunde verzichtet auf andere Features). Also, wenn das nicht revolutionär ist!

Bei XP wird ständig Aufwand geschätzt, wobei alle Mitarbeiter einbezogen sind. Der Planende schätzt im Konflikt mit dem Kunden und im Konflikt mit dem Programmierer. Der Programmierer ist gezwungen seine Realzeit zu schätzen und einzuhalten. Es gibt ständige Rückkopplungen für alle Beteiligten und zunehmende Erfahrungswerte. Außerdem ergibt sich für jeden Einzelnen die Möglichkeit des messbaren Wettbewerbs innerhalb des Teams, sowohl bei der Schätzung als auch bei der Implementierung.

Kunde und Programmierer erarbeiten in gemeinsamer Diskussion den Entwicklungsplan, indem der Kunde Anforderungen definiert, die Programmierer deren Realisierungsaufwand schätzen und der Kunde schließlich die Prioritisierung festlegt. Einen außenstehenden 'Planer' gibt es in diesem Sinne dabei nicht.

Die Programmierer schätzen nicht Realzeit, sondern Idealzeit. Das Verhältnis zwischen Idealzeit und Realzeit wird ständig gemessen und der Entwicklungsplan bezüglich der daraus gewonnenen Erkenntnisse korrigiert. Jedem muss klar sein, dass Schätzungen eben nur Schätzungen sind; die Programmierer gehen lediglich die Verpflichtung ein, den Kunden sofort zu informieren, sollte sich eine Schätzung als falsch herausstellen, damit dieser seine Prioritisierungen anpassen kann.

Die kleinen Arbeitseinheiten und die Rotation lösen das Problem ungerechter Arbeitsverteilung im Projekt. Kein Programmierer kann sich irgendwo als Spezialist auf seinen (ruhigeren) Bereich zurückziehen. Kein Einzelner kann daran Schuld sein, dass sich ein Projekt verzögert. Natürlich gibt es Leistungsunterschiede, die auch im Faktor Realzeit/Idealzeit sichtbar und messbar werden können, aber das beeinträchtigt das Projekt als Ganzes nicht.

Der Realzeit:Idealzeit-Faktor ist kaum ein sinnvoller Indikator zur Leistungsbewertung, da Idealzeit ein sehr subjektiver Wert ist. Die reine 'Programmierleistung' ist jedoch sowieso kein angemessenes Bewertungskriterium für ein Mitglied eines Projektteams.

Ein zusätzlicher Anreiz könnte sein, dass der Kunde die Entwicklung zu jedem Zeitpunkt abbrechen kann, und dann ein funktionierendes System bekommt, in dem die von ihm als am wertvollsten eingestuften Features realisiert sind.

XP beinhaltet verschiedene Mechanismen um die Teamperformance zu optimieren. Dazu gehören die verschiedenen Feedbackzyklen von Minuten (Unit Tests, Pair Programming) über Stunden (Continuous Integration) bis zu Wochen und Monaten (Short Releases, Planning Game). Des weiteren zwingen die Praktiken zu intensiver Kommunikation zwischen den Entwicklern (Pair Programming, Collective Ownership), und auch zwischen Entwicklern und Kunden (Planning Game, Functional Testing, Short Releases, On-Site Customer). Und es gibt Praktiken, die die Qualität des Systems und des Codes prioritär einstufen und frühzeitig fördern und unterstützen (Unit Testing, Functional Testing, Coding Standards, Simple Design, Refactoring). Mit dem Planning Game und Short Releases sind sehr effektive Risikomanagement-Strategien implementiert, welche die Chancen eines Scheiterns weiter minimieren helfen. --PeterGassmann


Mögliche Probleme:


XP macht Probleme in der Softwareentwicklung deutlich sichtbar, und nennt die Probleme häufig beim Namen. Zum Beispiel die Geschichte mit der Mitarbeit in 5 Projekten gleichzeitig (je 20%) siehe oben. Oder die Geschichte mit verteilter Software-Entwicklung, wo XP ziemlich deutlich sagt dass es keine sehr gute Idee ist. Oder das der Kunde das perfekte Resultat haben möchte, ohne sagen zu müssen wie es aussehen soll... (siehe auch oben).--PeterGassmann
Was ich noch vermisse: XpCoach. --DierkKoenig
Was ist das Wesentliche an ExtremeProgramming?

Gibt es Bestandteile, die wichtiger sind als andere? Oder sind alle Bestandteile unverzichtbar?

... wichtiger ...
PerfekteTests? dann ProgrammierenInPaaren

... unverzichtbar ...
Nichts. XP ist ja das Prinzip des Flusses. Die Anpassung des Prozesses an lokale Gegebenheiten ist da wichtig.

Sollte das nicht auf ExtremeProgrammierung? umbenannt werden? --ReiniUrban


StartSeite | ExtremeProgramming/ | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 21. September 2001 12:58 (diff))
Suchbegriff: gesucht wird
im Titel
im Text