Diskussion:Extreme Programming/Archiv/1

Dieses Diskussionsarchiv hat die empfohlene SeitengröVorlage:SSe erreicht und gilt damit als abgeschlossen. Sein Inhalt sollte nicht mehr verändert werden (ausgenommen Kleinbearbeitungen wie Link- und Vorlagenfixe). Verwende für die Archivierung von Diskussionsbeiträgen bitte das aktuelle Archiv und benutze bitte für aktuelle Diskussionen die aktuelle Diskussionsseite. Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise [[Diskussion:Extreme Programming/Archiv/1#Abschnittsüberschrift]] oder als Weblink zur Verlinkung auVorlage:SSerhalb der Wikipedia https://de.wikiup.org/wiki/Diskussion:Extreme_Programming/Archiv/1#Abschnittsüberschrift

XP-Prinzipien

Ich lese jetzt das erste Mal, das eine 40-Stunden-Woche zu den XP-Prinzipien gehört. Gibt es dazu auch eine Quelle? Was ist außerdem mit den Programmierern, die eine 35-Stunden-Woche haben? Kann es nicht auch sein, dass in anderen Ländern mehr als 40 Stunden üblich sind?

Bei solchen Aussagen bekomme ich immer Bachschmerzen...

-- Herr Schroeder 12:03, 9. Dez 2004 (CET)

Die 40-Stunden-Woche wird tatsächlich postuliert. Damit ist aber gemeint, dass keine Überstunden gemacht werden sollen. -- Dishayloo [ +] 22:01, 10. Dez 2004 (CET)

Hast Du dazu auch eine Quelle? Ich habe nur gelesen, dass keine Überstunden gemacht werden sollen (an sich ein hehres Ziel), aber ich habe nirgends 40-Stunden-Woche gelesen... Ich würde zumindest diesen Punkt unter den Prinzipien abschwächen... -- Herr Schroeder 11:43, 13. Dez 2004 (CET)

Genügt ein Hinweis auf das Inhaltsverzeichnis der Originalpublikation von Kent Beck als Quelle? Jpp 17:05, 13. Dez 2004 (CET)

OK, trotzdem wäre ich für eine abgeschwächte Form, das heißt keine explizite Nennung der 40-Stunden-Woche sondern ein Satz der folgenden Art: Überstunden sind zu vermeiden, denn Überstunden mindern die Freude an der Arbeit und somit auch die Qualität des Produkts.

-- Herr Schroeder 18:04, 13. Dez 2004 (CET)

Ich glaube, dass man sich bei einem Artikel über etwas so wohl definiertes wie XP durchaus an "das Original" halten und die 40-Stunden-Woche daher explizit nennen sollte. Eine Abschwächung kann ja in den Ausführungen folgen.--ChristianHujer 16:55, 24. Jan 2005 (CET)

-- Stefan Roock 01.06.2005

Inzwischen heißt die Technik doch Nachhaltiges Tempo (manchmal auch "Durchhaltbares Tempo", "Sustainable Pace")

Eine Nachfrage wegen "begründete die Klasse der agilen Methoden": Crystal wurde das erste mal 1991 offiziell und in den späten 1980ern "inoffiziell", d.h. ohne den Namen eingesetzt. Von wann stammt XP?

Ich stimme zu, dass der Satz "begründete Agile Methoden" gelöscht oder zumindest geändert werden sollte. XP hat Agile Prozesse nicht begründet, nur stark zu deren Popularität beigetragen.

Ich habe den Satz geändert. Okay so? --Jpp 13:03, 12. Jan 2005 (CET)

Ja. --Jwilkes 19:52, 6. Feb 2005 (CET)

Sagt mal, in dem Artikel steht, dass ein Flexibilitätskriterium die gute Dokumentation sei. in vielen anderen Artikeln zum Thema XP steht aber, dass auf die Doku verzichtet wird und nur der Quelltext als Doku dient (weil einfach zu verstehen und Programmierstandarts eingehalten werden). Gerade dies ist ja das Problem bei XP - nämlich die schlechte Wartbarkeit.

Diagramm

Das bestehende Diagramm ist insofern völlig unangebracht, als dass die Beschriftung der X-Achse suggeriert, XP sei ein auf dem klassischen Wasserfall basierender Entwicklungsprozess und würde jede Phase nur einmal durchlaufen. Falls das Diagramm jedoch den Mini-Wasserfall widerspiegelt, ist es ebenso falsch, weil im Spiralmodell ohne XP der Aufwand gegen Ende eines Zyklus nicht wesentlich zunimmt, sondern erst von Zyklus zu Zyklus. Ich schlage vor, die Beschriftung der X-Achse also aus dem Diagramm zu entfernen. --ChristianHujer 13:34, 12. Jan 2005 (CET)

Auch das Diagramm ist an diesem Artikel nicht i.O. --Michael Hüttermann 21:43, 30. Mär 2006 (CEST)

Überarbeiten

Dem Artikel fehlt eindeutig ein klarer Aufbau. --PhilippW 19:44, 14. Jul 2005 (CEST)

Der Artikel sollte komplett überarbeitet werden, da er teilweise sehr strittig ist. (Kostendiagramm, Vergleiche mit anderen Methoden fehlen und das was XP ausmacht, nämlich die eigentlichen Vorteile sind mir nur zu knapp beschrieben...)

Vielleicht kann man dabei auch Unworte wie "Unnutzbarkeit" oder auch "Unwartbarkeit" vermeiden. Nicht vor jedem Wort macht "Un" Sinn, obwohl ein Blick in Google das suggerieren mag. Das Gegenteil von Segen ist eben nicht Unsegen, sondern Fluch. Darüber habe ich mich erst vor ein paar Tagen mit einer Pfarrerin gestritten, deshalb bin ich so empfindlich ;-) UlrichJ 12:39, 25. Okt 2005 (CEST)

Man sagt aber auch Unseglich :-) -- schon gut! sparti 13:46, 25. Okt 2005 (CEST)

XP als Modell

Hallo,

vielleicht irre ich mich. Aber ich habe in der Hochschule gelernt (jaja :-), daß XP Prinzipien und Techniken darstellt und kein eigenes Modell ist. Will sagen, daß es sich nicht ausschließt XP mit anderen Modellen zu kombinieren.

Da musst du differenzieren, von was für einer Art von Modell die Rede ist. XP ist ein Vorgehensmodell, also eine Methode. Die Modelle, die du im Sinn hast, sind wohl eher Analyse- oder Entwurfsmodelle im Sinne der UML, oder? --jpp ?! 21:48, 16. Dez 2005 (CET) PS: Wenn du deine Beiträge mit „--~~~~“, lässt sich leichter diskutieren.

== Artikel gründlich Überarbeiten == --MartinSchwienbacher 19:44, 6. Jan 2006 (CET)

Dies ist ein Online Lexikon und KEIN Werbeforum für XP, der Artikel ist viel zu positiv!

Ich finde nicht, dass der Artikel wie ein Werbeforum für XP klingt. Wenn die sachliche Beschreibung von XP einen positiven Eindruck macht, vielleicht ist XP ja wirklich eine gute Sache.--ChristianHujer 20:21, 3. Mär 2006 (CET)

Die Grafik stammt von einer Organisation, die offensichtlich ein Interesse an der Vermarktung von XP hat. Sie wiederspricht allen wissenschaftlichen Untersuchungen zur Kostenverteilung bei SE Prozessen.

Welchen wissenschaftlichen Untersuchungen? Sämtliche Grafiken die ich kenne, z.B. auch vom Fraunhofer Institut im Zusammenhang mit perspektivenorientierten Code Reviews und quality driven code inspections, sprechen ebenfalls davon, dass im Wasserfall die Kosten ansteigen, je später man Änderungen durchführt oder Fehler findet. Dass die Grafik von einer Firma stammt, stimmt. Dass die Firma ein Interesse an der Vermarktung von XP hat, möchte ich ihr nicht absprechen, was aber meiner Vermutung nach daran liegt, dass sich diese Firma grundsätzlich mit neuen Technologien und Methoden der Software-Entwicklung auseinandersetzt. Die Grafik hat andere Schwächen, und zwar suggeriert sie, dass Software-Entwicklung sowohl grundsätzlich als auch mit XP in einem Wasserfall ablaufe. Deswegen ist die Grafik schlecht. Sie ist aber ansonsten in Einklang mit allen mir bekannten Untersuchungen zur Kostenverteilung. Ich finde es zudem okay, wenn sich auch Unternehmen an der Arbeit an der Wikipedia beteiligen, solange sie nicht direkt Eigenwerbung machen. Sich als Firma dann als Autor einer Grafik zu nennen, halte ich aber für legitim. Firmen sollten genauso wie Privatleute das Recht haben, als Urheber ihrer Werke genannt zu werden. Wichtig ist, dass der NPOV gewahrt bleibt. Der Input von Firmen sollte natürlich besonders kritisch betrachtet werden, um Werbung und Wettbewerbsverzerrung zu vermeiden, denn die Wikipedia soll und will neutral bleiben. Deswegen Input von Firmen gleich abzulehnen oder zu verteufeln, wäre aber meiner Meinung nach falsch. --ChristianHujer 20:21, 3. Mär 2006 (CET)

Ich muss schon einräumen, dass meine Aussagen über XP etwas zu negativ sind - aber im Kontrast zu den positiven Aussagen hier ist das vielleicht zulässig. Zur Grafik - Ich zumindest habe den Eindruck, dass diese Grafik einfach nur eine Kurve ohne Einheiten etc. zeigt die suggertiert, dass alle anderen Techniken neben XP eine Kostenexplosion in den späten Projektphasen (mal abgesehen davon, dass hier "Wartung" fehlt und ich mir nichts unter "Produktion" vorstellen kann) zur Folge haben - das ist nichts anderes als Marketing - es wäre doch schön wenn die Urheber hier ein paar stichhaltige Argumente bzw. Referenzen zur Unterstütung dieser Grafik anbringen würden und nicht nur relativ "nackte" Aussagen.--MartinSchwienbacher 16:28, 13. Aug 2006 (CEST)

Ich muss dir Recht in Bezug auf die Grafik geben. Zudem sagt sie aus, dass die Kosten in anderen Verfahren exponentiell steigen. Die Kosten für Test oder Produktion (laufender Betrieb, Wartung) seien also relativ höher, als z.B. die Projektphasen Design oder Implementierung. Das ist zu pauschal und falsch. Lehmi 17:15, 13. Aug 2006 (CEST)

Hmm? Falls hier das Anforderungsdiagramm gemeint ist: Es geht hier um den Zeitpunkt, wann Anforderungen an das Produkt kommuniziert und umgesetzt werden. Die Graphik ist eine gelungene Beimischung und auch Ableitung zum Text-Pauschalisierungen oder falsche Aussagen kann ich nicht erkennen (bitte Formatierung/Absatzkontrolle berücksichtigen, habe nachgebessert) --Michael Hüttermann 21:40, 13. Aug 2006 (CEST)

XP ist meiner Meinung nach ein mit marketingtechnisch "sexy" Begriffen wie "Refactoring" aufgemotztes Remake von "Code and Fix" - das so was bei großen Projekten nicht funktioniert, weiß man seit Tollcollect wohl auch in der Öffentlichkeit.

Das stimmt ja wohl überhauptnicht. XP ist nichts neues, sondern ein Konglomerat langbewährter Praktiken, unter einem Namen zusammengefasst - aber mit "Code and Fix" hat das nichts zu tun. Wer XP mit Drauflosprogrammieren und Cowboy-Programmierung gleichsetzt, hat XP nicht verstanden. Z.B. gehören strenge Code Conventions und Release-Planung auch zu XP. Und Tollcollect hat ja nun wirklich nichts mit XP zu tun.

In diesem Zusammenhang halte ich ein Zitat von Steve McConnell angebracht: '"Wenn ich das Buch heute schreiben würde, wäre wohl die Fehleranalyse über den gesamten Lebenszyklus einer Software als "Best Practice" enthalten, ebenso wie das Vorgehen nach dem Motto "zuerst testen". Die meisten Vorgehensmodelle sind jedoch seit zehn oder zwanzig Jahren bekannt, sie werden einfach nicht benutzt. Ansonsten hat es einige durchaus interessante Neuformulierungen der grundlegenden Ideen gegeben seit ich "Rapid Development" geschrieben habe, die Bekannteste ist wohl "Extreme Programming".' [1]--ChristianHujer 20:21, 3. Mär 2006 (CET)

Refactoring macht man in der Regel bei Systemen, wenn die Architektur zu schlecht ist. Laufendens Refaktoring zeigt also, dass die Architektur bei XP laufend - weil nie geplant - schlecht ist. Kennt ihr einen Autohersteller, der seine Fahrzeuge nach XP entwickelt.

Mehrere Punkte. Refactoring hat nichts mit schlechter Architektur zu tun, sondern ist auch bei guter Architektur notwendig, z.B. um eine Architektur bei Erweiterungen anzupassen, sodass die Erweiterung leichter durchgeführt werden kann. Solche Anpassungen sind notwendig unabhängig von der Qualität der Architektur.

Schiebt man notwendiges Refactoring auf, und dieser Zeitpunkt kommt während jeder ernsthaften Softwareentwicklung früher oder später, ganz unabhängig von der ursprünglichen Architekturqualität, führt das über kurz oder lang zu dem, was man "übelriechenden Code" oder beschönigend "historisch gewachsen" nennt, manchmal sagt man auch einfach der Code sei "tot". Je früher man Refactoring durchführt, desto lebendiger bleibt der Code.

Anders ausgedrückt könnte man auch sagen, die Architektur muss sich immer wieder an neue Anforderungen anpassen, und kontinuierliches Refactoring ist ein Mittel, sich diesen Anforderungen frühzeitig und ständig zu stellen, anstatt solche notwendigen Anpassungen bis zu einem großen Krach aufzuschieben.

Kontinuierliches Refactoring schafft eine Balance zwischen der Erhaltung einer guten, anpassbaren Architektur und dem Willen, nur das zu implementieren, was tatsächlich gefordert wird. Man implementiert bei XP keine Features, die man nicht oder noch nicht braucht, sorgt aber gleichzeitig kontinuierlich dafür, dass man es sich nicht unnötig schwer macht, zukünftig neue Features zu implementieren.

Weiters sei angemerkt, dass XP aus dem Umfeld von Daimler-Chrysler stammt, zwar nicht aus der KfZ-Entwicklung, aber immerhin aus dem Umfeld eines Konzern der "Automotive" Industrie.--ChristianHujer 20:21, 3. Mär 2006 (CET)

Außerdem sind die Entwickler bei XP anonym - das hat nicht nur Vorteile.

Aehm... mitnichten. Ein Version Control System ist wichtig für XP, früher wurde häufig CVS vorgeschlagen, heute ist es zunehmend Subversion, und da wird nicht nur verfolgt, was geändert wurde, sondern auch wer die Änderung durchgeführt hat. Entwickler sind bei XP definitiv nicht anonym, das aus "Collective Code Ownership" zu schließen ist völlig falsch. "Collective Code Ownership" bedeutet, dass ich als Entwickler nicht in meinem Kämmerlein für meinen Code verantwortlich bin, sondern das gesamte Team für den gesamten Code, mit jedem einzelnen in Gesamtverantwortung mit allen Rechten und Pflichten, die das mit sich bringt. Wenn ich Code sehe, der verbessert werden sollte, habe ich bei XP sowohl das Recht als auch die Pflicht, den Code zu verbessern.--ChristianHujer 20:21, 3. Mär 2006 (CET)

XP bzw. Code and Fix war wohl vermutluch auch der Tod des Netscape Browser, die waren einfach nicht mehr in der lage ein so tolles Refactoring zu machen und wurden von Microsoft auch technisch und nicht nur vom Marketing her aufgerollt.

Was hat XP mit Netscape Navigator zu tun? Das ist ja wohl nun wirklich an den Haaren herbeigezogen. Und warum soll der angeblich tot sein? Was bitte ist dann Mozilla oder Firefox? Technisch vor einigen Jahren ja, war der IE besser als Netscape Navigator, aber jetzt hat Mozilla / Firefox eindeutig wieder die Nase vorn: Tabbed Browsing, XHTML-Support (incl. application/xhtml+xml MIME-Type), SVG-Support, vollständigere CSS Level 2-Umsetzung, mehr CSS Level 3-Support etc. etc.. (Ich selbst gebe jedoch Konqueror den Vorzug)--ChristianHujer 20:21, 3. Mär 2006 (CET)

Geeignet ist XP eher für kleine Softwareprojete und Webapplikationen - aber da ist ja die Architektur seitens des Applicationservers vorgegeben.

XP ist kaum darauf beschränkt. Eventuell muss man XP in Projekten mit Teams von mehr als 20 Personen anpassen, z.B. das Projekt in Komponenten aufteilen und die Komponenten als Produkt im Sinne von XP auffassen. Das ändert aber nichts an der prinzipiellen Eignung von XP als Entwicklungsprozess für sehr viele Bereiche.--ChristianHujer 20:21, 3. Mär 2006 (CET)

Ich habe den Artikel zur Überarbeitung markiert: - Marketingaussagen und Grafik entfernen! - XP vorstellen - Ziele usw. erläutern - Probleme des Ansatzes gleichwertig darstellen - dann zu anderen Modellen abgrenzen (Phasenmodelle usw.)

Du hast hier doch einige ziemlich harte Aussagen bezüglich XP gemacht. Ich gehe mal - think positive - davon aus, Du weißt wirklich, wovon Du sprichst. Dann wäre es aber auch schön, wenn Du mithelfen würdest, den Artikel zu verbessern. Deine Kritik ist ja schonmal ein Anstoß, ändert aber noch nichts am Artikel.--ChristianHujer 20:21, 3. Mär 2006 (CET)

Auf jeden Fall muss deutlich werden, dass XP nicht für Großprojekte und schon gar nicht für in Deutschland typische Embedded Projekte usw. geeignet ist - einfach desswegen, weil wesentliche Schnittstellen zur Zerteilung eines Projetes fehlen.

Warum soll XP nicht für Großprojekte oder Embedded Projekte geeignet sein? Ich kann dafür keinen Grund sehen, lerne aber gerne dazu und freue mich auf eine Diskussion.--ChristianHujer 20:21, 3. Mär 2006 (CET)

--195.65.71.45 07:20, 13. Feb 2006 (CET)Auf wieviele Jahre praktischer Erfahrung mit XP basierst Du Deine sehr pauschalen Äusserungen? Das der Artikel vielleicht nicht ganz objektiv ist, hat sicher etwas. Aber Deine Aussagen sind kein bisschen objektiver!

--84.154.36.151 12:12, 29. Jan 2006 (CET) Nana jetzt mal immer langsam. XP ist sicher mehr als Code and Fix, allein schon deshalb weil die Idee eher ist "Code without bugs" (d.h. ohne fix); das ist zumindest die Idee hinter den andauernden Unit-Tests usw.

So wie ich Code and Fix interpretiere heisst das: Man programmiert drauf los (ohne Tests), das System wird immer größer und wenn dann irgendwann Fehler entdeckt werden, dann behebt man sie. Dieses Vorgehen hat gar nichts mit XP zu tun.

Du beziehst dich auf Toll-Collect; wurde denn bei diesem Projekt XP eingesetzt ?

Auch die Aussage über Refactoring ist ziemlich extrem. Wenn man nur dann Refactored, weil die Architektur schlecht ist, dann macht man etwas falsch. Refactoring sollte man eigentlich immer einsetzen, wenn sich aufgrund von Änderungen in den Anforderungen eine Änderung der Architektur anbietet. Wenn man in solchen Fällen die Architektur nicht ändert, dann würde ich das als schlimmstes Beispiel für "Code and Fix" verwenden...

Dann fragst du ob irgendein Autohersteller seine Autos nach XP entwickelt. Das ist eine ziemlich ungenaue Frage, denn XP ist ja vor allem für die Software-Entwicklung gedacht, eben wegen der Annahme, dass sich "klassische" Entwicklungsprozesse nicht besonders gut auf die Software-Entwicklung übertragen lassen. Wenn es um die Software in den Autos geht, dann wird die Sache interessanter. Soweit ich weiss wurde XP bei DaimlerChrysler schon eingesetzt, aber da ich dafür keine Quelle nennen kann, ist das nur ein unbestätigtes Gerücht. Kann das also jemand bestätigen.

Ja. Der erste dokumentierte Einsatz von XP war bei Chrysler. In welcher Branchen sind (waren) die nochmal? Ach ja Automobile. Nicht nur der Bereich im Artikel ist doch etwas ausbaufähig. --Michael Hüttermann 21:55, 26. Feb 2006 (CET)

Insgesamt bin ich der Meinung, der Artikel braucht nicht als "Überarbeiten" gekennzeichnet werden. Ich will die Entscheidung, das "Überarbeiten" zu löschen, aber nicht alleine treffen. Also wenn das hier jemand liest und auch der Meinung ist, der Artikel bräuchte keine Überarbeitungskennzeichnung... --ChristianHujer 20:21, 3. Mär 2006 (CET)

Kommentar aus Artikel hierhin verschoben

Den folgenden Kommentar habe ich aus dem Artikel hierhin verschoben. --jpp ?! 21:22, 21. Jan 2006 (CET)

Liest sich wie ein Werbeflyer --MartinSchwienbacher 00:59, 21. Jan 2006 (CET)

Kritik

Zitat: Durch den Verzicht auf ein reguläres Anforderungsmanagement ist XP nicht für umfangreiche Projekte mit planbaren Kosten und Terminen geeignet. Für diese Projektkategorie erscheint XP demnach als Rückschritt, der durch eine Gegenbewegung des Software Engineerings ausgelöst wurde, die auf mangelnder Akzeptanz der bestehenden Methoden durch betroffene Software-Entwickler beruht. XP ist für alle Beteiligten bequemer, da unverbindlicher, birgt jedoch die Gefahr in sich, keine belastbaren Abnahmekriterien für das erstellte Produkt zu erreichen. In Branchen, in denen deterministisches Verhalten des Endprodukts zu einem bestimmten Zeitpunkt von zentraler Bedeutung ist, wird auf XP vollständig verzichtet (z.B. Automobilelektronik). XP erfordert ein Projektmanagement, das in der Lage ist, Metriken auszuwerten und sorgfältig zu interpretieren sowie frühzeitig zu kommunizieren und frühzeitig Entscheidungen zu fällen, andernfalls können bei XP Aufwandsschätzungen und realer Aufwand auseinanderlaufen.

Der Kritik kann ich nicht zustimmen. Natürlich gibt es bei XP Anforderungsmanagement, und ist auch für umfangreiche Projekte geeignet. Was soll denn bitte heissen es ist 'bequemer'?!? Alleine dieser Absatz begründet, dass der Artikel überarbeitungswürdig ist. --Michael Hüttermann 18:02, 29. Mär 2006 (CEST)

Ich ebenfalls nicht. Ich habe den ersten Absatz gelöscht. Den zweiten finde ich nachvollziehbar (wenn ich mich recht entsinne, stammt er sogar von mir ;-) Ich habe für die Löschung folgende Begründung:

• XP besitzt sehrwohl ein reguläres Anforderungsmanagement. Die Vorgehensweise mit Story Cards und Task Cards ist sehrwohl ein Anforderungsmanagement. Gepaart mit Metriken ("Das Wetter von gestern") lassen sich auch längerfristig Kosten und Termine sehr gut planen, genau das ist ja auch eines der Ziele von XP.
• XP ist definitiv nicht durch einen Gegenbewegung des Software Engineerings ausgelöst. Diese Darstellung klingt ja zudem so, als sei XP eine Gegenbewegung gegen das Software Engineering. Dabei ist gerade XP eine Bewegung für besseres Software Engineering. Bei kaum einem Prozess wird so viel wert auf die Kerntätigkeiten guten Software Engineerings gelegt wie bei XP: Testen sowohl aus Entwickler- (Unit-Tests bei Test Driven Development) als auch aus Kunden-Sicht (Akzeptanztests), gutes Design (Refactor mercilessly), selbst Code Conventions, um nur einige Beispiele zu nennen.
• Als unverbindlich würde ich XP niemals bezeichnen.
• In Branchen, in denen deterministisches Verhalten des Endprodukts zu einem bestimmten Zeitpunkt von zentraler Bedeutung ist, wird auf XP vollständig verzichtet (z.B. Automobilelektronik). Mit XP sei deterministisches Verhalten nicht erreichbar ist eine völlig falsche Annahme. Der Inhalt einer Story-Card ist aus Sicht der Entwickler nicht abänderbar. Nur der Kunde darf ihn abändern. Wenn der Kunde auf die Story-Card geschrieben hat, Feature foo sei gemäß ISO-Norm bar zu realisieren, dann ist das unumstößlich, und die Akzeptanztests für Feature foo könnten z.B. eine bar-conformance-test-suite sein. Ich kann daran nichts erkennen, was XP ungeeignet für Umfelder mit unumstößlichen Anforderungen machen soll.
• Aus dem Verzicht einiger Automobilelektronikentwickler auf eine mangelnde Eignung von XP zu schließen, ist wohl noch schlechter, als daraus zu schließen, diese Unternehmen hinken dem allgemeinen Wissensstand über Software Engineering gut ein Jahrzehnt hinterher. --ChristianHujer 03:37, 3. Apr 2006 (CEST)

sehr gut! Dem kann ich mich nur anschliessen. Alleine, dass XP bei Chrysler geboren wurde sagt bzgl. diverser Aussagen schon alles. XP hat darüber hinaus überhaupt nichts mit bequemer zu tun. --Michael Hüttermann 20:20, 3. Apr 2006 (CEST)

Hervorragender Artikel

Ich habe den Artikel jetzt halb gelesen und finde ihn so gut, dass der Hinweis: "Dieser Artikel oder Abschnitt bedarf einer Überarbeitung. Näheres ist (...)" entfernt werden könnte. Er hat mir einen sehr guten Überblick verschafft, was XP ist. ClausVB 17:42, 12. Apr 2006 (CEST)

Nachtrag: Ich habe den Artikel und die Diskussion jetzt ganz gelesen. Der Artikel ist wirklich gut und ich finde es absolut in Ordnung, dass er nicht mehr zur Überarbeitung gekennzeichnet ist. -- ClausVB 19:22, 22. Apr 2006 (CEST)

User Story Beispiel (Satzbau)

Hier sollte auch erklärt sein, was User Stories sind und wie sie benutzt werden. Welche Inhalte sind empfehlenswert, welche nicht. Mit dem gegenwärtigen Text kann man so nichts anfangen. M.Buch

Da meine Änderung leider revertiert wurde, müssen wir wohl diskutieren. Warum muss die Schablone der User Story in solch holprigem Deutsch formuliert sein?

1. Diese Schablone kann niemals korrektes Deutsch ergeben: „Als xxx, ich kann xxxx, um xxxx.“
2. Diese dagegen schon: „Als xxx kann ich xxxx, um xxxx“.

Also, was spricht gegen Variante 2? --jpp ?! 16:29, 6. Jun 2006 (CEST)

Ich finde die Unterstellung der falschen Übersetzung etwas irreführend. Wie ich auf Deiner Diskussionsseite bereits skizzierte habe ging es mir bei der Formulierung darum Bausteine zu präsentieren. Es ist ein Template welches in dieser Form in meinen Augen besser verdeutlicht wird. Die Story besteht aus drei Fragmenten. So ist es viel besser ersichtlich. Ferner: "Sprachliches zur User Story" find ich etwas übertrieben. --Michael Hüttermann 18:21, 6. Jun 2006 (CEST)

