Xp Kritik Ursprüngliche Texte
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

von ExtremeProgramming
Weiterhin strittige / offene Themen:

Das XP Planungsspiel ist mir zu wenig. Argumente von mj:

Argumente von ip: Bem: Nach meiner Erfahrung stellt eine ungeschickte Modularisierung ein grosses Problem dar, das im sich im Lebenszyklus einer Software immer weiter verschlimmert. Durch eine frühe Modularisierung werden schlechte Schnittstellen begünstigt. Schlechte Schnittstellen steigern den Kommunikationsbedarf bei der Entwicklung und senken die Wartbarkeit während und nach der Fertigstellung.
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?.
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.

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.

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 Takswechsel verringern, sondern sie eher weniger störend gestalten. Ich könnte mir vorstellen, dass auch hier TestgetriebenesDesign (insbesondere durch seine MiniIterationen?) helfen kann.

Übereinkünfte:

Bemerkung: Bei meiner XP-Lektüre hatte ich nicht denEindruck, daß die Freiwilligkeit bei Rotation eine besondere Rolle spielt... Sobald der falsche Manager den gleichen Eindruck wie ich von XP erlangt, fang ich dann wieder an mir Sorgen zu machen.
Ja, die Sorgen würde ich mir dann auch machen.
Ich selber kenne und schätze eigentlich auch eine relativ freie Aufgabenwahl, allerdings ohne explizite Rotation.

Ich habe versucht, die Ergebnisse unserer Diskussion zusammenzufassen und übersichtlich darzustellen. Die ursprüngliche Diskussion habe ich unten angehängt, wenn du (ip) mit meiner Zusammenfassung einverstanden bist, kannst du die toten Threads der Diskussion gerne löschen.

Ich bin im Großen und Ganzen durchaus einverstanden. Dennoch werde ich die Diskussion noch für eine Weile stehen lassen, um zu sehen, welche Teile davon ich (oder meinetwegen auch jemand anders) als Anregung zur Erweiterung der diversen XP-Seiten verwenden kann. -- ip

Provokativ:

Um's vorwegzunehmen ich finde XP in manchen Bereichen gut und sinnvoll ...

Die Wettbewerbsituation im Team verhindert die tatsächliche Teambildung.

Welche XP-Praktiken führen zu dieser Wettbewerbssituation?
Rotation erhöht den Stress im Team, es gibt keine abgesteckten Reviere. -jerger@jerger.org-
Rotation ist ein Kann, kein Muss. Partner werden nicht verordnet, sondern finden sich - je nach Vorlieben. Und da auch Verantwortung für Tasks nicht verordnet, sondern übernommen wird, sehe ich nicht, wie die Reviere ein Problem darstellen sollen.
[Rotation] Kann ist theoretisch gut, praktisch wird Rotation eingesetzt, um Unabhängigkeit von einzelnen Personen zu erlangen.
Noch einmal: Die Rotation wird in XP nicht eingesetzt (im Sinne von 'verordnet'), sondern passiert auf freiwilliger Basis, immer dann wenn gerade die Lust oder das Gefühl der Notwendigkeit auftaucht. Niemand muss rotieren, wenn er nicht will.
Ich seh's so es gibt zwei Extreme:
* Der Programmierer, der allein irgend was zusammenhackt und dann undokumentierten und obfuscated Code kommentarlos abliefert.
* Und die jeder weiss alles Philosophie.
Ich möchte keines der beiden Extreme leben und fuer mich einen Tradeoff dazwischen finden.
Schön, das scheint mir genau die Philosophie hinter XP zu sein. Wenn jeder Entwickler sich seine Tasks (im Rahmen des in der Iteration zu Schaffenden) und seine Entwicklungspartner selber aussuchen darf, werden Vorlieben und Abneigungen ganz selbstverständlich zu gewissen Spezialisierungen etc. führen. Es ist halt nur so, dass niemand in eine bestimmte Rolle gedrängt wird oder einen bestimmten Task nicht übernehmen darf, weil das der 'Experte' tun muss.

