Diskussion:Extreme Programming

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)

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)

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?

: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.

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!

2* optimiert

Allgemein: weniger Fremdwörter.

Da fäält 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)