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)

Servus Michael,

Hi Uli. --Michael Hüttermann

die Definition von SOA ist meiner Ansicht nach nur im 2. Teil eine echte Definition. "Definitionen" sehen doch immer so aus: "Ein ~ ist ein ...". Damit will man kurz den Begriff klären und abgrenzen. Im 1. Abschnitt der SOA-"Definition" steht aber u. a.: "der SOA-Ansatz [ist] verbunden mit einem Umdenken". In einer Definition sollte statt dessen stehen: "der SOA-Ansatz bedeutet folgende Denkansätze im Vergleich zur Komponentenarchitektur [oder was auch immer] und zwar: 1. ... 2. ... Also: "neu" ist in einer Definition kein Kriterium - diese Defintion muß auch noch in 100 Jahren Bestand haben, wenn man schon 40 andere Architekturansätze durchs Dorf getrieben hat.

jain. :) Ich gebe Dir Recht, man kann den Absatz noch optimieren. Es ist aber dennoch eine Definition. --Michael Hüttermann

Inhaltlicher Einwand: "die fachliche Klärung des eigenen Geschäftsumfelds" ist wohl bei jedem Softwareprojekt Teil des Fachkonzeptes und wird schon seit 30 Jahren bei Softwareprodukten mitbedacht. Also: Wenn man das nicht präziser fassen kann, dann sollte man es nicht in die "Definition" packen, sondern in ein eher erklärendes Kapitel weiter hinten.

"wird häufig unterschätzt oder komplett außen vor gelassen". Das mag so sein oder auch nicht. Aber beschreibt diese Aussage die Eigenschaft von SOA? Eher nicht, daher ist das kein Thema für die "Definition". Das gehört eher in das Kapitel "Mögliche Fallstricke beim Einsatz von SOA".

es ist ja gerade ein Kernansatz SOAs, der unbedingt in die Definition muß. --Michael Hüttermann

Stell Dir einen Leser vor, der schnell wissen: "Welche Architektur ist SOA und welche nicht?". Kommt er mit Deiner Definition rasch weiter? Aber genau die Antwort auf diese Frage sucht er im Kapitel "Definition". Also: Überdenke doch bitte Dein Kapitel noch mal und schreib es um.

Soweit ich das sehe, wären Kriterium für die Abgrenzung: Software-Komponente bedeutet: Öffentliche Schnittstelle, aufrufbar von beliebigen Betriebssystemen und Programmiersprachen, leistet eine genau beschriebene fachliche Aufgabe. SOA ist Software-Komponente plus zusätzlich: kann von mehreren Softwaresystemen aufgerufen werden (residiert also zentral im Speicher oder auf einem Rechner), Systeme bestehen ausschließlich aus Software-Komponenten.

gerade weil der Leser sofort vertehen soll um was es geht muß das in die Definition rein. SOA ist ja eben nicht nur eine technische Architektur, es ist auch ein Umdenken etc. --Michael Hüttermann

Wenn Du mich fragst, dann bist Du mit diesem ganzen Geschäftsprozeß-Thema auf dem Holzweg. Das ist doch nur ein Argument von uns IT'lern mit dem wir die BWL'er über den Tisch ziehen, die von Software keine Ahnung haben. Schon die alten /390-Systeme waren natürlich am Geschäftsprozeß orientiert. Das ist doch nur logisch, daß Software immer die bestehenden oder geplanten Geschäftsprozesse unterstützt. Die einen machen das besser, die anderen schlechter. Das kannst Du mit SOA schlecht machen und mit einem grauenhaften Monolithen auch sehr gut machen (bei dem Du dann halt kaum Wiederverwendbarkeit etc. hast)

:) weg von den technik-lastigen, proprietären Lösungen hin zu einem service-basierten Ansatz ohne Redundanzen, das ist schon neu. --Michael Hüttermann

Also bitte: Die Computerwoche ist ganz heiß auf dieses Hip-Wort "SOA" und tausend Vorstände möchten wissen, was es damit auf sich hat - also schreib diese Definition um! So ist der Artikel keine Zierde für Wikipedia!

ich werd den Absatz mal zeitnah überarbeiten. Danke für Dein üppiges posting. --Michael Hüttermann

Uli Bähr

so, ich hab mich mal dran gemacht. --Michael Hüttermann 01:13, 1. Nov. 2006 (CET)

Sorry, aber in einer generellen Definition von SOA hat die Beschreibung und die konkreten Hinweise auf einzelne Technologien wie OSGI, Eclipse(!!!) nun wirklich nichts zu suchen. Habe mir deshalb die Freiheit genommen, diesen Teil komplett zu entfernen.