Naja, wie sollte ich den Absatz sonst nennen? Für die Unterstellung der falschen Übersetzung entschuldige ich mich hiermit, das war unhöflich, insbesondere, weil du einen so großen und wichtigen Beitrag zum Artikel geleistet hast. --jpp ?! 18:59, 6. Jun 2006 (CEST)

Ich habe diesen Diskussionsabsatz hier umbenannt und auf den Scope der Diskussion begrenzt. Es ging ja schließlich nur um das User Story Template, und nicht um den ganzen Artikel. Ich hoffe, dass ist OK für Dich. Ich habe alle beispielhaften User Stories umformuliert. Ich habe in der Praxis auch schon viele User Stories gesehen, die dem Template nicht folgten und zunächst einfach suboptimal formuliert waren. Das ist unschön. Aber so ist es auch ganz chic. Ja, genau, deswegen war ich auch irritiert: wenn ich so viel Zeit investiere den Artikel inhaltlich nach vorne zu bringen, dann...:-) --Michael Hüttermann 19:29, 6. Jun 2006 (CEST)

Na, dann freue ich mich, dass ich wenigstens dazu beitragen konnte, den Chic des Artikels etwas zu verbessern. ;-) Manchmal fangen kleine Verbesserungen halt etwas zu polterig an. --jpp ?! 21:35, 6. Jun 2006 (CEST)

Komplette Überarbeitung und Erweiterung

Ich habe den Artikel die letzte Tage und Nächte einer umfangreichen Überarbeitung unterzogen, und ihn ernorm erweitert. Nun sollte verständlich sein, was XP eigentlich ist, und wie man in XP vorgeht. Ich habe auch eine Unzahl an Fehler korrigiert. Hat jemand vielleicht jetzt noch Verbesserungsvorschläge?--Michael Hüttermann 23:19, 6. Jun 2006 (CEST)

Ich habe mir den Artikel nochmal durchgelesen. Donnerwetter! Da ist ja wirklich eine Menge passiert. Der Artikel ist jetzt sehr gut. Jetzt weiss man auch endlich was XP eigentlich ist und wie man da vorgeht. Das fehlte völlig. Die Bilder sind eine sehr gute Ergänzung. Die ganze Diskussion bis dato ist quasi obsolete. Kann man die eigentlich löschen? Bravo. --80.134.255.204 23:33, 6. Jun 2006 (CEST)

Danke für das prompte Feedback. Aber mit der Diskussion...mal halblang. Die kann ruhig bleiben. :-) Hast Du nicht Lust Dich persönlich anzumelden, und ggf. noch aktiv an dem Artikel mitzuschreiben? Hast Du noch eine Idee wie man den Artikel verbessern könnte? --Michael Hüttermann 23:56, 6. Jun 2006 (CEST)

Bilder

Einen Wunsch habe ich noch: Eigentlich sind die Diagramme ganz gut gelungen. Aber die durch JPG bedingten Kompressionsartefakte (graue Flecken) sehen etwas hässlich aus. Wäre es vielleicht möglich, die Grafiken als PNG heraufzuladen? Oder, noch besser, als SVG? --jpp ?! 10:18, 7. Jun 2006 (CEST)

Das lässt sich einrichten. Allerdings finde ich das bereits länger existente Bild zum Thema Anforderungen ist im .png Format und sieht auch nicht besser aus?! Oder muss ich meinen Monitor mal wieder gründlich abwischen?--Michael Hüttermann 11:05, 7. Jun 2006 (CEST)

Dort treten die Artefakte aber nur in der verkleinerten Darstellung auf. Bei voller Größe sehe ich nur ein ganz normales Anti-Aliasing. Aber wie gesagt, SVG wäre natürlich am allerbesten, wird aber leider nicht von jedem Werkzeug beherrscht. --jpp ?! 11:11, 7. Jun 2006 (CEST)

Du hast Recht! Ich habe es geändert, und es sind wirklich Welten. Viel besser jetzt! Danke!--Michael Hüttermann 11:38, 7. Jun 2006 (CEST)

Aufbau: zuviele Listen

Der Artikel wurde die letzten Tage wirklich kräftig überarbeitet, dafür schon mal danke. Eins stört mich aber und das wären die vielen Listen bzw. Definitionslisten. Ein viel zu großer Teil des Artikels ist ungefähr wie folgt aufgebaut.

Begriff: Ein bis zwei Sätze Erklärung.

Dies stört den Lesefluss enorm. Das liegt zum einen daran das man denkt man ließt in einem Wörterbuch und dementsprechend schwierig gestaltet es sich auch alle angesprochenen Begriff im Hinterkopf zu behalten. Das ist wie Vokabellernen und ist dementsprechend unbeliebt. Zum anderen wirkt der Text auch optisch unschön und man neigt dazu diese Definitionslisten einfach zu überlesen. Eine Lösung wäre es diese Listen in Fließtext zu gestalten und möglichst wenige Begriffe aufzugreifen. --Haeber 01:01, 12. Jun 2006 (CEST)

Hi Haeber. Ja, stimmt, die letzten Tage habe ich den Artikel kräftig umgekrempelt und fundamental ausgebaut. Ja, diese Problematik (Begriff->Erklärung) ist mir bewusst. Eine vollständige Definition XPs muss allerdings auf all die Punkte eingehen. Ein Fließtext, welcher möglichst weniger Begriffe aufgreift, würde dieser Definition nicht gerecht. Ich denke, ich werde beide Ansätze verbinden. Danke für den Tipp.:-)--Michael Hüttermann 12:14, 12. Jun 2006 (CEST)

so, ich habe nun daraus Fließtext gemacht. Die allererste Lösung von vor ein paar Tagen aus jedem Begriff eine eigene Überschrift zu machen habe ich schnell überarbeitet. Die nächste, dann bessere Lösung mit dem Aufbau Begriff->Erklärung war schon viel besser, allerdings bei so vielen unterschiedlichen Begriffen tatsächlich ein wenig unglücklich. Nun habe ich daraus Fließtext gemacht, zu Beginn der Kapitel die notwendigen Begriffe aufgezählt, um dann auf sie im Fließtext einzugehen. Meine Änderungen um das zu erreichen waren recht überschaubar, so dass meine Arbeit der letzten Woche nicht verloren ist. Die traditionellen, sehr wichtigen, zentralen Praktiken gibt es nach dem Begrff->Erklärung Schema. Das scheint mir zur Betonung adäquat, und, zusammen mit den anderen Darstellungsansätzen, eine sinnvolle, optische Auflockerung. --Michael Hüttermann 13:58, 12. Jun 2006 (CEST)

Hervorragend, das sieht schon viel besser aus. --Haeber 16:36, 12. Jun 2006 (CEST)

Im Review vom 11. Juni 06 bis zum 17. Juni 06

Extreme Programming (XP) ist ein sogennantes agiles Vorgehensmodell in der Softwaretechnik. Ich bitte um Feedback zu diesem Artikel. Was würde ihm ggf. noch fehlen, um als lesenswert durchzugehen? Herzlichen Dank. --Michael Hüttermann 13:36, 11. Jun 2006 (CEST)

Ich habe die optische Darstellung weiter optimiert.--Michael Hüttermann 14:07, 12. Jun 2006 (CEST)

Hallo, der Artikel gibt insgesamt eine gute Darstellung des Themas. Ich würde stärker zwischen der ersten und der zweiten Auflage des Buches unterscheiden, da sich hier sehr viel geändert hat und die älteren Sachen einen höheren Bekanntheitsgrad haben, bis jetzt zumindest. Ich kenne kein XP Manifest, nur das für agile Entwicklung, das sollte klarer sein und auch einen Link zum agile Manifesto haben, nicht unbedingt zum Begriff in wikipedia. tmey@munichre.com

Danke fürs Feeback, und das Lob. Ich habe bereits sehr stark zwischen erster und zweiter Auflage des Buches unterschieden. Auch auf Art, Umfang und Bedeutung der Änderungen bin ich bereits detailliert eingegangen. Höhere Bedeutung der traditionellen Version habe ich bereits ebenso angesprochen wie ich den externen Link zum agilen Manifest aufgenommen habe. Ich werde die angesprochenen Dinge noch mehr betonen respektive an der Betonung feilen.--Michael Hüttermann 20:41, 12. Jun 2006 (CEST)

Alles hinreichend drin, danke.--Michael Hüttermann 20:44, 12. Jun 2006 (CEST)

Schöner Artikel. Für "lesenswert" allerdings noch etwas zu trocken und zu philosophisch. Ich hab mir die Freiheit zu kleinen Änderungen bzgl Wikilinks und englischen Begriffen rausgenommen. Anzumerken ist, dass ich noch keinen 10-Minuten-Build gesehn hab. Wenn wir einen Build machen, braucht der parallel auf schnellen Servern locker 2h. Damit wäre ich bei der Projektgröße. Erst ganz am Ende wird in der Kritik erwähnt, dass 10-Leute Maximum ist. "PAir Programming" wird von Controllern als Resourcenverschwendung angesehn. Bei der Kritik sollte vielleicht auf diese Problematik eingegangen werden. Ich würde eine Grafik an den Anfang des Artikels setzen (optisch auflockern). Der Begriff "Artefakt" sollte erläutert werden (der Wikilink nützt da wenig). --Flea 13:17, 13. Jun 2006 (CEST)

Danke! Da ich den Artikel weiter optimieren möchte bin ich Dir sehr dankbar. Hmmm, wie könnte man ihn so modifizieren, dass er "nicht trocken" und "nicht philosophisch" wirkt!? Letztendlich ist er ein recht technischer Artikel über ein Vorgehensmodell in der Informatik, da kann der eine oder andere schon mal meinen der Artikel sei trocken, je nach Blickwinkel. Und auf harten Fakten beruht der Artikel auch. :-) Ja, ich habe schon Deine Änderungen gesehen! Perfekt! Danke!

• Der 10-Minuten Build scheint mir eher eine Vorgabe zu sein, genauso wie das wöchentliche Treffen. Der Build sollte bzgl. Zeit und Kosten gegen 0 gehen, wird dies aber natürlich nie erreichen. Gerade bei großen Projekten dauert ein Build auch entsprechend lange, aber hoffentlich komplett automatisiert.
• Ich werde in der Kritik noch auf Pair-Programming tiefer eingehen, danke!
• Grafik am Anfang: gute Idee! Darüber denke ich bereits länger nach. Allerdings gibt es kein XP-Logo oder vergleichbares. Ich bin etwas unschlüssig welche Grafik ich da positionieren könnte. Hast Du da eine Idee?
• Fremdwörter/Fachbegriffe wo noch nicht geschehen erläutere ich, z.B. Artefakt.

Was weiter macht aus dem "schönen" Artikel einen "sehr schönen" bzw. lesenswerten Artikel? :-) Danke. --Michael Hüttermann 13:38, 13. Jun 2006 (CEST)

Ich habe die Punkte soweit aufgenommen.--Michael Hüttermann 14:11, 13. Jun 2006 (CEST)

wow, die Änderungen gingen aber schnell. Ja es ist schwer das Thema lebhafter zu beschreiben. Mir ist beim Lesen aufgefallen, dass der imho interessantere Teil (Nutzen) erst am Ende kam. Vielleicht kann man das vorziehen? --Flea 16:47, 13. Jun 2006 (CEST)

So, ich habe den Artikel noch ordentlich gepimpt. Ferner habe ich mal prototypisch den ganzen Nutzen Bereich nach oben gezogen. Ich bin mir nicht sicher. Rein inhaltich macht der Nutzen-Abschnitt erst nach der XP Vorstellung richtig Sinn, da die Ansätze und Begriffe vorher erklärt wurden. Frage an Flea und allen anderen: macht es den Artikel jetzt noch spannender wo die Nutzung nun oben steht?--Michael Hüttermann 17:00, 13. Jun 2006 (CEST)

Es liest sich imho besser mit "Nutzen" (und evtl auch "Vorgehen") am Anfang. Logisch wäre aber auch die ursprüngliche Reihenfolge. Ich bin etwas uneins. Genial wäre natürlich eine elegante (knappe) Einleitung, die das Vorweg nimmt. Aber richtig gute Einleitungen sind bei solchen Themen ziemlich knifflig. --Flea 08:19, 14. Jun 2006 (CEST)

Hallo Flea. Was genau sollte die Einleitung vorwegnehmen? Was meinst Du? Ich habe das Vorgehen mal nach oben gezogen.--Michael Hüttermann 11:16, 14. Jun 2006 (CEST)

Ich habe die generelle Struktur noch weiter optimiert.--Michael Hüttermann 12:37, 14. Jun 2006 (CEST)

Ich erinnere mich vor 2 oder 3 Jahren in der CT mal einen Artikel zu XP gelesen zu haben. Da war eine Grafik dabei, die die Iterationen mit einer Art Spirale erläutert hat. Leider hab ich die Ausgabe nicht mehr. Vielleicht kann man so etwas neben die Einleitung setzen. Als "teaser" sozusagen. --Flea 14:38, 14. Jun 2006 (CEST)

Hmmm, was hat denn die Grafik gezeigt? Die Iterationen mit einer Spirale? Findest Du das Ding vielleicht irgendwo, vielleicht elektronisch? Wenn ich das erstellen soll müsste ich schon wissen was da rein soll. Oder ich denk mir noch was aus. Ja, ein Teaser oben wäre ganz gut. --Michael Hüttermann 14:54, 14. Jun 2006 (CEST)

Die alten CTs hab ich nicht mehr. Dafür hab ich mal gegoogelt und die Grafik hat mir noch am besten gefallen. http://www.selectscopemanager.com/ Vielleicht kann man so etwas machen. --Flea 19:42, 14. Jun 2006 (CEST)

Ach sowas meinst Du! OK, ich werde etwas in der Richtung erstellen und oben hinterlegen. Danke! --Michael Hüttermann 01:25, 15. Jun 2006 (CEST)

Ich habe den Teaser hinzugefügt. Inhaltlich habe ich mich an Deinem Linktipp orientiert, allerdings ein paar Änderungen vorgenommen. Der "ScopeManager" von der Seite spiegelt nicht wirklich gut XP wieder. Es wird dort ein Produkt angepriesen.--Michael Hüttermann 08:47, 16. Jun 2006 (CEST)

Ist doch gut geworden. Mir ging es mehr darum, dass ein Bild, das XP irgendwie repräsentiert in der Einleitung auftaucht. Mir ist nämlich aufgefallen, dass ein Bild, egal was, zum Weiterlesen animiert. Vielleicht weil man vom vielen Text nicht so abgeschreckt wird. Zeil erreicht. --Flea 09:21, 16. Jun 2006 (CEST)

Ja, genau! Die Einleitung wird aufgelockert. Der Leser wird animiert weiterzulesen. Flea, vielen, vielen Dank für die Tipps!:-)--Michael Hüttermann 13:31, 16. Jun 2006 (CEST)

So, ich war heute nochmal fleissig, und habe den Artikel noch weiter ausgebaut. Der Artikel steht ja nun fast eine Woche im Review. Fällt vielleicht trotzdem noch jemanden etwas zum Artikel ein? Danke. :-)--Michael Hüttermann 22:55, 16. Jun 2006 (CEST)

Resonanz aufgrund der Lesenswert-Kandidatur, die hier garnicht hingehört

Was für ein Geschwafel, eine Ansammlung von Banalitäten und Trivialitäten! Natürlich muss man einen Arbeitsplan aufstellen, schneller arbeiten und Arbeiten auslagern, wenn die Zeit knapp wird oder der Kunde Änderungs- und Ergänzungswünsche vorlegt. Was ist daran so außergewöhnlich und "extreme"? Typischer Informatikerkauderwelsch und Wichtigtuerei. Einfach wieder mal eine Mücke zum Elefanten gemacht.

"Oh mein Gott" war genau mein Gedanke zu diesem Thema! 100%-ige Übereinstimmung. Das ist echt nicht mehr normal. "Informatikerkauderwelsch" triffts genau, wenn ich von Ärzten, Story Points und Evolution lesen muss, dann frag ich mich echt wo bei den Leuten der Verstand geblieben ist. ×ASM× 10:46, 18. Jun 2006 (CEST)

Geht es vielleicht noch unfachlicher? Ist nicht fast alles eine Ansammlung ein komplexes System aus Banalitäten und Trivialitäten? Und warum führen wir die Diskussion eigentlich an zwei Orten? Geo-Loge 13:03, 18. Jun 2006 (CEST)

Ja, danke Geo-Loge. Man sollte die Diskussion doch an einer Stelle führen. Ich hoffe, es wird auch noch eine Diskussion. Geschwafel ist für mich ein Artikel oder ein Diskussionsbeitrag, der unsachlich ist, plakativ, emotional, nicht auf Fakten beruhend. Wenn es für den einen oder anderen Informatikerkauderwelsch ist dann möge er sich diesen Artikel erst garnicht anschauen. Ich lese auch keinen Artikel über eine Disziplin in der ich mich überhaupt nicht auskenne, nur um dort zu sagen, das wäre Geschwafel. Aussagen wie Verstand geblieben ist kommentiere ich nicht. Es gab doch gerade die Wiki Academy. Ich denke, es ist noch viel Grundlagenarbeit zu verrichten, um Leute zu motivieren, hochqualitative Artikel aus Fachbereichen zu schreiben, und vor allem auch die anderen Personen, die sich hier mehr oder weniger aktiv einbringen, darauf vorzubereiten.--Michael Hüttermann 14:12, 18. Jun 2006 (CEST)

Aktivitäten werden an das ganze Team verteilt, zunächst nicht an einzelne Personen. Es existiert das Bewusstsein und die Verpflichtung nur als Team erfolgreich sein zu können. Diese Verpflichtung wird täglich gelebt. - der gesamte Artikel befindet sich auf ähnlich tiefem intellektuellem Niveau, das schon fast an Schwachsinn grenzt. Sorry, nimm es nicht persönlich, aber du solltest deine Zeit sinnvoller investieren. 217.83.113.213 14:31, 18. Jun 2006 (CEST)

Was verstehst Du denn daran nicht? Bitte Dich anmelden sowie sachlich und unemotional diskutieren. Danke.:-)--Michael Hüttermann 14:36, 18. Jun 2006 (CEST)

Was verstehst Du denn daran nicht? - Aktivitäten werden an das ganze Team verteilt. Soweit verstehe ich das. Aber im Nebensatz steht dann gleich, dass diese ZUNÄCHST nicht an einzelne Personen verteilt werden. Aber nach einer gewissen Zeit dann schon, oder wie? Falls ja, widerspricht dies der ersten Aussage, dass Aktivitäten an das ganze Team verteilt werden. Das ist logischer Unsinn vom Feinsten. 217.83.115.120 15:24, 19. Jun 2006 (CEST)

Hallo IP. Ja, das Vorgehen ist tatsächlich so. Ich habe den Satz etwas umgeschrieben, um es noch klarer auf den Punkt zu bringen. --Michael Hüttermann 15:42, 19. Jun 2006 (CEST)

Die IP hat insofern nicht ganz unrecht (auch wenn ihre Umgangsformen nicht vom Feinsten sind), als nicht dort geschrieben steht, wann die Aktivitäten vom Team an einzelne Teammitglieder weitergegeben werden. Bei dem Teil der Formulierung bin ich mir ebenfalls unsicher, wie das genau abläuft. Das Wörtchen „zunächst“ irritiert etwas. --jpp ?! 15:55, 19. Jun 2006 (CEST)

Hi Jpp. Ich habe das noch ausführlicher erläutert. OK so?--Michael Hüttermann 16:20, 19. Jun 2006 (CEST)

Äh, ja. Aber eigentlich hatte ich den Abschnitt „kollektives Eigentum“ bei den „traditionellen Praktiken“ im Sinn. Dort irritierte das Wörtchen „zunächst“. Jetzt tut es das nicht mehr, zumindest wenn man den ganzen Artikel am Stück liest. --jpp ?! 16:58, 19. Jun 2006 (CEST)

Rangfolge

Wonach sind eigentlich die Weiterführenden Informationen oder Bücher geordnet? Ich beziehe mich mit dieser Frage insbesondere auf die Tools, schließlich sind diese auch von Interesse/Vorteil für die verlinkten Firmen/Projekte. --Haeber 22:29, 18. Jun 2006 (CEST)

Jetzt: "Tools" nach Name, "Siehe auch" nach Name, "Literatur" nach Autor, "Weblinks" nach Name. Vorher war es unsortiert. Besser so?:-)--Michael Hüttermann 23:02, 18. Jun 2006 (CEST)

Jop, es sei denn da versteckt sich ein anderes System hinter, evtl. bei Literatur/Weblinks nach Informationsgehalt. --Haeber

Bisher nicht, Literatur und Weblinks sind angeführt ohne Wertung. Viele Grüße--Michael Hüttermann 23:09, 18. Jun 2006 (CEST)

Betriebswirtschaftliche Sicht

Perfekt! Danke! Es ist eine weitere Sicht auf den Nutzen XPs insbesondere der Nutzen für das Personalwesen gefällt mir ausgezeichnet. Was meinst Du genau mit "Risikoverlagerung ist schwer"? Ich habe ein, zwei Sachen etwas geglättet, ich hoffe es ist OK so für Dich.--Michael Hüttermann 23:21, 18. Jun 2006 (CEST)

Risikoverlagerung bedeutet das Risiko an jemand anderen abzugeben sprich Outsourcing oder Versicherung. Beides wird eigentlich durch Extreme Programming erschwert bzw. ist sowieso kaum üblich. Geo-Loge 00:17, 19. Jun 2006 (CEST)

Der Punkt gefällt mir sehr. Eine gute Ergänzung im Artikel, die ihm echten Mehrwert bringt. Allerdings stehe ich der Aussage ambivalent gegenüber, dass XP eine Risikoverlagerung erschwert. Outsourcing gibt es auch bei Projekten mit XP. Versicherung bei Softwareprojekten? Sind mir in der Praxis nicht wirklich untergekommen, ausser das es Versicherungsprämien /-strafen geben kann je nach Projektdauer und -verlauf. Darauf habe ich im Artikel Kapitel "Diskussion" hingewiesen. --Michael Hüttermann 00:37, 19. Jun 2006 (CEST)

„XP gilt als schwerer einsetzbar in verteilten Umgebungen. Direkter Kontakt mit Entwicklern untereinander und dem Kunden ist problematisch, falls mehrere verschiedene Kunden existieren und/oder die Beteiligten räumlich getrennt arbeiten (z. B. Entwicklung ist teilweise outgesourced).“ Steht so im Artikel und sollte daher speziell beim Umgang im Risikomanagement bewertet werden. Ich werde die Passage noch um Informationsmanagement erweitern. Das fehlt noch. Geo-Loge 08:39, 19. Jun 2006 (CEST)

Ja, stimmt. Bewertung bzgl. Risikomanagment war wirklich notwendig. Eine Erweiterung um Informationsmanagement wäre das Sahnehäubchen.--Michael Hüttermann 12:27, 19. Jun 2006 (CEST)

Diagramm

Ist das nicht eher das Spiralmodell anstelle des XP Modells?!?

siehe Google

oder hier Goole

Wer da? Der Vorgehensmodell-Kenner weiß, dass beide Modelle iterativ und inkrementell sind. Diese visuelle Aufbereitung ist auch für XP prädestiniert. Hast Du Dir mal die Diagramme genauer angeschaut? Gibt es vielleicht Differenzen zwischen den dortigen Bildern und dem Diagramm aus dem Artikel? Schau mal genau hin, bitte.--Michael Hüttermann 15:45, 19. Jun 2006 (CEST)

Aus der Kandidatur 18./19.06.06, um auf den Artikel aufmerksam zu machen (Abgeschlossen)

Extreme Programming (XP) ist ein agiles Vorgehensmodell in der Softwaretechnik. Ich habe den Artikel die letzten Wochen umfangreich überarbeitet und enorm ausgebaut. Der Artikel stand eine Woche im Review. Feedback habe ich aufgenommen. Ich möchte mich bei allen bedanken, die mir die letzten Wochen in Form von Feedback oder tatkräftig direkt am Artikel geholfen haben.--Michael Hüttermann 00:29, 18. Jun 2006 (CEST)

Was für ein Geschwafel, eine Ansammlung von Banalitäten und Trivialitäten! Natürlich muss man einen Arbeitsplan aufstellen, schneller arbeiten und Arbeiten auslagern, wenn die Zeit knapp wird oder der Kunde Änderungs- und Ergänzungswünsche vorlegt. Was ist daran so außergewöhnlich und "extreme"? Typisches Informatikerkauderwelsch und Wichtigtuerei. Einfach wieder mal eine Mücke zum Elefanten gemacht.217.83.90.139 10:34, 18. Jun 2006 (CEST)

Sorry, aber das ist nun mal XP. Soll ich lügen, um etwas zu schreiben, was Dir gefällt? Es ist ein Spezialartikel. Erstens würde ich mich freuen würdest Du Dich namentlich anmelden, zweitens würde ich mich freuen wenn Du sachlich und konstruktiv kritisieren würdest, und nicht so plakativ und emotional. Danke.--Michael Hüttermann 13:59, 18. Jun 2006 (CEST)

Aktivitäten werden an das ganze Team verteilt, zunächst nicht an einzelne Personen. Es existiert das Bewusstsein und die Verpflichtung nur als Team erfolgreich sein zu können. Diese Verpflichtung wird täglich gelebt. - der gesamte Artikel befindet sich auf ähnlich tiefem intellektuellem Niveau, das schon fast an Schwachsinn grenzt. Sorry, nimm es nicht persönlich, aber du solltest deine Zeit sinnvoller investieren. 217.83.113.213 14:39, 18. Jun 2006 (CEST)Ich habe Dir zu genau der gleichen Aussage ja schon etwas auf der Diskussionseite des Artikels geschrieben. Warum machst Du es jetzt nicht besser, und kopierst den Text einfach nochmal hier hin? Willst du vielleicht destruktiv Stimmung machen?:-) ,sagt --Michael Hüttermann 15:14, 18. Jun 2006 (CEST)

Was verstehst Du denn daran nicht? - Aktivitäten werden an das ganze Team verteilt. Soweit verstehe ich das. Aber im Nebensatz steht dann gleich, dass diese ZUNÄCHST nicht an einzelne Personen verteilt werden. Aber nach einer gewissen Zeit dann schon, oder wie? Falls ja, widerspricht dies der ersten Aussage, dass Aktivitäten an das ganze Team verteilt werden. Das ist logischer Unsinn vom Feinsten. 217.83.115.120 15:24, 19. Jun 2006 (CEST)

