Benutzer Diskussion:Michael Hüttermann

Service Oriented Architecture

Hallo Michael,

koennst Du bitte im Artikel Service Oriented Architecture erlaeutern, was ein Domain Model ist. Wenn es schon so wichtig ist, dann sollten wir es wenigstens auch erklaeren. Danke -- sparti 12:49, 27. Feb 2006 (CET)

Hallo sparti. Ja sorry. Ich hab das mal etwas erläutert. Es ist wirklich sehr wichtig und sollte somit auch erläutert werden. --Michael Hüttermann 13:36, 27. Feb 2006 (CET)

Anti-Pattern

Hallo Michael, der Artikel Anti-Pattern ist jetzt gut, aber deinen letzten beiden Änderungen beim Artikel Schleifen kann ich wieder nicht zustimmen. Siehe Diskussion:Schleifen. Ragalla 07:14, 11. Mai 2006d (CEST)

Java User Group

Servus Michael, ich hab dir den Artikel, bevor ich ihn im Artikelnamensraum gelöscht habe, auf eine Unterseite in deinem Benutzernamensraum verschoben (Benutzer:Michael Hüttermann/Java User Group). Du kannst ihn nun in aller Ruhe mithilfe von WP:WSIGA überarbeiten bzw. – wie in der Löschdisku vorgeschlagen – in Java (Programmiersprache) einarbeiten. Sollte er dich in deinem Benutzernamensraum stören, meld dich einfach, dann lösch ich die Unterseite wieder. --Gardini · Power-Duo 22:45, 7. Jun 2006 (CEST)

Hallo Gardini. Ich brauch nochmal ein Tipp von Dir. Wo ist der signifikante Unterschied zwischen dem von Dir gelöschten Artikel Java User Group und Linux User Group)? Die WSIGA sind mir durchaus bekannt, allerdings hatte ich bisher keine Zeit den Artikel weiter auszubauen. Danke.:-)--Michael Hüttermann 23:26, 7. Jun 2006 (CEST)

Der signifikante Unterschied ist wohl, dass LUGs momentan „relevanter“ oder „bedeutender“ sind als JUGs, weswegen letztere in den Java-Artikel eingebaut werden sollten, erstere jedoch ein eigenes Lemma verdient haben. Ich persönlich finde zwar, dass man die LUGs ebenfalls im Hauptartikel unterbringen könnte, aber meine persönliche Meinung interessiert dann halt doch nicht so arg. Ein wichtiger Unterschied besteht natürlich auch in der Qualität der beiden erwähnten Artikel. Ausschlaggebend für meine Entscheidung war dies und eine einfache Abschätzung per Google ([1] vs [2]). Gruß, --Gardini · Power-Duo 20:14, 8. Jun 2006 (CEST)

Hi Gardini. Danke für Deinen ausführlichen Post. Ich bin mir sehr sicher, dass Linux User Group nicht relevanter ist als Java User Group. Qualität: wenn die Beteiligten ihre Mühen in den Löschvorgang bzw. die Diskussion darüber investiert hätten einfach noch einen Satz an den Java User Group Artikel dranzuhängen, dann hätte es wohl auch gepasst?! Schade, dass es offenbar mehr Spass macht einen Artikel zu löschen respektive zum löschen vorzuschlagen als einfach proaktiv an dessen Verbesserung mitzuarbeiten, gerade wenn es wie in diesem Fall so einfach gewesen wäre (ja, gibt es denn einen signifikanten Unterschied zwischen den Artikeln Java User Group und Linux User Group? Ich suche noch...). In dieser Form nach der Anzahl der Suchergebnisse zu gehen halte ich für bedenklich. Ich sage ja auch nicht Birne muss gelöscht werden weil nicht so relevant wie Apfel, weil: ([3] vs [4]). Naja, so ist das halt mit der Wikipedia. :-) --Michael Hüttermann 23:20, 8. Jun 2006 (CEST)

Extreme Programming