Es bestehen insgesamt gesehen, scheinbar immer noch erhebliche Defizite beim Verständnis über den Sinn und Nutzen von Service-orientierten Architekturen, der oftmals in einer eingeschränkten Sichtweise auf rein technologische Aspekte resultiert.

SOA soll sich als moderne Lösung für die akuten Probleme der Unternehmen bei der flexiblen Gestaltung und Umsetzung ihrer Geschäftsprozesse (im fachlichen Sinne!!!) darstellen. Eine Service-orientierte Sichtweise, die sich wiederum an technologischen Argumenten orientiert, wird nur schwerlich zur Behebung dieser Problematiken beitragen können und in einer Fortsetzung der langjährigen monolithischen Denkweise resultieren.

R.

....schön, aber warum sagst Du mir das? :-) OSGI? Eclipse? Das kam nicht von mir...gut dass Du das gelöscht hast. Ich habe mit diversen Beiträgen auf den eigentlichen Sinn von SOA hingearbeitet, weg von einem zu technischen Fokus. Auch wenn ich mich sehr über Deine persönliche Nachricht freue, bei diesen Aussagen rennst Du bei mir offene Türen ein.--Michael Hüttermann 23:33, 30. Dez. 2006 (CET)

Michael, es tut mir leid - aber meine Nachricht war natürlich nicht persönlich gemeint. Ich finde insgesamt gesehen schon, dass die Umschreibung von SOA in die richtige Richtung tendiert, sehr gelungen ist und dem Leser ein umfassendes Bild über Service-orientierte Architekturen verschaffen kann.

Aber gerade deswegen sind diese bereits mehrfach eingebrachten technologischen Beiträge über OSGI (dies ist sicherlich keine Basistechnologie von SOA und es gibt hier in Wikipedia ja bereits eine ausreichende Umschreibung über dieser Technologie) auch besonders aufgefallen.

Ich freue mich über weitere Beiträge von Deiner Seite - gerne werde ich meinerseits auch weiteren Input über SOA einbringen.

Roland

hmm? Ich nehme es nicht persönlich...und hoffe, meine Antwort hat nicht den Anschein gemacht...es ist nur so, dass mein persönlicher Beitrag am SOA Artikel doch recht übersichtlich ist. Ich habe zwar etwas beigesteuert -ich glaube ich war auch der Erste, der das Ganze weniger technisch gesehen hat- aber OSGI kommt definitiv nicht von mir. Auch habe ich derzeit keine Zeit den Artikel voranzubringen. Wenn Du inhaltlich etwas zum SOA Artikel sagen möchtest, ich denke, da ist die Diskussion an dortiger Stelle besser geeignet.--Michael Hüttermann 01:53, 1. Jan. 2007 (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 ->

XP Lebenszyklus

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)

Hmmm, also bei mir stellt sich das so dar, dass ich nur eine Leerzeile sehe. Das ist der normale Absatz, der im Quellcode des Artikels so drin steht.--Michael Hüttermann 22:40, 22. Jun 2006 (CEST)

Seltsam ! Bei mir sind das so circa 5-6 Leerzeilen. Frag doch mal den Geo-Loge oder irgendjemand anders, wie das bei dem aussieht. PS: Bin jetzt müde und gehe schlafen. Gute Nacht Boris Fernbacher 22:44, 22. Jun 2006 (CEST)

Also ich muss nochmal sagen: vielen, vielen Dank für das Bild. Genau das hat wirlich noch gefehlt! Super, danke nochmal. Die Zeilen haben sich wieder etwas geändert. Vielleicht sind die 5 Leerzeilen bei Dir nun auch weg?--Michael Hüttermann 12:20, 23. Jun 2006 (CEST)

Hallo Michael,

ich bin jetzt eigentlich fertig mit der Durchsicht des Artikels. Würde mal sagen, dass es sich jetzt ganz gut liest. Irgend jemand, der darin sehr fit ist, sollte sich mal Rechtschreibung und Zeichensetzung vornehmen. Ich selber bin da kein Weltmeister drin. Eine Anregung: Manches scheint mir immer noch an mehreren Stellen wiederholt erwähnt (Wichtigkeit der Kommunikation, Einbeziehung des Kunden, und andere Sachverhalte). Okay, das ist dann meist in einem anderen Zusammenhang (mal aus BWL-Sicht, mal aus IT-Sicht, mal aus Sicht des Kunden oder dann der des Enwicklers). Ich würde es trotzdem für sinnvoll halten, wenn du dir es nochmal anschaust, an welchen Stellen man solche "Doppelungen" eventuell streichen kann, ohne zu viel fachlichen Informationsverlust zu verursachen. Die "Doppelungen" ermüden halt, und ziehen den sowieso schon langen Artikel noch mehr in die Länge. Da ich mich mit XP nicht so gut auskenne, möchte ich das aber lieber nicht übernehmen. Am Ende lösche ich eventuell wichtige Sachen. Gruß Boris Fernbacher 19:32, 26. Jun 2006 (CEST)

