Xp Kritik Aktuelle Diskussion
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

von ExtremeProgramming
Weiterhin strittige / offene Themen:

Das XP Planungsspiel ist mir zu wenig. Ich denke bei jeder Projektform ist

Aber:
Diese Argumentation schiebt meiner Meinung nach den schwarzen Peter dem Kunden zu. Dadurch dass XP keine verbindlichen Zeitzusagen machen will, ist der XP - Entwickler zwar immer ehrlich, aber der Kunde erhält insgesamt weniger Dienstleitung und muss längere Projektlaufzeiten bezahlen.
siehe FestpreisVertrag

Fehlendes Design machen evtl. vermeidbares CodeRefactoring nötig. Dagegen steht:
Die Aufteilung in AnforderungsGeschichte'n dient nicht der Modularisierung des Designs, sondern der Aufstellung des ReleasePlan?'s mit möglichst großem Wert für den Kunden und zur Realisierung des Feedbacks über die EntwicklungsGeschwindigkeit?.
Modularisierung erfordert für mich, erst einen Problemüberblick zu erhalten. Die Karteikartenmethode begünstig aber eher linear ein Teilproblem nach dem anderen abzuarbeiten. Dadurch enstehen dann unguenstige Modulschnitte.
Ohne Zweifel kann ein Design, das für Iteration 1 geeignet schien, sich bereits in Iteration 2 als unzureichend erweisen (genau genommen geschieht das in viel kleineren Schritten - von TestFall zu TestFall). In diesem Fall sind die Entwickler angehalten, das Design per CodeRefactoring immer auf dem bestmöglichen Stand zu halten.
Also ehrlich, "auf ... Stand halten" hört sich für mich nach unelegant und unnötig viel Arbeit an.
Falsche Modularisierung ist tödlich, wenn man keine Möglichkeit hat, sie zu korrigieren. Falsche Modularisierung ist unproblematisch, wenn man Mittel und Wege kennt, sie zu korrigieren.
Die richtige Modularisierung für heute kann bereits für die morgigen Anforderungen ungeschickt sein; über den Lebenszyklus einer Software verschlimmert sich dies immer weiter, wenn man nicht gegenarbeitet. Um so besser die Modularisierung und umso kleiner die Korrekturschritte, desto unproblematischer die Korrekturen. Daher ist ständiges CodeRefactoring keine unnötige Arbeit, sondern Investition in die Wart- und Erweiterbarkeit des Codes, die sich sehr schnell auszahlt.
Das ist schon klar ... allerdings ist ein CodeRefactoring bei Modul-Schnittstellen recht teuer und mit Architektur kann ich diesen Aufwand vermindern. Natürlich ist keine Architektur perfekt für alle Anforderungen der Zukunft gerüstet. Aber wenn meine designten Schnittstellen 3-4 XP CodeRefactoring Zyklen überleben, ist das schon ein Gewinn, oder ?
Ich möchte mich hier nicht ausschliesslich an der Modularisierung aufhängen. Modularisierung ist nur eine der Stellen, an denen sich fehlendes Design besonders bemerkbar macht.
Was ich damit sagen will ist, dass mir XP mit dem Verzicht auf eine ausgeprägte Design Phase zuviel Richtung try&error geht. Ich denke mit Intelligentem Vorgehen kann man sich einige zufälligen try&error Schritte ersparen. Sozusagen Gen Design contra Evolution - mit allen bekannten Vor- und Nachteilen.

Tests in XP: Argumente von mj: Nachteil in der Argumentation von mj: Bem: Assertions sind nur als wirkliche LowLevel? Tests sinnvoll. Allerdings notiere ich während der Entwicklung viel lieber eine Assertion als nochmal extra Testklassen zu synchronisieren. Werden KomponentenTests zum Testen von Objektinteraktion (eigentlich sind das Kommunikationsprotokolle) bleibt auch hier der Dokumentationsgedanke auf der Strecke. Zur Dokumentation von solchen Komunikationsprotokollen eignen sich z.b. EventPorts? (A.Lauder & S. Kent, University of Kent). Allerdings lassen sich EventPorts? noch nicht automatisch testen.

KomponentenTests sind für TestgetriebenesDesign unerlässlich. Der Aufwand für die Erstellung zusätzlicher Testklassen wird bei weitem durch den Einfluss auf das Design und die Sicherheit bei CodeRefactorings (die Assertions meiner Einschätzung nach nicht bieten können) aufgewogen.
Hmm, ich denke eine Kombination Assertions und Komponententests sind mein Königsweg.
Damit wärst Du nicht alleine in der XpGemeinde?. Wichtig ist nur, die Vorteile und Kosten zu beobachten und seine Entscheidung danach anzupassen.

Einschiebsel von MatthiasBohlen: Assertions und Komponententests ergänzen sich -- siehe AbgrenzungTestenZuAssertZuDesignByContract .

Fluktuations-Overhead wird nicht vermieden. Pair-Programming und Rotation nehmen den Fluktuations-Overhead nur vorweg. Argumente von mj:

Argumente von ip: Bem: In dieser Frage sind unsere Differenzen wohl nicht so groß ... Ich praktiziere Pair-Design / Programming in weiten Teilen, allerdings gibt's wirklich Sachen, die ich auch alleine machen kann. Taskwechsel empfinde ich aber als extrem störend und unproduktiv, ich weiss aber noch nicht wie ich Taskwechsel sinnvoll verringern kann.
Vielleicht musst Du gar nicht die Taskwechsel verringern, sondern sie eher weniger störend gestalten. Ich könnte mir vorstellen, dass auch hier TestgetriebenesDesign (insbesondere durch seine MiniIterationen?) helfen kann.
Das kann ich gar nicht nachvollziehen. Jeder Taskwechsel stört mich und ich geb zu ich tendiere hier eher zu Tom DeMarco?, Taskwechsel sind verlorene Zeit.
Andere Idee: Verringere Taskwechsel, indem Du die Tasks kleiner gestaltest. Wenn jeder Task nur eine Stunde dauert, hast Du jede Stunde die Gelegenheit den Partner zu wechseln.
Hmmm inzwischen stimme ich da mit DIr üerein, siehe XPKritik. Ich wollte nur die alte Diskussuion noch nicht löschen ...

KategorieXp
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 8. Dezember 2002 1:13 (diff))
Suchbegriff: gesucht wird
im Titel
im Text