Diskussion:Extreme Programming

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Extreme Programming“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

Archiv

2004 bis 2012 ab 2013
Wie wird ein Archiv angelegt?

Abschnitt "Projektsicht"

Letzter Kommentar: vor 12 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt

"...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)Beantworten

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)Beantworten

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)Beantworten

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

Allgemein + Abschnitt Kritik

Letzter Kommentar: vor 11 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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)Beantworten

Einfach vs. Kompliziert

Letzter Kommentar: vor 11 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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)Beantworten

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