Hi Boris. Vielen Dank. Ich gehe den Text nochmal durch im Hinblick auf Doppelungen. Mit der Interpunktion etc., ja, bei mir hat schon ein Tunnelblick eingesetzt. Mir fallen solche Sachen an diesem Artikel nicht mehr auf, nachdem ich hier so viel Zeit investiert habe. Es wäre wirklich schön, wenn auch eine andere Person mal drüber schauen könnte, die auch Ahnung von XP hat. Allerdings ist mir hier in der Community keiner bekannt. Inhaltlich passt es aber auch soweit, es geht in meinen Augen nur noch darum Formulierungen und Grammatik und Verständlichkeit zu optimieren. Deswegen ist es noch hilfreicher, wenn Leute darüber schauen, die nicht soooooo fit sind mit XP.--Michael Hüttermann 20:26, 26. Jun 2006 (CEST)

Kleine Anregung

Hallo Michael,

wenn man es sich recht überlegt, sind viele der Werte/Konzepte/Methoden/etc. von XP in ihrer potentiellen Anwendbarkeit doch nicht auf die Softwareentwicklung begrenzt. Da lässt sich doch vieles sicher auch in gänzlich anderen Produktions/Konstruktionsprozessen einsetzen. Vielleicht sollte man deshalb folgendes noch herrausarbeiten:

1.) Welche Werte/Konzepte/Methoden/etc. hat XP aus schon vorher bestehenden Vorgehensmodellen/etc. (Kaizen oder andere) übernommen ?

2.) Welche Werte/Konzepte/Methoden/etc. sind genuine XP Neuentwicklungen ?

3.) Welche Werte/Konzepte/Methoden/etc. von XP konnten in der Folgezeit auf andere Gebiete jenseits der Softwareentwicklung übertragen werden ?

4.) Wo sind die Grenzen einer eventuellen Übertragbarkeit ?

-> Das würde den Artikel leider noch etwas in die Länge ziehen. Es würde das Ganze halt in einen zeitlich und thematisch weitergefassten größeren Zusammenhang stellen. Wäre wohl recht interessant. Vielleicht lassen sich dafür in anderen Bereichen Details streichen oder Redundanzen vermeiden.

PS: Ein paar deutsche Weblinks (natürlich seriöse) wären für den "des englischen nicht mächtigen" oder faulen Leser praktisch.

Gruß Boris Fernbacher 15:52, 28. Jun 2006 (CEST)

Hi Boris. Da halte ich nicht viel von. Das wird den ARtikel ungemein aufblähen, er ist jetzt schon umfangreich, und das ist er "zu Recht", denn die Passagen sind alle in dieser Form wichtig bzw. so gewünscht. Einzeln:

@1.) Darüber gibt es keine Quellen. Das wären Mutmassungen bzw. harte Analysearbeit, siehe 2.

@2.) Dafür müsstest Du alle Vorgehensmodelle heranziehen. Eine sportliche Aufgabe!

@3.) Mutmassungen. Das würde den Artikel total sprengen.

@4.) siehe 3. --Michael Hüttermann 20:44, 28. Jun 2006 (CEST)

Doppelungen

Hallo Michael,

unter Doppelungen verstehe ich in etwa folgendes ->

---

Historie:

Die Methode berücksichtigt, dass der Kunde die wirklichen Anforderungen an die zu erstellende Software zu Projektbeginn meist noch nicht komplett kennt

Kundensicht:

Eines der größten Risiken der Softwareentwicklung ist, dass dem Kunden ein Produkt bereitgestellt wird, welches er in dieser Form nicht möchte. XP möchte dem vorbeugen...

Projektsicht:

Unter richtiger Anwendung XPs soll der Kunde Software erhalten, dessen Umfang ihn nicht überraschen wird.