Den ungesunden Wettbewer sehe ich da, wo sich Leute (rotationsbedingt) in allen Gebieten behaupten muessen. Niemand ist ueberall gleichgut, ich denke deshalb: Spezialisierung ist ein natuerlicher Prozess, den ich nicht verhindern will ....
Wie ich oben bereits versucht habe, deutlich zu machen, steht das in keinerlei Widerspruch zu XP, im Gegenteil. XP unterstützt diesen natürlichen Entwicklungsprozess, indem sich jeder das Gebiet aussuchen kann, in dem er arbeitet. Dadurch wird ebenfalls berücksichtigt, dass sich Vorlieben mit der Zeit auch ändern können.

Wie ich sehe stimmen wir an der praktischen Front überein, allerdings hatte ich nach diversen XP-Lektueren den Eindruck, dass die Spezialisierung einzelner nicht erwuenscht ist. -jerger@jerger.org-

Die XP-Abschätzungen kenne ich eigentlich schon aus meinen Anfangszeiten (meine idealen Tage * Faktor 3). Mit diesen Schätzungen war ich nicht immer glücklich.

Der Faktor ist nicht fest, sondern wird gemessen. Diese Regel wird in XP-Kreisen meist WetterVonGestern genannt.
Hab nicht behauptet, mein Faktor wäre statisch. Sobald Neuland betreten wird, ist WetterVonGestern nicht ausreichend. XP bietet mir hier keine hilfe. -jerger@jerger.org-
Bei Betreten von Neuland werden in XP SpikeSolutions präferiert, um das Neuland besser beurteilen zu können.
Meine Aussage praezisiert: XP ist beim Thema Abschaetzung trivial.
Und das ist eine Kritik, weil...?

Na ja, von einem Prozess, der mir was bringt, erwarte ich ins besondere eine Unterstuetzung bei der Zeitabschaetzung. Ist schon klar, im Endeffekt laufen alle Abschaetzungen auf WetterVonGestern raus. Allerdings helfen dann so Sachen, wie Risikoabschaetzung, Personalvorausplanung, usw. mit, den Zeitplan einzuhalten und Veränderungen fruehzeitig zu erkennen.
Es fällt mir immer noch schwer zu verstehen, was konkret Dir bei der Planung in XP fehlt. Vielleicht sollte ich einfach demnächst das PlanungsSpiel, sowie ReleasePlanung und IterationsPlanung? genauer beschreiben, und wir setzen die Diskussion dann dort fort...

Das Herunterbrechen auf karteikartengrosse User-Stories ist nicht immer möglich und sinnvoll. Manchmal wird durch eine zu starke Frakturierung von Problemen die Komlplexität auch wieder erhöht (s.a. Just For Fun L. Torvalds).

Das Herunterbrechen der User-Stories ist nicht unbedingt eine Strategie zum Verringern von Komplexität. Es dient dazu, dem KundenTeam? möglichst viel Kontrolle über die Priorisierung von Funktionalität und möglichst schnell Feedback über die 'Korrektheit' und Fortgeschrittenheit der Implementierung zu geben.
Leute, die mehr Erfahrung darin haben als ich, berichten, dass dies häufig weniger problematisch ist, als man annehmen könnte. Manchmal erfordert es allerdings etwas Kreativität - und manchmal muss man vielleicht auch einfach in den sauren Apfel beißen und eine größere Story akzeptieren...

Das mit dem Testen hört sich so zwar gut an, im praktischen Einsatz decken die Minitest aber gerade nicht bedachte Fälle nicht ab.

Wie können ProgrammierenInPaaren und AkzeptanzTests hier helfen?
?? Hab ja nicht behauptet, dass XP hier (nicht? -- ip) hilft ... mir fehlen hier UseCases [UseCase] und ein unabhängiger Kopf der über nicht Bedachtes nachdenkt (ein TestDesigner?). -jerger@jerger.org-
Es ist bestimmt keine schlechte Idee, einen TestDesigner? mit ins Team aufzunehmen. Was UseCases angeht, so werden diese eher von AkzeptanzTests abgedeckt - die natürlich auch wieder mit Hilfe eines professionellen Testers erstellt werden können.
Vielleich hab ich hier XP auch falsch verstanden ...