Diskussion Lesenswert Kanditatur

Hallo. Ein Nachwort meinerseits zu der Diskussion: Die meisten kritisierten (auch sehr häufig sachlich und belegt), die fehlende Neutralität und weisen damit auf ein Grundmangel eines Wikipediaartikels hin. Eine Kritik an der Neutralität wirkt natürlich sehr schnell wie eine Kritik an der Sache selbst. Mit dem Bereich zu ökonomischen Betrachtung wollte ich – ohne den großen Lehrmeister zu spielen – eine Passage anlegen, die an sich kritisch (das heißt argumentativ abwiegend, nicht ablehnend) Extreme Programming betrachtet. Ähnliches fehlt auch zur Bewertung der Methoden aus Sicht der Informatik. Wenn diese nachgetragen sind und die Kosmetik, die zuletzt dem Artikel aufgetragen wurde etwas verfeinert wurde, ist der Artikel durchaus auch ziemlich schnell Kandidat für eine Auszeichnung. Bevor es dabei losgeht, würde ich den Artikel auch noch mal überlesen, damit die polemische Diskussion ausbleibt. Gruß, Geo-Loge 17:54, 19. Jun 2006 (CEST).

Hallo Geo-Loge. Die pauschalisierende, polemische, emotionale, unsachliche Art und Weise der Kritik hat mich irritiert. Das ist wenig konstruktiv. Mein Ansatz war halt ein anderer: XP sachlich vorstellen und unter dem Kapitel Diskussion umfangreich kritisch hinterfragen. Gerade der stetig gebrachte Vergleich mit einem Brockhaus: dort ist es auch nicht so, dass nach jedem neutralen Satz bei der Vorstellung dieser direkt negativ kritisiert wird. Deine Ergänzungen waren wirklich exzellent. Aber auch vor der Kanditatur war im Kritik-Bereich des Artikels ein Hinweis, dass es z.b. mit der Einbindung von Kunden Schwierigkeiten geben kann. Der Umfang des Artikels war schon so sehr umfangreich. Noch eine weitere Nutzenperspektive, noch dies noch das....es existieren lesenswerte Kanditaturen, die keine so vielschichtige Thematik und komplexen Artikel zur Grundlage haben. Also, aus der Neutralität sollte dann auch keine Gegen-Stimmung werden, die alles per se verteufelt. Man kann in der Sache diskutieren, aber warum so emotional? Ich werde alleine sicher nicht die Zeit finden den Artikel so voranzubringen wie ich es die letzte Zeit gemacht habe. Leider war es nicht möglich die Kritikpunkte auch nur ansatzweise zu kategorisieren. Das wäre aus meiner Sicht dringend notwendig, um zu wissen, wie die konkreten nächsten Schritte sein sollten. Nur ein Beispiel: eine Aussage, die sich darüber amüsiert, dass XP "Best Practices in einer extremen Art und Weise verfolgt". Wo ist denn hier bitte das Problem? Warum heisst Extreme Programming eigentlich Extreme Programming. HHmmmm. Bei solch einer aufgeschaukelten, voreingenommenen Stimmung war es auch nicht mehr möglich zu diskutieren. Ich bin ja auf jeden einzelnen konstruktiven Kritikpunkt eingegangen, aber leider war das dann auch nicht richtig. Es scheint schwierig einen Artikel über eine so komplexe Thematik zu schreiben. Aufgrund der einfachen Sprache (z.b.Mut und Respekt) meinen offenbar viele auf eine Banalität zu schließen. Warum wurde stetig die Thematik bewertet, und nicht der Artikel. Danke für Deine Nachricht.:-)--Michael Hüttermann 20:45, 19. Jun 2006 (CEST)

Eine Anmerkung noch zum Diskussionsverhalten: Ich finde es unglücklich mit kleiner Schrift in den Aussagen der anderen zu kommentieren. Das ist nahezu unlesbar. Ich habe dann in der Regel per Versionsunterschied gelesen, was du geschrieben hast. Geo-Loge 21:15, 19. Jun 2006 (CEST)