• Kontra: Schon der erste Satz („XP ist gelebtes Risikomanagement.“) lässt schlimmes befürchten. schlimmes befürchten? was meinst Du?Bei XP werden also auch Entscheidungen getroffen, ob man sich gegen Feuer versichert oder doch Rücklagen bildet, aha. Es geht hier um die Erstellung von Software. Das sollte aus dem Artikel hervorgehen.Ist XP nicht mehr ein Option des Risikomanagements speziell in der Softwareentwicklung? ja, genau. Wenn man in einem derartigen Spezialartikel über die Softwareentwicklung schreibt muss ich doch wohl nicht das Risikomanagement nochmal explizit einschränken, dass es sich hier nicht auf einen Wohnungsbrand bezieht oder?Die Aufbauorganisation ist mir nach minutenlangem Anschauen völlig unklar. Was soll das sein? „Rolle Projektmanager; Beispiel: Ist gewöhnlich der Product Owner, kann auch Entwickler sein; nicht Manager des Teams; Aufgabe: Führung des Teams“. Der Projektmanager ist nicht Manager des Teams führt aber das Team? Was heißt Manager? Das kommt eigentlich von manum agere = „an der Hand führen“, wird heute als „andere zum Erfolg führen“ definiert. Ich empfehle vorsichtig mit Begriffen umzugehen und da mal etwas Logik hineinzubringen! Sorry, aber warum so plakativ und emotional? Das sind nun mal die Rollen und Aufgaben in der Sprache von XP. Ich habe es so erklärt wie es in der Disziplin üblich ist. Alles andere wäre unlogisch.Ansonsten stecken da auch jede Menge Pauschalisierungen („Mit XP wird der Kunde definitiv Software erhalten dessen Umfang ihn nicht überraschen wird.“) drin, die verdächig erscheinen Was heißt verdächtig? Es ist nun mal so, dass aufgrund der permanenten Diskussion mit dem Kunden er nicht überrascht sein wird, wenn denn XP richtig angewendet wurde. Du solltest bedenken wer die Zielgruppe des Artikels ist, und, dass es sich hierbei um einen Spezialartikel handelt. Geo-Loge 12:05, 18. Jun 2006 (CEST) Kommentare von--Michael Hüttermann 13:59, 18. Jun 2006 (CEST)

Da es eine Reaktion auf der Diskussionseite des Artikels gab habe ich auch dort kurz die Posts kommentiert. Das möchte ich hier nicht verheimlichen, und vor allem auf meine Antwort hinweisen. Danke.:-)Diskussion:Extreme_Programming#Oh_mein_Gott.--Michael Hüttermann 14:17, 18. Jun 2006 (CEST)

Auch wenn es sich um einen Spezialartikel Artikel handelt, sollten dessen Aussagen stimmen. XP ist nicht gelebtes Risikomanagement sondern eine Möglichkeit Risiken in der Softwareentwicklung zu managen insbesondere zu vermeiden.ja, genau, und deswegen ist es gelebtes, implizites Risikomanagement (laut XP) Es liegt dabei sogar ein Zielkonflikt des Risikomanagements vor: Risiken können bei XP schwerer übertragen werden (Steht ja auch da, dass XP und Outsourcing schwer zu vereinbaren ist). Wieso Risiken übertragen? Was hat das mit Outsourcing zu tun? Wo ist denn hier der Zielkonflikt?Ich bitte einfach nur darum, dass man mit Begrifflichkeiten besonnen umgeht, insbesondere bei denen, die man sich bei anderen Wissenschaften ausleiht. Die Fehler fielen mir speziell bei den wirtschaftswissenschaftlichen Fachwörtern auf, die teilweise als entstellte „Buzzwords“ auftauchen. Ich kann mir einfach nicht vorstellen, dass es in der Diziplin üblich ist, Aussagen zu treffen, deren Begriffe bei genauer Betrachtung die gesamte Aussage ad absordum führen. Was ist speziell mit dem Zitat als Beleg für Pauschalisierung gemeint: Es sind so viele Randbedingungen (Realisierbarkeit, Beherrschung des XP-Konzepts) an die Aussage daran geknüpft, das man einfach nicht von definitiv sprechen kann. Vorschlag: Schreib doch einfach: „Mit idealtypisch verlaufendem XP wird der Kunde Software erhalten, dessen Umfang ihn nicht überraschen wird.“ Dann ist das akzeptabel. ach so, ich habe das an der einen Stelle für Dich angepasst, wobei ich die Notwendigkeit nicht wirklich erkennen kann, siehe weitere DiskussionSo in der Art müssen Aussagen aber an sehr vielen Stellen korrigiert werden Nachdem ich den einen konkreten Punkt von Dir angepasst habe: welche Formulierung ist denn noch für Dich unschön?. Geo-Loge 14:38, 18. Jun 2006 (CEST) Kommentare von --Michael Hüttermann 15:23, 18. Jun 2006 (CEST)

Die Aussagen stimmen.:-) Ein Artikel, welcher XP beschreibt, beschreibt die Eigenschaften XP idealtypisch, in der Diskussion gehts dann kontroverser zu. Was stimmt denn daran nicht? Ich kann nicht in jedem Satz schreiben falls richtig gemacht oder wenn XP richtig angewendet wird. Ich habe es schon neutral und relativiert formuliert. Du kannst mir glauben, dass ich sehr besonnen arbeite. Der Artikel leiht sich von keinen anderen Wissenschaften etwas aus, er leiht sich von den unten angeführten fachrelevanten Quellen und Literatur etwas aus. Wenn Dich an einzelnen Passagen etwas stört so führe diese einzelnen Passagen an und diskutiere diese. Offenbar kommt Du aus der Wirtschaftswissenschaft? Warum verurteilst Du die in XP üblichen Fachbegriffe als Buzzwords, und wertest sie ab. Ich verstehe nicht die Wertungen und emotionalen Unsachlichkeiten in dieser Diskussion.:-)--Michael Hüttermann 15:10, 18. Jun 2006 (CEST)

Ich habe mir bisher immer Passagen gesucht und daran erklärt, dass begriffliche Fehler vorliegen. „XP ist gelebtes Risikomanagement“ ist keine besonnene Aussage. Ist eine Haftpflichtversicherung gelebtes Risikomanagement oder eine Kapitalrücklage für schwebende Geschäfte? Soetwas wirst du bei diesen Begriffen nie lesen. Nun ja, warum jetzt meine Kritik die immer an Textstellen den Sinn von Aussagen an Hand der Begriffe hinterfragt, emotional unsachlich sein soll, verstehe ich nicht. Ich stelle hier auch nur dar, wozu die Fehler meiner Meinung nach führen. Ich muss im übrigen auch der IP Recht geben, wenn sie ganze Passagen kritisiert, die eigentlich zu relativierende Aussagen enthalten. Quellenarbeit ist ja ganz gut, aber für die Richtigkeit hier sollten wir selber verantwortlich sein. Geo-Loge 15:39, 18. Jun 2006 (CEST)

Hi Geo-Loge. Danke nochmal für Dein Feedback. Also Deinen Punkt bzgl. "Kunde wird nicht überrascht" habe ich angepasst. Risikomanagement: ich werde es jetzt sofort anders formulieren, was Dich hoffentlich mehr überzeugt. IP: "die eigentlich zu relativierende Aussagen enthalten"? Also was denn nu: zu wenig relativiert oder zu viel relativiert? Man kann es vermutlich nicht jedem Recht machen, aber glaube mir, dass ich besonnen arbeite, mich in der Thematik sehr gut auskenne und über die "Richtigkeit" sehr gut urteilen kann, wobei manche Dinge auch in der Literatur bzw. in der Praxis kontrovers beschrieben/bewertet werden, wie ich auch im Artikel beschrieben habe. Über die für mein Verständnis unsachliche, emotionale Kritik habe ich schon etwas gesagt (nochmalige Beispiele: "keine besonnene Arbeitsweise": Unterstellung; "Ausleihen von Buzzwords aus Wirtschaftswissenschaften": unsachlich; "lässt schlimmes befürchten": emotional, unsachlich usw). Wenn du noch weitere Formulierungen als unglücklich einstufst würde ich mich freuen, wenn Du diese konkret aufführst (statt anhand von ein, zwei Aussagen auf den ganzen Artikel zu schliessen, was für mich eine Pauschalisierung ist), vielleicht in koordinierter Listenform zwecks Abarbeitung? Also wenn wir den Artikel noch weiter verbessern können -wo möglich- wäre das doch für alle das Beste. Der Artikel stand bereits im Review und am Ende kam kein Feedback mehr, wobei Feedback dort ausgesprochen gut und konstruktiv war. Jedem steht übrigens die Möglichkeit frei sich proaktiv in den Edit das Artikels einzubringen. Danke. :-) --Michael Hüttermann 16:01, 18. Jun 2006 (CEST)

Eine eigentlich zu relativierende Aussage ist etwas anderes, als eine eigentlich zu relativierte Aussage ;-) Geo-Loge 16:26, 18. Jun 2006 (CEST) dem kann ich mir nur anschließen.  :-) Hast Du noch eine weitere Idee den Artikel noch weiter zu verbessern, Geo-Loge? Ich kämpfe um Dein kontra. :-) --Michael Hüttermann 20:27, 18. Jun 2006 (CEST)

Hab unten noch ein paar Punkte; an dem Kontra wird sich erst mal nichts ändern. Was ich vorschlage geht so in Richtung wissenschaftliche Methoden und Modelle aus anderen Wissenschaften, die beim Extreme Programming genutzt werden. Dazu gehört sicher auch die ökonomische Betrachtung. Geo-Loge 20:54, 18. Jun 2006 (CEST)

Es ist zwischenzeitlich eine Menge passiert. Was denkst Du nun über den Artikel? Bitte bedenke auch die Komplexität der Thematik. --Michael Hüttermann 14:33, 19. Jun 2006 (CEST)

Kontra: Obwohl mir der Artikel streckenweise gut gefällt, kann mich leider nicht zu einem pro durchringen, da ich doch an verschiedenen Ecken "hängengeblieben" bin:

• Die Kritik an XP sollte auch in der Einleitung erwähnt werdenIch habe einen kritischen Einschub in die Einleitung gepackt. Reicht das?--Michael Hüttermann 21:33, 18. Jun 2006 (CEST)
• Welche Bedeutung hat XP im Vergleich zu sonstigen Vorgehensmodellen (wie oft kommt es zum Einsatz)?Das habe ich unten in der Diskussion geschrieben, Stichwort Forrester Research. OK?--Michael Hüttermann 21:33, 18. Jun 2006 (CEST)
• Die Rolle "product owner" wird missverständlich beschrieben. Warum sind auch "project manager", der Kunde und der User "product owner"?Sie können es sein, das ist unterschiedlich. Ich habe eine Erläuterung ergänzt. OK?--Michael Hüttermann 21:33, 18. Jun 2006 (CEST)
• Der Projektmanager ist nicht Manager des Teams, aber er führt das Team? Und der User führt auch das Team? Verstehe ich nicht!OK, ich ergänze eine Erläuterung. OK so?--Michael Hüttermann 21:33, 18. Jun 2006 (CEST)
• Die Spalte "traditionelle Vorgehensweise / Risiko" in der Tabelle mit XP-Kerndisziplinen ist etwas problematisch. Viele der erwähnten Punkte (z.B.: mangelnde Tests) haben nichts mit der traditionellen Vorgehensweise zu tun, sondern sind als handwerkliche Fehler einzustufen. Diese können auch in einem XP-Projekt passieren.Hmmm, ich habe die Tabellenüberschrift angepasst. Ich verstehe Deinen Einwand. Ich hoffe, die neuen Überschriften treffen den Punkt besser?--Michael Hüttermann 21:33, 18. Jun 2006 (CEST)
• Der Satz "XP ist gelebtes Risikomangement" gefällt mir nicht. Jedes Projektmanagement ist "gelebtes Risikomangement". Was ist daran spezifisch für XP?--Belsazar 16:19, 18. Jun 2006 (CEST) Ich habs überarbeitet, danke.--Michael Hüttermann 21:33, 18. Jun 2006 (CEST)

Danke für Deine konstruktive Kritik. Ich gehe darauf zeitnah detailliert ein.--Michael Hüttermann 21:03, 18. Jun 2006 (CEST)

Danke Belsazar nochmal für Deine konstruktive Kritik. Ich habe Deine Punkte aufgenommen. Ist es OK so?--Michael Hüttermann 21:33, 18. Jun 2006 (CEST)

 Kontra Der Artikel ist Werbeflyer für diese Methode und läßt jegliche Außenperspektive vermissen. Schon von dem PR-Sprech bekomm ich Augenschmerzen, kann das sein, dass sich der Artikel teilweise an einem "Lehrbuch" dazu orientiert?? XP ist gelebtes Risikomanagement, da hatte ich schon keine Lust mehr (Wenn überhaupt: Die Verfechter der XP-Methode bezeichen sie als gelebtes Risikomanagement); hab aber weitergelesen und habe es wirklich beräut; das Diagram der Zentralen XP-Werte ist die schlimmste PR-Sprech-DümmlichDingsBummmens der letzten Zeit (Wie in drei Teufels Namen soll eine Methode um Programmierprojekte abzuwickeln Respekt und Mut als Wert beinhalten). Dann der ausdauerende und falsche Fettdruck im Mittelteil.Sobald die Kandidatur vorbei ist gehts wohl in die QS.--syrcro.ПЕДИЯ^(б) 16:40, 18. Jun 2006 (CEST)

Wenn Du mal etwas tiefer in den Artikel schaust wirst Du einen umfangreichen Diskussionsbereich finden, der sehr kritisch mit XP umgeht ("Außenperspektive"). Die ersten Kapitel stellen XP halt vor, das hat mit PR nichts zu tun. Das gelebte Risikomanagement hatten wir ja schon weiter oben. Ich habe es in den Sätzen danach erläutert?! Die Diagramme der zentralen Werte, Prinzipien sind sehr sachlich. Die dargestellten Infos sind halt die Merkmale die XP objektiv ausmachen. Wenn Du etwas nicht verstehst, so erkennbar mit der Aussage bzgl. Respekt und Mut, musst Du trotzdem nicht so emotional loslegen. Was denn für ein andauernder Fettdruck? Es sind die Kernbegriffe XPs. Wie soll ich sie sonst visuell auszeichnen? Dein QS Satz finde ich amüsant. Sorry, aber den kritischen Post vor Dir fand ich wesentlich konstruktiver und sachlicher. :-) --Michael Hüttermann 21:03, 18. Jun 2006 (CEST)

Syrcro: es ist eine Menge passiert seit Deiner Bewertung, formal und inhaltlich. Ist der Artikel nun OK für Dich? :-)--Michael Hüttermann 13:57, 19. Jun 2006 (CEST)

• entschlossenes abwartendes  Kontra. Umfang und Stil lassen die Grundlage für ein Wikibook (bzw. einen Werbeprospekt auf Wikisource) erkennen, als rein deskriptiver Enzyklopädieartikel kann er allerdings in dieser Form nicht stehen bleiben. Konkret beziehen sich die Mängel auf eine überdurchschnittliche Fixierung auf die im Rahmen des Konzepts eingeführten Fachbegriffe, die sehr häufig als Schlagwort gebraucht und zudem fast vollständig kursiv gesetzt sind. Warum schafft es beispielsweise ein Artikel über Fetofetales Transfusionssyndrom (kurz FFTS) mit einem deutlich schwierigeren Lemma, die Abkürzung durchschnittlich etwa 1 mal pro Bildschirmseite zu verwenden, während das eingängige Schlagwort "Extreme Programming" mit der "coolen" (und ein wenig an Windows erinnernden) Abkürzung "XP" mehr als 10 mal pro Bildschirmseite auftaucht? Die bereits angeführten nicht aussagekräftigen Sätze sind ein weiterer Punkt. Vorschlag: Reduktion des gesamten Themenkomplexes auf: Konzeption, Umsetzung, Vergleich mit anderen Methoden und Kritik. --Taxman ^Rating 17:19, 18. Jun 2006 (CEST)

Versteh ich nicht. Wenn Dir das kursive nicht passt, darüber lässt sich streiten. Ich fand es hilfreich in dieser Form die Begriffe auf die es ankommt visuell hervorzuheben. Es sind die Kernbegriffe XPs. Ja, es sind in der Tat Schlagworte. Darf man keine Wörter kursiv oder fett hervorheben? Konzeption? Sind die Werte, Prinzipien, Praktiken. Umsetzung? Siehe Vorgehen. Vergleich + Kritik gibts auch. Dein Transfusionssyndrom hat ein schwierigeres Lemma? Glaube ich nicht. Wenn ich mir die Reaktionen hier anschaue zeugen sie von grosser Unkenntnis in der Sache, und Schwierigkeiten in der Form. :-) Ich möchte auch keine Wertung reinbringen zwischen XP und Transfusionssyndrom, das sind zwei total unterschiedliche Dinge. Vielleicht denkt ja der eine oder andere aufgrund der sehr gute, verständlichen Beschreibung und der Begriffe wie Respekt oder Mut das Lemma ist ganz einfach. Ha! Deine Aussage ist auch der Artikel ist zu lang? Cool, bald haben wir alles durch. :-) Also was wäre denn in Deinen Augen konkret zu tun? --Michael Hüttermann 21:03, 18. Jun 2006 (CEST)

Möglicherweise hängt es damit zusammen, dass ich mich bislang überhaupt nicht mit Vorgehensmodellen auseinandergesetzt habeVorgehensmodell wird direkt im ersten Satz referenziert. Soll es zusätzlich noch erklärt werden?: Die Strukturierung (Inhaltsverzeichnis) macht es mir leider unmöglich, nachzuvollziehen, welche Inhalte ich wo finden werde, was ein zentraler Aspekt bei einem so langen Artiekl ist. Ist bsp. das Wort "Attribut" ein feststehender Begriff innerhalb dieser Wissenschaft? Als Laie kann ich mir unter "Attribut eines Vorgehensmodells" zumindest nicht das vorstellen, was mich dann im Absatz erwartet. Außerdem sehe ich "Nutzen" als Konsequenz aus einer richtig durchgeführten "Vorgehen", daher wundert es mich, dass dieser Absatz zuerst kommt. Das trägt in meinen Augen etwas zu dem Werbecharakter bei (a lá "Sie können alle diese Vorteile bekommen. Sie müssen nur folgendes machen"). Wenn ich mir allerdings Prototyping (Softwareentwicklung) anschaue scheint das durchaus eine gängiger Aufbau zu sein. Nutzung hatte ich zunächst weiter unten, allerdings kam das Feedback es nach oben zu packen. Das soll angeblich den Text lebendiger und den Leser neugieriger machen. Ich find das mittlerweile garnicht schlecht. Attribute ist irreführend, stimmt. Ich ändere das. Ich dachte schon das Inhaltsverzeichnis ist gut und beinhaltet alles wichtige. Hmmm, allerdings bin ich auch in der Materie drin und mache das beruflich.

Noch ein für mich sprachlich nicht besonders gelungenes Beispiel (ich werde mich bemühen einige weitere demnächst auf die Diskussionsseite zu schreiben):

Extreme Programming ist die Summe einzelner Best Practices. Sie sollen alle zusammen eingesetzt werden, um den größten Nutzen zu erzielen. XP definiert sich selbst mit diesen Prinzipien allerdings nicht als Allheilmittel. Da wo es den individuellen Anforderungen nicht genügt, soll es angepasst werden. Viele Prinzipien greifen verzahnt ineinander. Einzelne Praktiken sind an sich nicht neu, werden teilweise bereits lange genutzt, oder sind sogar von trivialer, und doch unterschätzter Natur. Die Praktiken sind die greifbaren, konkreten Maßnahmen, die sich aus den Werten und den Prinzipien ableiten lassen.

..definiert sich nicht als Allheilmittel: Wer würde das auch von seinem Modell behaupten wollen ohne völlig unglaubwürdig zu werden?doch, das ist leider so. Andere Vorgehensmodelle geben das Vorgehen tatsächlich strikt vor.

..soll es angepaßt werden: Muß man Gruppenleitern wirklich den Tipp geben, dass sie etwas verbessern können, falls der ursprüngliche Vorschlag ihnen nicht paßt? Ist diese Tatsache relevant für einen Enzyklopädieartikel? Vielleicht ließe sich das in einen noch zu schreibenden Absatz über die philosophische-/motivations- Komponente von XP einbauen.Laut Vorgehensmodell kann das individuelle Vorgehen angepasst werden. Das ist wichtig. Andere Vorgehensmodelle beinhalten das nicht. Sie geben einen Weg strikt vor. Und die Unternehmung glaubt daran und zieht das Projekt bis zum Ende durch.

Einzelne Praktiken sind nicht neu...: Wenn es eine Summe aus Best Practices ist, können sie (zumindest gemäß der verschachtelten Definition innerhalb des Artikels) nicht neu sein.Ja, stimmt. Ich habe hier einen Hinweis aufgenommen Best Practices ganz kurz zu erklären. Ich kann das auch alles rausnehmen, allerdings wird es dann wohl für den Leser, der nicht vom Fach ist, noch schwerer, und er muss häufig einzelne Wörter nachschlagen.

... von trivialer, und doch unterschätzter Natur: Wer behauptet hier, daß irgendwer eine triviale Praktik unterschätzt? Leute, die mit XP in Berührung kommen, auch die Leser hier. Bestes Beispiel: einige Kritiker hier, die das als Geschwafel abtun, alles sei doch ganz klar.

Ich hoffe meine Bedenken sind nachvollziehbar. --Taxman ^Rating 13:08, 19. Jun 2006 (CEST)Ja, sind sie.:-) Allerdings sehe ich Deine Bedenkung eher als Grundsatzproblem. Wie oben in den Einzelfällen beschrieben möchte es der eine so haben, der andere lieber anders. Verzwickte Situation. Was kann man da tun?--Michael Hüttermann 13:31, 19. Jun 2006 (CEST)

•  Pro XP hat mehr mit Projektmanagement und Motivation zu tun als mit Software, daher ist das von anderen angeprangerte „Geschwafel“ nichts anderes als ein darauf aufbauendes notwendiges Informationsmuster. Soll heißen das der Artikel gerade dadurch an Nutzen gewinnt, das er eben solche für manch einen als Banalitäten abgestempelte Dinge verdeutlicht, um einen umfassenden und möglichst verständlichen Artikel zu ermöglichen. Ich studiere Informatik und in den Fächern Softwaretechnik (I–III) bzw. Projektmanagement werden (in Anführungsstrichen) „auch nur solche Banalitäten“ in Bezug zur Agilen Software-Entwicklung (inkl. XP) aufgebracht, das liegt an der wie schon oben erwähnten Sache von XP, die nunmal daraus besteht so etwas mitzuteilen, XP ist reine Psyche und kann nur so erklärt und wiedergegeben werden. Es ist natürlich klar das der Artikel verbesserungsfähig ist Wo genau?--Michael Hüttermann 21:03, 18. Jun 2006 (CEST), ihn jedoch mit pauschalen und schlecht bzw. unbegründeten Aussagen wie Geschwafel oder Banalität abzustempeln zeugt von Fachlicher Unkenntnis oder Voreingenommenheit. Pro auch deswegen, um durch die für mich unverständlich harte Kritik vorerst der 5-Contra-Lösch-Regel zu entgehen und ein Weiterführen der Diskussion zu ermöglichen. --Haeber 18:40, 18. Jun 2006 (CEST)

Einschub @ Michael Hüttermann: Verbesserungswürdig in der Hinsicht die wie schon auf der Artikel-Diskussion angeprangerte Buzzword-Verwendung (zu viele Begrifflichkeiten/Schlagwörter [siehe die vielen kursiven oder fettgedruckten Wörter] das ist too much, die Worte sind natürlich größtenteils berechtigt nur das Verhältnis zum Fließtext passt nicht) auch kommt mir das Wörtchen XP zu häufig vor, vielleicht kann man da einiges Umformulieren, ich meine jedoch nicht XP einfach durch es, Verfahren oder ähnliches zu ersetzen sondern den gesamten Text daraufhin zu verbessern, siehe auch die teils berechtigte Kritik von Benutzer Taxman. Vielleicht wären auch Statistiken zur Verwendung von XP (inkl. Vergleiche mit anderen Vorgehensweisen, Einbau wichtiger Punkte objektiver Anwendungsberichte), mehr Schlussfolgerungen/Kritiken von Usergroup-/Acedemy-Treffen oder Anwendern sinnvoll. Zitate. Auf der anderen Seite natürlich all’ die möglichen Verbesserungen die von anderen Benutzern kommen :-) --Haeber 21:33, 18. Jun 2006 (CEST)

Schade, dass das nicht früher von Dir kam. Du hast den Artikel ja über längere Zeit verfolgt, mitentwickelt und auch gesehen dass er im Review stand.:-) XP besteht halt auch aus Schlagwörtern, wie kann man das anders aufnehmen?? Also ich minimiere mal die fetten und kursiven Begriffe, mal gucken was passiert. :-) OK, mit der Häufigkeit des Vorkommens des Begriffs: ich schaue nochmal drüber. Statistiken zur Verwendung XPs habe ich doch aufgenommen?! Vergleiche mit anderen Vorgehensmodellen habe ich in der Tabelle durchgeführt! Objektiver Anwendungsbericht? Zitate? Was denn noch alles? Ich will hier keinen exzellenten Artikel schreiben. :-) "All die möglichen Verbesserungen von anderen Benutzern": Ich habe mittlerweile vieles aufgenommen. Das meiste was hier geschrieben wurde ist nur destruktiv, unsachlich und emotional. Aber das was ich rausziehen konnte habe ich rausgezogen.:-)Da ich weiss das Du sachlich und fundiert diskutierst würde ich mich über folgendes freuen: mach doch auf der Diskussionsseite des Artikels eine Liste auf mit den konkreten ToDos die noch offen sind. Das wäre super!---Michael Hüttermann 21:55, 18. Jun 2006 (CEST)

Warum schade, man hat doch alle Zeit der Welt Kritik aufzunehmen (wobei einige Kritikpunkte auch erst mit der Zeit entstanden sind, bzw. erst in diesem Zustand sinnvoll sind sie zu erwähnen) und wenn diese Kandidatur nicht glückt kann man einfach eine neue initialisieren. Achso wegen der ToDo damit hab ich schlechte Erfahrungen gemacht (siehe meine ToDo bei der Mondlandungslüge, die verhindert nur das sich andere am Artikel beteiligen, weil man denkt das immer der Ersteller der ToDo das erledigen möchte und man selbst sich nicht rantraut), entwickle diesen Artikel lieber iterativ, das macht ihn eingängiger und nicht so zerstückelt, würde auch eher den XP bzw. YAGNI-Modell entsprechen :-) --Haeber 22:10, 18. Jun 2006 (CEST)

stimmt. :-) Meine Intention der Kandidatur ist es primär den Artikel einer noch breiteren Öffentlichkeit zugänglich zu machen und den Artikel dadurch zu verbessern. Ich habe jetzt die konkreten, artikulierten Kritikpunkte aufgenommen, die vorgebracht wurden. Hmm..was jetzt?:-) --Michael Hüttermann 22:33, 18. Jun 2006 (CEST)

Okay. Diskutieren wir weiter: Wenn sich der Artikel auf ein psychologisches Thema bezieht, wo sind dann die psychologischen Darstellungen? Viele kritisieren den Prospektcharakter: Nur weil das Thema an die Psyche geht, muss sich der Artikel ja nicht wie ein Motivationsskript lesen. Wo sind Ansätze der Kommunikationstheorie (Medienreichhaltigkeit etc.) und Kritik des Aufwands der Kommunikation zur Abstimmung beim XP? Warum nicht auf den soziologischen Aspekt des Wissensaustauschs eingehen und schauen, was es an soziologischen Lemmata dazu gibt? Geo-Loge 18:49, 18. Jun 2006 (CEST)

