Diskussion:Extreme Programming/Archiv/1

message: 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)
thread_title:  Diagramm 

message: Dem Artikel fehlt eindeutig ein klarer Aufbau. --PhilippW 19:44, 14. Jul 2005 (CEST)
replies: text: 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)
replies: text:  Man sagt aber auch Unseglich :-) -- schon gut! sparti 13:46, 25. Okt 2005 (CEST)
thread_title:  Überarbeiten 

message: Den folgenden Kommentar habe ich aus dem Artikel hierhin verschoben. --jpp ?! 21:22, 21. Jan 2006 (CET)
replies: text: Liest sich wie ein Werbeflyer --MartinSchwienbacher 00:59, 21. Jan 2006 (CET)
thread_title:  Kommentar aus Artikel hierhin verschoben 

message: 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)
thread_title:  Hervorragender Artikel 

message: Hier sollte auch erklärt sein, was User Stories sind und wie sie benutzt werden. Welche Inhalte sind empfehlenswert, welche nicht. Mit dem gegenwärtigen Text kann man so nichts anfangen. M.Buch
Da meine Änderung leider revertiert wurde, müssen wir wohl diskutieren. Warum muss die Schablone der User Story in solch holprigem Deutsch formuliert sein?
# Diese Schablone kann niemals korrektes Deutsch ergeben: „Als xxx, ich kann xxxx, um xxxx.“
# Diese dagegen schon: „Als xxx kann ich xxxx, um xxxx“.
Also, was spricht gegen Variante 2? --jpp ?! 16:29, 6. Jun 2006 (CEST)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  User Story Beispiel (Satzbau) 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Komplette Überarbeitung und Erweiterung 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Bilder 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text: Hervorragend, das sieht schon viel besser aus. --Haeber 16:36, 12. Jun 2006 (CEST)
thread_title:  Aufbau: zuviele Listen 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: Was verstehst Du denn daran nicht? Bitte Dich anmelden sowie sachlich und unemotional diskutieren. Danke.:-)--Michael Hüttermann 14:36, 18. Jun 2006 (CEST)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text:  Hi Jpp. Ich habe das noch ausführlicher erläutert. OK so?--Michael Hüttermann 16:20, 19. Jun 2006 (CEST)
replies: text:  Ä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)
thread_title:  Resonanz aufgrund der Lesenswert-Kandidatur, die hier garnicht hingehört 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text:  „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)
replies: text:  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)
thread_title:  Betriebswirtschaftliche Sicht 

message: 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)
thread_title:  Diagramm 

message: 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)
replies: text: "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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: Was verstehst Du denn daran nicht? Bitte Dich anmelden sowie sachlich und unemotional diskutieren. Danke.:-)--Michael Hüttermann 14:36, 18. Jun 2006 (CEST)
thread_title:  Oh mein Gott 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Informationsmanagement 

message: 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)
replies: text: Eindeutschung rausgenommen, fand ich auch blöd, wollte es aber erstmal retten, daher auch die kleine Anpassung. --Haeber 01:26, 21. Jun 2006 (CEST)
replies: text:  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)
thread_title:  Ehrlicher Umgang mit Kunden + und Eindeutschung 

message: 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)
replies: text:  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)
replies: text: Ich nehme eine Erklärung auf.--Michael Hüttermann 00:33, 22. Jun 2006 (CEST)
replies: text:  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)

text: 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)
replies: text: Das ist eine gute Idee. Boris Fernbacher 22:41, 21. Jun 2006 (CEST)

text: 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)
replies: text: 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)
replies: text: 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)

text: wird erledigt, danke.--Michael Hüttermann 22:20, 22. Jun 2006 (CEST)
thread_title:  Fachwörter 

message: 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)
replies: text: Ich habe das mal anders geschrieben und umgestellt. Besser so?--Michael Hüttermann 01:31, 22. Jun 2006 (CEST)
replies: text:  Jop, bin zufrieden, danke; gewinnt aber noch keinen Pulitzer. :-) --Haeber 02:22, 22. Jun 2006 (CEST)
replies: text:  -> 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)
replies: text:  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)

text: 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)
replies: text: So gesehen hast du recht. Da war ich wohl etwas zu spitzfindig. Boris Fernbacher 15:17, 22. Jun 2006 (CEST)

text: 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)
replies: text: Ist gut verständlich so. Boris Fernbacher 15:17, 22. Jun 2006 (CEST)
thread_title:  Sonstige Kleinigkeiten 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text:  Ich danke Euch beiden! Es gab schon sehr viele Verbesserungen. --Michael Hüttermann 02:13, 24. Jun 2006 (CEST)

text: Ich habe es umgeschrieben. Ist es besser so?--Michael Hüttermann 20:07, 26. Jun 2006 (CEST)
replies: text: Ist jetzt verständlicher. Boris Fernbacher 20:49, 26. Jun 2006 (CEST)

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