(„Was werden die wohl liefern?“ „Haben die mich verstanden?“) und Entwicklung („Was will er eigentlich genau?“

In XP soll nur das verwirklicht werden, was tatsächlich einen Nutzen für den Kunden hat.

Anforderungsmanagment:

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.

Entwicklung und Abschluss:

So ist es denkbar, dass der Kunde während des Akzeptanztest neue Prioritäten setzt oder weitere Ideen hat.

---

-> Es wird an manchen Stellen wiederholt Dasselbe oder zumindest Ähnliches oder sehr Verwandtes festgestellt. Dies gilt z.B. auch für andere Aussagen wie z.B. dass "immer eine funktionstüchtige Version" bereitstehen sollte.

Verstehe dies bitte nicht als destruktive Kritik ! Ab 20 Seiten lässt halt selbst beim gutwilligen Leser die Konzentration etwas nach. Vielleicht könnte man also den Artikel etwas "konzentrierter" gestalten. Das wäre dann sozusagen Lean oder Extreme-Wikipedia-Writing. Ich glaube das Ganze hätte dann mehr "Durchschlagskraft". Ist nur eine Anregung von mir. Kannst du oder andere ja auch anders sehen. Vielleicht sollte man im Review einfach mal diese Frage stellen. Ich habe mir inzwischen zum Ziel gesetzt, dass der Artikel doch noch "Lesenswert" wird. Nähere mich dem in inkrementellen, iterativen und kommunikationsintensiven Schritten (GeoLoge, WortUmbruch, Haeber und du) unter stetigem Feedback des Kunden (des späteren Lesers), der manchmal leider auch nicht weiß, was er für ein Endprodukt möchte.

Kannst mir ja mal eine Rückmeldung geben, wenn du aus den Untiefen deiner Java-Packages, Classes und Subclasses wieder aufgetaucht bist. Gruß Boris Fernbacher 18:18, 28. Jun 2006 (CEST)

Hervorragend!! Ich bin begeistert, vor allem über die Analogie. Danke für den konstruktiven Beitrag. Ich verstehe was Du meinst. Ja, diese Doppelungen müssen raus. Das ist allerdings nicht immer ganz einfach, weil manches aus verschiedenen Perspektiven beschrieben wird bzw. einmal einleitend andererseits vertiefend. Erklärungen mancher Praktiken sollten dann im ganzen Artikel nicht mehr vorkommen. Brauch man im Review gar nicht stellen, das sollte schon gemacht werden. Ja, bei der Arbeit, welche in diesen Artikel reingeflossen ist (was Du alleine reingesteckt hast), dem Umfang und dem inhaltlichem Niveau kann es nur ein Ziel geben: lesenswert.--Michael Hüttermann 20:50, 28. Jun 2006 (CEST)

Hallo Michael, Zu: -> Das ist allerdings nicht immer ganz einfach, weil manches aus verschiedenen Perspektiven beschrieben wird. -> It`s difficult to look from the inside to the outside. Kann ich aus Sicht meiner eigenen Musikartkel verstehen. Obwohl die zum Teil grüne Bapperl haben, sind die zum Teil wirklich nicht allgemeinverständlich. Habe ich selber bei den Abstimmungen nicht gesagt. Sei mal ehrlich: Kapierst du was ich da eigentlich schreibe ? Wir müssen den Artikel so hinkriegen, dass ihn zumindst jeder der mal Hello-World in Basic programmiert hat, kapiert. Das ist mein Ziel. Ob wir diesen von mir angeregten Ansatz mit dem Kaizen noch einbauen; darüber könne wir ja noch später reden. Gruß Boris Fernbacher 22:00, 28. Jun 2006 (CEST)

Ein sehr gutes und erreichbares Ziel! Also ich würde mich gerne nochmal verstärkt um die Doppelungen kümmern. Jetzt gerade geht mir aber -wie angekündigt- etwas die Zeit aus. Ich bin "leider" sehr stark im Thema drin, für mich ist das Ganze verständlich. Ob das allgemeinverständlich ist kann wohl nur jemand entscheiden, der nicht aus dem Thema kommt.--Michael Hüttermann 00:32, 29. Jun 2006 (CEST)

Also bzgl. Verständlichkeit: es gibt so viele "Lesenswert Artikel", auch exzellente Artikel von Dir, Boris, die verstehe ich überhaupt nicht. Ein Fachartikel über Musik ist für mich erstmal schwerer zu verstehen, als für Dich. --Michael Hüttermann 00:50, 29. Jun 2006 (CEST)

Also ich denke das ist OK so. Wenn man verschiedene Sichten hat und einen Diskussionsbereich und eine Einleitung und die Bestandteile XPs dann ist es ganz normal dass das eine oder andere in irgendeiner Weise thematisch erneut aufgegriffen wird. Klassische Redundanzen sind das aber nicht, die wären in der Tat fehlplatziert.--Michael Hüttermann 15:00, 29. Jun 2006 (CEST)

Hallo Michael,

ich werde am Artikel nicht mehr groß "rumbohren". Habe langsam den Eindruck, dass ich durch Umbau der Sätze und andere stilistische Änderungen nicht groß was verbessere. Manchmal kann es dadurch ja auch schlechter als vorher werden. Meiner Ansicht nach liest sich das jetzt ganz gut. WortUmbruch wollte außerdem ja noch die Interpunktion durchsehen. Das wäre auch ungeschickt, wenn ich während seiner Tätigkeit immer wieder was ändere. Gruß und schönen Tag Boris Fernbacher 10:28, 30. Jun 2006 (CEST)

Kandidatur ?

Hallo Michael,

was hälst du von einem neuen Versuch einer Lesenswert-Kandidatur ? Wir sollten noch abwarten, bis WortUmBruch sich Kommasetzung, Rechtschreibung, etc. durchgeschaut hat. Oder hällst du es noch für zu früh, oder hast noch große inhaltliche oder stilistische Änderungen vor ? Meiner unbedeutenden Meinung nach liest sich der Artikel jetzt ganz gut. Du kannst ja mal über diese Anregung nachdenken. Gruß und schönen Sonntag Boris Fernbacher 10:54, 2. Jul 2006 (CEST)

Hallo Boris. Sehr gute Idee. Inhaltlich ist der Artikel "abgeschlossen". Ja, der Artikel liest sich jetzt gut. Vielleicht machen wir einfach jetzt einen Cut. Ich habe gerade WortUmBruch auf seiner Seite die Info gegeben, dass er bitte jetzt nochmal drüber schauen möge, und dass der Artikel dann nochmal in die Kanditatur gehen könnte.--Michael Hüttermann 11:54, 2. Jul 2006 (CEST)

Alles klar. Boris Fernbacher 12:53, 2. Jul 2006 (CEST)

Hallo Michael, WortUmBruch ist der Meinung, wir sollte den Artikel noch etwas liegen lassen und ihn wie ein gutes Steak reifen lassen. Vielleicht hat er recht - i don`t know. Lassen wir den Artikel halt noch zwei Wochen im Review - kann auch nichts schaden. Was mich inzwischen viel mehr interessieren würde, wären die Artikel über Assembler, C und Java. Da besteht noch Verbesserungsbedarf. PS: Mir war es eigentlich immer rätselhaft, welchen Vorteil Java gegenüber einem C-Programm haben soll. So eine Klasseneinteilung mag ja ganz lustig sein; von der Performance kann das aber doch nur verlangsamend sein. Aber über sowas sollte ich leber auf den Java-Diskusionsseiten sprechen. Gruß und einen fröhlichen Tag morgen wünscht Boris Fernbacher 19:33, 3. Jul 2006 (CEST)

Kann sein. Was halt fehlt ist jmd wie WortUmBruch, der da mal aufräumt. Wenn er meint er bräuchte etwas Abstand vom Artikel, dann wird es wohl so sein.--Michael Hüttermann 21:27, 3. Jul 2006 (CEST)

positive Rückmeldung

Ich habe mir erlaubt eine neue Überschrift in die Diskussion einzubringen, weil es bisher nur die Frage gabe "Kritik wohin?". Es wäre schön, wenn alle Leser von "Extreme Programming", die positive Erfahrungen mit XP gemacht haben und/oder den Artikel sehr gut finden, das hier äußern. Falls mein Kommentar hier Off-Topic ist, kann er gerne in die Diskussion des Artikel verschoben werden, aber dort habe ich "nur" einzelne, sachbezogene Vorschläge gefunden.

Ich finde den Artikel "Extreme Programming" herausragend. Einer der besten (technischen) Artikel, die ich hier im Wikipedia gelesen habe. Ich arbeite seit 1996 in der EDV-Branche und programmiere seit 2001 PHP. Wenn Personen hier sagen, der Artikel ist zu positiv oder zu wohlwollend der XP gegenüber ... ich kann das nicht bestätigen. Es wird an einigen Stellen Nachteile zu XP genannt.

XP stellt Konzepte vor, die es ermöglichen sollen, dass

• Software und Source-Code eine hohe Qualität haben,
• der Kunde (tief) in das Projekt eingebunden ist
• und das Team Spaß an der Arbeit des Programmierens hat. [Anmerkung: Ich finde grässliche Code-Strukturen unzumutbar und "Frickelsoftware" zu erweitern macht mir überhaupt keine Spaß.]

Durch die Beschreibung der Techniken von XP ergeben sich schon die enormen Schwierigkeiten, die es erfordert XP in einer Firma umzusetzen.

Wer kennt ihn nicht, den ruhigen Programmier, der wenig kommuniziert, gar nicht den Source-Code kommentiert, aber ohne den nichts läuft, weil die wichtigsten Funktionen und Features von ihm sind. Stelle ihm XP vor und er wird XP ablehnen, weil an den eigenen Kommunikationsstrukturen und am eigenen Konfliktpotenzial zu arbeiten, den wenigsten Menschen Spaß macht. (Zitate aus meiner Firma: "Dat hammer schon immer so jemäht." - "Wenn der Kunde was will, muss er mich anrufen.")

Wie oft hört man in Firmen: "XY ist gerade in Urlaub. Kann das evtl. noch eine Woche warten?" weil die Vertretung durch den Code oder die Strukturen des anderen nicht durchsteigt.

Nach meinem Empfinden liegt in vielen Beschreibungen von XP automatisch der Nachteil von XP:

• Die strukturellen Veränderungen, die von einem Unternehmen durchgeführt werden müssen.
• Die Konflikte, die es automatisch geben wird.

Wenn Michael eine technische, sachliche Beschreibung für die Installation eines Industrieroboters geschrieben hätte ... würde er dann so unsachlich angegriffen werden? Nein, so etwas würde ihm dann nicht passieren. "Extreme Programming" ist aber eine technische und sachliche Beschreibung.

XP stellt Macht-Konzepte "Ohne mich läuft in dieser Firma nichts" in Frage. Es zwingt das Team miteinander zu kommunizieren und das Recht auf geistiges Eigentum an der Lösung aufzugeben.

Ich kann anhand des Artikels nicht feststellen, ob XP umzusetzen in den meisten Fällen

• ein Spaß,
• harte Arbeit,

oder eine Mischung aus beidem ist.

Ich bin sogar unsicher, wenn ich sage: "Dieser Michael ist ein totaler Fan von XP."

Bevor die Erweiterung von Michael existiert hat, habe ich von Ron Jeffries What is Extreme Programming? gelesen. IMHO ist der Wikipedia-Artikel besser als der genannte Text von Ron Jeffries. Zugegeben ... dazwischen liegen fünf Jahre Entwicklung, aber das ändert nichts an der hervorragenden Qualität des Artikels "Extreme Programming". --ClausVB 23:47, 19. Jul 2006 (CEST)

Hi Claus. Danke für die Blumen. :) Das mit dem Industrieroboter stimmt, die Schwierigkeit einen solchen komplexen, abstrakten Artikel zu schreiben wurde schon thematisiert. Klar, wenn Dir noch was auffällt schreib es ruhig hier hin. Ja, die Kritik war häufig emotional und unsachlich. Danke für Dein Post, und das Du den Artikel so gut findest. :) --Michael Hüttermann 19:07, 20. Jul 2006 (CEST)

