Diskussion:Extreme Programming/Archiv/2

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Extreme Programming/Archiv/2#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Extreme_Programming/Archiv/2#Thema_1

Abschnitt "Projektsicht"

"...die den größten Nutzen haben und das größte (technische) Risiko beinhalten."

Beginnt man nicht besser mit dem größten Nutzen bei kleinstem Risiko? Das stellt sicher, dass man dem Nutzer schnellstmöglich großen Nutzen verschafft. Wenn man hingegen (bei gleichem Nutzen) mit dem schwierigeren beginnt, muss der Kunde vmtl. länger warten. Vorteil wäre vmtl., dass man eher "die richtige Struktur trifft", wenn man mit komplex-first arbeitet.

--129.247.247.238 11:59, 19. Feb. 2013 (CET)

Es hat schon durchaus seinen Sinn, mit dem Aspekt anzufangen, in dem das größte Risiko steckt.

Wenn sich beim Versuch der Realisierung herausstellt, dass dies überhaupt nicht oder nur mit extremem Aufwand und nicht stabil implementierbar ist, dann kann man in einer Frühphase abbrechen oder sich eine neue Strategie ausdenken.

Fängt man hingegen mit lauter banalem Klein-Klein an und schiebt die größten Brocken und Schwierigkeiten vor sich her, merkt man erst kurz vor Ende, dass wesentliche Voraussetzungen nicht umsetzbar sind. Dann hat man viel Mühe in bunte Formatierung gesteckt, und steht trotzdem bei Null.

Liebe Grüße --PerfektesChaos 13:17, 19. Feb. 2013 (CET)

Wenn das "viele Klein-Klein" aber bereits "großen Nutzen" bringt, kann man kaum von "bei Null stehen" reden.

Ich stimme allerdings zu, dass ein solches Vorgehen dazu verführen könnte, auch "Klein-Klein"-Zeug zu implementieren, das eigentlich nur mäßigen oder eher geringen Nutzen bringt, solange man den "großen Brocken" noch ein wenig aufschieben kann.

Aber wenn es 2 Aspekte gibt, die beide als von-gleich-großem-Nutzen gelten, warum dann nicht das einfache (sehr schnell) zuerst, und das schwierige (das viel länger dauert) erst danach?

--arilou (Diskussion) 17:01, 19. Feb. 2013 (CET)

PS: Nett wär' auch 'ne Quelle, dass im XP das Komplizierte auf jeden Fall vorzuziehen ist...

Allgemein + Abschnitt Kritik

Hier fehlt eine klare Abgrenzung zu alternativen Agilen Methoden. Desweiteren sollte recherchiert werden, welche Praktiken explizit ebenfalls von Scrum genutzt werden.

Da in der Praxis stets Teile von XP verwendet werden, ist die Kritik "Alles-oder-Nichts" fehl am Platz

--Tristan301 (Diskussion) 20:33, 24. Jun. 2013 (CEST)

Einfach vs. Kompliziert

ME ist der Satz: „Die Lösungen sind technisch immer möglichst einfach zu halten“, zu schwammig formuliert. Ich verstehe bei besten Willen nicht, aus wessen Sicht er formuliert ist, der des Softwareentwicklers oder der des Anwenders. Häufig gibt es gerade in diesem Punkt häufig Differenzen:

• Als IT-Mensch kann man auf der Commandline oft weniger umständlich agieren. Für andere stellt diese aber häufig eine ziemliche Hürde dar.
• Intuitiv bedienbare Oberflächen sind für die Entwicklung meist ein zusätzlicher Aufwand.

Die Formulierungen enthalten das Wort einfach bewusst nicht, denn es bezieht Subjektivität in die Aussage mit ein. --Marco74 (Diskussion) 17:08, 10. Nov. 2013 (CET)

Schreibweisen

In dem Artikel sind einige englische Fachbegriffe in unterschiedlicher Schreibweise zu finden. Ein Vereinheitlichung wäre sinnvoll. Beispiel: User Story, Mehrzahl: User Stories (diese Schreibweisen scheinen sich durchgesetzt zu haben)

Schreibweisen im Text (bislang): User Story, User-Story, User Stories, User-Stories, User Storys (nicht signierter Beitrag von 92.230.77.232 (Diskussion) 09:42, 18. Mär. 2014 (CET))

Richtig; aber: Laut Duden ist der Plural von "Story" im dt. "Storys".

Und zusammengesetzte Nomen brauchen mindestens einen Bindestrich dazwischen, oder man schreibt sie zusammen in einem Wort.

Habe daher alle Nennungen auf "User-Story" / "User-Storys" gesetzt.

--arilou (Diskussion) 10:34, 18. Mär. 2014 (CET)

Der Fachbegriff ist aber User Story, auch wenn dieser nicht im Duden aufgeführt ist (allerdings gibt es dort auch Short Story als Begriff; somit muss nicht zwangsläufig ein Bindestrich zwischen den Nomen eingeführt werden). Auch die Schreibweise "User Stories" hat sich in der Praxis und der (deutschen) Fachliteratur durchgesetzt. Warum sollte hier die Wikipedia HIER (nur bei XP) eigene Schreibweisen verwenden? Im Beitrag zu Scrum wird "User Story" und "User Stories" verwendet. (nicht signierter Beitrag von 92.230.240.138 (Diskussion) 11:45, 20. Mär. 2014 (CET))

