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)

Inhaltlich

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)

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)

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)

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)