text: 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)
replies: text: 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)
replies: text:  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)
replies: text:  Okay, aktzeptiert. 2:1 entscheidet. Boris Fernbacher 20:49, 26. Jun 2006 (CEST)
replies: text:  Ist ja wieder super viel passiert heute. Mal schauen was noch im Review passiert. Danke. --Michael Hüttermann 00:59, 27. Jun 2006 (CEST)

text: Ich werde mich darum kümmern!--Michael Hüttermann 20:54, 28. Jun 2006 (CEST)
replies: text:  So ist es sehr gut. Synthese trifft die Sache auch gut.--Michael Hüttermann 00:37, 29. Jun 2006 (CEST)
thread_title:  ToDo 

message: 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)
replies: text: 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)
replies: text: Okay. Ging ja schneller als ich dachte. Problem gelöst würde ich sagen. Geo-Loge 20:58, 27. Jun 2006 (CEST)
replies: text: Untergliederung von dir in 1.1 und 1.2 finde ich gut. Boris Fernbacher 21:30, 27. Jun 2006 (CEST)
replies: text:  Sehr gute Idee! Allerdings haben wir dann zweimal sowas wie "Geschichte".--Michael Hüttermann 20:51, 28. Jun 2006 (CEST)
thread_title:  Operation "Schlanke Einleitung" 

message: 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)
replies: text: 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)
thread_title:  Allgemeine Einordnung in Bezug zu anderen Techniken 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text:  Nur der Umgang mit Kunden ist nach der XP-Philosophie kostenverursachend. . Wer sagt das denn?:)--Michael Hüttermann 17:46, 29. Jun 2006 (CEST)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Informationsmanagement, de zweite 

message: Eine User Story ist erst abgeschlossen, wenn alle seine Tasks abgearbeitet sind und die Tests geschrieben und alle erfolgreich durchlaufen sind. Der Demonstration dieser Vorgehensweise soll eine Tabelle mit Aufwandsabschätzungen in einer fiktiven Arztpraxis dienen.
 User Stories mit Aufwandsabschätzung in Story Points
