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

ab 2004
Wie wird ein Archiv angelegt?

Formale Spezifikationen und Dokumentation

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

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

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

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

Abschnitt "Kritik"

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

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

Redundanz

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

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

Abschnitt "Projektsicht"

Letzter Kommentar: vor 12 Jahren2 Kommentare2 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