Ja, sorry. Es gab soviele divergente Punkte, auf die wollte ich direkt vor Ort eingehen. Wenn die ganze Diskussion strukturierter und sachlicher gelaufen wäre, wäre das wohl nicht notwendig gewesen.Tschüs.--Michael Hüttermann 00:46, 20. Jun 2006 (CEST)

Hallo Michael,

es würde mir leid tun, wenn du meine Kritik an dem Artikel als emotional und unüberlegt werten würdest. Ich habe mein Contra ja auch in ein Neutral umgewandelt, da meine Kritik ungerechterweise hauptsächlich das Thema, und nicht den Artikel darüber betraf. Für die zuerst etwas "harsche Ausdrucksweise" beim Contra möchte ich mich entschuldigen. Ich habe mal versucht, den Artikel etwas von Fachbegriffen zu "entschlacken" und zu "straffen". Habe dies nicht im Artikel selber gemacht, sondern ihn auf Benutzer:Boris Fernbacher/Testseite2 kopiert, und dort Änderungen vorgenommen (nur die ersten 4 Seiten des Artikels). Schau es dir, falls du noch nicht gänzlich die Nase voll hast, mal an. Man sollte den Artikel nicht gänzlich aufgeben. Wenn ich Vereinfachungen vornehme, und du mit deiner Fachkenntnis bei zu großer Vereinfachung immer ein bißchen gegensteuerst, wäre das doch eine fast schon agile, iterative und kommunikationsintensive Methode, oder ? Mir hat es bei meinen Musikartikel, z.B. Quartenharmonik geholfen, dass mich Nicht-Musiker ab und zu aufgefordert haben, doch etwas einfacher zu schreiben. Dann habe ich ein Kapitel "Einführung: Intervalle und Akkordsymbole" und anderes eingebaut. Melde dich halt mal, falls du Interesse an einer Zusammenarbeit beim Extreme Programming hast. Bin kein beruflich aktiver Programmierer, aber programmiersprachenmäßig (C, Assembler) schon bißchen fit. Gruß Boris Fernbacher 19:47, 20. Jun 2006 (CEST)

Hallo Boris! Super Idee, bis auf die erste Rutsche hat sich Deine Kritik recht wohltuend von dem anderen Einheitsbrei abgehoben. Klasse Schritt, ich freue mich sehr. Meinst Du es ist notwendig, dass in einem anderen Namensraum zu machen? Wie wäre es wenn Du das einfach direkt im Original machst...nur als Vorschlag. Viele Grüße--Michael Hüttermann 00:46, 21. Jun 2006 (CEST)

Klar, könnte man auch im Original machen. Ich wollte halt (als Nicht-Fachmann) nicht gleich massive Eingriffe im Original machen, ohne dass du und eventuelle andere Autoren einverstanden sind. Gruß Boris Fernbacher 11:53, 21. Jun 2006 (CEST)

Das spricht für Dich. Aus meiner Sicht hättest Du das aber ruhig machen können. Es gibt zur Zeit nur einen Hauptautor. --Michael Hüttermann 14:48, 21. Jun 2006 (CEST)

Offenbar machst Du das jetzt auch, wie man an den Änderungen am Artikel sehen kann!?!? Gut, dann brauche ich nicht zwei verschiedene Versionen, den Artikel und Deine persönliche Version, gleichsam verfolgen.--Michael Hüttermann 18:28, 21. Jun 2006 (CEST)

Inhaltlich

Bilder

Hallo Michael,

Dies Bild ->