Story No.	Story                                                                            	Abschätzung(Story Points)
1        	Als Arzt kann ich alle Patienten sehen, die ich am Tage habe.                    	3
2        	Als Arzt kann ich über die Gesundheitsgeschichte meiner Patienten Auskunft geben.	5
3        	Als Assistentin kann ich einem Patienten einen Termin geben.                     	3
4        	Als Assistentin kann ich einem Patienten eine Verschreibung ausdrucken.          	3
----
Boris weist in einem (neuen) Satz auf die Tabelle mit der fiktiven Arztpraxis hin. Dabei ist mir folgendes aufgefallen:
*Warum als Beispiel eine Arztpraxis? Warum nicht ein konkretes und einfaches XP-Projekt? 
*Warum haben fast alle Stories – mit einer Ausnahme – die selbe Abschätzung (Story Points), nämlich drei? Dieses Beispiel könnte man spritziger und „markanter“ gestalten.
:Gute Idee ! Ein IT-Besipiel wäre passender. Da könnte Michael mal in seine Fachbücher schauen. Da müsste doch ein schönes Beispiel zu finden (oder konstruieren) sein.  Boris Fernbacher 11:30, 6. Jul 2006 (CEST)
replies: text: Auch ohne Fachbuch kann ich dazu etwas sagen. Man könnte eine Story mit 1 abschätzen, eine andere noch mit 2. Warum als Beispiel keine Arztpraxis? Das ist ein Beispiel aus einem konkreten und einfachen XP-Projekt. Eine User Story ist die Beschreibung einer Funktionalität eines Software-Programmes. Jeder Arzt hat ein Software Programm, welches die Patienten verwaltet. Eine User Story hat mit einem IT-Beispiel nix zu tun, das ist die Beschreibung der Fachlichkeit. Boris' Erläuterung der Tabelle find ich gut.--Michael Hüttermann 21:44, 6. Jul 2006 (CEST)
replies: text: Tut mir leid, aber ich kann mit dieser Tabelle einfach nichts anfangen. Eine User Story ist erst abgeschlossen, wenn alle seine Tasks abgearbeitet sind und die Tests geschrieben und alle erfolgreich durchlaufen sind. Der Demonstration dieser Vorgehensweise soll eine Tabelle mit Aufwandsabschätzungen in einer fiktiven Arztpraxis dienen. Diese Tabelle demonstriert – meiner Meinung nach – nicht plausibel und überzeugend diese Vorgehensweise! (Boris' Erläuterung der Tabelle find ich auch gut.) In dieser Form sollte man diese Tabelle vielleicht ganz löschen; besser: ein „spritziges“ Beispiel entwerfen. Gruß -WortUmBruch 11:06, 7. Jul 2006 (CEST)
replies: text: Ja, klar. Dann ist das Beispiel und die Formulierung nicht verständlich genug. Sorry. Ich werde es überarbeiten.--Michael Hüttermann 23:02, 7. Jul 2006 (CEST)

text: Ich finde den Artikel insgesamt gut so. Weder zu Populäwissenschaftlich noch zu Wissentschaftlich. Deshlb mache ich auch nicht mehr groß dran rum. Gruß Boris Fernbacher 17:10, 9. Jul 2006 (CEST)
replies: text:  Ich bin mir sicher der Artikel hat einen Stand erreicht, der mindestens als lesenswert zu bezeichnen ist.--Michael Hüttermann 17:13, 9. Jul 2006 (CEST)
replies: text:  Meine ich auch. Dann stelle ich ihn jetzt mal zur Abstimmung ein. Boris Fernbacher 18:34, 9. Jul 2006 (CEST)
replies: text: Das "Rumgeficke" um dies Problem ist mir langsam zu doof ! Sagt es es doch ganz einfach, wenn euch was nicht passt. Ist es zu Populäwissenschaftlich, oder zu "Wissentschaftlich"  ???? Bedauerlicherweise ist der Ton der Diskussion inzwischen ein wenig befremdlich. O Freunde, nicht diese Töne! Wollte heute mit der weiteren Korrektur fortfahren, aber der Artikel befindet sind schon in der Kandidatur. Der Review war – meiner Meinung nach – nicht umsonst, leider aber zu kurz; und er hat auch neue Fehler „hervorgebracht“. Ich finde den Artikel immer noch nicht lesenswert, da zu viele Fehler und andere Schwächen, die ich an anderen Stellen bereits erwähnt habe. Nur ein Beispiel: Quellenangabe des folgenden Textes (Agile Manifest)?
 Individuen und Interaktionen haben Vorrang vor Prozessen und  Werkzeugen.
 Lauffähige Software hat Vorrang vor ausgedehnter Dokumentation.
 Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.
 Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.
Gruß -WortUmBruch 09:51, 10. Jul 2006 (CEST)

text:  Steht doch da: Agiles Manifest, siehe dazu auch die Referenzen unten. Also Du willst direkt auf exzellente Kandidatur gehen? Schau Dir doch mal vergleichbare Artikel an die offiziell lesenswert sind, da ist der hier am mindestens gleichwertig. Wenn Du meinst das ist nicht der Fall kannst Du ihn aber gerne auch wieder aus der kandidatur rausnehmen. Bzgl. "Rumgeficke" habe ich weiter unten auf Boris' Post was geschrieben, eins tiefer. --Michael Hüttermann 19:36, 10. Jul 2006 (CEST)
replies: text:  Zu: "Bedauerlicherweise ist der Ton der Diskussion inzwischen ein wenig befremdlich. O Freunde, nicht diese Töne!" -> Ich habe hier doch immer einen freundlichen Ton gepflegt, oder nicht ? Ich tippe mal, Michael hat das mit dem "Rumgeficke" nicht so unfreundlich gemeint, wie es wirkt. Gruß Boris Fernbacher 10:04, 10. Jul 2006 (CEST)
replies: text:  Bitte? Du bist mir vielleicht ein Spaßvogel! Wenn Du nudeldicke(?) nachts um 4 Uhr solche Sätze hier reinschreibst dann steh auch dazu und schieb das nicht auf mich. Ich hätte das an Deiner Stelle ja einfach so unkommentiert stehen lassen. Ein einfacher Blick in die History zeigt: http://de.wikipedia.org/w/index.php?title=Diskussion%3AExtreme_Programming&diff=18772998&oldid=18732207 --Michael Hüttermann 19:36, 10. Jul 2006 (CEST)
replies: text:  Aua, das ist von mir. Habe ich ganz vergessen. Tut mir echt leid Michael. Waren wohl ein, zwei Bier zuviel. Da quasselt man halt so vor sich hin. Entschuldigung. Ich dachte echt das ist von dir. Gruß Boris Fernbacher 19:49, 10. Jul 2006 (CEST)
replies: text:  :-))))))))) --Michael Hüttermann 20:11, 10. Jul 2006 (CEST)
replies: text:  Ich weiß zwar nicht, was die vielen Klammern bedeuten sollen. Hatte aber echt vergessen, dass der Mist von mir ist. Boris Fernbacher 20:16, 10. Jul 2006 (CEST)
replies: text:  Ach so. Das ist ein Smiley: :-). Das schreibt man wenn man gerade lacht. Und wenn man richtig dolle herzhaft lachen muss, dann hängt man noch ein paar ")" dran. Je mehr desto mehr lacht man. :-) --Michael Hüttermann 20:25, 10. Jul 2006 (CEST)
replies: text:  Alles klar. Hoffe es war kein Fehler den Artikel mal in die Abstimmung zu stellen. Meiner Meinung nach ist der nämlich schon ganz gut. Gute Nacht Boris Fernbacher 20:30, 10. Jul 2006 (CEST)
thread_title:  Tabelle/Aufwandsabschätzung 