Danke für Deinen Eintrag in mein Gästebuch. Ich möchte hier noch einmal verdeutlichen, dass für mich der Artikel locker und flüssig zu lesen war. Du hättest den Artikel

• ohne Bilder
• mit vielen Fremdworten
• kompliziert und unstrukturiert

schreiben können. Das Gegenteil ist der Fall. Viele Konzepte werden mit Grafiken deutlicher erklärt. Die Sprache ist so einfach zu verstehen, dass ich den Text in einem Rutsch durchlesen konnte und vieles davon behalten habe. Ein Azubi (kein Fan von XP) hat aufgrund des alten Wikipedia-Artikels einen Vortrag gehalten. Er ließ dabei viele wesentliche Aspekte (wie "Pair Programming") außer acht. Aufgrund des erweiterten Artikels war ich aber in der Lage, ihn auf die Lücken in seinem Vortrag hinzuweisen und alle Argumente, die er hervorbrachte gegen XP genau zu durchleuchten. Was kann man sich mehr wünschen, als einen Artikel, den man von Anfang bis Ende versteht und wo die wichtigen Praktiken, Prinzipien und Inhalte auch noch "hängenbleiben"? --ClausVB 12:50, 21. Jul 2006 (CEST)

Um auf Deine Frage zu antworten: Ich bin in Paderborn zur Berufsschule gegangen. Ich hätte auch noch eine Idee für den XP-Artikel, würde aber gerne mit Dir über Mail oder Skype darüber reden, damit mir hier nicht wieder entgegen geblökt wird "Alles scheiße, alles trivial und marketing Mist!" Meine E-Mail ist cvbspam-gb (at) yahoo.de --ClausVB 21:03, 25. Jul 2006 (CEST)