Was Haeber sagt ist vollkommen richtig. Die Attribute die XP ausmachen wurden neutral formuliert. Ich kann da kein Motivationsblatt erkennen. Der Denkanstoss von Haeber ist korrekt, daraus allerdings neue Kritik zu schliessen es fehlen Hinweise auf Medienreichhaltigkeit ist der falsche Schluss. Dass XP von psychologischer Natur ist wurde ausreichend erwähnt, siehe auch Respekt und Mut und die anderen Werte, Prinzipien und Praktiken. Was für den einen Banalitäten sind ist vielleicht für den anderen psychologische Grundlagen? Warum wird hier so wild um sich geschossen? Geo-Loge willst Du unbedingt den Artikel hier rausdiskutieren?:-) --Michael Hüttermann 21:03, 18. Jun 2006 (CEST)

Die letzten erwähnten Sachen stehen eher einer Exzellenz im Weg. Vom Status lesenswert ist der Artikel aber so oder so noch sehr weit entfernt. Du solltest vielleicht mal weniger auf die rethorisch aufpolierten Wörter hier achten. Der Einwurf mit den WikiBooks war übrigens garnicht so schlecht. Schau dir zum Beispiel mal solche Werke an: OpenSource_im_Unternehmen. Rethorisch aggressiv formuliert Motivationsskript, possitiver ausgedrückt Bedienungsanleitung zur Umsetzung von Extreme Programming, was aber beides auf das Selbe hinausläuft. Was den meisten hier halt nicht gefällt ist der geringe enzyklopädische Stil. Im Übrigen: Anerkennung für deine tapfere Diskussion. Klingt jetzt abgewatscht aber da steckt sehr viel Arbeit drin und den ein oder anderen Beitrag hier hätte ich als Tritt in den Magen wahrgenommen. Geo-Loge 21:17, 18. Jun 2006 (CEST)

Aha. In meinen Augen handelt es sich nicht um ein Motivationsskript. Also ich kann nochmal drüber gehen und die Ausführungen noch weiter "relativieren". Aber was soll das?? Die ersten Kapitel wird XP erklärt, dann wird kritisch darauf eingegangen. Also der große Teil der Resonanz hier ist unsachlich, unstrukturiert, emotional und unfundiert. Ich habe Schwierigkeiten einzelne konstruktive Punkte zu identifizieren, die konkret zu verbessern sind. "enzyklopädische Stil"? Wenn ich mir die Resonanz anschaue: ist das enzyklopädischer Stil?:-) Ja, der steckt Arbeit drin, wie auch in dem Artikel. Wie man unschwer erkennt bleibt nicht viel übrig nimmt man sich die meissten "Kritiken" hier mal genauer vor. Es ist amüsant. Alle Leute hätten zu der Wiki Academy gemusst, das wäre sehr interessant gewesen für sie. :-) Es gibt sicher andere Artikel, in denen sich auch Experten auf ihrem Gebiet sehr stark einbringen die sich von solch unqualifizierten Aussagen abschrecken lassen. Schade, dass man somit gute Leute vergrault...Michael Hüttermann 22:07, 18. Jun 2006 (CEST)

Du verweist immer auf die Wiki-Academy, teile uns doch mal mit was du in Bezug zu diesem Artikel oder der Diskussion dazu ansprichst/meinst. --Haeber 22:23, 18. Jun 2006 (CEST)

Es geht zum Beispiel darum hochqualitative Artikel, vor allem auch Spezialartikel zu verfassen, bzw. Experten zu einer Mitarbeit zu motivieren. Diese Kandidaturdisskusion hier wird jeden Experten abhalten sich aktiv in Wikipedia einzubringen. Und deswegen denke ich ich muss dem Professor recht geben, der neben mir letzte Woche im Radio zu wikipedia interviewt wurde: er meinte wikipedia kann niemals die Qualität eines Brockhaus erlangen.Guck doch mal hier: http://www.wikipedia-academy.de/index.php. --Michael Hüttermann 22:40, 18. Jun 2006 (CEST)

Wobei man die Aussagen des Professors relativieren kann, schließlich sind die Experten die normalerweise Literatur verfassen, in der Wikipedia anderen Gegebenheiten ausgesetzt. Nur hier gibt es Pendanten aus allen Bereichen, der eine achtet auf die Typografie (kursiv, fett), andere auf Formulierungen, andere brauchen unbedingt viele Tabellen, andere sind Bild-/Grafikaffin, einige bevorzugen Listen/Schlagwörter der andere das genaue Gegenteil. Des Weiteren werden Artikel in der Wikipedia oft einem viel breiteren Publikum vorgesetzt, man muss es dem Anfänger also genauso gerecht machen wie dem Experten. Natürlich kann man auch in der Wikipedia Spezialartikel verfassen, nur müssen es die Spezialisten wegen dem breiten Publikum jedem recht machen, das scheuen die Experten, weil sie es einfach nicht gewohnt sind damit umzugehen und es erst lernen müssen. Oft braucht man nicht jede Kritik eins zu eins umzusetzen, in der Regel werden Kompromisse vorgeschlagen und eingegangen und das muss man begreifen. Man kann in der Wikipedia nunmal nicht sein eigenes Süppchen kochen, es wird von der Gemeinde gekocht und von dem einen mehr oder weniger gewürzt, der eine versalzt die Suppe der andere kippt dann zur Rettung noch mehr Wasser rein, das führt zu laschem Geschmack, es wird wieder mehr Pfeffer benötigt, noch ein paar Erbsen; halt zu viel die Kelle steht ja schon, also wieder mehr Wasser usw. u.s.f. :-) --Haeber 23:25, 18. Jun 2006 (CEST)

Hi Haeber! Naja, in der Theorie. Was bringt es mir wenn die Leute mit vermeintlich besonderen Fähigkeiten sich nicht aktiv und konstruktiv einbringen. Was bringt es der Qualität wenn Leute hier abstimmen können, die unsachlich und destruktiv "argumentieren"? Weil jemand etwas nicht versteht wird der ganze Artikel zerrissen...das würde es beim Brockhaus nicht geben. Und ja, der Brockhaus ist auch für die Allgemeinheit, und der Duden auch usw. Ein eigenes Süppchen kochen will der, der nicht konstruktiv mitarbeitet. Ich möchte die Qualität des Artikels über diese komplexe Thematik noch weiter verbessern. Wie soll das gehen, wenn hier so viel Polemik drin ist. Das ist halt der Nachteil wenn sich jeder auch anonym überall einbringen kann. Ich freue mich andererseits sehr über konstruktive Kritik, die ich gerne aufnehme. Noch besser ist es wenn die Leute sogar aktiv am Artikel mitschreiben. Seit einigen Stunden optimiere ich ja am Artikel fleissig weiter. Allerdings kommt jetzt der Punkt wo ich soweit durch bin. :-)--Michael Hüttermann 00:11, 19. Jun 2006 (CEST)

Einen Vorteil haben diese unkonstruktiven Beiträge, sie zeigen einem auf das der Artikel so wie er ist nicht jedem gefällt :-). Diese Beiträge darf man nicht zu ernst nehmen, oft ist es auch so das einer mit einem Verriss anfängt und andere es mehr oder weniger gelungen nachplappern. Ich kann dich zumindest damit trösten, das die Auszeichnung zum Lesenswerten oder Exzellenten Artikel keinerlei Verbesserung der Qualität des Artikels bewirkt, es kann sogar zur absoluten Stagnation kommen, lediglich die durch die Wahl hervorgebrachten Diskussionen und Hinweise bringen einen Artikel weiter. Stell dir vor der Artikel wäre einfach durchgewunken worden, dann wären sinnvolle Dinge wie die Betriebswirtschaftliche Sichtweise von Benutzer Geologe gar nicht erst eingeflossen, ebenso wie einige andere Punkte. Ob du es zugibst oder nicht auch einige Sachen die die Trolle weiter oben polemisiert haben, haben dich und den Artikel auch schon, wenn auch unbewusst, ein wenig beeinflusst :-) (Anmerkung an die sich hier angesprochen gefühlten Trolle: Mit Troll meine ich lediglich eure in dieser Diskussion eingenommene Rolle, ihr schmeißt sonst wahrscheinlich nur so mit konstruktiver Kritik umher, leider habt ihr in diesem Fall eine für mich unverständliche Ausnahme gemacht). --Haeber 01:00, 19. Jun 2006 (CEST)

Du hast vollkommen recht. Ich habe den Artikel in die Kandidatur gestellt um Feedback zu bekommen und den Artikel weiter verbessern zu können. Das ist ja die Intention dabei. Super soweit. Es kamen ja auch ein paar Sachen dabei rum, siehe meinen Zwischenfazit oben, allerdings ist es umständlich den ganzen Spam darauf hin zu filtern. Wenn ich mir die anderen Kandidaturen hier anschaue, das läuft extrem gesitteter, konstruktiver und sachlicher ab. Naja, kann ja noch kommen.:-)--Michael Hüttermann 01:52, 19. Jun 2006 (CEST)

Jop dieser XP-Artikel könnte auch zu einem Wikibook weiterentwickelt werden, müsste hier dann etwas abgespeckt werden, natürlich immer mit Verweis auf das Buch. Schließlich gibt es auch ’ne Menge Bücher über Softwareentwicklung/-technik die teils mehr als Tausend Seiten haben, die kann man schließlich auch nur in gekürzter Form in einen Artikel wie Softwaretechnik einbringen, dabei gehen natürlich auch die hier oft angeprangerten Buzzwords im Artikel verloren, die jedoch ins zu erstellende Wikibook gerettet werden können. --Haeber 21:41, 18. Jun 2006 (CEST)

Auch über xp gibt es Bücher mit 9292929 Seiten. Hätte ich ein Wikibook schreiben wollen hätte ich es getan. Was ist konstruktiv am Artikel zu tun? Schlagwörter raus? Hmm sieht komisch aus ein Artikel zu XP ohne Werte, Prinzipien und Praktiken...  :-) --Michael Hüttermann 22:07, 18. Jun 2006 (CEST)

Ich meine eher alles zu kürzen, Zusammenzufassen. Im Übrigen die Kursivität bzw. die Fetten Wörter aus dem Artikel zu entfernen hat ihn eher verschlimmbessert, da wäre eine Wiederherstellung angebracht. Die Kritik daran hatte eine andere Zielrichtung. --Haeber 22:19, 18. Jun 2006 (CEST)

Was willst Du denn bitte genau kürzen? Was willst Du zusammen fassen? Die Kritik an der kursiven Darstellung hatte denn genau was für eine Intention? Wenn das mal jemand konkret sagen könnte wäre ich ihm sehr dankbar. :-) Ich möchte auf Belsazar verweisen, wie man sachlich und konkret Kritik übt. :-)--Michael Hüttermann 22:40, 18. Jun 2006 (CEST)

 Kontra Sprachlich finde ich den Artikel nicht lesenswert; man sollte auch einen Blick auf die Interpunktion werfen. -WortUmBruch 08:29, 19. Jun 2006 (CEST)

Ich kann mich nicht um alles kümmern. Jeder ist angehalten mitzumachen. Du bist ja selbst mit gutem Beispiel vorangegangen.:-) --Michael Hüttermann 12:41, 19. Jun 2006 (CEST)

So ich habe nochmal drüber gelesen und ein paar Punkte verbessert. Was denkst Du jetzt?:-)--Michael Hüttermann 13:48, 19. Jun 2006 (CEST)

 Kontra Gleich am Anfang: „sich in der Praxis als nutzbar erwiesene Standards“ - was für ein Stil! --Hermann Thomas 10:21, 19. Jun 2006 (CEST)

Was ist mit diesem Satz nicht in Ordnung? Wow, ein Satz zu Beginn gelesen, zack Contra raus.:-)Wie würdest Du diesen Satz formulieren?--Michael Hüttermann 12:41, 19. Jun 2006 (CEST)

Ich habe den Satz umformuliert. Ist es so OK für Dich? Danke.:-)--Michael Hüttermann 13:48, 19. Jun 2006 (CEST)

 Kontra Geändert in  Neutral - das scheinen mir des Kaisers neue Kleider zu sein. Viel Gerede um Banailtäten. Man setzt bewährte Methoden ein, und nennt die Best practices. Schon der Einleitungssatz -> Extreme Programming (XP) ist ein agiles Vorgehensmodell in der Softwaretechnik, welches sich durch eine iterative, inkrementelle und kommunikationsintensive Herangehensweise auszeichnet. ist geeignet jeden Leser gleich zu verjagen. Niedriges Risiko - Hoher Value. -> Das ist Sprachvergewaltigung. Falls das die Erfinder von dem extreme programming so formuliert haben, kann der Autor nichts dafür. Dann müsste man aber wenigstens in den Artikel setzen, dass die spinnen. Gruß Boris Fernbacher 13:58, 19. Jun 2006 (CEST)

Hallo Boris. Es wäre schön würdest Du den Artikel bewerten und nicht Extreme Programming. Ich habe die eine von Dir angesprochene Sache angepasst (Risiko-Wert). Ist es OK so? Bitte überdenke nochmal Deine Wertung. Danke.:-)--Michael Hüttermann 14:15, 19. Jun 2006 (CEST)

Habe mein Contra in Neutral geändert. Ich kann nicht beurteilen, ob dieses Blah-Blah original von Kent Beck, Ward Cunningham und Ron Jeffries, oder von den Wikipedia-Autoren ist. Falls ersteres der Fall ist, können die Autoren ja nichts dafür. Sie können ja nur Sachen in möglichst verständlicher Form wiedergeben. Frage an Michael Hüttermann: Ist diese unsinnige und überflüssige Durchsetzung mit englischen Worten von den drei Erfindern dieser Sache ? Gruß Boris Fernbacher 14:28, 19. Jun 2006 (CEST)

Danke für die schnelle Antwort. Ja, das Blah-Blah ist von den drei "Erfindern" XPs. Die Autoren des Artikels haben den Artikel verständlich formuliert, aber bestimmte feststehende Begriffe beibehalten müssen. Davon unabhängig, warum nicht -pro-?--Michael Hüttermann 14:47, 19. Jun 2006 (CEST)

Mir fehlt da einiges: Es wird das ganze aus Sicht der Erfinder dieser Sache beschrieben. Hat sich das denn in der Praxis bewährt ? Bringt es echt die propagierten Vorteile ? Es gibt ein Kapitel "Kundensicht" -> da steht aber nur, wie es der Kunde theoretisch als positiv empfinden sollte. Wie sehen es die Kunden denn wirklich ? Das selbe gilt für die Programmierersicht. Wo stammen eigentlich die Grafiken "Kostenkurve" und "Kundenzufriedenheit" her (aus welchen statistischen Quellen) ? Es müsste auch eine kritische Würdigung rein, was an dem ganzen nun wirklich neuartig ist, und was nur "alter Wein in neuen Schläuchen" ist. Ich glaube auch, dass man manches doch auch auf deutsch sagen kann. Nur ein Beispiel: Warum müssen es denn Tasks, Feature Buffers, usw. sein ? Kann man das nicht deutsch ausdrücken, und den englischen Begriff dahinter in Klammern setzen ? So kapiert das die Hälfte der Leute nicht, und selbst denen, die die Worte kennen, vergeht die Lust am Lesen. Bei Artikeln zu anderen Themen fordert man auch, das Fachchinesisch auf das unumgängliche Mindesmaß zu begrenzen. Deshalb nur Neutral. Gruß Boris Fernbacher 15:18, 19. Jun 2006 (CEST)

Ich denke nicht, dass aus der Sicht der Erfinder beschrieben wird, es wird XP beschrieben und das aus unterschiedlichen Perspektiven. Was meinst Du mit "Wie sehen es die Kunden denn wirklich?", meinst Du, ich soll mal ein Zitat von einem Kunden einbringen? Diagramm Kundenzufriedenheit basiert auf dem Kano-Modell, siehe Text. Kostenkurve ist eine logische Ableitung des Vorgehens. Eine kritische Würdigung ist doch drin. Der Artikel ist sehr kritisch. Die Begriffe wie Tasks etc. sind aus dem Original übernommen. Ich verstehe Deine Kritik. Ich werde sie in der Tat mal eindeutschen und das Original in Klammern anfügen. Die Originalbegriffe sollten aber auf keinen Fall verloren gehen. Der Artikel soll aber nicht den Pulitzer Preis gewinnen: berücksichtigt man Komplexität der Thematik und Umfang des Artikels so sollte man in meinen Augen die Kritik für eine Lesenswertkanditatur doch beschränken. Beispiel: "Was sagen die Kunden denn wirklich?" Ich kenne eine Unzahl von Artikeln welche bei weitem nicht die Komplexität dieses Themas haben und auch nicht so umfangreich sind. Diesen Artikel hier kritisieren, dass die von Dir angesprochenen Dinge fehlen, macht vielleicht für eine Exzellenzkandidatur Sinn, ist aber für eine Lesenswertkandidatur zu viel. Da fehlt die Relation. Die englische Begriffe ersetzte ich, danke für den Tipp! --Michael Hüttermann 15:57, 19. Jun 2006 (CEST)

Ich habe die Buffers und den Task eingedeutscht und weiter erläutert. Die Begriffe waren auch vorher schon erklärt oder kursiv als Fremdwörter/Fachbegriffe gekennzeichnet. Beim Task gab es auch eine Wiki-interne Referenz zur Erläuterung. Das ist aber jetzt noch deutlicher, danke für den Tipp. Was denkst Du nun? Danke.--Michael Hüttermann 16:08, 19. Jun 2006 (CEST)

 Kontra - denn ich halte den Artikel nicht für lesenswert. Auch wenn oberflächlich betrachtet "neutralisierende" Satzbauteile eingefügt worden sind, bleibt es ein sehr begeisterter Text - und dazu noch über einen Entwicklungsprozess, der sich in den renomierten Software-Häusern nicht durchsetzen konnte.Wie wäre es mit Neutralität?:-)--Michael Hüttermann 20:57, 19. Jun 2006 (CEST) Dass XP helfen soll, qualitativ hochwertige Software zu entwickeln, wurde meiner Meinung nach in den wenigen Jahren seiner Existenz deutlich genug bewiesen. Die grossen Firmen - vor allem diejenigen, die kritische Software entwickeln - halten sich an RUP, benutzen UML etc. Wie wäre es mit Neutralität?:-)--Michael Hüttermann 20:57, 19. Jun 2006 (CEST)Liest man aber diesen Artikel, könnte man meinen, XP sei zukunftsweisend und das einzig richtige. Kritikabschnitt?--Michael Hüttermann 20:57, 19. Jun 2006 (CEST)Negativpunkte der traditionellen Methode wie Angst vor versäumten Terminen und Missverständnissen mit Kunden. find ich völlig fehlplatziert. Ja warum denn?--Michael Hüttermann 20:57, 19. Jun 2006 (CEST)Fazit: es klingt wie der Text von einem Fan. --Trugbild 16:14, 19. Jun 2006 (CEST)

contra - das erste Drittel des Artikels ist grässlichaua.--Michael Hüttermann 20:57, 19. Jun 2006 (CEST), die Kernaussagen sind nicht so formuliert, dass sie in eine Enzyklopädie passen. Die Haltung des Autors ist durch die Innensicht geprägt, anstatt von außen auf XP zu schauen. Außerdem versucht er durchgängig, XP zu "verkaufen", anstatt es einfach darzustellen. wo versucht der Autor denn was zu verkaufen konkret?--Michael Hüttermann 20:57, 19. Jun 2006 (CEST)Dazwischen sind gute, einfache Sätze, aber leider machen die nicht den Kern des Artikels aus. Nehmen wir als Beispiel den ersten Satz des zweiten Absatzes (in der Fassung von 16:53, 19. Jun 2006 (CEST)): XP identifiziert zahlreiche Kerndisziplinen der Softwareentwicklung, und basiert auf in der Praxis als nützlich erkannte Vorgehen und Standards (Best Practices), in einer extremen Art und Weise. Was soll das bitte schön heißen, dass XP Kerndisziplinen "identifiziert"? Diese Verwendung des Wortes "identifizieren" ist mir völlig unbekannt und ich habe wirklich keine Ahnung, was sie bedeuten soll. wirklich? dann müsste man das umschreiben.--Michael Hüttermann 20:57, 19. Jun 2006 (CEST)Auch die Bezeichnung "in einer extremen Art und Weise" ist MarketinggeschwätzWie wäre es mit Neutralität? Warum eine so emotionale, unsachliche Kritik? Was meinst Du wofür könnte das extreme in Extreme Programming wohl stehen.--Michael Hüttermann 20:57, 19. Jun 2006 (CEST). In einer Enzyklopädie hat das nichts verloren. Darf nicht beschrieben was XP ausmacht?--Michael Hüttermann 20:57, 19. Jun 2006 (CEST)Ich bitte den Hauptautor, sich ersteinmal klar zu werden, was er eigentlich beschreiben will und für wen. XP?--Michael Hüttermann 20:57, 19. Jun 2006 (CEST)Dann soll er den Artikel so schreiben, wie der Brockhaus ihn aufnehmen würde, also in zwei, maximal drei Sätzen, die den Kern des Konzeptes beschreiben. 3 Sätze? Wenn das so einfach wäre. Dafür ist das Thema viel zu komplex.--Michael Hüttermann 20:57, 19. Jun 2006 (CEST)Und zwar ohne jeden Marketingbegriff, auch kein "agil". Wie wäre es mit Neutralität? Ich verstehe diese Abwertung zu einem Marketingbegriff nicht. agil ist hier von fundamentaler Bedeutung. Wenn Du die Rolle von agile nicht verstehst, dafür gibt es ein inter-wiki Link--Michael Hüttermann 20:57, 19. Jun 2006 (CEST)Ich erkenne an, dass es enorm schwer ist, über ein derart marketingverseuchtes Konzept IIiiiiiii. Wie wäre es mit Neutralität?--Michael Hüttermann 20:57, 19. Jun 2006 (CEST)in deutscher Sprache zu schreiben. Aber nur so kann der Artikel lesenswert werden. Momentan braucht er jede Menge an Bannern und Warnungen, von {{unverständlich}} bis {{Neutralitätswarnung}}. Lieber Autor, du brauchst dringend einen Koautor, der gut schreiben kann, aber möglichst keine Ahnung von Softwareentwicklung hatHast Du nicht Lust?--Michael Hüttermann 20:57, 19. Jun 2006 (CEST). Schau mal ob du unter WP:AA/R jemanden findest, der sich dafür Zeit nimmt. Und Zeit werdet ihr brauchen. Wenn man die Kritik versachlichen und kategorisieren könnte wäre das tatsächlich ein möglicher nächster Schritt.--Michael Hüttermann 20:57, 19. Jun 2006 (CEST) --h-stt !? 16:53, 19. Jun 2006 (CEST)

Zurückgezogen.

Die meisten hier vorgebrachten Kritikpunkte waren leider unsachlich und eindimensional. Die konstruktiven Kritikpunkte widersprachen sich teilweise, man kann es nicht jedem Recht machen. Andere Punkte waren Unterstellungen und Polemik. Andere bewerten Extreme Programming selbst und nicht den Artikel.

Ich hoffe, ich habe zumindest den einen oder anderen auf den Artikel aufmerksam machen können. Darum ging es mir eigentlich, da der Artikel lange im Review stand, und ich mit wenigen anderen nicht wirklich weiter kamen. Da sich aber die Diskussion im Kreis dreht, und offenbar neue Bewerter sich von den ersten motivieren lassen, ist es der richtige Moment das Ding hier rauszunehmen, und sich wieder der WM zu widmen. :-)

Mein Pensum der letzten Wochen kann ich zeitlich auf keinen Fall weiter aufrechterhalten. Also, wer helfen will, kann sich dem Artikel ja mal annehmen....ich bin gespannt, ob jemand seinen großen Worten auch Taten folgen lässt. :-)

Die komplette Diskussion habe ich von hier in die Artikeldiskussion geschoben.

Vielen Dank an die Leute, die konstruktive Kritik vorgebracht haben. --Michael Hüttermann 17:24, 19. Jun 2006 (CEST)

Wollte der "lesenswert"-Diskussion eigentlich, bevor der Antrag zurückgezogen wurde, noch folgendes Anhängen:

•  Kontra, denn ein lesenswerter Artikel sollte einem breiten, auch fachfremden Publikum verständlich und vor allem flüssig lesbar sein. Eine gute Lesbarkeit sehe ich nicht gegeben, da zum einen fachspezifische Begriffe ohne nähere Erläuterung im Text verwendet werden (beispielsweise "Stakeholder"; soll ja Menschen geben, die kein Informatik studieren oder beim Wirtschaftsenglischkurs gepennt haben) (a), zum anderen leere Wikilinks (exemplarisch "User Stories") oder auch völlig deplazierte Links (wie z.B. grobkörnig (b), wo man zur Begriffserklärung "Körnung" witergeleitet wird, aber keine relevanz zu User Stories in der Release-Planungs-Phase erkennbar ist). Zudem kommt in dem Artikel der Praxisbezug zu kurz: Bei welcher Art von Projekten wird XP benutzt (Beispiele), bei welchen nicht und nach welchen Kriterien wird die Auswahl entschieden? Ist XP für jedes Projekt und Unternehmen sinnvoll? Warum hat sich XP (noch) nicht durchgesetzt (anscheinend liegt bei 86% aller Programmierprojekten immer noch eine traditionelle Methodik zugrunde)? (c) Auch stilistisch, da schließe ich mich den meisten meiner Vorredner an, liegt immer noch einiges im Argen. (d) Besonders erheitert hat mich der letzte Satz (den Kalauer kann ich mir nicht verkneifen) dieses Abschnitts: Gerade aufgrund der wachsenden Nutzung wird XP immer weiter optimiert und in der Praxis für die Praxis angepasst. (e) Das klingt für mich wirklich nach XP™...--Schimon 18:17, 19. Jun 2006 (CEST)

(a) Es gibt ein Inter-wiki Link. Gegenbeispiel: ich habe zunächst kurz Best-Practices erklärt, das war auch nicht erwünscht, also was nu? · (b) leere Links? naja, ein paar vielleicht. deplaziert? naja, das ist subjektiv. · (c) Was denn noch alles? Der Artikel ist bereits so sehr, sehr umfangreich. Wenn Du den Kritk-Bereich im Artikel siehst kannst Du Dir vorstellen, was den einen oder anderen Projektleiter vor der Nutzung XPs zurückschrecken lässt. · (d) Wo genau? · (e) Neutralität? --Michael Hüttermann 21:01, 19. Jun 2006 (CEST)

zu (a): Man hätte Stakeholder einführen und zumindest in einem Nebensatz erklären können, da nicht jeder (incl. me) auf Anhieb etwas damit anfangen kann. Ein InterWikiLink ist da ja goldrichtig, aber mit hin- und back-Geklicke kann ich beim lesen gleich wieder 2-3 Sätze höher neustarten. Dass Best Practices knapp erklärt wurde, halte ich auch für sinnvoll. · zu (b): Will sagen, das Links, die keine hilfreiche Erklärung liefern, auch weggelassen werden können, und zwar sehr objektiv. · zu (c): Ich hoffe doch, dass Projektleiter in der Programmierung ihr Wissen nicht aus der Wikipedia beziehen. Ich will sagen, dass der Artikel sehr theorielastig ist und zwar die Methodik und Vorgehensweise lang und breit darlegt, aber Beispiele in der Anwendung (bis auf das C3) und Erfolge, die auf XP zurückgehen, keinen Eingang in den Artikel finden. · zu (d): Der o. g. Satz zum Beispiel (2 x Praxis klingt nicht schick, besser wäre evtl. so etwas wie "praxisorientierte Optimierung" oder so). Der Artikel enthält noch weitere Stolperfallen. · zu (e): Nix Neutralität, aufgrund der (selbst für einen IT-Laien wie meinemeinen) sich aufdrängenden Analogie zu Win XP verdient der Satz einen Preis für "enzyklopädisches Kabarett".

