Diskussion:Crystal Family
Kopie aus der Gegenrede zum Löschantrag
Behauptungen waren: Artikel sei unbedeutend, Werbung, und "blutarm".
- Was daran bedeutend sein soll: Diese Frage kann man genauso bei anderen Agilen Methoden stellen. Es ist eine dieser Methoden; wenn andere, wie z.B. Extreme Programming ('XP') eine eigene Darstellung erfahren, warum nicht auch diese? Oder umgekehrt gefragt: wenn man diese nicht als separat aufführenswert ansieht, müßte auch XP gelöscht werden.
Denn die bei XP genannten einzelnen Werkzeuge sind nicht XP-spezifisch, sondern allgemein bei den Agilen Methoden in Verwendung; die verschiedenen Ansätze der Agilen Methoden unterscheiden sich in der Bewertung um im Einsatz dieser Werkzeuge.
- Werbung: Gut, da möchte ich erst mal eure Argumentation hören. Bei UML werden deren Urheber auch genannt, ebenso deren Bücher - das ist doch ein ähnlicher Fall, finde ich.
Meiner Ansicht nach sollte man diese angeben können, wenn die Urheber einige der besten Quellen zum Thema bereitstellen. Aber wenn das im Konsens Werbung sein sollte: gut, kann man entfernen. Dann aber bitte auch bei anderen Themen!
- Auch "blutarmut" angeht, sollte man den gleichen Maßstab anlegen wie bei anderen Methoden. Daß da sehr allgemeine Begriffe verwendet werden, liegt in der Natur der Sache. Aber im Vergleich treten die Unterschiede hervor.
Z.B. die erste Kernerkenntnis "Unterschiedliche Projekte benötigen unterschiedliche Prozesse oder Methoden" mag trivial scheinen. Schön, sehe ich auch so. Allerdings wird das in manchen Methoden ganz anders gesehen - da gilt "one method fits all". Auch der zweite Punkt wird in anderen Vorgehensmodellen unterschiedlich gesehen, und so fort.
Ich möchte die Auseinandersetzung, welche Methode besser sein, nicht im Artikel führen. Würde ich das, dann könnte man die relevanz der Aussagen wohl besser erkennen.
( Wenn die Aussagen trivial erscheinen, dann heißt das, daß sie so einleuchtend sind, daß die gegenteiligen Ansichten (insbesondere XP) es wohl nicht sind. Oder? )
--Jwilkes 02:14, 12. Jan 2005 (CET)
bzgl. Weiterbearbeitung
Ich persönlich kenne es so, daß man bei Wikis erst mal einen Artikel anfängt, und dieser dann schrittweise verbessert wird - vom Autor wie von anderen.
Das Verhalten, das ich hier hingegen erlebt habe, war krass anders: 1h 18min nach der ersten Version kam der Löschantrag, mit unfreundlichen Worten, nicht im geringsten konstruktiv.
Ist das normal in Wikipedia?
Solange nicht klar ist, ob der Artikel weiterbestehen kann, bin ich jedenfalls nicht sonderlich motiviert, weiter daran zu schreiben.
--Jwilkes 02:15, 12. Jan 2005 (CET)
Artikel- Weiterentwicklung
Erste Schritte
Mit Stand 12.1.05 hat sich der Artikel schon ein gutes Stück aus der Löschgefahrzone entfernt, es wird halbwegs klar, worum es geht. 3 Bauchschmerz-Punkte stören mich doch noch sehr:
- die "hölzernen Überwetzungen" sind noch nicht vollständig ersetzt ("Grössere Teams brauchen schwerere Methoden" ?!?!?!)
- Ist im deutschen Sprachraum die Eindeutschung "Agile Methoden" wirklich gebräuchlich? Für mich klingt das "irgendwie" komisch.
- Die Mehrzahl der Erkenntnisse, die dort aufgeführt werden, ist eher banal ("Übergewichtige Methoden sind teuer"). Anders als im Artikel Extreme Programming, wo wirklich originelle Ansätze wie Pair-Programming etc. aufgeführt werden, bleibt Crystal Family oft doch eher alleein-philosophisch ("Heiße Luft" wie "Unterschiedliche Projekte benötigen unterschiedliche Prozesse oder Methoden"). Da kann natürlich der Artikel nichts für, das liegt am "Produkt", erfordert m.E. aber eine kritische Würdigung.
-- RainerBi ✉ 08:54, 12. Jan 2005 (CET)
Sonstige Auffälligkeiten
- Das Artikelstichwort Crystal Family kommt im ganzen Artikel nicht einmal vor
- Die Tabelle Auswahl der Variante ist ein Fremdkörper im Artikel, der nichts erklärt – Was hat man sich unter L6 vorzustellen?
-- RainerBi ✉ 12:05, 15. Jan 2005 (CET)
Gegenrede.
In der Sache:
1. Die bei XP genannten Ansätze sind nicht "originell", sondern sind auch anderen Agilen Methoden gemein. Die eine Methode verwendet dies, die andere jenes. Nicht nur XP macht Pair Programming, nicht nur SCRUM sieht tägliche Treffen vor.
2. Die Allgemeinheit von Crystal ist volle Absicht; die Gründe stehen auch im Artikel! Das ist ja der wesentliche Unterschied gegenüber anderen Agilen Methoden: der anzuwendende Methodensatz wird dem Projekt angepaßt, statt dogmatisch für sämtliche Projekte die gleichen Methoden festzulegen. Aber was schreib' ich das nochmal, steht eh im Text.
Ich werde nicht hingehen und aus der erwähnten Literatur die konkreten Auflistungen und Pläne für die einzelnen Varianten abtippen. Das wäre abgesehen von der URV auch zuviel des Guten; der Artikel soll erklären, was etwas ist, nicht die Fachliteratur ersetzen.
3. "Größere Teams brauchen schwerere Methoden" - da verstehe ich die Kritik nicht. Inhaltlich ist das m.E. auch klar, und ich habe es auch am Beispiel der Kommunikation im Team dargestellt: je mehr Leute, desto schwieriger direkte Kommunikation, also braucht man dafür aufwendigere, schwerere Methoden. (Andere Punkte sind: Größere Teams haben erhöhten Dokumentationsbedarf und Verwaltungsaufwand). Und "schwere" durch "aufwendigere" ersetzen könnte der Kritiker auch selbst.
4. Gebräuchlichkeit von "Agile Methoden": Suchmaschine verwenden, Treffer zählen. Daß es in Fachkreisen gebräuchlich ist, kann ich ja nur von meinen ECOOP-Besuchen sagen, aber vermutlich würde das wieder in Abrede gestellt.
Persönlich
Ganz offen gesagt: Ich habe den Eindruck, das mit der heißen Luft liegt nicht am Produkt, sondern am Bewertenden.
Gerade bei Crystal, kann ich aus eigener Erfahrung sagen, ist weniger heiße Luft drin als bei anderen Agilen Methoden - es ist weit praxis- und ergebnisorientierter und weniger "sektenartig" als andere Methoden. Aber genau darum legt es auch nicht Zehn Gebote oder "die" zu verwendenden Mittel fest.
Mir ist durchaus bewußt, daß die verschiedenen Fraktionen innerhalb der Agilen Methoden einander nicht immer gewogen sind, und einige XP-Anhänger auch recht fanatisch werden können in ihrer Verteidigung des "einzig wahren Glaubens". Ich finde das schade, aber sie können gerne ihrer Methode anhängen. Nur sollte es auch die Toleranz geben, andere anderes tun - und darüber reden zu lassen. Soviel Fairness sollte sein.
Ich bin jetzt nicht sicher, ob die Zugeständnisse ("halbwegs klar") taktisch oder ernst gemeint sind. --Jwilkes 15:04, 12. Jan 2005 (CET)
Überarbeiten
Ich hab' den Artikel erstmal vorm Löschen verschont. Bitte dringend überarbeiten oder, falls dies nicht geschieht, zumm Löschen vorschlagen. --DaB. 12:58, 17. Jan 2005 (CET)
Grundsätzliches
Agile Methoden sind wichtig. Deutsche Ingenieure sind davon nicht sehr egeistert weil die amerikanische Herkunft schnell nach Oberflächlichkeit und Werbung riecht. Ich arbeite beratender Weise auch mit Leuten aus anderen Ländern, die sich da weniger sperren. Bitte lasst usn die Artikel weiter schreiben, denn die Relevanz ist definitv gegeben, auch wenn Deutschland (wie immer) ein wenig verstaubt reagiert. Vielleicht wird Euch die Sache weniger staubig wenn Ihr mal in meinen Exkurs zur Entwicklung des Agile Modeling reinschaut - sicher auch noch nicht perfekt, aber die Idee eines Wiki ist es doch, dass ein Startpunkt irgendwie erstmal drinsteht und dann über die Zeit weiter entwickelt wird. Bitte seid nicht so radikal mit der Löscherei! Wir scheiben ein Lexikon - das braucht Weile. Ich werde mich auch um die anderen Artikel zur Softwaretechnik kümmern so wie Zeit ist. Die Materie ist schwierig, also lassen wir uns Zeit und verlagern die Diskussion zurück von persönlichen Statements zu sachlichen Fachdiskussionen.
Frieden und Sachlichkeit
--HJG 17:43, 10. Apr 2005 (CEST)
- Schon zweimal hattte ich einen Text hier stehen, um gegen die ewige (Fast-)löscherei zu protestieren, es aber dann sein lassen aus Angst, ich wäre der einzige mit dem Eindruck. Schön zu sehen, dass dem nicht so ist.
- Ich stimme HJG 100% zu. Wenn einem ein Artikel irgendwie nicht passt, ist ein Löschantrag eine ziemlich billige Problemlösung - eigentlich keine, es ist eine Problemignorierung, keine Problemlösung. Besser wäre, zu überlegen, was einem nicht gefällt, und auf der Diskussionsseite darüber zu diskutieren. Aber das scheint einigen wohl doch etwas zu aufwendig, stattdessen wird wiederholt ein Löschantrag gestellt mit lediglich 1-2 Zeilen Begründung.
- 1-2 Zeilen Begründung sind meines Erachtens nach definitiv unzureichend für einen Löschantrag. Wenn ein Artikel nicht genug Inhalt hat, ist ein Löschantrag sowieso der falsche Weg. "Lieber kein Artikel als ein kurzer" kann nicht das Ziel der Wikipedia sein. Besser jemand fängt mal mit einem kleinen Artikel an, den andere dann erweitern können, als dass man das Thema überhaupt nicht behandelt. Löschanträge sollten Artikeln vorbehalten sein, die tatsächlich nichts zu suchen haben, das sind entweder Duplikate, bei denen klar ist, welcher Artikel bleibt und welcher nicht, und wirkliche Nonsens- oder Werbe-Artikel. Ich kann bei Crystal jedoch nicht erkennen, wie das den Schöpfern von Crystal auch nur irgendwie werbetechnisch helfen soll, wenn hier etwas darüber steht - genausowenig wie vergleichsweise bei Extreme Programming oder dem RUP. E=mc² ist doch auch keine "Werbung" für Albert Einstein. Wenn Crystal Family ausschließlich ein von einer Firma oder Person vertriebenes Produkt wäre - okay, aber das ist Crystal Family eben nicht. Und selbst wenn, in vielen Fällen sind Produkte und Firmen dennoch aufgeführt, und es gilt nicht als Werbung. Werbung wäre "Crystal Family ist geil, kaufen Sie Crystal Family Consulting bei Alistair Cockburn".
- Dieser Artikel muss da bleiben. Ich wäre verdammt froh darüber gewesen, wenn es vor ein paar Jahren diesen Artikel schon gegeben hätte, und ihn zu löschen wäre ein schmerzlicher Verlust. Es brächte die Wikipedia darum, ihre Aufgabe zu erfüllen, nämlich gleich einer Enzyklopaedie Fachbegriffe zu erklären, dazu gehört auch die Crystal Family.
- Natürlich ist klar, dass Crystal Family - anders als "Funktion" - ein vergleichsweise esoterischer Begriff ist, selbst für erfahrene Software-Entwickler, die versuchen, sich bezüglich solcher Themen ständig auf dem aktuellen Stand zu halten. Dass nur eine eingeschränkte Personengruppe ein Thema kennt, darf aber kein Löschgrund sein.
- Die Deklaration zur Überarbeitung wäre in Ordnung gewesen. Allerdings finde ich den Artikel in seinem jetzigen Zustand nicht wirklich dringend überarbeitungsbedürftig. Sämtliche auf die Löschanträge bezogenen Punkte sind behoben, und der Überarbeitenantrag liefert weder neue Begründungen noch frischt er ältere auf.
- Ich halte die Kennzeichnung zum Überarbeiten für unpassend, respektlos gegenüber dem Originalautor und der ganzen Arbeit und Zeit, die er investiert hat, und ungerecht. Ich habe stark den Eindruck, die Überarbeitungskennzeichnung ist lediglich eine Alibi-Funktion zur Verteidigung der früheren Löschanträge. Ich glaube, dass dies nicht der richtige Weg ist, neue Autoren für die Wikipedia zu gewinnen. Wenn ich Jwikes wäre, wäre mir die Lust auf Wikipedia gründlich vergangen. Ich kann mir gut vorstellen, wie er sich fühlt, zumal dieser Artikel nun wirklich nicht schlecht ist, und etliche Artikel eine Überarbeitung ganz erheblich nötiger hätten als dieser. Ich kann nur sagen: Jwikes, lass Dich nicht entmutigen, weiter so!
- Denen, welche die Löschantrag und den Überarbeitenantrag gestellt haben: <ironie>Gratulation</ironie>, ihr habt einen potentiell wertvollen Autor gleich bei seinen ersten Schritten vergrault, na prima! --ChristianHujer 22:46, 10. Apr 2005 (CEST)
Defekter Weblink
| Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt. |
|---|
|
– GiftBot (Diskussion) 14:09, 4. Dez. 2015 (CET)