Extreme Programming

Hallo.

Erst mal herzlichen Glückwunsch zur Auszeichnung des Artikels. Auch wenn mit dem Status Lesenswert noch nicht das Ende der Fahnenstange erreicht ist, ist der Schwerpunkt der Arbeit ganz nach Pareto nun erledigt. Ich denke es war für alle interessant zu sehen wie schnell ein Artikel enzyklopädisiert werden kann und wie fruchtbar gute Diskussionen und Ideen um einen Artikel sind, wenn mehrere Nutzer konstruktiv daran arbeiten. In dem Sinne: Möge uns eine solche Artikelentwicklung noch häufig widerfahren ;-)

Gruß, Geo-Loge 13:15, 20. Jul 2006 (CEST).

Naja, leider war der Großteil der Kritik unsachlich und emotional. Gut war, dass sich schließlich zwei, drei Autoren gefunden haben, die sachlich über den Artikel diskutiert haben. enzyklopädisiert: der Artikel war bereits in ersten Ausbaustufen kritisch, ich denke er ist jetzt schon fast überkritisch. Interessehalber: Was würde dem Artikel jetzt noch fehlen, um exzellent zu sein?--Michael Hüttermann 19:09, 20. Jul 2006 (CEST)

Es fehlt das angesprochene Ausreifen. Das schwierige ist, immer wieder Abstand zu gewinnen, Formulierungen neu zu überdenken und zu optimieren. Mit der Zeit fallen auch immer mehr banale Fehler heraus. Geo-Loge 12:04, 22. Jul 2006 (CEST)