Eben. Dem einen ist Stakeholder und Best Practice zu viel erklärt dem anderen zu wenig. Sehr subjektiv wo ein interwiki link platziert wird und wo nicht. Artikel jetzt schon sehr komplex: es wird auch das Vorgehen neutral erläutert. Es geht hier nicht um meine persönliche Erfahrung als Projektleiter, es geht um objektive Fakten bzgl. XP. Parallele zu Win XP als Kabarett zu empfinden zeugt nur von Unkenntnis. Dafür gibt es doch den Artikel. Was hat das mit fehlender Neutralität zu tun? Eben, nichts.--Michael Hüttermann 13:52, 20. Jun 2006 (CEST)

Eine abschließende Bemerkung: Ich habe in keiner Silbe die Neutralität bemängelt, lediglich den Stil, exemplarisch an dem genannten Satz (incl. Vorschlag zur Formulierung in Re:Re:). Da der Begriff Stakeholder nur einmal im Artikel erwähnt wird (ich habs mehrfach gezählt), aber mit nichten erklärt (die Schnittmenge zwischen "Vertreter des Managements" und "Kunde" halte ich für sehr begrenzt; ich weiss, ich stelle weiterhin meine Unkenntnis unter Beweis), halte ich hier einen WikiLink für erforderlich (das meinte ich ja auch nicht), eine kurze Erläuterung (wie gesagt, ein Nebensätzchen reicht schon aus) des Begriffs für objektiv notwendig. Ich nehme ja nicht an, dass der Artikel sich nur an ein Fachpublikum wenden will, sondern auch von einem Laien gelesen werden kann.--Schimon 15:11, 20. Jun 2006 (CEST)

Nun, für Stakeholder gibt es ein WikiLink. Hier ist die Frage wie weit jeder Begriff dann zusätzlich auch noch erklärt werden muss. Es gab im Artikel Gegenbeispiele, wo ich genau das gemacht habe, was auch nicht auf Gegenliebe traf.--Michael Hüttermann 15:14, 21. Jun 2006 (CEST)

Lieber Herr Hüttermann, ich würde sie abschließend noch bitten, Kommentare nicht in den fließenden Text zu editieren, vor allem nicht mitten in einen Satz, damit die Diskussion lesbar bleibt. Mit freundlichem Gruß --Schimon 23:45, 19. Jun 2006 (CEST)

Hallo Schimon, ja stimmt. Ich habe die Intention dahinter auf meiner persönlichen Diskussionseite erläutert.--Michael Hüttermann 13:52, 20. Jun 2006 (CEST)

Oh mein Gott

Ich glaubs ja wohl nicht, mit welchem Recht werden hier Diskussionsbeiträge gelöscht?! Zur Erklärung für alle die es nicht mitbekommen haben: In diesem Abschnitt haben 2 Benutzer ihre Meinung zu dem Thema selbst kundgetan. Mit dem Artikel an sich hatte dies Überhaupt nichts zu tun. Dass man auf einer Diskussionsseite nur über den Artikel, nicht aber über das Thema an sich diskutieren darf, wäre mir neu. Also lasst uns hier diskutieren und macht ihr bitte eure Lesenswert-Kandidatur, auf welche wir im Übrigen garantiert keinen Einfluss nehmen werden. ×ASM× 17:57, 19. Jun 2006 (CEST)

Ruhig Blut, bitte. Ich denke Du meinst das hier. Keiner löscht hier irgendetwas, ganz im Gegenteil. Es kann gerne diskutiert werden, aber bitte sachlich. Bitte verzeihe mir, dass ich die Überschrift Oh mein Gott modifiziert habe. Ich wollte die alte erhalten und durchstreichen, habe ich in der Hektik wohl vermasselt. Verzeihung, dass die Information aus dem Ursprungstitel temporär verlorengegangen ist. Die wertvollen, sachlichen Beiträge waren aber natürlich noch da. Aber eigentlich hast Du Recht: die ursprüngliche Kapitelüberschrift passt noch besser zu den zwei Ursprungsposts, auf die Du Dich beziehst. --Michael Hüttermann 20:27, 19. Jun 2006 (CEST)

---

Was für ein Geschwafel, eine Ansammlung von Banalitäten und Trivialitäten! Natürlich muss man einen Arbeitsplan aufstellen, schneller arbeiten und Arbeiten auslagern, wenn die Zeit knapp wird oder der Kunde Änderungs- und Ergänzungswünsche vorlegt. Was ist daran so außergewöhnlich und "extreme"? Typischer Informatikerkauderwelsch und Wichtigtuerei. Einfach wieder mal eine Mücke zum Elefanten gemacht.

"Oh mein Gott" war genau mein Gedanke zu diesem Thema! 100%-ige Übereinstimmung. Das ist echt nicht mehr normal. "Informatikerkauderwelsch" triffts genau, wenn ich von Ärzten, Story Points und Evolution lesen muss, dann frag ich mich echt wo bei den Leuten der Verstand geblieben ist. ×ASM× 10:46, 18. Jun 2006 (CEST)

Geht es vielleicht noch unfachlicher? Ist nicht fast alles eine Ansammlung ein komplexes System aus Banalitäten und Trivialitäten? Und warum führen wir die Diskussion eigentlich an zwei Orten? Geo-Loge 13:03, 18. Jun 2006 (CEST)

Ja, danke Geo-Loge. Man sollte die Diskussion doch an einer Stelle führen. Ich hoffe, es wird auch noch eine Diskussion. Geschwafel ist für mich ein Artikel oder ein Diskussionsbeitrag, der unsachlich ist, plakativ, emotional, nicht auf Fakten beruhend. Wenn es für den einen oder anderen Informatikerkauderwelsch ist dann möge er sich diesen Artikel erst garnicht anschauen. Ich lese auch keinen Artikel über eine Disziplin in der ich mich überhaupt nicht auskenne, nur um dort zu sagen, das wäre Geschwafel. Aussagen wie Verstand geblieben ist kommentiere ich nicht. Es gab doch gerade die Wiki Academy. Ich denke, es ist noch viel Grundlagenarbeit zu verrichten, um Leute zu motivieren, hochqualitative Artikel aus Fachbereichen zu schreiben, und vor allem auch die anderen Personen, die sich hier mehr oder weniger aktiv einbringen, darauf vorzubereiten.--Michael Hüttermann 14:12, 18. Jun 2006 (CEST)

Aktivitäten werden an das ganze Team verteilt, zunächst nicht an einzelne Personen. Es existiert das Bewusstsein und die Verpflichtung nur als Team erfolgreich sein zu können. Diese Verpflichtung wird täglich gelebt. - der gesamte Artikel befindet sich auf ähnlich tiefem intellektuellem Niveau, das schon fast an Schwachsinn grenzt. Sorry, nimm es nicht persönlich, aber du solltest deine Zeit sinnvoller investieren. 217.83.113.213 14:31, 18. Jun 2006 (CEST)

Was verstehst Du denn daran nicht? Bitte Dich anmelden sowie sachlich und unemotional diskutieren. Danke.:-)--Michael Hüttermann 14:36, 18. Jun 2006 (CEST)

Informationsmanagement

Zitat: Die dann zum Einsatz kommenden technischen Kommunikationssysteme verursachen vergleichsweise hohe Kosten. Auch die Einbindung des Kunden wird kritisch gegenüber anderen Verfahren betrachtet, da hier in der Regel von sich eine räumliche Trennung vorliegt. Warum verursachen die Kommunikationssysteme vergleichweise hohe Kosten? Und, Frage zur Strukur: Würde es nicht reichen in der Kritik weiter unten das Problem der räumlichen Trennung zum Kunden aufzunehmen? Warum muss das in den XP-Nutzen Bereich? Danke.--Michael Hüttermann 20:10, 19. Jun 2006 (CEST)

Bei räumlicher Trennung müssen teure Kommunikationssysteme eingesetzt werden so zum Beispiel Bildtelefonie bzw. aufwändige Konferenzsysteme. Warum muss das unten betrachtet werden? Nutzen ist doch das, was nach Abzug des Aufwands übrig bleibt. Geo-Loge 16:06, 20. Jun 2006 (CEST)

Bildtelefonie oder Konferenzsysteme gehören heutzutage zum 1x1. Das ist doch nicht teuer?! Hmmmm, Nutzen: Ich hatte ein anderes Vorgehen: oben das Plus unten das Minus. Wenn man Deiner Strategie folgt könnte man ja auch den kompletten unteren Diskussionbereich unten entfernen, oder? Ich finde eine sauber Aufteilung (oben die Pluspunkte, den Nutzen unten die Kritik) strukturierter.--Michael Hüttermann 00:54, 21. Jun 2006 (CEST)

Ehrlicher Umgang mit Kunden + und Eindeutschung

Der Unternehmung bzw. dem Projekt bietet XP die Möglichkeit Risiken zu minimieren. Unter richtiger Anwendung XPs soll der Kunde Software erhalten, dessen Umfang ihn nicht überraschen wird. Das Team soll ferner gegen Krankheit einzelner nicht mehr so anfällig sein. Ein ehrlicher Umgang mit dem Kunden möchte die Glaubwürdigkeit und Zufriedenheit steigern und die Angst minimieren, die gewöhnlich zwischen Kunde („Was werden die wohl liefern?“ „Haben die mich verstanden?“) und Entwicklung („Was will er eigentlich genau?“ „Ob er zufrieden sein wird mit dem was wir liefern?“) vorherrscht. Warum ist das komplett rausgeflogen? Es werden dadurch wichige Infos unterschlagen. Und: muss diese Eindeutschung sein? extreme programming = extreme programmierung? Das geht extrem am Ziel vorbei. --Michael Hüttermann 00:59, 21. Jun 2006 (CEST)

Eindeutschung rausgenommen, fand ich auch blöd, wollte es aber erstmal retten, daher auch die kleine Anpassung. --Haeber 01:26, 21. Jun 2006 (CEST)

Extremprogrammierung ist noch drin. Ich finde diese Eindeutschung zwar etwas unschön, wenn es allerdings zum Verständnis beiträgt....--Michael Hüttermann 15:08, 21. Jun 2006 (CEST)

Fachwörter

Mir ist aufgefallen das einige Fachwörter ohne Erklärung oder Wikiverlinkung im Text auftauchen. Da ich sicherlich nicht alle finden werde oder andere anderes Vorwissen haben schlage ich an dieser Stelle eine kleine Liste mit noch erklärungsbedürftigen oder zu verlinkenden Fachvokabeln vor. --Haeber 22:34, 21. Jun 2006 (CEST)

unabhängig von der Glossar Diskussion weiter unten: die Aufführung dieser Begriffe ohne Erläuterung ist eine gute Idee.--Michael Hüttermann 00:33, 22. Jun 2006 (CEST)

• Deployment kommt derzeit 5 mal ohne Erklärung/Links vor. Ich kenne es aus der Java-Webservices-Entwicklung kann mir aber nur über Umwege erklären wie es im Text gemeint sein kann. --Haeber 22:35, 21. Jun 2006 (CEST)

Ich nehme eine Erklärung auf.--Michael Hüttermann 00:33, 22. Jun 2006 (CEST)

Ist aufgenommen. Bei dieser Diskussion hier frage ich mich allerdings warum es interne WikiLinks gibt? Deployment war bereits referenziert auf die Erklärungsseite. Das kann man dann doch nachschlagen, um Details zu erfahren. Eine kleine Erläuterung im Text kann natürlich auch nicht schaden, wie jetzt hier geschehen. --Michael Hüttermann 00:38, 22. Jun 2006 (CEST)

Hab mir vorhin schon einmal überlegt, dass es ein Kapitel Vokabular geben sollte inklusive Erläuterungen, warum diese Schlagwörter notwendig sind. Geo-Loge 22:37, 21. Jun 2006 (CEST)

Das ist eine gute Idee. Boris Fernbacher 22:41, 21. Jun 2006 (CEST)

Das wäre natürlich eine Möglichkeit. Ich bin allerdings dafür die "Fachbegriffe" direkt vor Ort zu erklären. So geschehen schon mit "Best Practice" oder "Stakeholder" und zahlreichen anderen. Eine Erläuterung, warum diese Schlagwörter genutzt werden müssen finde ich kontraproduktiv. Wenn es im Text jeweils Sinn macht oder wenn es ein notwendiger Begriff ist, dann wird er aufgenommen. Macht er keinen Sinn oder ist nicht signifikant / charakterisierend für XP fliegt er raus. Ich kann mir schwierig ein Glossar vorstellen in dem erklärt wird, was ist "Best Practice" und warum ist das im Text wichtig ("weil XP eine Sammlung von Best Practices ist"?). Ich lass mich allerdings auch gerne vom Gegenteil überzeugen.--Michael Hüttermann 00:30, 22. Jun 2006 (CEST)

Naja: In der Diskussion wurde das Vokabular auch kritisiert. Ich finde, wenn der Artikel neutral sein soll, muss er auch darauf eingehen, warum teilweise seltsame Begriffe aufgesetzt wurden, welche Probleme sich daraus ergeben und welche gelöst werden. Geo-Loge 09:48, 22. Jun 2006 (CEST)

Also ich persönlich hätte da überhaupt nichts gegen. Allerdings finde ich das wäre schon recht außergewöhnlich und bzgl. aller anderer Wikipedia Artikel inkonsistent. Wenn ich mir andere Artikel aus anderen Fachbereichen anschaue, zum Beispiel zu der Musik oder Medizin, da gibt es das auch nicht. Da sind die Artikel auch voll mit "Fachbegriffen", die im Text direkt oder via WikiLinks erklärt werden. Wenn ich dazu einfach mal einen der zahlreichen exzellenten Artikel von Boris betrachte: Motiv (Musik), da verstehe ich auch nur Bahnhof, z.b. der Satz "Seufzermotiv (lateinisch = Suspiratio) für steigende oder fallende, meistens vorhaltsartige Sekundmotive"?? Da gibts auch kein Vokabular. Ich respektiere aber, dass das in dieser Form für einen derartigen Artikel notwendig ist und ich mich, wenn ich das will, einlesen und mich selber schlau machen kann. Ich würde aber niemals auf die Idee kommen diesen Artikel als "Geschwafel" oder sowas zu bezeichnen. Ganz im Gegenteil: ein exzellenter ARtikel mit hohem Niveau!--Michael Hüttermann 13:41, 22. Jun 2006 (CEST)

Noch etwas zur Verlinkung: Häufig wird auf Begriffserklärungen verwiesen, was noch zu ändern ist. Einige Begriffe können auch eingedeutscht werden: So der Anwendungsfall statt dem Use Case. Immer an die berühmt-berüchtigte Oma denken, die den Artikel auch verstehen soll. Anwendungsfall ist auch irgendwie schön genug um das Englische Vorbild zu ersetzen. Geo-Loge 22:06, 22. Jun 2006 (CEST)

wird erledigt, danke.--Michael Hüttermann 22:20, 22. Jun 2006 (CEST)

Sonstige Kleinigkeiten

Die letzten beiden Sätze im Punkt Kritik sind etwas unverständlich, vielleicht liegt das auch am unnötig komplizierten Satzbau.

Immer das einfachste Design, die einfachste Lösung zu realisieren kann kontraproduktiv sein, müssen in späteren Versionen der Software Änderungen oder Erweiterungen gemacht werden, die bereits zu Beginn zu antizipieren wären. So ist eine generische Lösung laut XP nicht anzustreben.--Haeber 01:16, 22. Jun 2006 (CEST)

Ich habe das mal anders geschrieben und umgestellt. Besser so?--Michael Hüttermann 01:31, 22. Jun 2006 (CEST)

Jop, bin zufrieden, danke; gewinnt aber noch keinen Pulitzer. :-) --Haeber 02:22, 22. Jun 2006 (CEST)

-> Auch die Anstrebung immer das einfachste Design ... -> Das Wort Anstrebung finde ich schon extrem seltsam. Habe ich eigentlich sonst noch nie gehört oder gelesen. Finde ich nicht ganz so optimal. Gruß und guten Morgen Boris Fernbacher 08:05, 22. Jun 2006 (CEST)

Guten Morgen. Oh je, Anstrebung, was ist das denn?! Das habe ich auch noch nie gehört. Das hängt wohl mit der Uhrzeit zusammen. Ich hab es geändert, sorry. Jetzt Pulitzer-reif?;-)--Michael Hüttermann 09:45, 22. Jun 2006 (CEST)

Ich habe mal den Plural "Methodiken" in den Singular "Methodik" geändert. Methodik ist in Wikipedia definiert als -> Die Methodik (griechisches Adjektiv μεθοδική... - die methodische...) ist eine Gesamtheit von Methoden, ... . Dann wären Methodiken ja das Plural der Gesamtheit von Methoden. Also mehrere Gesamtheiten. Das ergibt meiner Meinung nach keinen rechten Sinn. Oder wie seht ihr das ? Gruß Boris Fernbacher 11:00, 22. Jun 2006 (CEST)

Neben XP gibt es noch andere Agile Vorgehensmodelle. XP ist eine Methodik, es gibt aber auch andere. Beides ist OK.--Michael Hüttermann 13:32, 22. Jun 2006 (CEST)

So gesehen hast du recht. Da war ich wohl etwas zu spitzfindig. Boris Fernbacher 15:17, 22. Jun 2006 (CEST)

Ich weiß nicht ob die Bezeichnung des Doomsayers als Advocatus diaboli so ganz richtig ist. Im Internet habe ich folgende Definition des Doomsayers auf einer Seite über Extreme Programming gefunden. -> The doomsayer, or naysayer, is anyone on the team who senses a problem and brings it to the attention of the team. Die Definition des Advocatus diaboli ist ja doch etwas anders. Gruß Boris Fernbacher 11:42, 22. Jun 2006 (CEST)

Ja, ist nicht unbedingt gleich. Beides findet aber Anwendung. Ich habe die Formulierung geändert, und hoffe, es ist ok so.--Michael Hüttermann 13:32, 22. Jun 2006 (CEST)

Ist gut verständlich so. Boris Fernbacher 15:17, 22. Jun 2006 (CEST)

ToDo

Es sieht sehr gut aus. Ich bin die Kritik hier auf dieser Seite nochmal einzeln durchgegangen. Die Punkte scheinen alle aufgenommen, soweit ich das sehe. Oder? --Michael Hüttermann 12:14, 23. Jun 2006 (CEST)

Hallo Michael, habe bis Montag leider null Zeit. Schaue es mir Montag und Dienstag noch mal durch. Wollte noch so circa 6-7 Bildschirmseiten durchgehen, die ich bis jetzt noch nicht so intensiv gelesen habe. Gruß Boris Fernbacher 20:58, 23. Jun 2006 (CEST)

Bei mir sieht es ähnlich aus. Ich habe viel beigetragen in Bereichen in denen ich gewöhnlich garnicht arbeit und dies auch nur ungern tue... du hast viel erreicht ;-). Man sollte aber mit viel Zeit mal alle Formulierungen und Passagen durchlesen und auf angemessenen Stil prüfen. Gruß, Geo-Loge 21:07, 23. Jun 2006 (CEST).

Ich danke Euch beiden! Es gab schon sehr viele Verbesserungen. --Michael Hüttermann 02:13, 24. Jun 2006 (CEST)

Hallo Michael und Kollegen,

zwei Fragen bzw. Anregungen:

Diesen Abschnitt -> Die evolutionären Praktiken lassen sich unterteilen in Hauptpraktiken und ergänzende Begleitpraktiken. Generell drücken sie das Gleiche aus wie die traditionellen Praktiken. Teilweise ist der Leitbegriff verständlicher formuliert oder wurde in einzelne Unterpraktiken aufgeteilt. Die Praktik Metapher ist weggefallen, da es für sich genommen zu schwer zu vermitteln war. halte ich für etwas schwer verständlich (kapiere ehrlich gesagt nicht so recht, was damit eigentlich gemeint ist).

Ich habe es umgeschrieben. Ist es besser so?--Michael Hüttermann 20:07, 26. Jun 2006 (CEST)

Ist jetzt verständlicher. Boris Fernbacher 20:49, 26. Jun 2006 (CEST)

Den Ausdruck Sweet Spot sollte man weglassen, und die Tatsache schlicht auf Deutsch beschreiben. Wenn ich das richtig verstanden habe, geht es doch um die einfache Tatsache, dass man bei der Arbeit nur zu gewissen Zeiten und unter gewissen Bedingungen eine aktzeptable Effektivität erreicht, und das ein Arbeiten in Zeiten, die dieses Niveau deutlich unterschreiten (übermüdet, etc.), wenig sinnvoll ist. Außerdem geht der Link nur auf die doch ganz andere Bedeutung des Begriffes im Kontext von Musik, Sport und Physik ein. Eine optimale deutsche Beschreibung fällt mir gerade leider nicht so recht ein. Gruß Boris Fernbacher 15:15, 26. Jun 2006 (CEST)

Ich hab den Ausdruck weggelassen. --Michael Hüttermann 20:07, 26. Jun 2006 (CEST)

Habe mal einen kritischen, relativierenden Satz in die Einleitung eingebaut

-> Der Artikel beschreibt XP und die durch seine Anwendung zu erreichenden (von den "XP-Erfindern" teilweise in "leicht enthusiastischen" Formulierungen und Aussagen dargestellten) Verbesserungen in der Softwareentwicklung sowie die Auswirkungen auf die Qualität des Endproduktes. In wie weit diese Verbesserungen und Resultate in der Praxis tatsächlich zu verwirklichen sind und in bisherigen Projekten umgesetzt wurden, wird speziell im Abschnitt 4.4 Kritik, aber auch im restlichen Text, einer kritischen Würdigung unterzogen..

Was meint ihr dazu ? Boris Fernbacher 17:31, 26. Jun 2006 (CEST)

Ich finde die Einleitung an sich viel zu voll. Man sollte sich in der Einleitung nicht für abweichenden Stil entschuldigen. Leser, die den Regelfallartikel gewohnt sind, erwarten ja auch eine Kritik aus neutraler Sicht als Kerneigenschaft der Wikipedia. Geo-Loge 17:41, 26. Jun 2006 (CEST)

Mein Gedanke dabei war halt, dass dem Leser klar wird, dass die "enthusiastischen Formulierungen" aus XP selber kommen, und nicht auf mangelnder Neutralität oder Begeisterung der Autoren beruht. Diese Ansichten wurden ja in der Lesenswert-Diskussion wiederholt geäußert. Ihr könnt diesen Satz aber auch gerne modifizieren oder ganz rausnehmen. War nur mal so ne Idee. Gruß Boris Fernbacher 17:45, 26. Jun 2006 (CEST)

Es gab bei der Lesenswert Kanditatur die Aussage es würde nicht zu kritisch mit dem Thema umgegangen. Nun gibt es in jedem Bereich des Textes kritische Diskussionen, nicht nur wie vorher im "Diskussion"-Abschnitt. Gerade in der Einleitung sind jetzt auch sehr viele kritische Aussagen drin. Ich bin der Meinung von Geo-Loge: eine kritische Auseinandersetzung sollte man voraussetzen können, und es nicht übertreiben. Man sollte XP jetzt nicht schlechter machen als es ist, und wirklich eine Neutralität bewahren. Welche "enthusiastischen Formulierungen" meinst Du denn z.b.?--Michael Hüttermann 20:07, 26. Jun 2006 (CEST)

Okay, aktzeptiert. 2:1 entscheidet. Boris Fernbacher 20:49, 26. Jun 2006 (CEST)

Ist ja wieder super viel passiert heute. Mal schauen was noch im Review passiert. Danke. --Michael Hüttermann 00:59, 27. Jun 2006 (CEST)

Könnte bei folgendem Satz das "Identifizieren" durch einen klareren Begriff ersetzt werden. So ergibt es kein rechten Sinn (ich bin am rätseln, was genau gemeint ist) -> XP entstand durch die Identifikation zahlreicher Kerndisziplinen in der Softwareentwicklung, ....

Unter Identifizierung steht in Wikipedia folgendes: -> Eine Identifizierung ist der Vorgang, der zum eindeutigen Erkennen einer Person oder eines Objektes dient. Identifizierung ist nicht zu verwechseln mit der Identifikation als Einfühlung in einen anderen Menschen, obwohl beide Bezeichnungen oft synonym verwendet werden. unter Identifikation dieses: -> Die Identifikation (lat. idem : derselbe ; lat. facere : machen ) bezeichnet das Erkennen eines Objektes, Gegenstandes, Dings u. a. als Objekt, Gegenstand, Ding u. a. die (gedankliche) Gleichsetzung mehr oder weniger verschiedener Objekte, Gegenstände, Dinge u. a. Identifikation (v. lat.: idem = derselbe + facere = machen ) heißt eigentlich "gleichsetzen", gemeint ist in der Theaterwissenschaft der Vorgang, sich in einen anderen Menschen einzufühlen.

-> Wenn man diese Erklärungen zugrunde legt, wird nicht so recht klar, wie das im XP-Artikel verstanden werden soll. Er würde dann lauten: -> XP entstand durch das Erkennen zahlreicher Kerndisziplinen in der Softwareentwicklung, ... Das ergibt kein rechten Sinn. Boris Fernbacher 14:07, 27. Jun 2006 (CEST)

Ich werde mich darum kümmern!--Michael Hüttermann 20:54, 28. Jun 2006 (CEST)

So ist es sehr gut. Synthese trifft die Sache auch gut.--Michael Hüttermann 00:37, 29. Jun 2006 (CEST)

Operation "Schlanke Einleitung"

Hallo, mir ist die Einleitung mittlerweile ehrlich gesagt viel zu umfangreich. Für zwei Absätze könnte man zu einem Kapitel "Historie und Motivation" zusammenfassen und so auslagern. Weitere Ideen müssen wir noch finden. Geo-Loge 17:38, 27. Jun 2006 (CEST)

Habe ich mal umgebaut. Nur als erste Idee mal. Hast du eine Idee für das mit der "Identifikation" (siehe oben) ? Gruß Boris Fernbacher 18:29, 27. Jun 2006 (CEST)

Okay. Ging ja schneller als ich dachte. Problem gelöst würde ich sagen. Geo-Loge 20:58, 27. Jun 2006 (CEST)

Untergliederung von dir in 1.1 und 1.2 finde ich gut. Boris Fernbacher 21:30, 27. Jun 2006 (CEST)

Sehr gute Idee! Allerdings haben wir dann zweimal sowas wie "Geschichte".--Michael Hüttermann 20:51, 28. Jun 2006 (CEST)--Michael Hüttermann 00:35, 29. Jun 2006 (CEST)

Allgemeine Einordnung in Bezug zu anderen Techniken

man sollte eventuell noch einen Bezug zu den folgenden Konzepten -> Kaizen, Kontinuierlicher Verbesserungsprozess, Quick Response, Lean Manufacturing und anderen herstellen. Da gibt es anscheinend viele Ähnlichkeiten/Überschneidungen. Boris Fernbacher 20:54, 27. Jun 2006 (CEST)