message: Ich habe nur begrenzte Erfahrung (mehr Theorie als Praxis) mit XP. Ich habe mir erlaubt folgenden Satz in "Grundlagen" zu ändern:
"Kommunikation ist eine Grundsäule (siehe Werte) dieses Vorgehensmodells. Sollte die Kommunikation eines Teams gestört sein oder vom Chef unterdrückt werden, kann XP nicht funktionieren."
Damit soll dem Leser relativ früh klar werden, das die fünf Grundsäulen (siehe Werte) für XP unumgänglich sind. Fehlt Kommunikation in einem Team, hat kein Programmier den Mut schlechte Strukturen anzusprechen oder zu ändern, dann ist XP meiner Meinung nach zum Scheitern verurteilt. 
Der Artikel sollte über "Nutzen" klar machen, was man alles gewinnen kann (mit dem Einsatz von XP), aber im Sinne der Objektivität sollte nach Lesen des Artikels auch klar sein, was für Anforderungen XP hat. XP wird schwierig umzusetzen, wenn z. B. gilt: "Wir dürfen in unserer Firma nicht streiten und Struktur- und Organisationsprobleme nicht offen ansprechen. Der Kunde darf von Problemen auf keinen Fall etwas mitbekommen, lieber anlügen!"
Das (bestehende) Kunden belogen wurden (CeBit fällt mir da sofort ein) ist mir schon oft begegnet. 
Ich könnte den Artikel auch noch in zwei, drei Sätzen bei "Kommunikation" mit bekannten Modellen von Friedmann Schulz von Thun ergänzen und darauf hinweisen, wie wichtig eine ehrliche Analyse der eigenen Kommunikationsstrukturen ist, bevor man XP einsetzt. Man stelle sich eine Firma von Einzelkämpfer und/oder Eigenbrödlern vor, die auch darauf bedacht waren, ihr Wissen für sich zu behalten. Drei Freunde von mir (ausnahmslos gute bis sehr gute Programmierer) gingen mit Ihrer Firma insolvent, weil selbst wichtigste Themen tot geschwiegen wurden und somit Entscheidungen über die Zukunft der Firma ausblieben. Alleine "Pair Programming" einzuführen, hätte intensives Training und vielleicht auch ein paar Kommunikationsseminare erfordert. --ClausVB 22:07, 27. Jul 2006 (CEST)
thread_title:  Komponente "Kommunikation" erweitern 

message: Viel besser als früher.
Meine Kritik am Artikel (nach kurzem überfliegen):
* Zu lang, keine Zeit, ihn komplett zu lesen. In der Kürze liegt die Würze.
: --> glaub ich nich. will nich gezwungen amputieren.
* Die Aufwandskurve ist falsch, weil sie suggeriert, XP sei ein Wasserfall.
: --> ist nich falsch.
* Innerhalb des Entwicklungsteams darf es Rollentrennung geben, solange sie nicht nach Code ist.
: --> bitte?
* Die speziellen Entwickler-Rollen Tracker und Coach fehlen.
: --> könnte man noch ergänzen, ja.
* Ist Product Owner im XP-Prozess wirklich eine Rolle neben dem Kunden?
: --> orthogonal zum Kunden.
* Ist User im XP-Prozess wirklich eine Rolle neben dem Kunden?
: --> orthogonal.
* XP-Release != XP-Iteration.
** Release: Zyklus von 2-6 Wochen
** Iteration: einzelner Implementierungszyklus zur Abarbeitung einer User-Story, meist 2-4 Tage.
** Mehrere Iterationen (User-Story-Implementierungen) zusammen bilden ein Release.
: --> hmm?
* Respekt als XP-Wert: Ich befürchte, dass das für diesen Wikipedia-Artikel hinzuerfunden wurde. (Nichts gegen Respekt, Respekt ist wichtig!)
: --> Ich bitte Dich, ich erfinde doch nichts dazu nur für einen Artikel
* "10-Minuten-Build": Noch mehr hervorheben, dass das bereits eine umfangreiche Testsuite einschließt.
: --> dann wirds ja noooooooooch länger
* Der Aspekt der Einfachheit von XP geht in der Länge des Artikels unter.
: --> XP propagiert zwar Einfachheit, dennoch ist XP schon als komplex zu bezeichnen. Einfachheit wurde an mehreren Stellen erläutert.
Diese Kritik soll dazu beitragen, einen _bereits guten Artikel_ noch besser zu machen. Ich habe den Artikel kaum wiedererkannt, im vollständig positiven Sinne. In dem jetzigen Zustand bekomme ich sogar Lust, selbst wieder etwas daran zu arbeiten. Danke an Michael Hüttermann, weiter so! --ChristianHujer 00:46, 10. Aug 2006 (CEST)
replies: text: --> Gute Idee! Für weitere Optimierungen bin ich immer zu haben. Danke für das Lob. --Michael Hüttermann 01:52, 12. Aug 2006 (CEST)
thread_title:  Zu lang 