kapiere ich ehrlich gesagt nicht so recht. Sollen die vier Pfeile außen die Bewegung er Iterationsschritte im zeitlichen Ablauf anzeigen. Wie soll sich das dann bewegen ? Spiralförmig von innen nach außen, oder spiralförmig von außen nach innen ? Oder irgendwie anders ? Vom Mittelpunkt (Start) radial nach außen ? Oder stell ich mir das mit Bewegung ganz falsch vor ? Welcher Lifecycle ist gemeint ? Der des gesamten Produkterstellungsvorgangs, oder eines einzelnen Entwicklungsschritts ? Die Begriffe im oberen rechten Kreissegment kann ich irgendwie mit den Begriffen im linken unteren nicht so recht in Verbindung bringen. Sind die Begriffe im oberen rechten Segment den einzelnen Schalen des Kreises zuzuordnen ? Wenn ja, welchen ? Das erkennt man in der Grafik nicht so recht. Die Grafik ist im Text nicht so recht erklärt. Man muss eine Weile überlegen, wie es gemeint ist, oder sein könnte, und weiß dann trotzdem nicht, ob man es wirklich so wie es gemeint ist interpretiert hat. Also ich werde nicht so ganz schlau aus der Grafik. Vielleicht geht es ja anderen ebenso. Gruß Boris Fernbacher 12:52, 21. Jun 2006 (CEST)

Man sollte auf das Bild explizit eingehen, und es erklären. Eine gute Idee. --Michael Hüttermann 14:53, 21. Jun 2006 (CEST)

Ich habe das Teaser Bild in der Einleitung referenziert und rudimentär ~~erklärt~~ beschrieben. Die Begriffe bleiben natürlich an dieser Stelle weitestgehend unerklärt, da das erst später kommt und die Einleitung sprengen würde. Es ist also so eine Art Appetizer. Ist es OK so? Was denkt Ihr?--Michael Hüttermann 14:01, 22. Jun 2006 (CEST)

Für etwas ungeschickt halte ich es, dass das Bild XP-Loop ->

XP Kreislauf (Loop): Welche Schritte in welchen zeitlichen Abständen.

ungefähr 5 Bildschirmseiten vor der textlichen Behandlung der in ihm vorhandenen englische Begriffe (Stand up meeting, pair negaotiation, usw.) plaziert ist. So muss der Leser bei Betrachtung der Grafik erst mal suchen, wo diese Begriffe weiter unten im Text dargelegt werden. Der Sinn der beiden oberen Pfeile ist mir auch etwas unklar. Wenn es nur darum geht, die Richtung im Uhrzeigersinn klar zu machen, würde ein Pfeil in dem Kreis doch reichen. Gruß Boris Fernbacher 13:22, 21. Jun 2006 (CEST)

Stimmt, es sollte dort platziert sein, wo es besser zum Text passt. Ich frage mich, ob im Nutzen-Bereich eine Bebilderung sinnvoll und möglich ist?! --Michael Hüttermann 14:53, 21. Jun 2006 (CEST)

Bild nach unten geschoben.--Michael Hüttermann 18:29, 21. Jun 2006 (CEST)

Aufbauorganisation

Hallo Michael,

habe mal etwas weiter gelesen. Im Abschnitt Aufbauorganisation wird meiner Meinung nach nicht so rech klar, was der Unterschied zwischen Kunde und Product Owner sein soll. Okay, der User sind wohl die Typen, die dann später die Software benutzen. Der Kunde ist doch wohl die Firma, welche den Programmierauftrag vergeben hat. Aber wer soll dann der Product Owner sein ? Gruß Boris Fernbacher 18:15, 21. Jun 2006 (CEST)

Hallo Boris. Dann ist das nicht klar genug beschrieben, danke. Der Product Owner ist die Person, die für die Prioritäten zuständig ist und für das Produkt verantwortlich ist, siehe Tabelle insbesondere unter Aufgaben. Man muss das sehen wie zwei Namespaces: es gibt den User und den Kunden. Das sind die lebenden Personen. Sowohl User als auch Kunde können Product Owner sein. An dieser Stelle überhaupt erstmal vielen Dank für Dein Engagement! --Michael Hüttermann 18:30, 21. Jun 2006 (CEST)