Eigentlich eine sehr gute Idee. Das wäre aber eine sehr sportliche Aufgabe! Unter "Abgrenzung" kann man sicher das eine oder andere aufnehmen und diskutieren. Aber ein breiter Vergleich wäre in meinen Augen zu viel, siehe dazu auch meinen Kommentar auf meiner persönlichen Diskussionsseite.--Michael Hüttermann 20:53, 28. Jun 2006 (CEST)

Informationsmanagement, de zweite

Im Text steht nun folgende Bemerkung:

„Dabei kann insbesondere die Medienreichhaltigkeitstheorie eingesetzt werden: Obwohl die zu diskutierenden und kommunizierenden Sachverhalte in der Regel komplex sind, werden recht einfache Kommunikationsmedien gewählt.“ Liegt eventuell ein Verständnisproblem vor? Diese Aussage würde zum Beispiel bedeutet, dass Ideen, Vorschläge, Abstimmungen und Abläufe bei der Softwareentwicklung per SMS abgestimmt werden. Persönliche Gespräche sind aus technischer Sicht vielleicht einfache Kommunikationsmedien, aus Sicht der Theorie aber das komplexeste und reichhaltigste Medium (mit den wahrscheinlich höchsten Kosten). Geo-Loge 09:18, 29. Jun 2006 (CEST)

Das glaube ich allerdings auch. Ich habe es umgeschrieben. Bei den Kosten bin ich mir nicht so sicher. XP hat in Projekten bewiesen, dass es zu produktiven, effektiven und effizienten Arbeiten führen kann trotz? oder gerade wegen? der persönlichen Gespräche.--Michael Hüttermann 14:25, 29. Jun 2006 (CEST)

Fakt ist das insbesondere die Gespräche mit dem Kunden die Kosten erhöhen. Man sollte jetzt auch nicht meinen, dass komplexe Kommunikationsmedien gleich teure Kommunikationsmedien sind. Wenn ich eh alle Entwickler in einem Haus, an einem Flur habe, muss ich keine Videokonferenzen machen. Nur der Umgang mit Kunden ist nach der XP-Philosophie kostenverursachend. Geo-Loge 17:36, 29. Jun 2006 (CEST)

Nur der Umgang mit Kunden ist nach der XP-Philosophie kostenverursachend. . Wer sagt das denn?:)--Michael Hüttermann 17:46, 29. Jun 2006 (CEST)

Naja: Entweder teure Bildtelefonie oder Meetings und Konsorten zur Abstimmung zwischen Entwicklern und Kunden. Also für mich klingt das nach wesentlich mehr Aufwand als die wenigen Abstimmungsverfahren bei herkömmlicher Verfahrensweise. Geo-Loge 17:53, 29. Jun 2006 (CEST)

Entwicklungskosten ist der größte Faktor. Wenn Funktionalität falsch oder zuviel realisiert wird, so gehen die Kosten in die Höhe. Oder: wenn übermäßig dokumentiert und spezifiziert wird, so erhöht das die Kosten. Das ganze Produkt wegwerfen zu müssen oder z.b. so ein Chaos wie bei Tollcollet inkl. Image Schaden, das erhöht die Kosten. Kunden zu verlieren ist auch ein teurer Spaß. Also mir fallen spontan einige Gegenargumente ein, warum der Kundenkontakt nicht kostentreibend ist. Davon unabhängig finde ich die Formulierung irreführend: "ist nach XP-Philosophie"--> es ist Deine Analyse und bewertung, in der "XP-Philosophie" steht davon nix drin. Und: "kostenverursachend" ist alles was Kosten verursacht. So gesehen sind alle Schritte bei jedem Vorgehensmodell erstmal kostenverursachend. Die Frage muss dann aber auch erlaubt sein: wie ist der jeweilige Nutzen? Und: Bildtelefonie ist doch nicht teuer.--Michael Hüttermann 00:20, 30. Jun 2006 (CEST)

Ich denke die Möglichkeiten, die Steuerung von Effektivität und Effizienz betreffen, sind im Bereich Risikomanagement ausreichend dargestellt. Die Teilbereiche der Betriebswirtschaft versuchen in ihren Felder Aussagen zur Wirtschaftlichkeit zu treffen. Nenne es "Schatten der Zukunft" oder präskriptiv ungewisse Risiken, die veranlassen, dass Kosten wie Imageschaden bei Misserfolg etc. bei der Entscheidung für oder wider ein bestimmtes Vorgehensmuster auch Ganzheitlich nicht betrachtet werden. Auch ist der Zusammenhang zwischen Vorgehensmodell und Misserfolg wage und nur ein Faktor, der sich in der Regel nicht einmal deskriptiv bestimmen lässt. Ich denke für riskante Softwareprojekte nimmt ein Unternehmen so oder so Rückstellungen für schwebende Geschäfte auf. Geo-Loge 11:11, 1. Jul 2006 (CEST)

Sprachliches

:User Story: Als Arzt kann ich alle Patienten sehen, die ich am Tag habe.

Klingt ein wenig seltsam und trivial. Wo ist die Botschaft/Aussage? -> Soll wohl nur ein fiktives Demonstrationsbeispiel sein. Habe einen einleitenden Satz dazu eingebaut. Boris Fernbacher 15:53, 5. Jul 2006 (CEST)

:Kritisch zu hinterfragen ist hierbei die schwierige räumliche Verteilbarkeit der Entwicklungsprozesse, sowie die Einbindung des Kunden, bei der möglicherweise eine räumliche Trennung vorliegt.

Klingt ein wenig hölzern und unverständlich. -> Umformuliert. Hoffentlich jetzt verständlicher. Boris Fernbacher 15:38, 5. Jul 2006 (CEST)

:Normale Iterationen gehen von 1 Woche bis 4 Wochen.

Die ganzen Zahlen von eins bis zwölf werden in Buchstaben ausgeschrieben. Ab „dreizehn“ wird das Wort zu lang, diese Zahl und alle höheren werden in Ziffern dargestellt. Ausnahmen sind individuell möglich. -> Erledigt. Boris Fernbacher 15:38, 5. Jul 2006 (CEST)

:Das ganze Team ist bei der Erstellung beteiligt. Sie werden auf einzelnen Karten (Story Cards) geschrieben und für alle sichtbar an ein Medium platziert.

Wer? Bezug? -> Erledigt. Boris Fernbacher 14:53, 5. Jul 2006 (CEST)

Das meiste Wissen über die Funktionalität ihre Entwicklung befindet sich in den Köpfen der Beteiligten. User Stories werden gewöhnlich nur relativ geschätzt.

Doppeldeutig! Wertschätzung oder Schätzung?

:Die Kommunikation soll offen und die Entwickler mutig sein.

Grammatik. -> Erledigt. Boris Fernbacher 15:38, 5. Jul 2006 (CEST)

:In jeder Iteration konzentriert sich das komplette Team auf genau die Anforderungen, die jetzt gerade umgesetzt werden sollen. Dabei sollen die Umsetzungen technisch möglichst einfach sein. Sprachlich umgebaut. Boris Fernbacher 15:10, 5. Jul 2006 (CEST)

Durch eine Atmosphäre der Menschlichkeit müssen die Grundbedürfnisse der Entwickler; Sicherheit, Vollendung, Identifikation mit der Gruppe, Perspektive und Verständnis beachtet werden.

Verstehe das „ ; “ nicht? Vielleicht Doppelpunkt?

:Die erstellte Software beziehungsweise eine einzelne Funktionalität muss einerseits wirtschaftlich sein, und dennoch einen echten Wert bringen. Andererseits muss sie einen beidseitigen Vorteil bringen; Erledigt. Boris Fernbacher 14:53, 5. Jul 2006 (CEST)

:Wo allerdings Verbesserungspotential identifiziert wird, wird die Lösung angepasst. Erledigt. Boris Fernbacher 14:53, 5. Jul 2006 (CEST)

Zu einer guten Qualität gehört auch die Vermeidung von Redundanzen; unnötig mehrfach oder wiederholt ausgeführter Schritte oder auch manuell ausgeführter automatisierbarer Schritte.

Satzbau! Klingt ein wenig hölzern.

:Diese Verpflichtung wird täglich gelebt.

Das klingt nach XP-Marketing! Hurra, wir schaffen es! Besser löschen? Gelöscht. Boris Fernbacher 14:53, 5. Jul 2006 (CEST)

:Das Team soll einerseits von seiner Konstanz leben, kann aber auch geschrumpft werden. ::Wirklich? ;-) Umformuliert. Boris Fernbacher 14:53, 5. Jul 2006 (CEST)

:Neben der bekannten und verbreiteten agilen Methode XP hat auch Scrum eine gewisse Bekanntheit erlangt. -> Geändert in Bekanntheitsgrad. Boris Fernbacher 15:44, 5. Jul 2006 (CEST)

Agile Manifest: Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen...

Quellenangabe des Zitats?

:Sie schildern, wie sie XP im Detail eingesetzt haben, was es für Schwierigkeiten dabei auftraten und wie der Erfolg einzuschätzen war.

Grammatik und Satzbau. Erledigt. Boris Fernbacher 14:53, 5. Jul 2006 (CEST)

:oder wird outgesourced

Denglisch! -> Erledigt. Boris Fernbacher 15:57, 5. Jul 2006 (CEST)

2* optimiert

Allgemein: weniger Fremdwörter.

So viele Fremdworte sind es nicht mehr. Speziell hier fällt mir kein passender deutsche Begriff ein. Boris Fernbacher 15:38, 5. Jul 2006 (CEST)

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 durch ständige, aktive Einbeziehung des Kunden in den Entwicklungsprozess vorbeugen.

Habe den Artikel (zu) oft gelesen. Deswegen brauche ich ein wenig Abstand. Vielleicht sollte der Artikel, der immer noch viele Fehler (Interpunktion!) aufweist, noch ein oder zwei Wochen im Review verweilen? Gute Artikel ändern sich nicht, sie reifen! -WortUmBruch 09:43, 3. Jul 2006 (CEST)

Hmm, kann sein. Ich denke, der Artikel braucht einfach jmd wie Dich, WortUmBruch, der da mal aufräumt. Der Artikel stand ja bereits mal eine Woche im Review. Da ist nicht viel bei rumgekommen. Es muss sich nur einer erbarmen die Interpunktionen/Formulierungen zu optimieren. Also ich habe mittlerweile den totalen Tunnelblick. Schade, dass Du nicht die aufgeführten Punkte schon angegangen bist (soweit möglich, z.b. 1->eins). Dann wären es jetzt wieder einige Baustellen weniger.--Michael Hüttermann 21:31, 3. Jul 2006 (CEST)

Lieber ein paar Wochen reifen lassen... und dann die Kandidatur mühelos bewältigen... Oder überhastet (mit vielen Fehlern) die Hürde (wieder) reißen...? -WortUmBruch 17:32, 4. Jul 2006 (CEST)

Sehe ich auch so. Die Sprache war der Hauptkritikpunkt und ließ Fehlinterpretationen des Inhalts zu. Da hilft nur immer wieder durchlesen, Abstand gewinnen und wieder durchlesen; aber wem erzähl ich das eigentlich ;-) Geo-Loge 17:49, 4. Jul 2006 (CEST)

Einheitlichkeit bei der Genitivbildung

Beispiele: Mal heißt es des Projekts, mal des Projektes. Mal heißt es des Produktes, mal des Produkts.

Auffällig ist auch, dass bisweilen die selben Fremdwörter unterschiedlich dekliniert werden. -WortUmBruch 10:22, 3. Jul 2006 (CEST)

Einheitlichkeit: Prozent/%

Prozent vs. %. -> Vereinheitlicht in Prozent. Boris Fernbacher 14:53, 5. Jul 2006 (CEST)

Tabelle/Aufwandsabschätzung

Eine User Story ist erst abgeschlossen, wenn alle seine Tasks abgearbeitet sind und die Tests geschrieben und alle erfolgreich durchlaufen sind. Der Demonstration dieser Vorgehensweise soll eine Tabelle mit Aufwandsabschätzungen in einer fiktiven Arztpraxis dienen.

User Stories mit Aufwandsabschätzung in Story Points

Story No.	Story	Abschätzung (Story Points)
1	Als Arzt kann ich alle Patienten sehen, die ich am Tage habe.	3
2	Als Arzt kann ich über die Gesundheitsgeschichte meiner Patienten Auskunft geben.	5
3	Als Assistentin kann ich einem Patienten einen Termin geben.	3
4	Als Assistentin kann ich einem Patienten eine Verschreibung ausdrucken.	3

---

Boris weist in einem (neuen) Satz auf die Tabelle mit der fiktiven Arztpraxis hin. Dabei ist mir folgendes aufgefallen:

• Warum als Beispiel eine Arztpraxis? Warum nicht ein konkretes und einfaches XP-Projekt?
• Warum haben fast alle Stories – mit einer Ausnahme – die selbe Abschätzung (Story Points), nämlich drei? Dieses Beispiel könnte man spritziger und „markanter“ gestalten.

Gute Idee ! Ein IT-Besipiel wäre passender. Da könnte Michael mal in seine Fachbücher schauen. Da müsste doch ein schönes Beispiel zu finden (oder konstruieren) sein. Boris Fernbacher 11:30, 6. Jul 2006 (CEST)

-WortUmBruch 10:56, 6. Jul 2006 (CEST)

Auch ohne Fachbuch kann ich dazu etwas sagen. Man könnte eine Story mit 1 abschätzen, eine andere noch mit 2. Warum als Beispiel keine Arztpraxis? Das ist ein Beispiel aus einem konkreten und einfachen XP-Projekt. Eine User Story ist die Beschreibung einer Funktionalität eines Software-Programmes. Jeder Arzt hat ein Software Programm, welches die Patienten verwaltet. Eine User Story hat mit einem IT-Beispiel nix zu tun, das ist die Beschreibung der Fachlichkeit. Boris' Erläuterung der Tabelle find ich gut.--Michael Hüttermann 21:44, 6. Jul 2006 (CEST)

Tut mir leid, aber ich kann mit dieser Tabelle einfach nichts anfangen. Eine User Story ist erst abgeschlossen, wenn alle seine Tasks abgearbeitet sind und die Tests geschrieben und alle erfolgreich durchlaufen sind. Der Demonstration dieser Vorgehensweise soll eine Tabelle mit Aufwandsabschätzungen in einer fiktiven Arztpraxis dienen. Diese Tabelle demonstriert – meiner Meinung nach – nicht plausibel und überzeugend diese Vorgehensweise! (Boris' Erläuterung der Tabelle find ich auch gut.) In dieser Form sollte man diese Tabelle vielleicht ganz löschen; besser: ein „spritziges“ Beispiel entwerfen. Gruß -WortUmBruch 11:06, 7. Jul 2006 (CEST)

Ja, klar. Dann ist das Beispiel und die Formulierung nicht verständlich genug. Sorry. Ich werde es überarbeiten.--Michael Hüttermann 23:02, 7. Jul 2006 (CEST)

Das "Rumgeficke" um dies Problem ist mir langsam zu doof ! Sagt es es doch ganz einfach, wenn euch was nicht passt. Ist es zu Populäwissenschaftlich, oder zu "Wissentschaftlich"  ????

Ich finde den Artikel insgesamt gut so. Weder zu Populäwissenschaftlich noch zu Wissentschaftlich. Deshlb mache ich auch nicht mehr groß dran rum. Gruß Boris Fernbacher 17:10, 9. Jul 2006 (CEST)

Ich bin mir sicher der Artikel hat einen Stand erreicht, der mindestens als lesenswert zu bezeichnen ist.--Michael Hüttermann 17:13, 9. Jul 2006 (CEST)

Meine ich auch. Dann stelle ich ihn jetzt mal zur Abstimmung ein. Boris Fernbacher 18:34, 9. Jul 2006 (CEST)

Das "Rumgeficke" um dies Problem ist mir langsam zu doof ! Sagt es es doch ganz einfach, wenn euch was nicht passt. Ist es zu Populäwissenschaftlich, oder zu "Wissentschaftlich"  ???? Bedauerlicherweise ist der Ton der Diskussion inzwischen ein wenig befremdlich. O Freunde, nicht diese Töne! Wollte heute mit der weiteren Korrektur fortfahren, aber der Artikel befindet sind schon in der Kandidatur. Der Review war – meiner Meinung nach – nicht umsonst, leider aber zu kurz; und er hat auch neue Fehler „hervorgebracht“. Ich finde den Artikel immer noch nicht lesenswert, da zu viele Fehler und andere Schwächen, die ich an anderen Stellen bereits erwähnt habe. Nur ein Beispiel: Quellenangabe des folgenden Textes (Agile Manifest)?

Individuen und Interaktionen haben Vorrang vor Prozessen und  Werkzeugen.
Lauffähige Software hat Vorrang vor ausgedehnter Dokumentation.
Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.
Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.

Gruß -WortUmBruch 09:51, 10. Jul 2006 (CEST)

Steht doch da: Agiles Manifest, siehe dazu auch die Referenzen unten. Also Du willst direkt auf exzellente Kandidatur gehen? Schau Dir doch mal vergleichbare Artikel an die offiziell lesenswert sind, da ist der hier am mindestens gleichwertig. Wenn Du meinst das ist nicht der Fall kannst Du ihn aber gerne auch wieder aus der kandidatur rausnehmen. Bzgl. "Rumgeficke" habe ich weiter unten auf Boris' Post was geschrieben, eins tiefer. --Michael Hüttermann 19:36, 10. Jul 2006 (CEST)

Zu: "Bedauerlicherweise ist der Ton der Diskussion inzwischen ein wenig befremdlich. O Freunde, nicht diese Töne!" -> Ich habe hier doch immer einen freundlichen Ton gepflegt, oder nicht ? Ich tippe mal, Michael hat das mit dem "Rumgeficke" nicht so unfreundlich gemeint, wie es wirkt. Gruß Boris Fernbacher 10:04, 10. Jul 2006 (CEST)

Bitte? Du bist mir vielleicht ein Spaßvogel! Wenn Du nudeldicke(?) nachts um 4 Uhr solche Sätze hier reinschreibst dann steh auch dazu und schieb das nicht auf mich. Ich hätte das an Deiner Stelle ja einfach so unkommentiert stehen lassen. Ein einfacher Blick in die History zeigt: http://de.wikipedia.org/w/index.php?title=Diskussion%3AExtreme_Programming&diff=18772998&oldid=18732207 --Michael Hüttermann 19:36, 10. Jul 2006 (CEST)

Aua, das ist von mir. Habe ich ganz vergessen. Tut mir echt leid Michael. Waren wohl ein, zwei Bier zuviel. Da quasselt man halt so vor sich hin. Entschuldigung. Ich dachte echt das ist von dir. Gruß Boris Fernbacher 19:49, 10. Jul 2006 (CEST)

:-))))))))) --Michael Hüttermann 20:11, 10. Jul 2006 (CEST)

Ich weiß zwar nicht, was die vielen Klammern bedeuten sollen. Hatte aber echt vergessen, dass der Mist von mir ist. Boris Fernbacher 20:16, 10. Jul 2006 (CEST)

Ach so. Das ist ein Smiley: :-). Das schreibt man wenn man gerade lacht. Und wenn man richtig dolle herzhaft lachen muss, dann hängt man noch ein paar ")" dran. Je mehr desto mehr lacht man. :-) --Michael Hüttermann 20:25, 10. Jul 2006 (CEST)

Alles klar. Hoffe es war kein Fehler den Artikel mal in die Abstimmung zu stellen. Meiner Meinung nach ist der nämlich schon ganz gut. Gute Nacht Boris Fernbacher 20:30, 10. Jul 2006 (CEST)

Aus dem Review

Der Artikel wurde nach seinem Scheitern in der Lesenswert-Abstimmung beträchtlich verändert. Unnötige Anglizismen wurden entfernt bzw. auf deutsch mit dem englischen Fachbegriff in Klammern definiert. Die kritische Betrachtung des XP-Konzeptes wurde ausgebaut. Am Satzbau und der Stilistik wurde viel geändert. Mancher Gedanke wurde einfacherer formuliert. Habt ihr noch Verbesserungsvorschläge oder Kritik ? Gut wäre es auch, wenn sich ein Kenner in Rechtschreibung und Zeichensetzung das ganze nochmal anschauen würde. Gruß Boris Fernbacher 22:18, 26. Jun 2006 (CEST)

Die erste Rutsche total offensichtlicher Typos ist schon mal raus. Danke an Benutzer:WortUmBruch. Wenn man den ganzen Tag vor dem Artikel sitzt, sieht man den Wald vor lauter Bäumen nicht mehr.:-| --Michael Hüttermann 11:58, 27. Jun 2006 (CEST)

Folgende Aufzählung verstehe ich nicht! Grammatik!

umgeschrieben.--Michael Hüttermann 10:28, 29. Jun 2006 (CEST)

---

Risikoverminderung soll über Extreme Programming durch deren Eigenschaften im Umgang mit Fehlern, Mitarbeitern und Kunden möglich sein:

• Der geringen Fehlerlastigkeit des Ergebnisses (Sicherstellung der Effizienz durch geringe Nacharbeit)
• Der Kompensation von Krankheitsausfall (Sicherstellung der Effektivität und Effizienz)
• Einer Kundennahe Entwicklung (Sicherstellung der Effektivität durch Vermeidung von Fehlentwicklung)

---

Auch unverständlich, v. a. das nach dem Komma:

---

Er entscheidet wie genau vorgegangen werden soll, und ist beispielsweise das Produktmanagement, ein Kunde oder ein Nutzer.

umgeschrieben--Michael Hüttermann 10:28, 29. Jun 2006 (CEST)

---

Einige Knaller:

insbesonders
Softwareerstellenden Unternehmen 
Risikoakzeptierung
Mitarbeitzufriedenheit
Anforderungstellung
beauskunften
Umpriorisierung
automatisiertbarer
frühzeit
langläufige
Restaufwände

-WortUmBruch 12:22, 27. Jun 2006 (CEST)

Ein paar dieser wirklich seltsamen und unüblichen Begriffe habe ich ersetzt bzw. umformuliert. Boris Fernbacher 16:49, 28. Jun 2006 (CEST)

Ein paar dieser "Knaller" sind Typos, andere sind "IT-Fachbegriffe", welche man sicherlich durch verständlichere Alternativen ersetzen kann. --Michael Hüttermann 10:20, 29. Jun 2006 (CEST)

---

Ausdruck und Stil

• Die auf dem Team lastende Arbeitsbelastung soll gleichmäßig verteilt werden.

• Laut der Vertreter dieses Vorgehensmodells ist XP „gelebtes Risikomanagement“: wo in anderen Vorgehensmodellen das mit der Softwareerstellung verbundene Risiko und geeignete Gegenmaßnahmen nicht selten wenig oder explizite Berücksichtigung finden, geht XP einen anderen Weg.
  • Klingt hölzern und unverständlich - wie der ganze Satz!

habe mich der Punkte angenommen. Besser?--Michael Hüttermann 12:18, 29. Jun 2006 (CEST)

Wenn der Bearbeitungsprozess einige Tage ruht, werde ich mich um den Feinschliff kümmern, v. a. um die Zeichensetzung. Gruß -WortUmBruch 11:40, 29. Jun 2006 (CEST)

---

Wird und werden

Was mir sprachlich an diesem Artikel nicht gefällt, ist der bescheidene und monotone Stil mit wird und werden. Einige Absätze mögen das verdeutlichen:

Die zu entwickelnde Funktionalität wird in Form von Stories beschrieben, beispielsweise User Stories. In einem wöchentlichen Zyklus wird entschieden, welche Kundenwünsche als nächstes realisiert werden. Das Projekt selbst wird in einem quartalsweisen Zyklus geplant.

Aufwandsabschätzungen werden verlässlicher, da sie im Team getroffen und ständig einer kritischen Überprüfung (Review) unterzogen werden. Teamgeist wird laut XP gefördert. Jedem sollte klar sein, dass nur als Einheit das Ziel erreicht werden kann. Sollte ein Projekt, z. B. aus Kostengründen, vorzeitig eingestellt werden, besteht durch die regelmäßigen Iterationen dennoch ein zumeist einsatzfähiges Produkt.

Das sind – wie gesagt – nur einige Beispiele. Wird und werden sind gewissermaßen der basso continuo in diesem Artikel. Erstelle gerade eine neue (lange) Liste mit weiteren sprachlichen Knallern. -WortUmBruch 16:02, 29. Jun 2006 (CEST)

Da muss ich WortUmBruch zustimmen. Soviel "wird" und "werden" ist zwar nicht direkt verboten, aber stilistisch nicht sehr befriedigend. Habe schon 5 * "wird" und "werden" durch Umformulierung entfernt. Boris Fernbacher 08:18, 30. Jun 2006 (CEST)

---

Ausdruck und Stil

Der Kunde ist optimalerweise jederzeit auf dem selben aktuellen Informationsstand bezüglich Stand und Fortschritt des Projekts wie das Entwickler-Team.

Auch wenn Extreme Programming die Wertschöpfung beschreibt, bietet es über die Eigenschaft der Kundennähe Möglichkeiten zur kundennahen Unternehmung.

etabliert Prioritäten ???

User Story: Als Arzt kann ich alle Patienten sehen, die ich am Tag habe. - ???Was stimmt daran nicht?

Die Wiederverwendung existenter Lösungen

Das Team hält sich bei der Realisierung an Standards, welche erst die gemeinschaftliche Verantwortung des Teams bei der Realisierung ermöglichen. - ???

-WortUmBruch 09:43, 30. Jun 2006 (CEST) abgearbeitete Punkte markiert--Michael Hüttermann 20:54, 1. Jul 2006 (CEST)

Lesenswert-Kandidatur (abgeschlossen am 16.7.06)

Extreme Programming (XP), auch Extremprogrammierung, ist ein flexibles Vorgehensmodell in der Softwaretechnik, das sich den Problemen in wiederholten kleinen Schritten unter Verwendung von Rückkoppelungen sowie einer kommunikationsintensiven Herangehensweise zielgerichtet annähert.

Ein fachlich fundierter Artikel, der vor 4 Wochen schon mal in der Abstimmung war. Die damaligen Kritikpunkte wurden umgesetzt. Englische Begriffe wurden in deutsche umgewandelt, bzw. erklärt. Stilistisch wurde viel geändert. Sachverhalte wurden verständlicher formuliert. Die kritische Sicht auf das Thema wurde ausgebaut. Die vielen Veränderungen rechtfertigen meiner Meinung nach eine erneute Abstimmung. Insgesamt eine schöne Arbeit vom Hauptautor Michael Hüttermann. Gruß Boris Fernbacher 18:44, 9. Jul 2006 (CEST)

• Erstmal eine kurze Anmerkung: Der Artikel ist mit hoher Gründlichkeit geschrieben, trotzdem bitte ich auch hier die Wikipedia-Standards einzuhalten: Weiterführende Informationen sollte entfallen, Siehe auch zu einer H2-Überschrift werden und Weblinks auch nur unter Weblinks aufkreuzen. Auch wenn mir Referenzen sehr gut gefällt, werden hier ebenfalls die Standards nicht eingehalten; dort könnte man aber ein Auge zudrücken. Inhaltliche Kommentare hoffentlich später, wenn mehr Zeit (aber nur als Laie). --chrislb 问题 21:05, 10. Jul 2006 (CEST)

  Wurde erledigt. --Haeber 21:14, 10. Jul 2006 (CEST)