message: Hallo,
ich kann mir gut vorstellen, dass XP in der Praxis vom Ideal immer etwas abweicht. Immer abhängig von der Organisationsstruktur des Unternehmens, des Projekts, etc. Angenommen in einem Unternehmen ist ein angebrachtes Vorgehen in groben Zügen überlegt worden und man möchte nun wissen, ob es eher dem einen oder dem anderen Vorgehensmodell entspricht, was könnte man sagen, sind die grundlegenden Elemente des XP ? Z.B. ist Pair-Programming immer erforderlich oder kann auch eine Vorgehensweise, die Pair-Programming nicht vorsieht noch als XP bezeichnet werden ?
: Wer spricht denn da? Das wird im Artikel thematisiert. XP muß dort angepasst werden, wo es die individuellen Projektgegebenheiten notwendig machen. Eine Gewichtung von Prinzipien und Praktiken ist generell schwierig vorzunehmen. Dies wurde aber insofern gemacht, als dass die Primärpraktiken die grundlegenderen sind und die Sekundärpraktiken eher die optionalen AddOns. Das Wichtigste sind aber letztendlich die Werte. --Michael Hüttermann 00:02, 5. Dez. 2006 (CET)
thread_title:  Basismerkmale 

message: Unter Aufbauorganisation steht in der Tabelle:
* Projektmanager kann … nicht Manager des Teams sein
* Aufgaben: Führung des Teams
Klingt für mich erklärungsbedürftig. Also der Manager des Teams führt das Team nicht? 
--Björn Klippstein 19:50, 19. Sep. 2007 (CEST)
thread_title:  Der Manager des Teams führt das Team nicht? 

message: Ebenfalls unter Aufbauorganisation:
Verstehe ich es richtig: Der "Leiter" ist offenbar der gleiche, der später immer als "Product Owner" bezeichnet wird und woanders meistens "Projektleiter" heißt, richtig? Dann würde ich vorschlagen, entweder den einen Begriff oder den anderen zu verwenden. 
Der jedenfalls trägt die Verantwortung. Aber er kann auch der Kunde sein, so steht es in der Tabelle gleich zweimal. In welcher Konstellation aber kann es passieren, 
dass der Kunde selbst die Verantwortung dafür trägt, dass seine Software erfolgreich entwickelt wird? Dem Abschnitt mangelt es an Klarheit. --Björn Klippstein 20:07, 19. Sep. 2007 (CEST)
thread_title:  Der Kunde ist selbst verantwortlich für sein Projekt? 

message: Bei mehreren automatisierten Botläufen wurde der folgende Weblink als nicht verfügbar erkannt. Bitte überprüfe, ob der Link tatsächlich unerreichbar ist, und korrigiere oder entferne ihn in diesem Fall!
* http://www.objectmentor.com/ourCustomers/index (archive)
** In Extreme Programming on 2008-04-08 20:35:42, 404 Not Found
** In Extreme Programming on 2008-04-21 19:02:53, 404 Not Found
Die Webseite wurde vom Internet Archive gespeichert. Bitte verlinke gegebenenfalls eine geeignete archivierte Version: . --SpBot 21:00, 21. Apr. 2008 (CEST)
replies: text: Habe den Link auf’s Internetarchiv umgebogen. --j ?! 13:16, 23. Apr. 2008 (CEST)
thread_title:  Toter Weblink 

message: Bei mehreren automatisierten Botläufen wurde der folgende Weblink als nicht verfügbar erkannt. Bitte überprüfe, ob der Link tatsächlich unerreichbar ist, und korrigiere oder entferne ihn in diesem Fall!
* http://www.ddj.com/dept/architect/184414801C2
** In Extreme Programming on 2008-04-08 20:35:44, 404 Not Found
** In Extreme Programming on 2008-04-21 19:03:02, 404 Not Found
--SpBot 21:00, 21. Apr. 2008 (CEST)
replies: text: Habe den Link korrigiert, und bei der Gelegenheit auch gleich das Erscheinungsdatum. --j ?! 13:12, 23. Apr. 2008 (CEST)
thread_title:  Toter Weblink 

message: Sowohl Eigenheiten in der Aufbauorganisation als auch die Komplexität und Anforderungen an die zu entwickelnde Funktionalität lassen sich mit XP bei qualifizierter Wahrnehmung der Risiken meistern.
In Anbetracht der Laenge der Diskussion stelle ich das zuerst zur Debate (wuerde das gerne entfernen). Klingt wie ein "Allheilmittel" (bei entsprechender "qualifizierter Wahrnehmung"). Da XP und deren "Errungenschaften" immer noch als umstritten gelten, halte ich das fuer unpassend so zu formulieren. Traute Meyer 01:19, 7. Okt. 2008 (CEST)
replies: text:  Hallo Traute Meyer, du hast völlig recht, das ist nur sales talk.  Bei "qualifizierter Wahrnehmung der Risiken" lässt sich mit jeder Technik alles meistern. Raus mit dem Satz! --Herbert Klaeren 08:14, 7. Okt. 2008 (CEST)
thread_title:  Kritik 

