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 ist nur für ein relativ kleines Segment an Softwareprojekten tauglich.
- ProgrammierenInPaaren in Verbindung mit der erforderlichen Rotation führt zu sinnvollen Teamgrößen von ca. 4-10 Personen. Auch die XP Leute selbst halten größere Projekte für nicht sinnvoll.
- Das C3Projekt hatte ein 15-Mann-Team (richtig?). Bei wesentlich größeren Teams müssen zwangsweise Formalien eingeführt werden, da nicht mehr sinnvoll jeder mit jedem kommunizieren kann.
- ProgrammierenInPaaren erlaubt durchaus, dass sich lose 'Splittergruppen' bilden, die sich auf ein gewisses Teilgebiet spezialisieren.
- Der Kunde muss bereit sein, eine Person ins Team zu entsenden (relativ hoher Aufwand), d. h. er muss viel Vertauen in XP haben.
- Das ist nicht ganz korrekt. Der Kundenvertreter muss nur seinen Arbeitsplatz beim Team haben, er muss nicht full-time für das Team zur Verfügung stehen. Der Aufwand sollte nicht grösser sein als sonst. Der Vorteil für die Entwickler ist, dass sie sich nur umdrehen müssen um auch auf eine "kleine" Frage eine Antwort zu kriegen. Wenn kein Kundenvertreter vor Ort sitzt (in Rufweite!), fallen viele dieser kleinen Fragen unter den Tisch, da man nicht unbedingt eine Mail schreiben möchte oder gar das Telefon zur Hand nehmen will. Das führt zu einer Häufung von kleinen Fehlern in der Implementation, die dann erst viel später (wenn überhaupt) entdeckt und korrigiert werden.--PeterGassmann
- Es wäre allerdings interessant zu erfahren, wie gut es Kunden gelingt, diese Entscheidungs- und Auskunftskompetenz in einer Person zu konzentrieren. Das ist keine Problem von XP, sondern ein grundsätzliches Problem auf der Kundenseite. --hl
- Häufig geht es weniger um Entscheidungen, sondern mehr um fehlendes Detailwissen. Zum Beispiel in welchem Range ein Wert typischerweise sein kann, wie viele verschiedene Arten es maximal geben kann, etc. Das Problem der Entscheidungskompetenz ist tatsächlich vorhanden, XP hat aber den Vorteil dass das Problem früher explizit sichtbar wird (spätestens beim ersten CommittmentMeeting?)! Damit wird eher eine Lösung dafür gesucht, als wenn es lange unterschwellig bleibt. --PeterGassmann
- Ein KundeVorOrt verschafft dem Kunden die seltene Möglichkeit, die Entwicklung aus erster Hand zu erfahren und jederzeit einzugreifen. Die durch die äußerst direkte Kommunikation gesparrte Zeit schlägt sich in bares gesparrtes Geld nieder.
- Der Kunde muss mehr daran interessiert sein, eine Software um jeden Preis zu erzeugen, als eine fixierte Leistung um einen Pauschalpreis zu bekommen. D. h. XP eignet sich am besten für (1) Startups (2) "In-House-Corporate-Software".
- Und für Kunden, denen klar ist, dass bei einem Festpreis zwangsweise die Qualität auf der Strecke bleibt. Und für Kunden, die gerne bekommen möchten, was sie brauchen, nicht das, was die Entwickler denken, verstanden zu haben.
- Was ich vermutlich sagen wollte ist: in vielen Situationen muss man dem Kunden zusätzlich zur Problemlösung auch noch die Philosophie von XP verkaufen. Dies ist eine mögliche Schwierigkeit im Marketingbereich. Offenbar ist man sich dessen auch bewusst und arbeitet heftig an entsprechendem "hype", um vielleicht aus diesem Nachteil sogar einen Vorteil zu machen.
- XP ist vermutlich nur dort geeignet, wo Personen komplett einem Projekt zugeordnet werden. Eine Aufteilung von Spezialisten, die gleichzeitig für mehrere Projekte tätig sind, scheint nicht praktikabel (wäre für den Kunden nicht transparent).
- Unter welchen Umständen erscheint solche Arbeitsweise denn als praktikabel??? Und inwiefern ist eine Aufteilung bei XP weniger transparent, als ohne???
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))