1. "Der Fachbegriff ist aber User Story" - das ist zunächst mal eine Behauptung. "User-Story" wird sicherlich ebenfalls verwendet.
2. Im Gegensatz zu "User" ist "Short" kein im Duden verzeichneter deutscher Begriff; "Short Story" ist eine Zusammensetzung eines englischen Adjektivs ("Short") mit einem eingedeutschen "Story". Hier empfielt der Duden übrigens explizit für den Plural die deutsche "Storys" -Schreibweise, also nicht-ies.
3. Was andere Artikel (Scrum) noch veraltet/falsch machen, ist kein Grund, es hier ebenfalls so zu machen. Vielleicht gehört's ja dort geändert?

--arilou (Diskussion) 12:28, 20. Mär. 2014 (CET)

Alle deutschen Fachbuch-Autoren (!!) verwenden "User Story" und "User Stories". Soll man diese jetzt allesamt einmal anschreiben und auf ihren Fehler hinweisen? Warum hier eine eigenständige "Wikipedia-Schreibweise" eingeführt werden soll, bleibt schleierhaft, gerade bei solch etablierten Begriffen. (nicht signierter Beitrag von 92.230.247.14 (Diskussion) 09:38, 21. Mär. 2014 (CET))

Prinzipien

"Redunanz vermeiden" ist falsch. Es muss einfach nur Redundanz heißen. 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.

Einfach mal gelöscht, ohne Kommentar. Nur weil das Wort Redundanz beim Informatiker gleich Kopfschmerzen auslöst. (nicht signierter Beitrag von Reality3001 (Diskussion | Beiträge) 16:02, 2. Sep. 2014 (CEST))

Ursprung und Abgrenzung

Der Abschnitt nach der Tabelle halte ich so wie er da steht für überflüssig. Es ergeben sich keine neuen Informationen zu XP oder zumindest der Bezug ist unklar. Freimatz (Diskussion) 15:51, 18. Sep. 2014 (CEST)

Struktur des Artikels ist ungünstig

Ich erwarte bei einem Artikel ein Einführung mit Infos zum Hintergrund. Die Geschichte/Herkunft von XP wird aber als letztes Beschrieben. Wenn ich wissen will wer wann mit XP angefangen hat, muss ich das erst suchen. Hier sollte man nochmal umstrukturieren. Auch der Hinweis der "Umstrittenheit" am Anfang ist sehr wertend. Das müsste man dann bei allen Methoden hinschreiben.

Die deutliche unmissverständliche Wertung ist klar gegen WP:NPOV. Da hat jemand seine persönliche Meinung hineingetragen, anstatt rein sachlich zu bleiben. pfuui, soll der doch einen blog machen! --93.184.30.196 15:23, 7. Dez. 2015 (CET)

Heute ...

"Heute, über zehn Jahre nach den ersten XP-Schritten, erfreuen sich XP und andere agile Methoden wachsender Beliebtheit." Über 10 Jahre kann natürlich auch 30 Jahre sein, aber wann war aus Wikipedias bzw. des Autors Sicht "heute"? --37.24.17.180 20:53, 13. Mai 2019 (CEST)

Mangel an Quellen, Objektivität und Neutralität (Abwertungen): Abschnitt Kritik

Der Abschnitt "Kritik" scheint mir grundsätzlich neugeschrieben oder vorübergehend gar gelöscht werden zu müssen:

1. Der Abschnitt führt keinerlei Quellen an.
2. Er referenziert sich selbst: »[…] (siehe z. B. die Abschnitte Der ideale Kunde und Der ideale Programmierer)«
3. Er liest sich ausnahmslos als eine persönliche Argumentation statt als die nüchterne Wiedergabe öffentlicher, insbesondere jemals veröffentlichter Kritikpunkte. Keine Dritte-Person-Perspektive erkennbar.
4. Einige Passagen sind zudem wertend und gar abwertend. Das deutlichste Beispiel: »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.«

Mangels externer Referenzen scheint es mir nicht ohne weiteres möglich, den Abschnitt einfach zu überarbeiten (zu "entschärfen"). Ich empfehle eine Karenzzeit, um Raum zur Überarbeitung zu geben, und danach notfalls das Löschen des gesamten Abschnittes zur Qualitätssicherung Wikipedias. --David Schopenhauer (Diskussion) 19:36, 5. Jul. 2019 (CEST)

Zustimmung - ein solch langer belegloser Abschnitt sollte zum Entzug der Lesenswert-Auszeichnung führen. Die Kritik wurde im November 2008 eingefügt - über zehn Jahre Karenzzeit haben wir schon hinter uns. Der Autor ist seit vier Jahren nicht mehr in Wikipedia aktiv. Zügig raus damit. Grüße, --Schotterebene (Diskussion) 09:10, 6. Jul. 2019 (CEST)