message: Hallo,
ich habe diesen Artikel soeben durchgelesen. Da ich mich selbst intensiv mit (der Leitung von) Software-Entwicklungsprojekten auseinandergesetzt habe und auch seit vielen Jahren in diesem Bereich tätig bin, muss ich sagen, dass mich der Artikel doch insgesamt sehr enttäuscht hat, insbesondere da er das Prädikat "Lesenswert" erhalten hat. 
Zwar wurden doch hier und da Relativierungen der von XP angestrebten Vorteile eingebaut ("durch XP soll xyz erreicht werden" usw.), jedoch ist es für jeden neutralen Leser offensichtlich, dass die Mehrzahl der Autoren diesem Ansatz sehr positiv gegenüber stand und bestrebt war, ihn möglichst idealisiert darzustellen. Die Kritik beschränkt sich auf einen minimalen Absatz. Zudem wurden den einzelnen Kritikpunkten unmittelbar wieder Gegenargumente nachgestellt, so als habe XP auf fast jeden Einwand eine passende Antwort.
Ich habe mich daher entschieden, in diesen Artikel einen Neutralitäts-Baustein einzupflegen und bin auch gegen den vermutlich nun aufbrausenden ideologischen Ansturm der XP-Verfechter gewillt, diesen zu verteidigen, bis der Artikel die aus meiner Sicht unbedingt erforderlichen Eigenschaften aufweist:
* Es sollte herausgearbeitet werden, ob es heute irgendwelche wissenschaftliche (d.h. auf Studien basierende) Evidenz für die postulierte Überlegenheit dieses Entwicklungsansatzes gibt. Falls solche Studien nicht vorliegen, sollte an prominenter Stelle darauf verwiesen werden, dass die Wirksamkeit dieses Ansatzes bis heute nicht nachgewiesen ist. Auch wären Studien interessant, die ggf. das Scheitern des Ansatzes zeigen.
* Die Kritik sollte in einen eigenständigen Abschnitt auf höchster Ebene verlegt werden, zumal im Abschnitt "Diskussion" viele Teilabschnitte enthalten sind, die mit Diskussion gar nichts zu tun haben.
* Die einzelnen Kritikpunkte sind weiter auszuarbeiten. Fehlende Kritikpunkte sollten ergänzt werden. Insofern Kritikpunkte Gegenargumenten gegenübergestellt werden, sollte es nicht so aussehen, als sei die Kritik damit ausgeräumt. Wenn es tatsächlich eine Diskussion der einzelnen Kritikpunkte gibt, so kann diese in entsprechend besser ausgearbeiteten Unterabschnitten behandelt werden, statt einfach nur so zu tun als habe XP für alles ein Rezept.
* Es sollte klar aus dem Artikel hervorgehen, unter welchen Voraussetzungen ein XP-Ansatz funktionieren kann. Ich schlage hierzu einen Abschnitt "Voraussetzungen" vor.
Ich werde mich gerne nach und nach an diesen Arbeiten beteiligen, bitte aber um Verständnis, wenn mir die Zeit fehlt, dies in vielstündigen Sitzungen in sehr kurzer Zeit zu tun. Vielmehr werde ich immer wieder Einzelheiten einbringen. Um nochmal dem ideologischen Ansturm der Entrüstung vorzugreifen, bitte ich um eine sachliche Diskussion. Durch falsch verstandenes Software-Engineering wird Jahr für Jahr viel Geld und Zeit vergeudet. Das Thema ist daher zu ernsthaft, um es einer bloßen Begeisterung für das Thema zu überlassen. Eine ingenieursmäßige Abwägung und Darstellung ist daher dringend erforderlich. -- Mkleine 13:36, 10. Nov. 2008 (CET)
replies: text: Nach Ausarbeitung des Kritik-Abschnitts habe ich den Baustein wieder entfernt. -- Mkleine 03:57, 13. Nov. 2008 (CET)
thread_title:  Nicht lesenswert, sondern tendenziös, daher Neutralitäts-Baustein 

message: Leider verstehe ich nicht, was "attribuiert" im Abschnitt Der ideale Programmierer heißt. WIKTIONARY kennt das Verb "attribuieren" auch nicht. Grüße! --Bukk 11:54, 1. Jul. 2009 (CEST)
replies: text: ich stimme dir zu, es ist eine völlig unnötige Verwendung eines lateinischen Worts. 'attribuere' heisst 'zuteilen, zuordnen', ich formuliere den entsprechenden Satz gleich mal so um, dass er nicht so gespreizt daherkommt. --Herbert Klaeren 14:05, 1. Jul. 2009 (CEST)
replies: text: Hallo, Herbert Klaeren! Das ist gut! Und schnell ging es auch. Grüße! --Bukk 15:41, 1. Jul. 2009 (CEST)
thread_title:  Wortwahl "attribuiert" 