KomponentenTests sind Tests auf Methodenebene (wobei KomponentenTests in XP speziell unterstuetzt werden) ?

Die Hauptunterscheidung in XP ist, dass KomponentenTests von den Entwicklern, meist im Sinne von TestgetriebenesDesign geschrieben werden. Meist sind es Tests auf Klassenebene, können aber von Methodenebene bis zu Interaktionstests zwischen zwei Klassen reichen.

UseCases sind Test auf Systemebene !
Ich kenne UseCases [UseCase] eigentlich nicht als Tests, aber wenn man so will, dann kann man sie wohl mit AkzeptanzTests gleichsetzen.

Okay, ich teste jedenfalls meine erstellte Software gegen UseCases, wobei das nicht immer automatisiert werden kann ...
Richtig, AkzeptanzTests werden durch AnforderungsGeschichten motiviert. Inwieweit es möglich / sinnvoll ist, diese zu automatisieren, ist eine andere Geschichte...

Anm: Ein TestDesigner? ist eine spezielle Person und führt zu einem schwerer gewichtigen Prozess -- passt das dann noch zu XP ?

Ja, absolut. Ein HeterogenesTeam? ist immer wichtig, auch in XP. Der Prozess muss dadurch auch nicht zwingend schwergewichtiger werden. Der TestDesigner? ist halt einfach ein gleichberechtigtes Teammitglied, dass sich 'zufällig' in einem bestimmten Bereich besonders gut auskennt und deswegen dafür die Hauptverantwortung übernimmt. Wichtig ist nur, dass er nicht in seinem Elfenbeinturm sitzt, sondern mit dem Rest des Teams eng zusammenarbeitet, z.B. durch ProgrammierenInPaaren.

Ich moechte den Testdesigner aber nicht zu eng ans ProgrammierTeam? binden, denn
* er soll Zeit zum Nachdenken haben.
die soll er bekommen...
* versuchen auch andere Sichten auf die entwickelte Software zu erlangen, enge Teamzugehoerigkeit macht hier Betriebsblind.
ein XpTeam besteht nicht nur aus den Programmierern...
* aber die Software auch so gut kennen, um systematisch Tests ausdenken & schreiben zu koennen.

Im übrigen sind diese Tests nichts anderes als Assertions (mit dem Dokumentationsvorteil bei Assertions).

Könntest Du ausführen, was Du damit meinst und inwieweit dies ein Nachteil ist?
Assertions werden zur Compile/Laufzeit überprüft und können automatisch Docu generieren. Dieser Mechanismus ist mächtiger als Designzeit Tests. -jerger@jerger.org-
Testen/dokumentieren Assertions wirklich das gleiche wie KomponentenTests? Könnte man den Dokumentationswert von KomponentenTests auch auf eine automatisierte Art und Weise erhöhen?