Ah, jetzt hab ich kapiert. Dachte, dass wären drei natürliche Personen. Vielleicht solltest du das auch im Artikel bißchen erklären. Es gibt vielleicht auch andere Leser, denen das (wie mir) nicht gleich klar ist. Boris Fernbacher 18:51, 21. Jun 2006 (CEST)

Ja, bestimmt ist es dann auch anderen nicht klar. Ich habe es dort etwas ausführlicher beschrieben. Reicht es so?--Michael Hüttermann 19:16, 21. Jun 2006 (CEST)

Anforderungsmanagement

Im Absatz Anforderungsmanagment taucht folgender Satz auf -> Dieses Vorgehen resultiert aus den Beobachtungen, dass einerseits der Kunde zu Beginn des Projektes noch gar nicht genau weiß was er möchte, andererseits sich diese Anforderungen im Laufe eines Projektes ändern. Darüber hinaus sind Fehler umso teurer je später man sie findet. Im schlimmsten Fall wird dem Kunden nach einem langen Projekt etwas geliefert was er gar nicht haben möchte., der ungefähr dasselbe aussagt wie folgender Abschnitt -> Die Methode berücksichtigt, dass der Kunde die wirklichen Anforderungen an die zu erstellende Software zum Projektbeginn meist noch nicht komplett kennt bzw. das mit der Realisierung betraute Entwickler-Team nicht über alle (technischen) Informationen verfügt, um eine verlässliche Aufwandsschätzung über die notwendige Dauer bis zum Abschluss zu geben. Im Laufe eines Projektes ändern sich darüber hinaus nicht selten Prioritäten. Zu Beginn geforderte Funktionen der Software werden möglicherweise in einer anderen Form benötigt oder werden im Laufe der Zeit sogar komplett hinfällig. am Anfang des Artikels. Auch das mit der Fehlerkorrektur ist weiter oben schon mal bei Unbenutzbarkeit aufgrund von Programmierfehlern erwähnt -> Fehler sollen so früher gefunden werdem, denn je später ein Fehler gefunden wird, desto teurer ist meist dessen Behebung. Außerdem soll die testgetriebene Entwicklung soll zu Programmcode führen, der ein besseres Design aufweist und besser wartbar ist. Wäre es nicht sinnvoll diese Redundanz irgendwie aufzulösen ? Gruß Boris Fernbacher 18:26, 21. Jun 2006 (CEST)

Der Inhalt ist komplementär, aus verschiedenen Blickwinkel aus. Es gibt diverse Schnittmenge. --Michael Hüttermann 18:39, 21. Jun 2006 (CEST)

Andere Frage: Was ist mit diesem Satz gemeint -> Durch die höhere Mitarbeitzufriedenheit soll die gesamte Produktivität erhöht werden auch wenn einige Verfahren rein mathematisch betrachtet Gegenteiliges vermuten lassen. -> Was für mathematisch betrachtete Verfahren sollen das sein ? Boris Fernbacher 18:51, 21. Jun 2006 (CEST)

Das kommt nicht von mir. Das verstehe ich auch nicht, und macht wenig Sinn. Ich finde genau diesen Kapitel sehr BWL-lastig mit vielen BWL-spezifischen Begriffen. Hat man mich wegen IT-Begriffen kritisiert, so muss ich sagen, finde ich die Wortwahl dieses Kapitels aber auch unschön. Unschön finde ich auch, dass die neutrale Bewertung XPs doch schnell ins Gegenteil kippt. Aus der in meinen Augen sachlichen, wertungsneutralen Darstellung wird nun langsam ein Artikel, der doch "überkritisch" mit dem Thema umgeht, und Gespenster jagen will?! Boris, was denkst Du?--Michael Hüttermann 19:16, 21. Jun 2006 (CEST)