Gratulation an die Autoren, sprachlich hat sich der Artikel wirklich verbessert. Vom Umfang her sehe ich zwar nach wie vor mehr Wikibook als Artikel, durch einen guten Abschnitt "Grundsätzliches" ist aber auch die Übersichtlichkeit gewahrt. Nach kurzem überfliegen und Stichprobenartiger Detailkontrolle (bei den von mir zuerst kritisierten Punkten) ein lesenswerter Artikel --Taxman ^Rating 08:44, 11. Jul 2006 (CEST)

Bzgl. Umfang: das Thema ist sehr komplex und vielschichtig. Köln und Berlin sind wesentlich länger. Dresden ist in der Exzellenz und extrem hyperlang, oder viele andere Beispiele. Der Umfang alleine sollte nicht ausschlaggebend sein. Nein, er kann sogar eine umfangreiche Abhandlung eines komplexen Themas dokumentieren. Viele Grüße--Michael Hüttermann 18:47, 11. Jul 2006 (CEST)

Dresden ist wirklich etwas lang geraten (Liegt aber hauptsächlich an Kultur) ;-) Ich sehe den Artikel zu Extreme Programming auch als lesenswert, enthalte mich aber, da ich inhaltlich etwas beigesteuert habe. Geo-Loge 21:11, 11. Jul 2006 (CEST)

•  Kontra Trotz zahlreicher Verbesserungen und Veränderungen halte ich den „Artikel“ für nicht lesenswert. Warum? Es handelt sich hierbei – meiner Meinung nach – um einen klassischen „Kategorienfehler“. Der „Artikel“ erinnert eher an eine Seminar- oder Diplomarbeit (in Auszügen) über Extreme Programming in Form eines Wikibooks. Falsche Schublade, falsche Baustelle! Sprachlich und inhaltlich halte ich ihn – neben einigen Schwächen im Ausdruck und Stilblüten nebst Fehlern – für äußerst redundant. Einige Beispiele, Tabellen und zahlreiche Grafiken, vor allem die mit dem Stern, sind für ein Lehrbuch/Wikibook bzw. für eine Präsentation äußerst hilfreich, für einen WP-Artikel jedoch entbehrlich. Außerdem habe ich immer noch den Eindruck, dass der Text ein wenig tendenziös ist, also freundlich und für XP werbend wirkt, obwohl kritische Äußerungen und Betrachtungen durchaus vorhanden sind und die XP-Marketingsprache entfernt wurde. Mein Vorschlag: der vorliegende „Artikel“ sollte „entschlackt“ werden: schlanker und straffer, weniger Doppelungen und Wiederholungen; Verzicht auf Ballast. Weg vom Seminarstil und hin zur enzyklopädischen Darstellung! Darüber hinaus könnte man aus dem langen Textkörper mit besseren Beispielen ein durchaus lesenswertes Wikibook basteln. -WortUmBruch 11:06, 13. Jul 2006 (CEST)

Die Kritik von WortUmBruch ist ernstzunehmen. Ich persönlich halte die Grafiken auch für etwas zu sehr im Powerpoint-Stil. Aber das lässt sich ja schnell ändern. Zum Punkt der tendenziösen, freundlichen Darstellung: -> Dieser Enthusiasmus liegt halt zum Teil im XP-Ansatz selber drin. Man kann schwer darüber schreiben, ohne ein bißchen davon mit rüber zu bringen. Es ist aber auch ein Kapitel (1 bis 2-Seiten) Abschnitt "Kritik" eingebaut, der die Begeisterung wieder etwas dämpft. Zur Länge -> Software beeinflusst das Leben des Menschen immer mehr. Also ist meiner Meinung nach auch ein langer Artikel zu Techniken der Softwareerstellung angebracht. Aber das ist Ansichtssache. Gruß Boris Fernbacher 15:35, 13. Jul 2006 (CEST)

Ist mir schleierhaft. Erstmal: warum jetzt? WortUmBruch hat die letzten Wochen fleissig letzten Feinschliff am Artikel durchgeführt, Sätze und Interpunktion optimiert. Und nun plötzlich ist der ganze Artikel fehlplatziert? Das ist inkonsistent. Inhaltlich: warum konkret Diplom-Arbeit? Ich sage ja auch nicht der Artikel zu Köln kommt aus einem Reiseführer. Der Artikel hier ist eine fundierte, vielschichtige Abhandlung zum Thema. Der Artikel ist die letzten Wochen soviel weiter optimiert werden, in meinen Augen gibt es keine groben sprachlichen Mängel oder vergleichbares. Was ist denn jetzt plötzlich mit den Grafiken falsch. Mir scheint es hier wird ständig versucht den Artikel schlecht zu reden. :-) Jetzt wo alles andere durch ist sind die Grafiken dran. Was ist denn bitte schön ein Powerpoint Bild und was nicht? Fehlt der Goldrand? Müssen Blumen rein? Die Grafiken sind sachlich und ergänzen wunderbar den Text. Wenn Ihr meint die "Stern-Bilder" sind keine guten ergänzenden Infos zum Text, dann löscht sie halt - bis der nächste kommt und da Bilder sehen will. Bitte nicht wieder mit der Neutralität anfangen: der Artikel ist mittlerweile so extrem kritisch, dass weitere Relativierungen etc. nun wirklich langsam aber sicher die Neutralität des Artikels in ein Gegen-XP Licht schieben würden. Und bitte, bitte nicht wieder den Artikel selbst mit dem Thema gleichsetzen: der Artikel kann nichts dafür, dass Extreme Programming inhaltlich genau das ausdrückt. Was ist denn bitte bei dieser vielschichtigen Darstellung "Ballast" und warum bitte bitte sind die Beispiele plötzlich nicht mehr gut genug? Der Artikel handelt das Thema nicht nur fundiert/sachlich ab, er bringt einen exzellenten Praxisbezug. Ganz neu ist auch der Bereich "XP in der Praxis". Er wurde auf Wunsch ergänzt. "Straffer" nein nein das Thema ist so komplex warum soll man wichtige Dinge amputieren? Ich gehe ja auch nicht auf den "Dresden" Artikel und lösche die komplette "Geschichte" und "Kunst" Passagen. Ich möchte "Dresden" auch nicht ins Wikibook verschieben. Warum auch? Oder soll jetzt alles ins Wikibook. Viele Anmerkungen aus der ersten Kandidatur gingen dahin, dass mehr Infos in den Artikel sollten zum Thema "XP in der Praxis", mehr Kritik mehr dies mehr das. Und jetzt plötzlich ist der Artikel zu lang und alles muss wieder raus? Hmmm. Und was bitte sind an diesem Artikel "Stilblüten nebst Fehlern"?? Ich bin recht enttäuscht von Deinem Beitrag hier, WortUmBruch, denn so drehen wir uns im Kreis. Es wurden alle! Kritikpunkte und Verbesserungsvorschläge mit größter Sorgfalt aufgenommen. Obwohl ich Hauptautor bin möchte ich mal ein Zeichen setzen: objektive Einschätzung und Einstufung auch zu anderen Artikeln und die sachliche Analyse der aufgenommenen Kritikpunkte sagen mir, dieser Artikel ist lesenswert.--Michael Hüttermann 20:12, 13. Jul 2006 (CEST)

Um Missverständnissen vorzubeugen: Mit -> "Die Kritik von WortUmBruch ist ernstzunehmen." habe ich gemeint, dass man über diese Punkte reden kann. Ich persönlich bin nicht der Ansicht, dass seine Kritikpunkte zutreffen. Sonst hätte ich den Artikel ja kaum hier vorgeschlagen, und mich beim Vorschlag positiv zum Artikel geäußert. Zu meinem kritischen Satz über die Bilder: Das ist Geschmackssache, und meiner Ansicht nach wirklich eine unbedeutende Nebensächlichkeit. Gruß Boris Fernbacher 08:46, 14. Jul 2006 (CEST)

*huestel* Sehe ich das grade richtig, dass der Hauptautor da grade mit abgestimmt hat? Es ist zwar nicht "verboten", aber zum guten Ton gehørt es jedenfalls auch nicht.

*huestel" Ja du siehst das richtig, wenn wir noch kleinlicher werden können wir auch anmerken das Benutzer:WortUmBruch auch die letzten Wochen am Artikel mitgearbeitet hat und dessen contra wohl auch fragwürdig wäre. Natürlich sind wir nicht so kleinkariert und lassen daher diese Stimmen gelten. --Haeber 21:15, 13. Jul 2006 (CEST)

*huestel* Das "Contra" eines (Mit-)Autors ist vielleicht doch noch mal _ETWAS_ anders zu werten als ein "Pro" - oder meinst du nicht? Wenn ein Mitautor schon sagt, dass einer "seiner" Artikel NICHT lesenswert ist, nehme ich im dass eher ab als die Stimme eines Autors, der aus "Trotz" ("um ein entsprechendes Zeichen zu setzen"!) positiv stimmt um ggf. aus unsachlichen Gruenden den positiven Ausgang zu forcieren. Falls du es uebringens uebersehen haben solltest: Ich habe mich bewusst meiner Stimme enthalten. --Kantor Hæ? 21:43, 13. Jul 2006 (CEST)

Ich sagte, ich möchte ein Signal senden. Jetzt wo ihr alle aufgewacht seid nehm ich meine Stimme natürlich wieder raus. Ich kann auch den ganzen Artikel gerne sofort aus die Kandidatur rausnehmen. Kein Trotz. Also alles nicht überbewerten. :-) Jetzt muss aber die contra-stimme des Mitautors auch raus! :) Warum "unsachliche Gründe"? Oh nein jetzt geht das wieder los. :-)--Michael Hüttermann 22:51, 13. Jul 2006 (CEST)

Jetzt wirds aber richtig absurd!!! Erst Stimme rein, "um Aufmerksamkeit zu erregen" - dann wieder zuruecknehmen, wenn jemand meckert? Und das soll kein Trotzverhalten sein??? (Da helfen sogar die Smilies nicht mehr weiter!) Du magst fachlich vielleicht sogar recht haben - aber der rein sachlichen Diskussion hier wuerde es enorm gut tun, wenn du dich mal "vornehm" zurueckhalten oder wenigstens konstruktive Entgegnungen/Erklærungen liefern wuerdest! Sorry fuer die harten Worte (ich mach mich hier wahrscheinlich jetzt zum Buhmann), aber das musste mal gesagt werden. --Kantor Hæ? 23:50, 13. Jul 2006 (CEST)

Lass es doch gut sein Kantor. Hätte ich die Stimme drin gelassen hättest Du dich auch aufgeregt. Ich glaube schon von mir behaupten zu können dass ich konstruktiv arbeite. An Deinem Post kann ich aber kein konstruktives Verhalten entdecken. Also willst Du die Stimme lieber drin haben? Ich verstehe nicht warum hier solche Unterstellungen ("trotzig") platziert werden. Was ist an diesem kleingeschriebenen Gepolter "sachlich"? Leute, es ist nur ein Posting, bringt nicht soviel negative Stimmung rein bitte. :-)--Michael Hüttermann 00:26, 14. Jul 2006 (CEST)

Ich habe die erste Lesenswert-Diskussion sehr ausfuehrlich verfolgt, wenn ich auch nicht direkt beteiligt war. Vielleicht muss man einfach mal ganz ehrlich sagen, dass Köln - da nun mal sehr konkret - wesentlich einfacher "lesenswert" zu bekommen ist als ein derart (anscheinend) umstrittenes und abstraktes Thema wie XP? Ich finde es einfach nicht schøn, hier auf "biegen und Brechen" das Prædikat durchboxen zu wollen - das funktioniert einfach nicht und ist auch nicht gerne gesehen! Allerdings hat sich am Artikel selbst seit der letzten Kandidatur sehr viel positives getan.

Wenn eine Darstellung des Themas einen gewissen "positiven Enthusiasmus" und damit zwingend eine "Kritik" benötigt, (nach Boris Fernbacher) stimmt einfach irgendetwas mit NPOV nicht! "Neutralität" bedeutet nicht, dass man quasi 2 Absätze Lobeshymmne einfach gegen 2 Absätze Kritik "verrechnet". Da ist dann noch einiges Grundsätzlich im argen und ich kann in diesem Sinne die Kritik von WortUmBruch völlig nachvollziehen.

Mit dem "positiven Enthusiasmus" habe ich mich vieleicht etwas ungeschickt ausgedrückt. Die Begeisterung der XP-Erfinder ist eventuell halt etwas spürbar. Was ist an einer kritischen Betrachtung den falsch ? Das da Absätze gegeneinander "verrechnet" werden, so hatte ich das nicht gemeint. Gruß Boris Fernbacher 08:53, 14. Jul 2006 (CEST)

Da die Diskussion hier - wie ähnlich vor 1 Monat - sehr ins Emotionale abdriftet und sich immer weiter von der Sachlage entfernt - was spricht eigentlich dagegen, den Artikel erstmal 3-6 Monate auf Halde zu legen, reifen zu lassen, und das ganze dann noch mal rein sachlich neu zu probieren? --Kantor Hæ? 20:56, 13. Jul 2006 (CEST) (ohne Wertung!)

Ein Grund der gegen das Reifenlassen spricht wäre der, dass das nunmal kein Wein sondern ein Artikel von einem kritikfähigen Hauptautor ist, der bisher jede sinnvolle Verbesserung unmittelbar einfließen ließ. Wenn wir verhindern wollen das Fachmänner, Wissenschaftler einfach aufgeben sich an der Wikipedia zu beteiligen, indem wir warten bis denen ein langer Bart gewachsen ist, so wäre dein Reifekriterium ein Meilenstein für eine wachsende Unpopularität der Wikipedia. --Haeber 21:22, 13. Jul 2006 (CEST)

Der Artikel wird in sechs Monaten nicht noch besser sein. Ja, das Thema ist abstrakter und strittiger als z.b. "Köln". Schade, dass das einen so negativen Einfluss hat. Es existiert keine Lobeshymne im Artikel. Bitte trennt endlich mal den Artikel vom Thema. Biegen und brechen kann ich nicht erkennen, nur strukturiertes Vorgehen: alle Verbesserungsvorschläge wurden gewissenhaft und zeitintensiv eingearbeitet.--Michael Hüttermann 23:01, 13. Jul 2006 (CEST)

Ich verstehe den Einwurf mit dem Wikibook auch nicht im Ansatz: Wenn ich den Artikel zum Wankelmotor lese, bin ich auch grob im Stande einen solchen Motor zu verstehen und eventuell zu reparieren. Was für ein tragisches Dilemma: Man kann theoretisches Wissen anwenden. Also ab sofort nur noch Artikel der Kategorie:Abstraktum in der Wikipedia? Geo-Loge 09:23, 14. Jul 2006 (CEST)

War so frei und habe deinen Eintrag bearbeitet. Kategorien bitte richtig angeben. --chrislb 问题 00:10, 16. Jul 2006 (CEST)

Stimm doch einfach für oder gegen den Artikel. Sorry, aber ob die Kategorie hier in diesem Satz refernziert wurde oder nich is doch wohl sowas von unwichtig.--Michael Hüttermann 03:16, 16. Jul 2006 (CEST)

 Pro Finde den Artikel lesenswert, habe selbst immer mal ein paar Typos, Tippos usw. korrigiert und konnte die Verbesserungen direkt mitverfolgen. Dass, die Bilder an Powerpoint-Präsentationen erinnern, kann ich Ersten nicht nachvollziehen und Zweitens ist es für einen lesenswerten Artikel unerheblich, ob jemanden einige wenige Bilder wegen eines solchen Stilunbehagen aufstoßen. Die oben besprochenen Kritiken sind unverhältnismäßig hart in Bezug zu einem Artikel der „lediglich“ als lesenswert ausgezeichnet werden soll, schließlich gibt es im Vergleich dazu viele regelrechte langweilige, trockene, teils sogar stark dem POV verfallene Lesenswerte Artikel. --Haeber 21:10, 13. Jul 2006 (CEST)

 Pro Klar Lesenswert!--80.134.240.65 03:24, 16. Jul 2006 (CEST)

 Pro - Der Artikel ist sehr umfassend. In der Vermeidung von unnötigen Fremdworten und Anglizismen sogar sehr gut. Angesichts eines IT-Themas recht anschaulich und wenig trocken. Die Kritik wegen mangelnder Neutralität und zu wenig kritischer Sichtweise kann ich nicht ganz nachvollziehen. Speziell angesichts dessen was einem im Umfeld der jüngeren Geschichte manchmal als neutraler, wissenschaftlicher, kritischer und ausgewogener Artikel verkauft werden soll. Gruß Boris Fernbacher 21:44, 16. Jul 2006 (CEST)

 Pro Der Artikel ist eine fundierte Abhandlung zum Thema. Was die letzten Wochen noch alles von vielen weiteren Autoren beigetragen wurde ist sensationell. Eine Aufnahme in die "Lesenswerten" hat in meinen Augen auch Signalcharakter für die Zukunft. So wird dieser Artikel einer breiteren Öffentlichkeit zugänglich und Akademiker bzw. Spezialisten weiter motiviert ihr Wissen offen bereitzustellen. Gerade bei solchen "abstrakten" Themen wie Artikel aus der IT muss noch einiges an Grundlagenarbeit geleistet werden. Auch das allgemeine Interesse wird erhöht: es ist schon schade, dass die Resonanz doch recht verhalten war. --Michael Hüttermann 00:20, 17. Jul 2006 (CEST)

 Pro 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. Mehr ... --ClausVB 20:52, 25. Jul 2006 (CEST)

Komponente "Kommunikation" erweitern

Ich habe nur begrenzte Erfahrung (mehr Theorie als Praxis) mit XP. Ich habe mir erlaubt folgenden Satz in "Grundlagen" zu ändern:

"Kommunikation ist eine Grundsäule (siehe Werte) dieses Vorgehensmodells. Sollte die Kommunikation eines Teams gestört sein oder vom Chef unterdrückt werden, kann XP nicht funktionieren."

Damit soll dem Leser relativ früh klar werden, das die fünf Grundsäulen (siehe Werte) für XP unumgänglich sind. Fehlt Kommunikation in einem Team, hat kein Programmier den Mut schlechte Strukturen anzusprechen oder zu ändern, dann ist XP meiner Meinung nach zum Scheitern verurteilt.

Der Artikel sollte über "Nutzen" klar machen, was man alles gewinnen kann (mit dem Einsatz von XP), aber im Sinne der Objektivität sollte nach Lesen des Artikels auch klar sein, was für Anforderungen XP hat. XP wird schwierig umzusetzen, wenn z. B. gilt: "Wir dürfen in unserer Firma nicht streiten und Struktur- und Organisationsprobleme nicht offen ansprechen. Der Kunde darf von Problemen auf keinen Fall etwas mitbekommen, lieber anlügen!"

Das (bestehende) Kunden belogen wurden (CeBit fällt mir da sofort ein) ist mir schon oft begegnet.

Ich könnte den Artikel auch noch in zwei, drei Sätzen bei "Kommunikation" mit bekannten Modellen von Friedmann Schulz von Thun ergänzen und darauf hinweisen, wie wichtig eine ehrliche Analyse der eigenen Kommunikationsstrukturen ist, bevor man XP einsetzt. Man stelle sich eine Firma von Einzelkämpfer und/oder Eigenbrödlern vor, die auch darauf bedacht waren, ihr Wissen für sich zu behalten. Drei Freunde von mir (ausnahmslos gute bis sehr gute Programmierer) gingen mit Ihrer Firma insolvent, weil selbst wichtigste Themen tot geschwiegen wurden und somit Entscheidungen über die Zukunft der Firma ausblieben. Alleine "Pair Programming" einzuführen, hätte intensives Training und vielleicht auch ein paar Kommunikationsseminare erfordert. --ClausVB 22:07, 27. Jul 2006 (CEST)

Zu lang

Viel besser als früher.

Meine Kritik am Artikel (nach kurzem überfliegen):

• Zu lang, keine Zeit, ihn komplett zu lesen. In der Kürze liegt die Würze.

--> glaub ich nich. will nich gezwungen amputieren.

• Die Aufwandskurve ist falsch, weil sie suggeriert, XP sei ein Wasserfall.

--> ist nich falsch.

• Innerhalb des Entwicklungsteams darf es Rollentrennung geben, solange sie nicht nach Code ist.

--> bitte?

• Die speziellen Entwickler-Rollen Tracker und Coach fehlen.

--> könnte man noch ergänzen, ja.

• Ist Product Owner im XP-Prozess wirklich eine Rolle neben dem Kunden?

--> orthogonal zum Kunden.

• Ist User im XP-Prozess wirklich eine Rolle neben dem Kunden?

--> orthogonal.

• XP-Release != XP-Iteration.
  • Release: Zyklus von 2-6 Wochen
  • Iteration: einzelner Implementierungszyklus zur Abarbeitung einer User-Story, meist 2-4 Tage.
  • Mehrere Iterationen (User-Story-Implementierungen) zusammen bilden ein Release.

--> hmm?

• Respekt als XP-Wert: Ich befürchte, dass das für diesen Wikipedia-Artikel hinzuerfunden wurde. (Nichts gegen Respekt, Respekt ist wichtig!)

--> Ich bitte Dich, ich erfinde doch nichts dazu nur für einen Artikel

• "10-Minuten-Build": Noch mehr hervorheben, dass das bereits eine umfangreiche Testsuite einschließt.

--> dann wirds ja noooooooooch länger

• Der Aspekt der Einfachheit von XP geht in der Länge des Artikels unter.

--> XP propagiert zwar Einfachheit, dennoch ist XP schon als komplex zu bezeichnen. Einfachheit wurde an mehreren Stellen erläutert.

Diese Kritik soll dazu beitragen, einen _bereits guten Artikel_ noch besser zu machen. Ich habe den Artikel kaum wiedererkannt, im vollständig positiven Sinne. In dem jetzigen Zustand bekomme ich sogar Lust, selbst wieder etwas daran zu arbeiten. Danke an Michael Hüttermann, weiter so! --ChristianHujer 00:46, 10. Aug 2006 (CEST)

--> Gute Idee! Für weitere Optimierungen bin ich immer zu haben. Danke für das Lob. --Michael Hüttermann 01:52, 12. Aug 2006 (CEST)

Basismerkmale

Hallo, ich kann mir gut vorstellen, dass XP in der Praxis vom Ideal immer etwas abweicht. Immer abhängig von der Organisationsstruktur des Unternehmens, des Projekts, etc. Angenommen in einem Unternehmen ist ein angebrachtes Vorgehen in groben Zügen überlegt worden und man möchte nun wissen, ob es eher dem einen oder dem anderen Vorgehensmodell entspricht, was könnte man sagen, sind die grundlegenden Elemente des XP ? Z.B. ist Pair-Programming immer erforderlich oder kann auch eine Vorgehensweise, die Pair-Programming nicht vorsieht noch als XP bezeichnet werden ?

Wer spricht denn da? Das wird im Artikel thematisiert. XP muß dort angepasst werden, wo es die individuellen Projektgegebenheiten notwendig machen. Eine Gewichtung von Prinzipien und Praktiken ist generell schwierig vorzunehmen. Dies wurde aber insofern gemacht, als dass die Primärpraktiken die grundlegenderen sind und die Sekundärpraktiken eher die optionalen AddOns. Das Wichtigste sind aber letztendlich die Werte. --Michael Hüttermann 00:02, 5. Dez. 2006 (CET)

Der Manager des Teams führt das Team nicht?

Unter Aufbauorganisation steht in der Tabelle:

• Projektmanager kann … nicht Manager des Teams sein
• Aufgaben: Führung des Teams

Klingt für mich erklärungsbedürftig. Also der Manager des Teams führt das Team nicht? --Björn Klippstein 19:50, 19. Sep. 2007 (CEST)

Der Kunde ist selbst verantwortlich für sein Projekt?

Ebenfalls unter Aufbauorganisation: Verstehe ich es richtig: Der "Leiter" ist offenbar der gleiche, der später immer als "Product Owner" bezeichnet wird und woanders meistens "Projektleiter" heißt, richtig? Dann würde ich vorschlagen, entweder den einen Begriff oder den anderen zu verwenden.

Der jedenfalls trägt die Verantwortung. Aber er kann auch der Kunde sein, so steht es in der Tabelle gleich zweimal. In welcher Konstellation aber kann es passieren, dass der Kunde selbst die Verantwortung dafür trägt, dass seine Software erfolgreich entwickelt wird? Dem Abschnitt mangelt es an Klarheit. --Björn Klippstein 20:07, 19. Sep. 2007 (CEST)

Toter Weblink

Bei mehreren automatisierten Botläufen wurde der folgende Weblink als nicht verfügbar erkannt. Bitte überprüfe, ob der Link tatsächlich unerreichbar ist, und korrigiere oder entferne ihn in diesem Fall!

• http://www.objectmentor.com/ourCustomers/index (archive)
  • In Extreme Programming on 2008-04-08 20:35:42, 404 Not Found
  • In Extreme Programming on 2008-04-21 19:02:53, 404 Not Found

Die Webseite wurde vom Internet Archive gespeichert. Bitte verlinke gegebenenfalls eine geeignete archivierte Version: [2]. --SpBot 21:00, 21. Apr. 2008 (CEST)

Habe den Link auf’s Internetarchiv umgebogen. --j ?! 13:16, 23. Apr. 2008 (CEST)

Toter Weblink

Bei mehreren automatisierten Botläufen wurde der folgende Weblink als nicht verfügbar erkannt. Bitte überprüfe, ob der Link tatsächlich unerreichbar ist, und korrigiere oder entferne ihn in diesem Fall!

• http://www.ddj.com/dept/architect/184414801C2
  • In Extreme Programming on 2008-04-08 20:35:44, 404 Not Found
  • In Extreme Programming on 2008-04-21 19:03:02, 404 Not Found

--SpBot 21:00, 21. Apr. 2008 (CEST)

Habe den Link korrigiert, und bei der Gelegenheit auch gleich das Erscheinungsdatum. --j ?! 13:12, 23. Apr. 2008 (CEST)

User-Stories versus User-Storys

Als Zitat schriebe man „User Stories“, das wäre dann korrektes Englisch. Wenn man den Bindestrich verwendet, muss man auch den Plural nach den Regeln der deutschen Rechtschreibung bilden. So, wie es jetzt im Artikel steht, ist es weder Deutsch noch Englisch, sondern Denglisch. --j ?! 22:22, 23. Aug. 2008 (CEST)

Danke für den Hinweis. Ich wäre für eine korrekte Verwendung des Ausdrucks User Stories aus der englischen Sprache bzw. wie in der englischen Sprache. Und in der Tat dann ohne Bindestrich, da gebe ich Dir recht. Vgl. auch User Story. – Natürlich verwendet/schreibt man da dennoch eine Art denglisch, aber als Informatiker bin ich die Verwendung solcher Fachtermini gewöhnt. --Talaris 22:35, 23. Aug. 2008 (CEST)

Hast vollkommen recht, Talaris. Wir müssen nicht jeden Blödsinn mitmachen, den die neue deutsche Schlechtschreibung uns versucht aufzudrängen. Wenn ich Storys, Proxys, Babys etc. sehe, schüttelts mich jedesmal... -- Klaeren

Das mag dich ja schütteln, dennoch ist es korrekt. Mich schüttelt’s beim Anblick der völlig verkorksten Sprache, die viele Informatik-Publikationen auszeichnet. Und ebenso schüttelt es mich beim Anblick des Artikels in seiner momentan Form. Aber da es zwei zu eins steht, werde ich vorerst mal die von euch bevorzugte, von mir als hässlich empfundene Version des Artikels stehen lassen. Nix für ungut, aber ihr solltet mal an eurem Sprachempfinden arbeiten. ;-) --j ?! 21:17, 24. Aug. 2008 (CEST)