message: Ein wenig scheint mir der Kritik Abschnitt einen Geschmäckle zu haben. Während mir viele Teile der Kritik durchaus schlüssig erscheinen finde ich Argumente wie "Programmierer haben ein großes Ego, deshalb ist eine Methode in der jeder alles ändern darf doof." oder "XP erfordert Disziplin von den Programmierern, da sie alles im Pair programmieren sollen." doch eher etwas holprig. Natürlich erfordert XP ein Stück Selbstlosigkeit und auch Disziplin usw, aber es geht doch auch nicht darum, dass es sowas wie der lustig pinke Gummibärchen Trunk der Softwareentwicklung ist. Auch das Argument es sei schwierig Kunden und Programmierer zu finden, für die XP funktioniert halt ich für richtig aber absolut nicht kritikwert. Wenn eine Methode für ein Team oder einen Kunden nicht passend ist kann ich sie nicht benutzen. Dieser Kritikpunkt ist meines Erachtens nach nur haltbar wenn XP irgendwo nachweisbar den Anspruch erhebt die Methode zu sein, die IMMER funktioniert. Wenn ich richtig informiert bin ist aber genau dies nicht der Fall, viel mehr habe ich das Gefühl, dass gerade die Macher von XP immer wieder betonen, dass "ihre" Methode für sie gepasst hat und passt aber sicher nicht für jeden geeignet ist.
Mein Wissen über XP reicht leider nur bis zur nächsten Ecke, ich fände es aber toll wenn jemand mit etwas mehr Sachverstand den Kritik Abschnitt einmal auf seine Schlüssigkeit prüfen könnte.
Thorben --134.102.117.51 02:26, 20. Jul. 2009 (CEST)
thread_title:  Objektivität? 

message: ... ist nach einem Artikel im Spiegel mit Methoden des Extreme Programming hergestellt worden. Bei VISTA lief MS mit konventioneller Programmierung in die "Komplexibilitätsfalle" und erhielt einen hochgradig mit Fehlern durchsetzten Code. Grüße! --Bukk 10:16, 20. Jul. 2009 (CEST)
replies: text: wenn mans genau liest, ist eigentlich nur das "pair programming" verwendet worden, von allen anderen Ingredienzien des XP ist bei Microsoft keine Rede.  Der Artikel redet trotzdem stellenweise über XP, aber dann ohne direkten Bezug zu W7. --Herbert Klaeren 13:11, 20. Jul. 2009 (CEST)
thread_title:  Windows 7 ... 

message: Gleich im ersten Satz wird XP als "agile Methode" bezeichnet, das widerspricht aber der Definition von Methode im Artikel Agile Softwareentwicklung. Um mit diesem Artikel konsistent zu bleiben, sollte das auf "agiler Prozess" geändert werden. Oder man verwendet das Wort "Methodik".
: dieser Einwand (unbekannten Datums) hat sich offensichtlich längst erledigt. --Herbert Klaeren 08:31, 4. Feb. 2010 (CET)
thread_title:  Methode, Methodik oder Prozess ? 

message: Zitat: "XP erweist sich insofern in gewisser Weise als immun gegen Kritik – es ist, wissenschaftlich gesprochen, kaum falsifizierbar." – Abgesehen davon, dass diese Ausssage nicht bequellt ist, wundere ich mich über ihren Inhalt. Ob wissenschaftlich falsifiziert werden kann oder nicht, ist doch eine Frage, die sich auf Theorien bezieht, nicht aber auf Arbeitsmethoden. Im Artikel wird Extreme Programming ausschließlich als Methode, nicht als Theorie definiert. (Ich stehe dem Thema übrigens neutral gegenüber.) --Suaheli 01:05, 4. Feb. 2010 (CET)
replies: text: da hast du recht, dieser Satz ist unsinnig. Ich lösch ihn mal raus... --Herbert Klaeren 08:35, 4. Feb. 2010 (CET)
thread_title:  Immun gegen Kritik? 

message: :Programmierer weisen oftmals ein recht ausgeprägtes Ego auf, das sich in großer Überzeugung von „richtigen Lösungen“ und einem gewissen Besitzdenken hinsichtlich des geschriebenen Codes äußert.
Das klingt eigenartig nach so alten Asperger-Computernerd-Vorurteilen. Es ist wohl den meisten Menschen zueigen, unabhängig vom Beruf. Darum würde ich vorschlagen, z.B. die folgende, etwas neutralere Formulierung zu wählen:
:Fachleute zeichnen sich häufig durch die Überzeugung von „richtigen Lösungen“ und einem gewissen Besitzdenken hinsichtlich ihrer Erzeugnisse aus.
Oder so ähnlich. Ja ich weiß, ist nicht besonders wichtig, aber auch auf Kleinigkeiten kommt es an. --82.83.59.83 07:55, 4. Apr. 2010 (CEST)
replies: text:  Ironischer Weise wurde eben dieser Absatz als Abhilfe gegen mangelhafte Neutralität und gegen tendentiöse Formulierungen hinzugefügt. Der neue Vorschlag liest sich zwar besser, aber letztlich ist das auch nur eine Behauptung, die sich allenfalls im privaten Umfeld bestätigen oder widerlegen lässt – es sei denn, das wurde mal untersucht. Ich bin für restloses Streichen. Überhaupt ist der ganze Abschnitt ohne Quellen, also potentiell die persönliche Meinung eines beliebigen, anonymen Autors. Eigentlich dürfte der Artikel längst nicht mehr lesenswert sein. --Zahnradzacken 16:34, 4. Apr. 2010 (CEST)
thread_title:  Menschliche Schwächen 