Ein Artikel ist kein Wein. Strukturiertes Vorgehen wäre konkrete Punkte zu identifizieren bzw. die "banalen Fehler" zu nennen. Also ich kann keine banalen Fehler sehen. Wenn ein Automobilhersteller ein Auto baut, dann stellen die das auch nicht drei Jahre in die Garage, um es "reifen" zu lassen. Entweder es ist gut oder es wird halt verbessert, aber "reifen"....von dieser Vorgehensweise halte ich garnichts. "Reifen" bedeutet auf die lange Bank schieben. Es wäre für mich einfach nur interessant zu wissen was dem Artikel für eine Exzellenz fehlt, oder ob ihm überhaupt etwas fehlt. Deine Antwort, Geo, sagt mir es fehlt dem Artikel nichts mehr. --Michael Hüttermann 12:13, 22. Jul 2006 (CEST)

Sieh es einfach als Anwendung von XP-Vorgehensweisen. Warum nicht auch einen Artikel einem Refactoring unterziehen? Ich kann dir nur sagen, wie ich Artikel schreibe. Und die liegen mal eben einen Monat im Trockendock, eh ich mal wieder daran arbeite. Fingerschnippen und die banalen Fehler (Tippfehler, Ortho- und Typografie, Stil) markieren und beseitigen, geht leider nicht. Ich habe Pareto angesprochen: Für die letzten 20% bis zum idealen Maximum, wirst du 80% der Zeit benötigen. Aber du hast mich soweit richtig verstanden: Ich sehe keinen Aspekt mehr, der dem Artikel fehlt. Geo-Loge 22:41, 22. Jul 2006 (CEST)

/* Frohe Feiertage und einen guten Start ins neue Jahr */

Na dann ein frohes Fest, einen dicken Braten und alles Beste! :) Marcus Cyron Bücherbörse 14:12, 23. Dez. 2006 (CET)

Einweihungsparty im Lokal K

Am 28. Juni ist es soweit, unser Lokal K feiert seinen offiziellen Start und lädt zum Besuch ein.

Fest steht, dass es einen Brunch geben wird, der von den Anwesenden organisiert werden sollte. Wikimedia Deutschland stellt Getränke zur Verfügung, alles weitere möchten wir mit der Community organisieren - bringt also bitte mit, was eurer Meinung unser Buffet bereichern sollte: Brote, Salate, Brotaufstriche, Käse, Wurst, Suppen, Süßkram - alles ist gern gesehen und wird sicher auch vertilgt werden. Dazu wird gequatscht, getippt, geplant, fotografiert, hochgeladen, geschrieben, präsentiert, whatever, ... lasst uns einfach einen netten Tag gestalten und das Lokal seinem Zweck als Community-Treffpunkt übergeben.

Wann

Das Lokal K wird am 28. Juni 2014 um spätestens 10:00 Uhr aufgeschlossen und wird dann den gesamten Tag und Abend geöffnet sein - open end.

Um einen Überblick zu haben, wer wann und wie beladen bei uns auflaufen wird, wäre es prima, wenn ihr euch in der Teilnehmer- und Mitbringliste ein. Raymond 14:48, 19. Jun. 2014 (CEST)

Chrysler Comprehensive Compensation System

Hallo Michael Hüttermann!

Die von dir angelegte Seite Chrysler Comprehensive Compensation System wurde zum Löschen vorgeschlagen. Gemäß den Löschregeln wird über die Löschung nun bis zu sieben Tage diskutiert und danach entschieden.

Du bist herzlich eingeladen, dich an der Löschdiskussion zu beteiligen. Wenn du möchtest, dass der Artikel behalten wird, kannst du dort die Argumente, die für eine Löschung sprechen, entkräften, indem du dich beispielsweise zur enzyklopädischen Relevanz des Artikels äußerst. Du kannst auch während der Löschdiskussion Artikelverbesserungen vornehmen, die die Relevanz besser erkennen lassen und die Mindestqualität sichern.

Da bei Wikipedia jeder Löschanträge stellen darf, sind manche Löschanträge auch offensichtlich unbegründet; solche Anträge kannst du ignorieren.

Vielleicht fühlst du dich durch den Löschantrag vor den Kopf gestoßen, weil der Antragsteller die Arbeit, die du in den Artikel gesteckt hast, nicht würdigt. Sei tapfer und bleibe dennoch freundlich. Der andere meint es vermutlich auch gut.