Ich stimme dir zu, dass der Informatiker-Slang manchmal schwer erträglich ist. Auch für die Informatiker selber, übrigens... Aber die Art von Denglisch, die mich *richtig* aufregt, ist die, die in scheinbar deutscher Verkleidung daherkommt, z. B. "Einmal mehr hat sich gezeigt...", "Ich erinnere einen Vorfall...", "Susi's Laden" etc. Aber da kämpfen wir auf völlig verlorenem Posten. Ich finde die "Storys" trotzdem kulturlos, ebenso wie das holländische "Odeklonje" für "Eau de Cologne". Klaeren

Dann findest du bestimmt auch die Zwischenstaatliche Kommission für deutsche Rechtschreibung kulturlos, oder? Ganz zu schweigen vom Institut für Deutsche Sprache. ;-) --j ?! 12:36, 27. Aug. 2008 (CEST)

Kritik

Sowohl Eigenheiten in der Aufbauorganisation als auch die Komplexität und Anforderungen an die zu entwickelnde Funktionalität lassen sich mit XP bei qualifizierter Wahrnehmung der Risiken meistern.

In Anbetracht der Laenge der Diskussion stelle ich das zuerst zur Debate (wuerde das gerne entfernen). Klingt wie ein "Allheilmittel" (bei entsprechender "qualifizierter Wahrnehmung"). Da XP und deren "Errungenschaften" immer noch als umstritten gelten, halte ich das fuer unpassend so zu formulieren. Traute Meyer 01:19, 7. Okt. 2008 (CEST)

Hallo Traute Meyer, du hast völlig recht, das ist nur sales talk. Bei "qualifizierter Wahrnehmung der Risiken" lässt sich mit jeder Technik alles meistern. Raus mit dem Satz! --Herbert Klaeren 08:14, 7. Okt. 2008 (CEST)

Nicht lesenswert, sondern tendenziös, daher Neutralitäts-Baustein

Hallo,

ich habe diesen Artikel soeben durchgelesen. Da ich mich selbst intensiv mit (der Leitung von) Software-Entwicklungsprojekten auseinandergesetzt habe und auch seit vielen Jahren in diesem Bereich tätig bin, muss ich sagen, dass mich der Artikel doch insgesamt sehr enttäuscht hat, insbesondere da er das Prädikat "Lesenswert" erhalten hat.

Zwar wurden doch hier und da Relativierungen der von XP angestrebten Vorteile eingebaut ("durch XP soll xyz erreicht werden" usw.), jedoch ist es für jeden neutralen Leser offensichtlich, dass die Mehrzahl der Autoren diesem Ansatz sehr positiv gegenüber stand und bestrebt war, ihn möglichst idealisiert darzustellen. Die Kritik beschränkt sich auf einen minimalen Absatz. Zudem wurden den einzelnen Kritikpunkten unmittelbar wieder Gegenargumente nachgestellt, so als habe XP auf fast jeden Einwand eine passende Antwort.

Ich habe mich daher entschieden, in diesen Artikel einen Neutralitäts-Baustein einzupflegen und bin auch gegen den vermutlich nun aufbrausenden ideologischen Ansturm der XP-Verfechter gewillt, diesen zu verteidigen, bis der Artikel die aus meiner Sicht unbedingt erforderlichen Eigenschaften aufweist:

• Es sollte herausgearbeitet werden, ob es heute irgendwelche wissenschaftliche (d.h. auf Studien basierende) Evidenz für die postulierte Überlegenheit dieses Entwicklungsansatzes gibt. Falls solche Studien nicht vorliegen, sollte an prominenter Stelle darauf verwiesen werden, dass die Wirksamkeit dieses Ansatzes bis heute nicht nachgewiesen ist. Auch wären Studien interessant, die ggf. das Scheitern des Ansatzes zeigen.
• Die Kritik sollte in einen eigenständigen Abschnitt auf höchster Ebene verlegt werden, zumal im Abschnitt "Diskussion" viele Teilabschnitte enthalten sind, die mit Diskussion gar nichts zu tun haben.
• Die einzelnen Kritikpunkte sind weiter auszuarbeiten. Fehlende Kritikpunkte sollten ergänzt werden. Insofern Kritikpunkte Gegenargumenten gegenübergestellt werden, sollte es nicht so aussehen, als sei die Kritik damit ausgeräumt. Wenn es tatsächlich eine Diskussion der einzelnen Kritikpunkte gibt, so kann diese in entsprechend besser ausgearbeiteten Unterabschnitten behandelt werden, statt einfach nur so zu tun als habe XP für alles ein Rezept.
• Es sollte klar aus dem Artikel hervorgehen, unter welchen Voraussetzungen ein XP-Ansatz funktionieren kann. Ich schlage hierzu einen Abschnitt "Voraussetzungen" vor.

Ich werde mich gerne nach und nach an diesen Arbeiten beteiligen, bitte aber um Verständnis, wenn mir die Zeit fehlt, dies in vielstündigen Sitzungen in sehr kurzer Zeit zu tun. Vielmehr werde ich immer wieder Einzelheiten einbringen. Um nochmal dem ideologischen Ansturm der Entrüstung vorzugreifen, bitte ich um eine sachliche Diskussion. Durch falsch verstandenes Software-Engineering wird Jahr für Jahr viel Geld und Zeit vergeudet. Das Thema ist daher zu ernsthaft, um es einer bloßen Begeisterung für das Thema zu überlassen. Eine ingenieursmäßige Abwägung und Darstellung ist daher dringend erforderlich. -- Mkleine 13:36, 10. Nov. 2008 (CET)

Nach Ausarbeitung des Kritik-Abschnitts habe ich den Baustein wieder entfernt. -- Mkleine 03:57, 13. Nov. 2008 (CET)

Wortwahl "attribuiert"

Leider verstehe ich nicht, was "attribuiert" im Abschnitt Der ideale Programmierer heißt. WIKTIONARY kennt das Verb "attribuieren" auch nicht. Grüße! --Bukk 11:54, 1. Jul. 2009 (CEST)

ich stimme dir zu, es ist eine völlig unnötige Verwendung eines lateinischen Worts. 'attribuere' heisst 'zuteilen, zuordnen', ich formuliere den entsprechenden Satz gleich mal so um, dass er nicht so gespreizt daherkommt. --Herbert Klaeren 14:05, 1. Jul. 2009 (CEST)

Hallo, Herbert Klaeren! Das ist gut! Und schnell ging es auch. Grüße! --Bukk 15:41, 1. Jul. 2009 (CEST)

Objektivität?

Ein wenig scheint mir der Kritik Abschnitt einen Geschmäckle zu haben. Während mir viele Teile der Kritik durchaus schlüssig erscheinen finde ich Argumente wie "Programmierer haben ein großes Ego, deshalb ist eine Methode in der jeder alles ändern darf doof." oder "XP erfordert Disziplin von den Programmierern, da sie alles im Pair programmieren sollen." doch eher etwas holprig. Natürlich erfordert XP ein Stück Selbstlosigkeit und auch Disziplin usw, aber es geht doch auch nicht darum, dass es sowas wie der lustig pinke Gummibärchen Trunk der Softwareentwicklung ist. Auch das Argument es sei schwierig Kunden und Programmierer zu finden, für die XP funktioniert halt ich für richtig aber absolut nicht kritikwert. Wenn eine Methode für ein Team oder einen Kunden nicht passend ist kann ich sie nicht benutzen. Dieser Kritikpunkt ist meines Erachtens nach nur haltbar wenn XP irgendwo nachweisbar den Anspruch erhebt die Methode zu sein, die IMMER funktioniert. Wenn ich richtig informiert bin ist aber genau dies nicht der Fall, viel mehr habe ich das Gefühl, dass gerade die Macher von XP immer wieder betonen, dass "ihre" Methode für sie gepasst hat und passt aber sicher nicht für jeden geeignet ist.

Mein Wissen über XP reicht leider nur bis zur nächsten Ecke, ich fände es aber toll wenn jemand mit etwas mehr Sachverstand den Kritik Abschnitt einmal auf seine Schlüssigkeit prüfen könnte.

Thorben --134.102.117.51 02:26, 20. Jul. 2009 (CEST)

Windows 7 ...

... ist nach einem Artikel im Spiegel mit Methoden des Extreme Programming hergestellt worden. Bei VISTA lief MS mit konventioneller Programmierung in die "Komplexibilitätsfalle" und erhielt einen hochgradig mit Fehlern durchsetzten Code. Grüße! --Bukk 10:16, 20. Jul. 2009 (CEST)

wenn mans genau liest, ist eigentlich nur das "pair programming" verwendet worden, von allen anderen Ingredienzien des XP ist bei Microsoft keine Rede. Der Artikel redet trotzdem stellenweise über XP, aber dann ohne direkten Bezug zu W7. --Herbert Klaeren 13:11, 20. Jul. 2009 (CEST)

Methode, Methodik oder Prozess ?

Gleich im ersten Satz wird XP als "agile Methode" bezeichnet, das widerspricht aber der Definition von Methode im Artikel Agile Softwareentwicklung. Um mit diesem Artikel konsistent zu bleiben, sollte das auf "agiler Prozess" geändert werden. Oder man verwendet das Wort "Methodik".

dieser Einwand (unbekannten Datums) hat sich offensichtlich längst erledigt. --Herbert Klaeren 08:31, 4. Feb. 2010 (CET)

Immun gegen Kritik?

Zitat: "XP erweist sich insofern in gewisser Weise als immun gegen Kritik – es ist, wissenschaftlich gesprochen, kaum falsifizierbar." – Abgesehen davon, dass diese Ausssage nicht bequellt ist, wundere ich mich über ihren Inhalt. Ob wissenschaftlich falsifiziert werden kann oder nicht, ist doch eine Frage, die sich auf Theorien bezieht, nicht aber auf Arbeitsmethoden. Im Artikel wird Extreme Programming ausschließlich als Methode, nicht als Theorie definiert. (Ich stehe dem Thema übrigens neutral gegenüber.) --Suaheli 01:05, 4. Feb. 2010 (CET)

da hast du recht, dieser Satz ist unsinnig. Ich lösch ihn mal raus... --Herbert Klaeren 08:35, 4. Feb. 2010 (CET)

Menschliche Schwächen

Programmierer weisen oftmals ein recht ausgeprägtes Ego auf, das sich in großer Überzeugung von „richtigen Lösungen“ und einem gewissen Besitzdenken hinsichtlich des geschriebenen Codes äußert.

Das klingt eigenartig nach so alten Asperger-Computernerd-Vorurteilen. Es ist wohl den meisten Menschen zueigen, unabhängig vom Beruf. Darum würde ich vorschlagen, z.B. die folgende, etwas neutralere Formulierung zu wählen:

Fachleute zeichnen sich häufig durch die Überzeugung von „richtigen Lösungen“ und einem gewissen Besitzdenken hinsichtlich ihrer Erzeugnisse aus.

Oder so ähnlich. Ja ich weiß, ist nicht besonders wichtig, aber auch auf Kleinigkeiten kommt es an. --82.83.59.83 07:55, 4. Apr. 2010 (CEST)

Ironischer Weise wurde eben dieser Absatz als Abhilfe gegen mangelhafte Neutralität und gegen tendentiöse Formulierungen hinzugefügt. Der neue Vorschlag liest sich zwar besser, aber letztlich ist das auch nur eine Behauptung, die sich allenfalls im privaten Umfeld bestätigen oder widerlegen lässt – es sei denn, das wurde mal untersucht. Ich bin für restloses Streichen. Überhaupt ist der ganze Abschnitt ohne Quellen, also potentiell die persönliche Meinung eines beliebigen, anonymen Autors. Eigentlich dürfte der Artikel längst nicht mehr lesenswert sein. --Zahnradzacken 16:34, 4. Apr. 2010 (CEST)

Universales Wischiwaschi ohne klare Definition

Ich habe es immer noch nicht begriffen. Hat es überhaupt jemand begriffen? Mal ehrlich. Ich lese in diesem Artikel einen zusammengewürfelten Riesenhaufen von trivialen Selbstverständlichkeiten. Wenn ich all diese Eigenschaften und Methoden dieses sogenannten Extreme Programmings zusammenfasse, komme ich zu dem Schluss, dass ein jeder Programmierer dieser Welt mehr oder weniger ein Extreme Programmer sein muss, denn für Nicht-Extreme Programming bleiben keine Merkmale mehr übrig. Vielleicht gibt es demnächst auch Extreme Baking: Da wird dann einer ein BWL-soziologisches Seminar organisieren und vorne auf die Schautafel schreiben: Mehl kaufen, Ofen anheizen, Menschlichkeit, Risikoabwägung, Teig-Test, Brotverkauf, mit Kunden reden etc. -- um dann zu übersehen, dass eigentlich jeder irdische Bäcker ein Extreme Baker ist. -- Kurz gesagt: Wenn sich eine Sache nicht vom Rest des Universums unterscheidet, dann ist sie entweder selbst das Universum, oder sie ist nicht existent. Vielleicht lässt sich der Artikel um 90% kürzen: Einfach auf ein paar Original-Zitate reduzieren, ganz enzyklopädisch, neutral den unerklärbaren Schwachsinn für sich sprechen lassen, damit er seine Unerklärbarkeit selbst enttarnt, ohne dabei von persönlichen Mutmaßungen vernebelt zu werden. --Suaheli 03:59, 5. Apr. 2010 (CEST)

Im Artikel sollte eine deutlichere Abgrenzung vorgenommen werden, teilweise lesen sich die Abschnitte wie aus einem XP-Buch. Das Wischiwaschi wurde übrigens 2006 als lesenswert betrachtet: Diskussion:Extreme_Programming/Archiv/2006 (das muss verbessert werden oder es wird Zeit für eine Abwahl). Teilweise finde ich das Bemühen ja lobenswert, die Ideale auch Laien verständlich zu machen. Aber langes Gefasel verwirrt vielleicht am Ende jedermann. Dennoch möchte ich obiger Kritik widersprechen, da sie sich nicht nur auf den Artikel sondern auch das XP selbst bezieht: Ich sehe keine Ansammlung von Selbstverständlichkeiten. Welche wären das? Welche Zitate sind unerklärbarer Schwachsinn? --Zahnradzacken 02:09, 8. Apr. 2010 (CEST)

XP als "Schwachsinn" zu bezeichnen, war natürlich fies und außerdem nicht artikelbezogen, Du hast Recht. -- Zur Sache: Jede enzyklopädisch bedenkliche Stelle in diesem langen Artikel zu nennen, hieße, einen fast ebenso langen Kommentar zu schreiben; also fange ich besser häppchenweise an: Schon die Einleitung ist bezeichnend für den nebulösen Charakter des Artikels. Zitat: "Extreme Programming ... ist eine Methode, die das Lösen einer Programmieraufgabe in den Vordergrund ... stellt und dabei einem formalisierten Vorgehen geringere Bedeutung zumisst." -- Obwohl dem "geringere Bedeutung" zugemessen werde, erläutert dieser Artikel ellenlang nichts anderes als genau das: XP-Formalitäten. (Übrigens meine ich, dass das Lösen einer Programmieraufgabe in der IT-Welt immer im Vordergrund steht, das liegt in der Natur des Berufs und ist nicht XP-spezifisch.) Ebenso bezeichnend finde ich den zweiten Satz: "Diese Vorgehensweise definiert ein Vorgehensmodell der Softwaretechnik, das sich den Anforderungen des Kunden in kleinen Schritten annähert." Abgesehen von dem tautologisch aufgeblähten Satzanfang, steht hier wenigstens ein klares Merkmal: In kleinen Schritten nähere man sich den Kundenanforderungen. Allerdings ist das wiederum so alltäglich auch in anderen Arbeitsmethoden, dass es schon wieder nichtssagend ist, also enzyklopädisch nicht weiterhilft. -- Soviel mal fürs Erste. Vielen Dank. Servus --Suaheli 16:05, 8. Apr. 2010 (CEST)

So fies nun auch nicht ;) Nur nicht zielführend, im Gegensatz zu deiner Antwort. Dazu: Wenn das genauso lang wie der Artikel wird, machen wir doch eine Unterseite auf ;) Nun zu deinen Häppchen: Da ich den Artikel alles andere als lesenswert finde, bin ich ganz deiner Meinung, dass die Einleitung besser formuliert werden könnte. Wie wäre es mit

"XP ist eine Strategie für Projekte der Softwareentwicklung, die zum Ziel hat, möglichst wenig Zeit auf Formalitäten zu verwenden, sondern vielmehr schnell und in kurzen Entwicklungsphasen Fortschritte im Projekt zu erlangen."

Natürlich ist das Lösen der Aufgabe immer das Ziel, aber bei manchen Vorgehensmodellen geht der Entwicklung eine viel längere Phase der Planung voraus (gerade wenn man für Behörden entwickelt). Außerdem könnte bei anderen Ansätzen auch die Verlässlichkeit der Qualitätsaussagen wichtig sein, während bei XP das augenscheinliche Funktionieren wichtig ist (mMn). Grüße --Zahnradzacken 18:33, 8. Apr. 2010 (CEST)

Inhaltlich kann ich hier nicht mitreden, aber sprachlich kann ich vielleicht beitragen: Ich meine, in Deinem Vorschlag verwendest Du zuviele redundante und abstrakte Wörter, und sehr wichtiges konkretisierst Du erst im unsichtbaren Privatkommentar danach ("andere planen viel länger" -- Aha!). Wenn ich Deine Gedanken spontan zusammenfasse, und übrigens noch erkenne, dass XP für Gruppen, nicht für Einzelne, gedacht ist, kommt mir dieses Konzentrat heraus:

XP ist eine spezielle Gruppenarbeitsweise in der Softwareentwicklung. Sie zielt, unter anderem, auf eine starke Verkürzung der Zeit zwischen der Produktplanung Planungsbeginn und dem ersten praktischen Entwicklungsschritt Planungszeit. Um das dadurch erhöhte Fehlerrisiko zu vermindern, werden die Entwicklungsschritte gleichfalls stark verkürzt, so sollen Qualitätskontrollen und Korrekturen schneller greifen können. Nicht nur die Zeit wird in kleinere Einheiten aufgeteilt, auch die Aufgabenbereiche werden kleiner zerteilt und können situationsbedingt personell jederzeit umbesetzt werden.

So, oder so ähnlich, habe ich es bisher verstanden. --Suaheli 20:18, 8. Apr. 2010 (CEST)

Man muss hoffentlich kein Experte sein, um hier zu verbessern, sonst müsste ich mich auch ausklinken. Aber ich glaube, du hast andere Schlüsse aus meinem Beitrag gezogen, als ich es im Sinn hatte. Das liegt auch daran, dass ich nur einen Satz vorgeschlagen habe, zur erschöpfenden Einleitung braucht es aber mehrere, da XP aus mehreren (teils unabhängigen) Konzepten besteht. Ich halte XP für einen Gegenentwurf zu den üblichen Vorgehensmodellen der Softwareentwicklung (Wasserfallmodell, V-Modell etc). Da aber übliche Vorgehensmodelle eher starr sind, kann man XP deshalb (vielleicht) nicht kurz und knapp mit dem Schlagwort Vorgehensmodell beschreiben (zumindest wurde das irgendwann rauseditiert). Gruppenarbeitsweise finde ich unzutreffend, es klingt nach einer eindeutigen, homogenen Art und Weise, nicht nach dem losen Bündel an Konzepten, als das ich XP sehe. Es gibt auch keine Zeit zwischen der Planung und der ersten Entwicklung (außer Urlaub ;)). Verkürzt werden soll die Planung. --Zahnradzacken 22:57, 8. Apr. 2010 (CEST)

Ich meinte die Dauer der Planung (habe es gerade oben korrigiert). -- Du bringst meinen Satz noch viel besser auf den Punkt: "Die Planung soll verkürzt werden." Genau! Redundante Wörter raus. -- Zum Begriff "Gruppenarbeitsweise": Ich meine, selbst das Chaos ist eine Art und Weise. Beispielsweise ist sogar die Ablehnung eines Konzepts ein Konzept. Ein Gesetz, das Gesetze verbietet, ist auch ein Gesetz. -- Wenn Du stattdessen "Projekt" schreibst, meinst auch Du letztendlich ein Arbeits-Projekt, oder? :-) --Suaheli 23:35, 8. Apr. 2010 (CEST)

Jaja, irgendwann fängt Deutsch an, sich einschränkend anzufühlen.. ;) Alles passt irgendwie und doch auch nicht. Mit "Projekt [+ in] der Softwareentwicklung" meinte ich natürlich in der Tat ein Projekt, in dem gearbeitet wird, also ein Softwareprojekt. Die XP-Strategie ist aber nicht für das Projekt sondern für die Entwicklung im Projekt (oder so). "Formalitäten" ist in der Tat zu abstrakt, aber schon im ersten Satz ausführlich zu schildern, was XP nicht ist, finde ich keinen guten Ansatz. Ein ander mal --Zahnradzacken 01:31, 9. Apr. 2010 (CEST)

Ich glaube, wenn Du eine Unterscheidung zu machen gedenkst zwischen den Formulierungen "für das Projekt" und "im Projekt", dann suchen Deine Gedanken -- wahrscheinlich unbewusst -- nach einem undeutlichen Oberbegriff, um allen Eventualitäten gerecht zu werden. Eine gute Einleitung sollte, meiner Ansicht nach, den umgekehrten Weg gehen: Einen undeutlichen Oberbegriff durch ein paar konkrete Begriffe zu ersetzen. Dafür reichen meist schon zwei oder drei, manchmal sogar nur einer. --Suaheli 16:38, 10. Apr. 2010 (CEST)

Gut beobachtet. Es ist vermutlich nicht hilfreich, den passenden Begriff zu suchen, wenn der Leser dann erahnen muss, was ich nun meinte. Andererseits finde ich es aber nicht unbedingt hilfreich, zu Beginn mit Teilaspekten anzufangen. Die kann man durchaus in der Einleitung bringen, aber zum Einordnen braucht es meiner Meinung nach ganz zu Beginn etwas Abstraktes, so wenig das auf Anhieb das Wesen selbst erklärt. So weiß aber ein Leser, egal aus welcher Ecke er kommt und mit welchen Erwartungen er den Artikel zu lesen anfängt, was ihn thematisch erwartet (und, sollte ein Kenner es lesen, dass die Darstellung nicht selektiv ist). Leider bin ich gerade zu unkreativ, einen vollständigen Entwurf vorzuschlagen. --Zahnradzacken 16:11, 11. Apr. 2010 (CEST)

Formale Spezifikationen und Dokumentation

Im Artikel heißt es: Des Weiteren muss er auf eine formale Festlegung der Projektinhalte (Spezifikation) sowie auf eine Dokumentation der realisierten Software verzichten. >>> Während die erste Behauptung (Nichtexistenz formaler Spezifikation) ja noch zwangsläufig irgendwie wahr sein dürfte, kann ich die zweite Behauptung (Nichtexistenz einer Dokumentation) nicht nachvollziehen: Sprachen wie Java bieten die Möglichkeit, am Ende jedes Entwicklungstages die aktuelle Dokumentation via javadoc automatisiert zu erstellen... und das ist prinzipiell auch relativ einfach für beliebige Sprachen und Umgebungen machbar. Warum soll es also angeblich keine Doku geben? --85.179.197.44 19:53, 13. Apr. 2010 (CEST)

Javadoc dokumentiert den Programmcode, nicht die Endanwendung des Programms. Der Autor des obigen Zitats meinte vermutlich eine Dokumentation für den Endanwender, wie etwa "Zum Kaffeekochen roten Knopf drücken"; nächste Woche könnte es ja der blaue sein, daher erst gar nicht dokumentieren :-) -- Der Artikel ist leider so nebulös wie sein Lemma. --Suaheli 23:54, 13. Apr. 2010 (CEST)

Falls der Endanwender gemeint ist, müsste es dann also heißen: "Doku kann erst bei Projektende erstellt werden!" - und nicht: "Doku kann nicht erstellt werden!" Ansonsten: Wieso soll das Lemma (und der Artikel) denn "nebulös" sein? --85.177.143.232 00:47, 16. Apr. 2010 (CEST)

Abschnitt "Kritik"

Im Folgenden möchte ich Kritik gegenüber dem Abschnitt "Kritik" und den Verweis auf diesen Im Einleitungssatz äußern ("Die Wirksamkeit des Ansatzes ist umstritten (siehe Abschnitt Kritik).").

Dabei möchte ich betonen, dass das nicht heißen soll, dass dieses Schriftwerk verwerflich wäre - es gehört aber nicht in die Wikipedia (könnte allerdings anderweitig veröffentlicht werden und als Beispiel für die Kritik gegenüber XP referenziert werden, wenn eine gewisse Relevanz anerkannt wird).

Wie die Warnmarkierung andeutet, finden sich dort "einige subjektive Formulierungen". Diese spiegeln offensichtlich das wieder, was der/die Autor/in/n/en ausdrücken möchte - seine/ihre subjektive Kritik gegenüber XP. Außer den Formulierungen finden wir eigene Ausarbeitungen vor, die die ebenfalls eigenen Thesen unterstützen; aber Kritik als konkretes, objektives Faktum, das außerhalb des Artikels existiert, wird hier nicht behandelt. Somit dokumentiert dieser Abschnitt keine Tatsachen, sondern diese werden zur Meinungsäußerung verwendet. Aber letzteres ist in einem Wikipedia-Artikel genau fehl am Platz (siehe Wikipedia:Was_Wikipedia_nicht_ist, Punkt 4). Kurzum: Der Abschnitt selbst ist Kritik und dokumentiert nichts.

Einen eigenen Absatz in meiner Kritik möchte ich dem oben genannten Satz aus der Einleitung des Artikels widmen. Dieser Satz macht nicht bloß auf die Kritik aufmerksam, die weiter unten im Artikel steht. Er erweckt außerdem einen objektiven Eindruck, der der referenzierten Kritik zudem eine hohe Relevanz zuspricht (die im Artikel weder durch Literatur noch Medien belegt ist).

Mich wundert, dass ich in der Kritik-Seite zum Wikipedia-Artikel über das "Extreme Programming" keine Ausarbeitung über den "Kritik"-Abschnitt des Artikels finde. Ich könnte hier mit Floskeln und bildlichen Ausdrücken arbeiten, um das Problem, das ich im genannten Abschnitt sehe, einfacher zu verdeutlichen; aber ich vermute, das wäre hier fehl am Platz. Deshalb würde ich mich sehr freuen, wenn auf meine Kritik eingegangen würde (Änderung/Löschung genannten Textes oder weningstens eine Antwort hier auf der Kritik-Seite). (nicht signierter Beitrag von 141.99.254.253 (Diskussion) 02:54, 7. Sep. 2011 (CEST))

Redundanz

Prinzipien "Redundancy Yes, redundancy. The critical, difficult problems in software development should be solved serveral different ways. Even..." (Beck, Kent, Extreme Programming Explained, Embrace Change, Seite 31) Für Kritische Probleme sollen mehrere verschiedene Problemlösungen gefunden werden. Es handelt sich bei der Redundanz hier nicht um Codewiederholung.--Reality3001 16:12, 11. Jan. 2012 (CET)