Ob das jetzt zu kritisch, unkritisch oder richtig ausgewogen ist, kann ich nicht so recht beurteilen. Dafür fehlt es mir an theoretischen und praktischen Kenntnissen in Extreme programming. Das musst du oder andere Fachleute entscheiden. Ich beschränke mich bei meinen Änderungen am Artikel darauf, schwer oder unverständliche Abschnitte, Formulierungen und Fachbegriffe aufzuspüren und zu "entschärfen" (zu verbessern), evtl. redundantes zu kürzen, sowie die ein oder andere stilistische Änderung zu machen. Bevor ich an den inhaltlichen Aussagen wesentliche Änderungen mache, würde ich dich auf jeden Fall vorher fragen, ob das in der Form korrekt wäre. Gruß Boris Fernbacher 21:16, 21. Jun 2006 (CEST)

Das ist auch super! Vielen, vielen Dank nochmal für Deine Mithilfe und Deine kritische, konstruktive Beteiligung. Was ich meinte: es scheint schwer zu sein den Artikel objektiv zu verbessern. Ich möchte zwar sehr gerne die Kritik soweit möglich aufnehmen, allerdings ist der Artikel für mich zur Zeit immer noch auf dem gleichen Stand (also allgemeiner Level) wie vorher. Und das finde ich auch gut so, wie soll ein derartiges Thema auch sonst beschrieben werden. Ich befürchte allerdings dass wieder Leute sagen würden das ist IT-Geschwätz. Aber das hat so ein Artikel nun mal an sich. Und nun gibt es ein Kapitel mit "BWL-Geschwätz" (sorry, ist nicht so gemeint, nur plakativ gemeint und Leute hier zitiert) und die Kritik an XP, die auch schon vorher im Artikel da war, wird nun mehr oder weniger redundant auf den ganzen Artikel übertragen. Hier kann ich keine objektive "Verbesserung" erkennen, wenn die denn notwendig ist. Noch ein Beispeil: In der Einleitung muss in meinen Augen rein, dass XP inkrementell, iterativ und agil ist. Das sind eindeutige Schlüsselbegriffe die keinesfalls fehlen dürfen. Die würden auch in jedem Brockhaus stehen. Und die Abkürzung von Extreme Programming ist halt XP, auch wenn es ein Betriebssystem mit ähnlichem Titel gibt. Da kann ich oder XP auch nix für. Deine Punkte verstehe ich alle, die sind super nachvollziehbar. Durch die Modifikationen und Änderungen ist der Artikel auf jeden Fall besser geworden. Ist ungefähr klar geworden auf was ich hinaus will?--Michael Hüttermann 23:58, 21. Jun 2006 (CEST)

Kritik wohin?

Anderes Beispiel: so langsam ist im ganzen Artikel direkt bei Einführung von Merkmalen auch direkt eine Kritik dabei. Vorher war die Kritik ein eigener Abschnitt. Wenn wir die Ausführungen zu Anforderungsmanagement zusammen legen weil redundant, dann wäre es folglich konsequent den ganzen Kritik-Absatz aufzulösen. Was denkst Du?--Michael Hüttermann 18:39, 21. Jun 2006 (CEST)

Tja, weiß ich auch nicht so recht, ob man die Kritikpunkte an XP Stück für Stück über den Artikel verteilen soll, oder in einem Abschnitt Kritik zentral zusammenfassen soll. Boris Fernbacher 18:51, 21. Jun 2006 (CEST)

Den meisten Leuten war der Artikel ja zu wohlwollend, nur weil nicht jeder Satz einen kritischen Nebensatz hatte. Das war halt mein Vorgehen. Erst XP objektiv, sachlich vorstellen, ohne Bewertung, und dann später einen Kritik/Diskussions-Abschnitt. Offenbar erwartet die Mehrheit das nun eingeschlagene Vorgehen jeden einzelnen Satz direkt kritisch zu hinterfragen. Optimal find ich das nicht.--Michael Hüttermann 19:16, 21. Jun 2006 (CEST)

Frage zu Release, Iteration, Story und Tasks