Ja, aber Assertions leisten noch mehr. Assertions dienen zum (runtime!)Test und zur Dokumentation und sind als Methode schon etabliert (in java uebrigens ab 1.4 mit dabei ...).
Natürlich kann man KomponentenTests auch dahingehend aufbohren ... aber Assertions gibt es schon ... (und um Namen geht's mir hier nicht).
Inwieweit sind Assertions fähig, Objektinteraktionen oder eine Sequenz von Methodenaufrufen zu testen? Wie gut sind sie geeignet für TestgetriebenesDesign?

Mir fehlt die komplette Risiko-Vorabschätzung. Auch bei wenig strukturierten Prozessen ist das ein sehr hilfreiches Instrument.

Inwieweit ist das PlanungsSpiel unzureichend? Wie müsste XP ergänzt werden, um Deiner Vorstellung zu genügen?
Ein speziell Beauftragter ist Pessimist und notiert Risiken, alle anderen notieren natürlich auch, was Ihnen einfällt. Dann werden erste Merkmale eines Risikos bestimmt, auf die geachtet wird und eine Lösungsstrategie für die Risiken festgelegt. Dadurch kann man fruehzeitig und schnell auf Risiken reagieren. -jerger@jerger.org-

Pair-Programming und Rotation nehmen den Fluktuations-Overhead vorweg, sie vermindern in nicht.

Untersuchungen zeigen, dass ProgrammierenInPaaren nicht weniger produktiv ist. Die Rotation führt nicht dazu, dass Wissen verloren geht, sondern dass sich Wissen im Team verbreitet.
Verglichen mit was ? Da stimm ich nicht zu, selbst wenn's Statistiken dazu gibt ... :-).
Verglichen mit Programmieren nicht in Paaren.
Meine Erfahrung ist, Taskwechsel kosten Zeit...
Andererseits ist es zusammen mit einem Partner wesentlich leichter, wieder in einen Task 'hineinzuschlüpfen'. Zudem kann die 'verlorene' Zeit durch neue Einblicke eines frischen, unbefangenen Partners bei weitem aufgehoben werden.
und Pairprogramming ist nicht immer notwendig (System.out.println kann ich alleine ...).
Nach meiner Erfahrung ist gerade bei stupiden Standardvorgehen ein Partner sehr wertvoll, und sei es nur, um das Leid gemeinsam durchzustehen. In den meisten Fällen würde ich allerdings erwarten, dass man eine Chance zur Automatisierung / Reduzierung von Duplikation übersehen hat, wenn der Partner anfängt sich zu langweilen.
:-) geteiltes leid ...
Versteh mich nicht falsch, ich lehne Pair-* nicht grundsätzlich ab, nur deren ausschliessliche Verwendung. -jerger@jerger.org-

Die Austauschbarkeit behagt mir nicht *Ich möchte nicht austauschbar sein*.

Niemand ist austauschbar. Wer würde so etwas behaupten?
Ist das nicht der Wunsch, der hinter Wissensverbreitung und Rotation steht ? -jerger@jerger.org-
Nein, die Wissensverbreitung dient der Risiko-Minimierung für den Fall, dass mal jemand nicht zur Verfügung steht. Ich habe schon Fälle erlebt, wo ein Projekt in ernsthafte Schwierigkeiten gekommen ist, weil einer der Entwickler für zwei Wochen im Urlaub war. Keine Technik der Welt kann verhindern, dass zum einen jeder Entwickler seinen ganz individuellen, unersetzbaren Beitrag zu einem Projekt und der Teamkultur beiträgt (gerade in einem XP-Projekt!), und dass zum anderen jedes neue Projektmitglied eine nicht unerhebliche Einarbeitungszeit braucht, bevor es genauso produktiv ist, wie ein 'alter Hase'.
siehe auch Rotation ... oben.

Generell

macht das ganz den Eindruck:

Nein, XP sagt: Um so größer der Zeitraum für den ich plane, um so gröber wird die Planung zwangsläufig und um so wichtiger wird es, die Planung regelmäßig zu überprüfen und zu aktualisieren.
Ich weiss auch, dass XP nicht vollstaendig vom Nachdenken befreit, aber ich moechte nicht auf langfristige Palnung verzichten, nur weil die Planung hin und wieder schief gehen kann.

Woher kommt der Eindruck, XP würde keine langfristige Planung beinhalten?

Klar ist auch, dass vorrausschauende Palnung bei kleineren Projekten nicht so umfangreich sein muss. Aber auch bei kleinen Projekten ist mir XP zu wenig.

Ich will XP aber die Erkenntnis zu gute halten, dass fuer ein 5 MannTageProjekt? kein RationalUnified? aufgesetzt werden muss.

Die Erfahrung von einigen Leuten scheint nahezulegen, dass das auch für ein 12 Mann-Projekt über mehrere Jahre nicht unbedingt notwendig ist.

Einige XP-Methoden schaetze ich übrigens auch ... :)

jerger@jerger.org
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 17. November 2001 22:49 (diff))
Suchbegriff: gesucht wird
im Titel
im Text