Grüße, Xqbot (Diskussion) 19:37, 18. Dez. 2014 (CET)   (Diese Nachricht wurde automatisch durch einen Bot erstellt. Wenn du zukünftig von diesem Bot nicht mehr über Löschanträge informiert werden möchtest, trag dich hier ein.)

Hallo! Offenbar ist die deutschsprachige Wikipedia der Meinung, dass der von dir angelegte Artikel Chrysler Comprehensive Compensation System nicht in eine Universalenzyklopädie gehört. Ich halte dies für eine Fehlentscheidung. Da ich den gelöschten Artikel sehr interessant fand, habe ich ihn unter Chrysler Comprehensive Compensation System in das Software-Wiki exportiert. Falls du Lust hast, wäre es schön, wenn du dort ein Auge auf den Artikel hättest. Viele Grüße, --Asturius (Diskussion) 11:28, 16. Jan. 2015 (CET)

„Hier trifft sich die Wikipedia-Community und tut Dinge“

Wikipedia-Community - das bist auch Du, und das Lokal K ist auch Dein Raum, um Ideen rund um Wikipedia zu planen, diskutieren und umzusetzen. Um Dich auf Ideen zu bringen, komm doch einfach am Sonntag, den 26. April 2015 nach Köln-Ehrenfeld und mach mit:

• Du hast etwas, was Du immer schon mal für Wikipedia fotografieren oder filmen wolltest ?
• Du wolltest immer schon wissen, wie bestimmte Dinge in der Wikipedia funktionieren ?
• Du hast ein Projekt im Kopf und suchst dafür Raum und Mitstreiter?
• Du hast die Nase voll von der Wikipedia und willst Dich mal auskotzen?
• Du hast eine ganz andere Idee (...)?

Die Tür ist ab 11.00 Uhr offen in der Hackländerstr. 2, siehe Anfahrt. Wenn Du magst, kannst Du Dich anmelden, komm aber auch gern spontan vorbei.

Projektseite: Wikipedia:Lokal K/Aktionstag.

Viele Grüße aus dem Lokal K. 22:04, 19. Mär. 2015 (CET), Raymond

Aktionstag im Lokal-K: nächsten Sonntag

Hallo Michael Hüttermann,

dies ist eine kleine Erinnerung an unseren Aktionstag im Kölner Lokal K, zu dem wir Dich ganz herzlich einladen. Wir wollen versuchen, noch mehr Menschen aus der Community für die Möglichkeiten dieses Real-Live-Raums zu begeistern. Wenn Du magst, trag Dich doch in die Teilnahmeliste ein, oder schau einfach spontan vorbei, wir würden uns freuen!

• Wikipedia:Lokal K/Aktionstag

Grüße aus Köln-Ehrenfeld,

--Elya 22:18, 20. Apr. 2015 (CEST)

PS. Sorry für die erneute Rundmail, du bekommst diese Nachricht, weil Deine Benutzerseite in einer der Kategorien „Benutzer aus (Köln/Umland)“ ist. Es ist ganz bestimmt die letzte Mail für diesen Aktionstag ;-)

Java User Group

Hallo Michael Hüttermann!

Die von dir angelegte Seite Java User Group wurde zum Löschen vorgeschlagen. Gemäß den Löschregeln wird über die Löschung in der Regel sieben Tage diskutiert und danach entschieden. In den hier nachzulesenden Fällen kann eine Seite auch sofort gelöscht werden.

Du bist herzlich eingeladen, dich an der Löschdiskussion zu beteiligen. Wenn du möchtest, dass der Artikel behalten wird, kannst du dort die Argumente, die für eine Löschung sprechen, entkräften, indem du dich beispielsweise zur enzyklopädischen Relevanz des Artikels äußerst. Du kannst auch während der Löschdiskussion Artikelverbesserungen vornehmen, die die Relevanz besser erkennen lassen und die Mindestqualität sichern.

Da bei Wikipedia jeder Löschanträge stellen darf, sind manche Löschanträge auch offensichtlich unbegründet; solche Anträge kannst du ignorieren.

Vielleicht fühlst du dich durch den Löschantrag vor den Kopf gestoßen, weil durch den Antrag die Arbeit, die du in den Artikel gesteckt hast, nicht gewürdigt wird. Sei tapfer und bleibe dennoch freundlich. Der andere meint es vermutlich auch gut.

Grüße, Xqbot (Diskussion) 09:59, 24. Apr. 2023 (CEST)   (Diese Nachricht wurde automatisch durch einen Bot erstellt. Wenn du zukünftig von diesem Bot nicht mehr über Löschanträge informiert werden möchtest, trag dich hier ein.)