message: Im Artikel heißt es: Des Weiteren muss er auf eine formale Festlegung der Projektinhalte (Spezifikation) sowie auf eine Dokumentation der realisierten Software verzichten. >>> Während die erste Behauptung (Nichtexistenz formaler Spezifikation) ja noch zwangsläufig irgendwie wahr sein dürfte, kann ich die zweite Behauptung (Nichtexistenz einer Dokumentation) nicht nachvollziehen: Sprachen wie Java bieten die Möglichkeit, am Ende jedes Entwicklungstages die aktuelle Dokumentation via javadoc automatisiert zu erstellen... und das ist prinzipiell auch relativ einfach für beliebige Sprachen und Umgebungen machbar. Warum soll es also angeblich keine Doku geben? --85.179.197.44 19:53, 13. Apr. 2010 (CEST)
replies: text: Javadoc dokumentiert den Programmcode, nicht die Endanwendung des Programms. Der Autor des obigen Zitats meinte vermutlich eine Dokumentation für den Endanwender, wie etwa "Zum Kaffeekochen roten Knopf drücken"; nächste Woche könnte es ja der blaue sein, daher erst gar nicht dokumentieren :-) -- Der Artikel ist leider so nebulös wie sein Lemma. --Suaheli 23:54, 13. Apr. 2010 (CEST)
replies: text: Falls der Endanwender gemeint ist, müsste es dann also heißen: "Doku kann erst bei Projektende erstellt werden!" - und nicht: "Doku kann nicht erstellt werden!" Ansonsten: Wieso soll das Lemma (und der Artikel) denn "nebulös" sein? --85.177.143.232 00:47, 16. Apr. 2010 (CEST)
thread_title:  Formale Spezifikationen und Dokumentation 

message: Im Folgenden möchte ich Kritik gegenüber dem Abschnitt "Kritik" und den Verweis auf diesen Im Einleitungssatz äußern ("Die Wirksamkeit des Ansatzes ist umstritten (siehe Abschnitt Kritik).").
Dabei möchte ich betonen, dass das nicht heißen soll, dass dieses Schriftwerk verwerflich wäre - es gehört aber nicht in die Wikipedia (könnte allerdings anderweitig veröffentlicht werden und als Beispiel für die Kritik gegenüber XP referenziert werden, wenn eine gewisse Relevanz anerkannt wird).
Wie die Warnmarkierung andeutet, finden sich dort "einige subjektive Formulierungen". Diese spiegeln offensichtlich das wieder, was der/die Autor/in/n/en ausdrücken möchte - seine/ihre subjektive Kritik gegenüber XP. Außer den Formulierungen finden wir eigene Ausarbeitungen vor, die die ebenfalls eigenen Thesen unterstützen; aber Kritik als konkretes, objektives Faktum, das außerhalb des Artikels existiert, wird hier nicht behandelt. Somit dokumentiert dieser Abschnitt keine Tatsachen, sondern diese werden zur Meinungsäußerung verwendet. Aber letzteres ist in einem Wikipedia-Artikel genau fehl am Platz (siehe Wikipedia:Was_Wikipedia_nicht_ist, Punkt 4). Kurzum: Der Abschnitt selbst ist Kritik und dokumentiert nichts.
Einen eigenen Absatz in meiner Kritik möchte ich dem oben genannten Satz aus der Einleitung des Artikels widmen. Dieser Satz macht nicht bloß auf die Kritik aufmerksam, die weiter unten im Artikel steht. Er erweckt außerdem einen objektiven Eindruck, der der referenzierten Kritik zudem eine hohe Relevanz zuspricht (die im Artikel weder durch Literatur noch Medien belegt ist).
Mich wundert, dass ich in der Kritik-Seite zum Wikipedia-Artikel über das "Extreme Programming" keine Ausarbeitung über den "Kritik"-Abschnitt des Artikels finde. Ich könnte hier mit Floskeln und bildlichen Ausdrücken arbeiten, um das Problem, das ich im genannten Abschnitt sehe, einfacher zu verdeutlichen; aber ich vermute, das wäre hier fehl am Platz. Deshalb würde ich mich sehr freuen, wenn auf meine Kritik eingegangen würde (Änderung/Löschung genannten Textes oder weningstens eine Antwort hier auf der Kritik-Seite). (nicht signierter Beitrag von 141.99.254.253 (Diskussion) 02:54, 7. Sep. 2011 (CEST)
thread_title:  Abschnitt "Kritik" 

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