Frage zur Gliederung: Kann man das sich in etwa wie in folgender Grafik (schön ist die nicht, nur so auf die Schnelle gezeichnet) vorstellen ?

-> Der Release besteht aus mehreren Iterationen, die aus mehreren User Stories, die wiederum aus einzelnen Tasks bestehen ? Kann man das so einfach sehen ? Und wo ist diese Aufteilung eher eine räumliche in Teilaufgaben, und wo eher zeitlich, oder auf einzelne Mitarbeiter ? Frage (ohne XP kritisieren zu wollen). Was ist an einer Untergliederung von Aufgaben neuartig (von XP erfunden) ? Eine gewisse Art von Strukturierung muss es doch auch in herkömmlicher Softwareentwicklung und auch in ganz anderen Berufen schon vorher gegeben haben. Gruß Boris Fernbacher 22:38, 21. Jun 2006 (CEST)

Hallo Boris! Das Bild gefällt mir ausgezeichnet! Ich bin total begeistert! Release->Iterationen->User Stories->Tasks, ja das kann man so einfach sehen. Was meinst Du wo könnten wir das unterbringen? Noch zwei Optimierungspunkte: das Wort Bewertung sollte in meinen Augen besser durch Abschätzung ausgetauscht werden. Es wird ja nichts bewertet, mit Story Points wird "nur" der Aufwand geschätzt. Die Bewertung kommt dann später. Dann: Velocity-Messung. Velocity wird zwar auch gemessen, aber nicht nur. Zu Beginn muss nämlich nicht unbedingt ein Wert vorliegen z.b. bei neuem Projekt und neuem Team. Also "Messung" ist zwar ein Anwendungsbereich von Velocity aber nicht der einzige. Ich denke einfach nur "Velocity" tuts auch. Könntest Du das wohl noch bitte anpassen?

Die Aufteilung in Tasks wird zu Beginn der Iteration vom ganzen Team für die in dieser Iteration anzugehenden User Stories durchgeführt. Die Tasks werden vom ganzen Team abgeschätzt. Also erstmal kommt die Aufteilung in Teilaufgaben. Erst anschließend schnappen sich die einzelnen Entwickler je nach ihrer Verfügbarkeit neue Tasks. Das habe ich im Artikel etwa so beschrieben. Neuartig ist an dem XP-Ansatz z.b.: das ganze Team schätzt die Aufwände, nicht nur einzelne Personen. Das Verfahren der Schätzung ist auch "neu". Der Zeitpunkt, wann und wie die Tasks den einzelnen Entwicklern zugeteilt werden ist auch neu. Ferner zeichnet sich XP dadurch aus, dass die Größe einer Einheit wie Release oder Iteration unabhängig von ihrer Dauer betrachtet wird. Es existieren erstmal nur relative Abschätzungen, bis dann später die Tasks konkret auf Stundenebene abgeschätzt werden. Dann spielt hier mit rein, dass nach jeder Iteration ein Akzeptanztest durchgeführt wird und der Kunde (genauer: der Product Owner) bestimmt, was in der nächsten Iteration durchgeführt (wobei man diesen Punkt noch am wahrscheinlichsten bei anderen Vorgehen antreffen wird) und noch andere Abgrenzungseigenschaften mehr. Es gibt also zahlreiche Unterschiede beim Vorgehen zwischen XP und "herkömmlichen" Vorgehen. Vielleicht wäre ein derartiger Abschnitt mit diesen Unterschieden noch ganz hilfreich?!? Wobei man wirklich irgendwo einen Cut machen muss: das Thema ist so komplex, also dann könnte man auch noch tiefer vergleichen zwischen XP und einzelnen anderen Vorgehen usw.--Michael Hüttermann 23:45, 21. Jun 2006 (CEST)

Freut mich, dass dir die Grafik zusagt. Werde sie morgen (bin heute zu müde) deinen Vorschlägen entsprechend verbessern. Werde auch noch versuchen, das vom Layout (Position der Kästchen, Pfeilformen, evtl. etwas bunter) noch etwas aufzupeppen (das Auge isst ja auch mit). Ich würde es bei Planung einbauen, wo diese Begriffe ja auch textlich erläutert werden. Interessant sind deine Erklärungen zu meiner Frage, was XP-Erfindung dabei ist. Aber du hast schon recht: Irgendwo muss mal ein Cut gemacht werden. Der Artikel ist ja so schon von der Seitenanzahl bedenklich lang. Gruß Boris Fernbacher 01:05, 22. Jun 2006 (CEST)

Super! Ich habe mal prototypisch ein neues Kapitel eingefügt, welches die eigentliche Innovation von XP zusammenfasst. Immer den Cut im Hinterkopf. Ja, der Artikel ist recht lang, allerdings kann man von den Inhalten auch nichts weglassen, das Thema ist halt so komplex. --Michael Hüttermann 01:23, 22. Jun 2006 (CEST)

Hallo Michael,

habe die Grafik entsprechend deinen Vorschlägen geändert, und hier als "Release3.png" hinterlegt. Wollte dir noch eine E-Mail mit der Grafik als Word-Document schicken. Habe erst nach dem abschicken gemerkt, dass man da anscheinend keine Anhänge mitschicken kann (man bin ich doof). Gruß Boris Fernbacher 21:38, 22. Jun 2006 (CEST)

Fantastisch! Das Bild gefällt mir total. Möchtest Du das in den Text einbinden, oder soll ich das machen? Wäre nicht nötig gewesen mir die Grafik per mail zuzuschicken, wenn es geklappt hätte.:-)--Michael Hüttermann 21:47, 22. Jun 2006 (CEST)

Bau du es doch ein. Dann kannst du die Größe mit dem px-Wert noch nach deinem Geschmack einstellen. Gruß Boris Fernbacher 21:49, 22. Jun 2006 (CEST)

Wunderbar! Ist drin. Herzlichen Dank!--Michael Hüttermann 21:55, 22. Jun 2006 (CEST)

Frage zur eingebauten Grafik: Kann man die etwas unschönen Leerzeilen im Text bei der Grafik irgendwie beseitigen ? Oder macht das die Wikipedia-Software zwangsläufig, ohne dass man Einfluss darauf hat ? Weiß ich ehrlich gesagt selber nicht. Bist du eigentlich Java-Programmierer, weil die Beispiele im Artikel aus Java sind (wenn ich das fragen darf) ? Boris Fernbacher 22:04, 22. Jun 2006 (CEST)

Welche unschönen Leerzeilen meinst Du genau? Also mit den Grafiken, da bin ich manchmal selbst überrascht, was wikipedia daraus macht. Entweder das läuft noch nicht ganz so rund, oder ich bin noch nicht 100% dahinter gestiegen. Klar darfst Du fragen. Also Java ist zweimal referenziert. Einmal musste das so sein, weil das historisch, sachlich der Fall war, dass damals Java Smalltalk den Rang abgelaufen hat und das laut Quelle mit der Grund für die Einstellung von C3 war. Die zweite Stelle ist der Modultest. Da hätte man als Beispiel auch NUnit für Smalltalk nehmen können. Aufgrund der allgemeinen Popularität von Java war mir das irgendwie sinnvoller. Diese Info bzw. das konkrete Beispiel ist in meinen Augen nice-to-have. Ja, ich war die letzten Jahre so alles von Software Engineer, Architekt und Technischer Projektleiter...hauptsächlich auf Java Plattform, aber nicht ausschließlich. --Michael Hüttermann 22:31, 22. Jun 2006 (CEST)

Ich meine die Leerzeilen nach dem Textabschnitt -> ... dessen Größe im Laufe des Releases aufgrund gewonnener Erkenntnisse und durchgeführten Fortschritts ständig abnimmt. Gruß Boris Fernbacher 22:34, 22. Jun 2006 (CEST)