Diskussion:Agile Softwareentwicklung/Archiv

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:Agile Softwareentwicklung/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

Überarbeiten/Lösch-Frage

Überarbeiten

"Testgetriebene Entwicklung" wird als agiler Prozess dargestellt, Kent Beck sagt in TDD by Example allerdings, daß er TDD als Methode versteht, die in XP (und anderswo) verwendet wird. -- RS

Unerträgliches Geschwurbel wie auch unter Agil... Ich werde äußerst selten so deutlich, aber hier muss es sein: Dies ist eine Enzyklopädie und keine Powerpoint-Präsentation für einen "Lasst uns mal alle AGIL buchstabieren!"-Workshop! Dringend überarbeiten, sonst folgt ein Löschantrag! --PanchoS 05:39, 18. Jul 2006 (CEST)

Weiss nicht, was der Sancho Pansa damit meint, soll er's doch mal konkretisieren. --RS

P.S.: Wenn ich sehe, was da in der Pipeline noch folgen soll, dann Gute Nacht (Quelle: siehe weiter unten auf der Diskussionsseite):

Insgesamt bräuchte man Artikel zu den folgenden Themen:
* Agile Softwareentwicklung / Agil / Agilität / Agile Softwaretechnik / Agile Development
** Agiler Wert / Agile Werte / Agile Value / Agile Values
** Agiles Prinzip / Agile Prinzipien / Agile Principle / Agile Principles
** Agile Methode / Agile Method
Bestandteile:
* Agiler Prozess / Agile Methoden / Agiles Verfahrensmodell / Agile Process / Agile Methods
** Agile Modellierung / Agile Model(l)ing
*** Agile Analyse / Agile Analysis
*** Agiler Entwurf / Agiles Design / Agile Design
** Agiles Testen / Agile Testing
** Agile Progammierung / Agile Implementierug / Agile Programming / Agile Implementation

Löschen Ich wäre für eine Entfernung dieser perversen Form der Schleichwerbung und zwar asap und würde daher einen Löschantrag beführworten ... --MartinSchwienbacher 14:49, 13. Aug 2006 (CEST)

Wie wärs mit der [[Kategorie:Pseudowissenschaft]]? --Bernd vdB 00:59, 3. Sep. 2007 (CEST)

Überarbeitet

• Habe den Abschnitt "Aktivitäten der Softwareentwicklung/Phasen" gelöscht. Der Fließtext war meiner Meinung nach sehr unpräzise formuliert. Die Verwendung der eingebrachten Begriffe Prozess, Aspekt, Aktivität und Iteration war unklar. Die folgenden Unterabschnitte waren mit einem Stichwort zu kurz, außerdem waren alle genannten Stichworte redundant. Teilweise war die Zuordnung falsch.
• Außerdem habe ich die Werbegrafik Xpkurve.png

  

  entfernt.
• Gelöscht: "Einige Agile Methoden können auch außerhalb Agiler Prozesse zum Einsatz kommen. Häufig sind jedoch die verschiedenen Methoden eines Agilen Prozesses verzahnt und stützen sich gegenseitig, sodass der Einsatz einzelner Methoden ohne die anderen sich als fatal erweisen kann." — eine solche Behauptung müsste begründet und näher spezifiziert werden: Welche Methoden stützen sich gegenseitig, bzw. welche Methoden führen isoliert eingesetzt zu „fatalen“ Ergebnissen?
• Gelöscht: Einleitung zum Abschnitt „Bestandteile Agiler Softwareentwicklung“ war: "Wichtigster Bestandteil ist die Umsetzung von Agilität. Je nach Betrachtungsquerschnitt lässt sich Agile Softwareentwicklung auf verschiedene Arten zergliedern." Diesem Satz fehlte meiner Meinung nach eine Sachaussage.
• Gelöscht: "Andererseits kennt die klassische Softwaretechnik verschiedene Phasen oder Aspekte der Softwareentwicklung, die ebenfalls unter Einsatz von Agilität realisiert werden können. Dazu gehören das Agile Modelling mit Agiler Analyse und Agilem Entwurf, das Agile Testen und die Agile Programmierung." — die genannten Phasen gehören gar nicht zu klassischen Vorgehensmodellen.
• Gelöscht: "Nicht alle agilen Prinzipien und Methoden lassen sich genau einem Aspekt der Softwaretechnik zuordnen, eine Tatsache, die ebenfalls charakteristisch für die agile Softwareentwicklung ist." und fortfolgend. Was genau ist charakteristisch für agile Methoden?
• ach je das geht ja immer so weiter. Ich gebe auf und schließe mich dem Löschantrag an.

--Björn Klippstein 23:59, 18. Sep. 2007 (CEST)

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Todo

• Texte für die einzelnen Phasen / Aspekte
• Mehr Beispiele für die einzelnen Phasen / Aspekte, nicht nur Methoden, sondern auch Prinzipien und evtl. Werte
• Aufpassen, dass Phasen / Aspekte kein größeres Gewicht erhalten als die eigentlichen Bestandteile

--ChristianHujer 22:20, 22. Apr 2005

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Link

der Link zu XP vs. RUP stimmt nicht mehr und sollte mal aktualisiert werden !!!

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Kopiert aus Diskussion zu Agile Methode

Soll aus agiles Prinzip ein eigenständiger Eintrag werden? Pro:

• Agile Prinzipien werden oft fälschlicherweise als Agile Methode bezeichnet, obwohl sie eigentlich keine Methode sind. Ich denke, die Wikipedia sollte das richtig machen.
• Agile Principle(s) ist ein im Zusammenhang mit Agilen Methoden, Agilen Prozessen und Extreme Programming häufig auftauchender Begriff.

--ChristianHujer 02:00, 11. Apr 2005 (CEST)

macht sinn. zwei begriffe - gemäß diskussion in agiler prozess wären das dann bausteine, die von der generellen agility seite aus verlinkt werden könnten. --HJG 12:15, 11. Apr 2005 (CEST)

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Zusammenlegung von Agile Modeling + Agile Methode + Agiler Prozess?

Andererseits: Siehe Diskussion:Agiler Prozess --ChristianHujer 02:58, 11. Apr 2005 (CEST)

naja, einzelne begriffe ja, aber eben ohne wirrwarr --HJG 12:15, 11. Apr 2005 (CEST)

Aus dem Text hierher verschobener Text

Ungünstiger Begriff weil abstrakte Methoden durch die Objektorientierung begrifflich vorbelegt sind. Bleiben wir doch bei "Agile Prinzipien" und "Agile Methoden" mit der Definition: Agile Prinzipien sind Leitsätze für die Agile Arbeit, Agile Methoden sind Arbeitsanweisungen für die Durchführung konkreter Handlungen in agilen Projekten, wobei die Methoden mit den Prinzipien konsistent seinmüssen um Agil genannt zu werden. Damit wäre ohne begriffliche Verstrickung gesagt, dass die Prinzipien als Basis der Methoden abstrakter als dieselben sind.

Ich habe das hierher verschoben, weil das nichts im Artikel zu suchen hat, sondern Diskussion ist. Den Artikel habe ich entsprechend angepasst.--ChristianHujer 11:47, 11. Apr 2005 (CEST)

danke --HJG 12:15, 11. Apr 2005 (CEST)

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Kopiert aus Diskussion zu Agiler Prozess

Weiteres Verfahren mit Agile-Artikeln

Insgesamt bräuchte man Artikel zu den folgenden Themen:

• Agile Softwareentwicklung / Agil / Agilität / Agile Softwaretechnik / Agile Development
  • Agiler Wert / Agile Werte / Agile Value / Agile Values
  • Agiles Prinzip / Agile Prinzipien / Agile Principle / Agile Principles
  • Agile Methode / Agile Method

Bestandteile:

• Agiler Prozess / Agile Methoden / Agiles Verfahrensmodell / Agile Process / Agile Methods
  • Agile Modellierung / Agile Model(l)ing
    • Agile Analyse / Agile Analysis
    • Agiler Entwurf / Agiles Design / Agile Design
  • Agiles Testen / Agile Testing
  • Agile Progammierung / Agile Implementierug / Agile Programming / Agile Implementation

Allerdings befürchte ich, dass bestimmte Definitionen und Aufzählungen dann immer wiederholt würden. Man könnte diese Artikel also auch alle unter Agiler Prozess zusammenfassen und entsprechend Redirects und Unterpunkte schaffen. Was meint Ihr?

Ein paar Beispiele für potentielle Widerholungen: In Agile Modeling werden die "Werte Kommunikation, Innovation, Kundennähe, Bescheidenheit, Einfachheit" aufgeführt. Dies sind jedoch keine Werte, die alleine dem Agile Modeling zuzuschreiben wären, sondern sie gehören zur Agilität im allgemeinen.

Ich befürchte auch, kaum eines dieser Themen würde, bei wenig Wiederholung und möglichst viel Bezug auf andere Artikel des selben Themenunterkreises, tatsächlich eigenständig ausführlichen Enzyklopädie-Charakter erlangen, ohne dabei gleich in eine Art "Kapitel eines Lehrbuches über Agile Development" zu verfallen.

--ChristianHujer 11:59, 11. Apr 2005 (CEST)

Da Agility disziplinübergreifend ist, sollte man das unterteilen, denn auch in anderen branchen wird man zunehmend über agility reden. also machen wir doch eine seite "agility" um dort das intro zu geben, die begriffe zu systematisieren und zu verlinken. dann ließen sich die unterbregriffe kürzer halten und die von dir richtiger weise angesprochenen prinzipien redundanzfrei darstellen. --HJG 12:11, 11. Apr 2005 (CEST)

Ja, gute Idee. Aber bitte die Hauptartikel auf Deutsch und die gebräuchlichen Englischen Begriffe als Redirects. --ChristianHujer 12:20, 11. Apr 2005 (CEST)

Ok, deutsche begriffe (s. unten) mit englischen redirects. --HJG 12:33, 11. Apr 2005 (CEST)

Wikipedia soll hier offensichtlich als Plattform verwendet werden, um einer geschlossenen, pseudowissenschaftlichen Begriffswelt einen wissenschaftlichen Anstrich zu geben. Macht euer eigenes Wiki für solche Spielchen, Mediawiki ist kostenlos für jeden verfügbar... --Bernd vdB 01:02, 3. Sep. 2007 (CEST)

Kurzdefinitionen

Agil

Unter Verwendung agiler Werte und darauf aufbauender Prinzipien und Methoden.

Agilität

Verwendung agiler Werte und darauf aufbauender Prinzipien und Methoden.

Agile Softwareentwickung, Agile Development

Software-Entwicklung mit Elementen der agilen Software-Technik.

Agile Softwaretechnik

Oberbegriff für die einzelnen agilen Methoden.

Agiler Wert

Der Agilität zu Grunde liegender Wert, wie Einfachheit, Robustheit, Kundenorientierung etc..

Agiles Prinzip

Aus ein oder mehreren Agilen Werten abgeleiteter Grundsatz.

Agile Methode

Einzelne agile Arbeitsanweisung für die Durchführung konkreter Handlungen.

Agiler Prozess / Agile Methoden / Agiles Verfahrensmodell

Zusammenfassung von agilen Werten, Prinzipien und Methoden zu einem Verfahrensmodell oder umgekehrt, ein Verfahrensmodell, das agilen Methoden verwendet, um sich an agilen Prinzipien und Werten auszurichten.

Agile Modellierung

Teile des Prozesses, Software-Modellierung ausgerichtet auf Agilität.

Agile Analyse

Teil der Modellierung, Systemanalyse ausgerichtet auf Agilität.

Agiler Entwurf

Teil der Modellierung, Systementwurf ausgerichtet auf Agilität.

Agiles Testen

Teil des Prozesses, Software-Test ausgerichtet auf Agilität.

Agile Programmierung

Teil des Prozesses, Progammierung ausgerichtet auf Agilität.

Eine Enzyklopädie sollte meines Erachtens nach versuchen, wo möglich einem Artikel eine gewissen Eigenständigkeit zu verleihen. Natürlich kann man zu jedem einzelnen Begriff aus der Agilität einen einzelnen Artikel gönnen, nur würde er entweder ohne Lesen von Referenzen unverständlich sein oder sehr viel Redundanz mit anderen Artikeln aus dem selben Themenkreis haben. Gerade deshalb sehe ich Sinn in der Zusammenlegung - zumindest vorläufig wäre meines Erachtens nach dem Leser sehr viel damit gedient.

Als Titel des gemeinsamen Artikels schlage ich "Agilität (Softwaretechnik)" vor, den Rest als Redirects darauf.--ChristianHujer 12:20, 11. Apr 2005 (CEST)

Längst geschehen, sogar mit (hoffentlich nun korrekter) Etymologie. Allerdings möchte ich an dieser Stelle auch vorsichtig darauf hinweisen, dass Wikipedia keine Werbeplattform ist. --ChristianHujer 13:23, 11. Apr 2005 (CEST)

ist völlig korrekt, daher startwert für text auch gleich wieder raus. --HJG 18:18, 11. Apr 2005 (CEST)

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Zusammenlegung

Aufgrund der vielen Überschneidungen habe ich erstmal die Artikel Agile Methode und Agiler Prozess zusammengefasst. Der Artikel ist noch unvollständig, insbesondere bezüglich Agiler Phasen / Aspekte. Ich glaube jedoch, dass dies für den Leser erstmal einen großen Gewinn darstellt. Die verschiedenen Begriffe aus der Agilen Softwareentwicklung sind so hoffentlich wesentlich besser in ihrem Zusammenhang zu sehen. Sollten einzelne Erklärungen wie zu Agiler Prozess oder Agile Methode dann doch noch wachsen, kann man ja wieder eigenständige Artikel daraus machen. Die Zusammenlegung ist jedoch sicherlich eine große Hilfe, um Redundanz zu vermeiden.

Jetzt muss sich nur noch jemand um Agile Modeling kümmern. --ChristianHujer 21:58, 22. Apr 2005 (CEST)

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Link auf Firma

hallo, ist es nicht ungewöhnlich, in einem Artikel direkt auf eine Firma zu verweisen? Hier wird auf agile-methoden.de verlinkt. Es wäre doch interessanter z.B. detuschsprachige Artikel im Netz zu verlinken, wie z.B. die Beiträge von Frank Westphal [1] - Sebastian

Stimmt, sollte raus. Allerdings ist "Frank Westphal" mehr oder minder auch eine Ein-Mann-Firma. :-)

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Link auf Firma

hallo, ist es nicht ungewöhnlich, in einem Artikel direkt auf eine Firma zu verweisen? Hier wird auf agile-methoden.de verlinkt. Es wäre doch interessanter z.B. detuschsprachige Artikel im Netz zu verlinken, wie z.B. die Beiträge von Frank Westphal [2] - Sebastian

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Schleichwerbung

--MartinSchwienbacher 00:52, 21. Jan 2006 (CET) Warum habe ich nur den Verdacht, dass es sich bei diesem Artikel nebst dem anderen Artikel über XP "http://de.wikipedia.org/wiki/Extreme_Programming" um Schleichwerbung handelt - dafür ist ein Lexikon der falsche platz.

Insb. die Grafik ist traurig und wohl kaum "beweisbar".

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Toter Weblink

Bei mehreren automatisierten Botläufen wurde der folgende Weblink als nicht verfügbar erkannt. Bitte überprüfe, ob der Link tatsächlich down ist, und korrigiere oder entferne ihn in diesem Fall!

• http://www.andrena.de/Links/Paper3.pdf
  • In Agile Softwareentwicklung on Sat Jan 14 12:33:39 2006, 404 Not Found
  • In Agile Softwareentwicklung on Tue Jan 17 12:50:49 2006, 404 Not Found
  • In Agile Softwareentwicklung on Sat Jan 21 17:51:12 2006, 404 Not Found

--Zwobot 17:52, 21. Jan 2006 (CET)

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Toter Weblink

Bei mehreren automatisierten Botläufen wurde der folgende Weblink als nicht verfügbar erkannt. Bitte überprüfe, ob der Link tatsächlich down ist, und korrigiere oder entferne ihn in diesem Fall!

• http://www.agilealliance.org/programs/roadmaps/Roadmap/index.htm
  • In Agile Softwareentwicklung on Sat Jan 14 12:33:41 2006, 404 Not Found
  • In Agile Softwareentwicklung on Tue Jan 17 12:50:46 2006, 404 Not Found
  • In Agile Softwareentwicklung on Sat Jan 21 17:51:12 2006, 404 Not Found

--Zwobot 17:52, 21. Jan 2006 (CET)

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Agil, agil, agil ...

Wenn ich so etwas schon lese: "Dazu bedient sich ein agiler Prozess hauptsächlich Agiler Methoden. Wird ein Agiler Prozess erfolgreich zur Entwicklung von Software eingesetzt, spricht man von Agiler Softwareentwicklung. Um die vergleichsweise Einfachheit Agiler Prozesse zu unterstreichen, spricht man oft von Agilen Methoden statt einem Agilen Prozess. Das unterstreicht die Einfachheit der meisten Agilen Prozesse, die sich lediglich als Zusammenfassung einiger Agiler Methoden verstehen."

Das ist doch hohles Geschwurbel ohne Erkenntniswert. Versucht doch mal, den Begriff "agil" mit Leben zu füllen, statt ihn ununterbrochen zu wiederholen. Das ist hier doch kein Mantra und keine religiöse Schrift, sondern ein Lexikoneintrag! --83.135.255.178 18:42, 17. Jan. 2007 (CET)

agil - Man lese dort den ersten Absatz (=Wörterbucheintrag). --the one who was addicted (#) 17:49, 29. Jan. 2007

Noe, auch das "mit Leben füllen" können sie gern auf ihrer eigenen Web-Community machen, dafür ist WP nicht vorgesehen: WP:TF. MMn hat dieses ganze Zeugs bei der WP nix verloren. --Bernd vdB 01:06, 3. Sep. 2007 (CEST)

Als Softwareentwicklungsingenieur kann ich dir eines garantieren: Agil ist eine Religion !! ;-) --micha Frage/Antwort 01:14, 19. Sep. 2007 (CEST)

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Das ist doch Satire, oder???

Das ist doch nicht ernst gemeint? Als ich den Artikel in der c't darüber gelesen hab, war ich nach 1, 2 Sätzen überzeugt, dass das ganze eine Satire ist. Wenn nicht, warum ist der Artikel und auch diese Wikipedia-Seite in diesem komischen aufgeblasenen Stil geschrieben? --Schmidbauer 23:22, 9. Jul. 2008 (CEST)

Im Prinzip hört sich das wie eine Satire an. Z.B ist Punkt 3 der agilen "Werte" schon ein Widerspruch in sich: Verträge legen wichtige Parameter für die Zusammenarbeit fest, andererseits wird die "Zusammenarbeit mit dem Kunden" über Verträge gestellt. Wie kann das sein wenn Verträge die Basis zur Zusammenarbeit sind?

2. ist auch ganz lustig. Eine Dokumentation der Software hat nicht im geringsten etwas damit zu tun ob Software funktioniert oder nicht. Bei einer nicht dokumentierten Software ist man aber immer abhängig vom Entwickler, weil nur er sich damit auskennt und man auf seine Mitarbeit in zukünftigen Projekten angewiesen ist. Das ist so eine typische Ausrede dafür, dass manche keine Dokumentationen wollen.

4. Fasst so das meist miserable Anforderungsmanagement bei "agilen" Projekten zusammen.

Der Rest des Artikels hört sich für mich an wie eine Rechtfertigung von eigenbrötlerischen Entwicklern dafür, dass sie nicht mit anderen zusammenarbeiten wollen. Wenigstens sind Entwickler nicht die Projektleiter und haben nicht über die Vorgehensweise im Projekt zu entscheiden. In größeren Projekten sind solche dubiosen "Methoden" sowieso nicht bekannt und das ist auch gut so. (nicht signierter Beitrag von 88.78.151.123 (Diskussion) )

Nein, das ist keine Satire, die Autoren meinen das ernsthaft. Das Konzept Test First beipielsweise habe ich selbst schon ausprobiert. Ein durchaus ernst zu nehmendes diskussionswuerdiges Vorgehen und ein wegen der Verbreitung der Beitraege in Buechern und Zeitschriften sicherlich relevantes Lemma. Aber das Ganze liest sich eher wie ein Marketing-Flyer von Kent Beck & Jünger und stellt die Drawbacks nicht ebenbuertig dem Marktgeschrei gegenueber.

Schoen zu lesen das Dir Stil und Inhalt genauso zu denken geben wie mir. Ich lade Dich ein mitzuhelfen den Artikel zu verbessen und ihn zumindest auf ein akzeptables Niveau zu heben; Ich bin bereits damit angefangen, ist aber noch ein hartes Stueck Arbeit. Traute Meyer 22:42, 15. Okt. 2008 (CEST)

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Hääääääää

der artikel ist einfach zu schwer!!!!! wir sollten in der schule eine präsi machen und haben nix gerafft. Bitte im copy and past-Format verfassen.

Danke

Jetzt mal ohne scheiss: Ich habe keine Ahnung von agiler Softwareentwicklung und hab nach dem Lesen immer noch keine, so seltsam fand ich den Artikel!

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Broken Link

Im Teil "Agiler Prozess" ist der Link im letzten Absatz "Der Rational Unified Process (RUP) ... (siehe dazu 'XP und RUP – Passt das zusammen?')" derzeit oder dauerhaft down. -- 84.57.17.172 14:18, 30. Mär. 2009 (CEST)

Link ist wieder aktualisiert. Durch Umstrukturierungen hat sich wohl die Zieladresse geringfügig geändert - war aber über google sehr leicht ausfindig zu machen. Einfach bei solchen Dingen selbst aktiv werden und ein wenig suchen :) --FirstGuardian 14:24, 1. Sep. 2009 (CEST)

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Definition Agil: Flower Power für Entwickler

Ich meine das ernst und bin überzeugt, daß nach dem Abklingen des Agile-Hypes in der Retrospektive der naive Wunsche der Software-Entwickler nach einer besseren Welt in der sich alle mögen als Hauptmotor der ganzen Bewegung angesehen werden wird.

Bis dahin sollte man trotzdem versuchen, eine möglichst neutrale Beschreibung des aktuellen Standes hinzubekommen - der vorliegende Artikel ist das nicht. (nicht signierter Beitrag von 85.177.118.165 (Diskussion | Beiträge) 22:55, 20. Jun. 2009 (CEST))

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Starker Anfang!!!111

"Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität (lat. agilis ‚flink, beweglich‘) in der Softwareentwicklung."

Übrigens: Agiles Artikelschreiben ist der Einsatz von Agilität in der Artikelschreiberei! --91.55.119.197 19:30, 29. Apr. 2010 (CEST)

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

"back to the roots" oder die Nostalgie-Bewegung in der SW-Entwicklung

Ich kann "Agile" noch nicht wirklich endgültig bewerten, weil ich noch nie in einem solchen Projekt gearbeitet habe. Mein derzeitiger Eindruck kommt aus Vorträgen von Technischen Redakteuren (TR) und Testern, von Berichten von Informatik-Studenten und aus fast 30 Jahren Erfahrung mit Software-Entwicklern. Wie erwartet sind die Vorträge für TR eher ein "Wie lasse ich mich möglichst wenig stressen" oder "Welche Methoden gibt es, um trotzdem an Informationen zu kommen", während die Studenten begeistert diesen Weg als den einzig gangbaren in den Himmel loben. Alles, was ich in Agile sehe, ist ein Versuch alte Zeiten wieder aufleben zu lassen, als die Entwickler vor sich hin entwickelt und haben irgendwann anderen Projekt-Beteiligten ihr Werk präsentierten. Man musste sich z.B. kryptische Befehle merken, weil Aspekte wie Dokumentation, Test oder gar Benutzung in deren Anforderungsliste nicht vorkamen - wer schon mal mit SAP R3 gearbeitet hat, weiß, was ich meine ...

In der Denkwelt der SW-Entwickler kommen Kommunikationsdesigner, Technische Redakteure und Tester nicht vor - nicht mal Kunden. Oder sie meinen, sie könnten deren Jobs mindestens genauso gut, und sie verstehen nicht, warum man all diese Jobs in einem Vollzeitstudium erlernen muss. Gerüchteweise sollen ja zumindest die freiberuflichen Programmierer schon seit geraumer Zeit versuchen, in die Künstler-Sozialkasse aufgenommen zu werden ... da passt "Agile" ins Bild.

Vielleicht sollte man diese Artikel also eher wie eine Beschreibung von Utopia behandeln und nicht wie einen Enzyklopädieeintrag? Vielleicht kommt dann ja mit 10, 20 Jahren mehr Erfahrung ein brauchbarer Eintrag zustande oder dieses Stichwort verschwindet im Nirwana ... (nicht signierter Beitrag von 85.183.206.126 (Diskussion) 13:16, 30. Nov. 2010 (CET))

Zunächst mal: die Diskussionsseiten der Wikipedia sind nicht dafür da persönliche Anschauungen zu einem Thema zu reflektieren. Also bist mit Deinen Ausführungen hier fehl am Platz.

Dann aber als Infos dazu: Agil wird üblicherweise bei oberflächlicher Betrachtung missverstanden - die meisten, die das erste mal darüber stolpern denken Agil = Hackprozess wie anno dazumal. Das ist aber grundlegend falsch. Agil ist wesentlich strukturierter, qualitätsorientierter und auch schwieriger zu meistern als klassische Vorgangsweisen. Am besten Du liest mal ein Buch über agile SWE, dann erst bilde Dir eine Meinung. Dein aktuelles Bild ist weit weg von agiler Theorie und auch Praxis.

@Enzyklopädieeintrag - Agile SWE gibt es seit min. 1 Jahrzehnt - sie ist Realität und wird breit eingesetzt. Das rechtfertigt einen Eintrag in der WP, egal ob Du persönlich oder auch jeder das Thema nicht mag. Siehe WP:Relevanzkriterien --Sebastian.Dietrich ✉ 20:53, 30. Nov. 2010 (CET)

Dieser Abschnitt kann archiviert werden. Sebastian.Dietrich ✉ 21:04, 30. Nov. 2010 (CET)

Agile Model Driven Development

Könnte dieser eine Satz vom verwaisten Artikel Agile Model Driven Development nicht hier irgendwo untergebracht werden? Habe sowieso nicht so ganz verstanden was der Unterschied zu Agiler Modellierung ist --Roterraecher 17:28, 12. Jan. 2007 (CET)

Artikel schon seit 03/2007 nicht mehr existent, daher:

Dieser Abschnitt kann archiviert werden. Hamburger 18:37, 28. Dez. 2011 (CET)

Stellen Brückenbauer ausführbares Wissen her?

-Wenn nicht, dann muss es unter "Kritische Betrachtung" doch heißen, dass die herkömmlichen Methoden zum Scheitern verurteilt sind und nicht die agilen. Oder blick ich's nur nicht? (nicht signierter Beitrag von 87.151.206.223 (Diskussion) 23. Oktober 2008, 17:49 Uhr)

Es wird aus der aktuellen Fassung ersichtlich was gemeint ist. M.M.n.

Dieser Abschnitt kann archiviert werden. Hamburger 18:30, 28. Dez. 2011 (CET)

Agile Softwareentwicklung (Begriff)

In welchem Zusammenhang wurde der Begriff Agile Softwareentwicklung das erste Mal benutzt? Was wurde damals darunter verstanden? Wie hat sich der Begriff ausgeweitet? Wann und wo war die erste Konferenz die aussschliesslich "Agile Softwareentwicklung" (AS) zum Thema hatte. Welche Autoren, Gruppen und Bewegungen bemühen sich um AS?

Zum Glossar: Ich habe zwar einige Änderungen am AS-Glossar versucht, aber es gefällt mir nicht. Ohne eine Antwort auf die Fragen oben ist es schwierig es zu verbessern.

Ausblick: Hoffen wir dass es bei AS nicht auch so ist, dass in ein paar Jahren der Neuheitswert dieses Begriffes abgenutzt sein wird ist und eine "neue" Softwareentwicklung gefordert werden wird. HJH 18:26, 9. Apr 2006 (CEST)

Versuch einer Begriffsklärung

1. Der Begriff Agile Softwareentwicklung wurde zum ersten Mal 2000 im Manifest für agile Softwareentwicklung verwendet. http://agilemanifesto.org/, https://www.youtube.com/watch?v=a-BOSpxYJ9M

 Gründerväter sind 
 * Kent Beck (Begründer des Extreme Programming 1999)
 * Robert Cecil Martin (Autor von Agile Software Development: Principles, Patterns, and Practices)
 * Jim Highsmith (Adaptive Software Development, Agiles Management)
 * [J. Mellor], Verfechter von Agile Model Driven Architecture
 * Andy Hunt (Autor) und Dave Thomas (Programmierer)  (Autoren von: The Pragmatic Programmer)
 * Ken Schwaber Autor von [Agile Software Development with Scrum|https://www.amazon.de/Agile-Software-Development-Scrum-Beedle/dp/0130676349/ref=sr_1_1?s=books-intl-de&ie=UTF8&qid=1499009180&sr=1-1&keywords=Agile+Software+Development+with+Scrum.]
 * Alistair Cockburn, Autor von Agile Software Development: The Cooperative Game, Verfechter des Crystal Family-Entwicklungsprozesses.
 * Ron Jeffries, Autor von [Extreme Programming Installed (XP)|https://www.amazon.de/Extreme-Programming-Installed-Ron-Jeffries/dp/0201708426/ref=sr_1_2?s=books-intl-de&ie=UTF8&qid=1499009460&sr=1-2&keywords=Ron+Jeffries]
 * Jeff Sutherland, Erfinder von Scrum
 * Ward Cunningham, (Pionier des Extreme Programming 1999)
 * Jon Kern
 * Martin Fowler, Autor von Planning Extreme Programming
 * Brian Marick

Jeder dieser Autoren hat den Begriff für sich weiterentwickelt und was Scrum angeht auch kommerzialisiert. (Zitat von Dave Thomas (Programmierer): „Agile is now an industry“). Wie man sieht ist nur Ken Schwaber Scrum-Vertreter. Die Mehrheit scheint Extreme Programming als Mittel der Wahl anzusehen.

2. Ziel des Manifests war es die Softwareentwicklung fit zu machen für eine Umgebung in der sich Anforderungen beständig ändern indem man schwergewichtige Prozesse abbaut: Zitat von Jon Kern: ,,My recollection was that heavy-weight processes--like RUP and MIL-STD 2167--were more commonplace than I liked. The massive rigor of RUP especially rubbed me the wrong way--and, at TogetherSoft, we were always going head-to-head (and frequently winning) against Rational. But Rational was a huge marketing machine, and people were fawning all over the heavyweight process CDs. UGH. http://www.informit.com/articles/article.aspx?p=1739476

Sind deine Fragen damit beantwortet? --Cornerstone 18:15, 2. Jul. 2017 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Schotterebene (Diskussion) 07:15, 27. Sep. 2020 (CEST)

Definition von "Agil"

Im Einleitenden Satz wird Agilität als Einsatz von Agilität definiert. So etwas ist weder eine Erklärung noch ist so etwas in einem Nachschlagewerk üblich. Gibt es eine Definition des Begriffes?

Das stimmt so nicht. Es wird nicht "Agilität als Einsatz von Agilität definiert" sondern das Lemma "Agile Softwareentwicklung" mit dem Begriff "Agilität" in Verbindung gerbracht. Traute Meyer 20:25, 18. Okt. 2008 (CEST)

"Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität" ist der einleitende Satz. "Agil" wird hier als "Agil" definiert. So etwas sollte es in einen Nachschlagewerg nicht geben, weil es ja dazu dient, den Begriff "Aglie Entwicklung" zu erklären.

Bestimmt sind wir uns darueber einig, das der Artikel (und der einleitende Satz insbesondere) einer Ueberarbeitung beduerfen, um in einer akzeptablen Form zu gelangen; da ist viel Media Hype drin. Deine Kritik ist garnicht abwaegig. Ich selbst mache aus Zeitgruenden zZ. "nur" Streichung von offensichlichem Unfug. Ueber konkrete Verbesserungen (auch von Dir) freue ich mich deshalb. Falls Du im Thema bist, sei mutig und leg' los.

Ach ja, Signaturen (einfach 4x Tilde hinter Deinem Edit setzen (Tilde = "~") ) werden ganz gerne gesehen, dann muss man als Leser sich den Author nicht aus der Historie heraussuchen. Traute Meyer 21:29, 25. Okt. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Schotterebene (Diskussion) 07:15, 27. Sep. 2020 (CEST)

3.3 Agile Methode

"Streng genommen bezeichnet Agile Methode eine an Agilität ausgerichtete Methode zur Softwareentwicklung."
Das ist ein Pleonasmus und sollte entfernt werden. -- 88.65.176.79 14:35, 14. Dez. 2009 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Schotterebene (Diskussion) 07:15, 27. Sep. 2020 (CEST)

3.4 Kritische Betrachtung - Belege

Die fachlichen Angaben und Zahlenangaben in dem Abschnitt gehoeren zum Grundwissen des Software Engineering. Ich glaube nicht, dass dies Belege bedarf. Jeder, der SE studiert hat, wird diese Angaben bestaetigen.

Die Angabe, die an dieser Stelle beginnt:

Kritisch wird es, wenn Entwickler, die sich gut behaupten können, die Arena im Unternehmen für sich übernehmen...

...hatte ich ehemals eingefuegt, da ich es wichtig fand auch die personellen Konsequenzen zu beruecksichtigen. Von 5 agilen Projekten, waren nach meiner Erfahrung eben 5 over Budget, aber keines wurde abgebrochen. Meine Aufgabe als Berater war haeufig in bereits zerschossenen Projekte einzusteigen. D.h. es kann natuerlich sein, dass meine Erfahrung nicht repraesentativ ist - es waren aber immer Agile Projekte, die zerschossen waren, alle anderen verliefen meist (80% Regel) nach Plan und im Unterschied zu den Agilen Umgebungen waren auch durch und durch durchgeplant. Insgesamt habe ich soweit fuer etwa 20 Unternehmen gearbeitet.

Von der Personalstruktur her betrachtet, gilt m.E. in Agilen Projekten die Ellenbogenmentalitaet. Vielleicht ist das manchen Leuten einfach nicht bewusst, weil sie keine stabile Arbeitsumgebung kennen, wie z.B. junge Entwickler, jedenfalls gilt unter meinen Kollegen der Grundsatz - Agil? Da wird nicht gearbeitet, sondern ums Leben gekaempft. Da wird eben Sitzung fuer Sitzung versucht sich vor dem Chef zu profilieren. Es hat etwas mehr von einer Wahrheit als einem persoenlichen Standpunkt. Es kommt drauf an von welcher Schule man kommt. Jetzt ueber die Unvernuft Anderer etwas zu publizieren, wer soll damit aufsteigen? Ich kenne Kollegen, die lieber eine schoene Diplomarbeit ueber die schoene, heile Welt des agilen Vorgehens geschrieben haben. Wird dadrin stehen, dass waehrend der Diplomarbeit 50% der Leute in den ersten 4 Wochen gehen mussten, weil das Projekt-Budget falsch angesetzt war?

Was mich immernoch am Artikel stoert, ist, dass die Autoren nicht wirklich Ahnung haben, dass schon lange vor dem Hype so gearbeitet wurde und statt dessen den Hype rezitieren. In den 90ern wurde das sog. Software Lab bei der Nasa angewandt, Nasa setzte damals stark auf Ada. Die Methodik nannte sich, glaube ich, Clean Room. Im Prinzip in Stuecke zersetzt wurde ein Programm von einem Ingenieur vom Programmierer abgenommen und getestet. Also das ist so, wie man auch kritische mechanische Komponenten abnimmt - ein Ingenieur testet die Arbeit des Mechanikers. --188.46.210.117 22:39, 15. Jan. 2010 (CET)

Schon eine Weile her, dass die Diskussion hierzu eröffnet wurde. Trotzdem ein Kommentar, da weiterhin aktuell: M.M.n. ist tatsächlich nicht alles in dem Abschnitt belegpflichtig. Literaturreferenzen wären aber sicher hilfreich, die aufzeigen können wie die namhaften Autoren der Szene Agiles PM kritisch beleuchten. Das hat sicher höheren Mehrwert als krampfhaft Einzelnachweise von fraglicher Relevanz satzweise herbeizuzerren. :-) --Hamburger 18:34, 28. Dez. 2011 (CET)

die Beiträge sollten unbedingt behalten werden. Diese Erfahrung machen viele BeraterInnen. Ich habe die Erfahrung aus dem Blog von Quality and Gender als Beleg für weitere solche Stimmen angefügt.--VNeumann 18:09, 17. Feb. 2012 (CET)

Blogs taugen aber leider als Belege nicht - dazu gibts eindeutige Richtlinien in der Wikipedia. Vielleicht findest noch was besseres... --Sebastian.Dietrich ✉ 18:27, 17. Feb. 2012 (CET)

Die Diskussion ist zwar schon etwas älter, aber vielleicht taugt ja das Buch Agile!: The Good, the Hype and the Ugly von Bertrand Meyer amazon als Beleg, gerade zum Thema: "the good isn't new the new isn't necessarily good." --Ch0peng (Diskussion) 12:35, 15. Mär. 2017 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Schotterebene (Diskussion) 07:15, 27. Sep. 2020 (CEST)

Zuther, Bernd

Zuther, Bernd: Agile Methoden zur Einführung eines ERP-Systems am Beispiel einer Internetagentur. Akademikerverlag, 2012. ISBN 3639386582 bzw. ISBN 978-3639386585
Ist das Werk relevant? Bitte jetzt nicht einfach ja sagen, sondern auch Belege dafür (d.h. Sekundärliteratur) beifügen. Grüße, Uncopy 23:57, 16. Jan. 2012 (CET)

Im Leben nicht relevant. Habs entfernt. Der Verlag hat sich - wie so viele in letzter Zeit - auf das Verlegen von Diplomarbeiten u.ä. spezialisiert. Wer die Zusammenfassung auf Amazon liest, dem erübrigen sich weitere Gedanken über die Relevanz des Werkes im hiesgen Kontext (Zitat: "Dazu werden Vorgehensmodelle aus Softwareentwicklung betrachtet." [sic]). Selbst wenn es genau zum Thema passen würde: Es kam gerade erst raus, und hatte somit noch gar keine Zeit sich einen Namen auf dem Markt zu machen. So was hier reinzusetzen ist entweder schlichweg dumm ganz schlechte Quellenarbeit - oder ausgesprochen dreiste (Eigen-)Werbung. --Hamburger 22:27, 4. Feb. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Schotterebene (Diskussion) 07:15, 27. Sep. 2020 (CEST)

Manifest

Habe die deutsche Übersetzung des Manifests nach Kommunikation mit Benutzer:Uwe Haleksy geändert, da sie einerseits falsch war ("übergehen" ist was anderes als "goes over", "Festhalten" schreibt man groß) andererseits schlecht war. Benutzer:Uwe Haleksy wird diese Übersetzung als Vorschlag für die Webseite von Ward Cunningham einbringen. --Sebastian.Dietrich ✉ 21:31, 26. Jun. 2012 (CEST)

Ich finde, auch "contract negotiation" ist mit "Vertragsverhandlung" falsch übersetzt. Ursprünglich ist hier "Auftragsverhandlung" gemeint und bezieht sich auf die langwierige Pflichtenheftphase vor der eigentlichen Entwicklung. WÄHREND eines Projekts werden kaum noch Verträge verhandelt. --Rherschke (Diskussion) 21:36, 22. Mär. 2018 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Schotterebene (Diskussion) 07:15, 27. Sep. 2020 (CEST)

Abschnitt entfernt

Habe folgenden unbequellten Abschnitt entfernt. Bitte um Belege - meiner persönlichen Erfahrung nach stimmt das überhaupt nicht. Kurze Liegezeiten sind sehr gut mit agilen Methoden abdeckbar. Man muss nur vom (Scrum) Grundsatz weggehen, dass das gesamte Team an einem Feature arbeitet. --Sebastian.Dietrich ✉ 19:04, 27. Feb. 2013 (CET)

In der Industrie wurden bereits sehr gute Erfahrungen mit agilem Vorgehen gemacht, inzwischen kristallisiert sich jedoch ein Hauptkriterium für deren Einsatz heraus:

• Projekte mit langen Liegezeiten (es existiert eine lange Liste mit Anforderungen, welche fast in beliebiger Reihenfolge implementiert werden können) lassen sich am besten agil entwickeln.
• Projekte mit kurzen Liegezeiten (nichts bleibt lange liegen, weil viele Artefakte auf dem kritischen Pfad liegen; außerdem gibt es ggf. hohe Abhängigkeiten zwischen den Anforderungen), lassen sich wesentlich besser mit dem traditionellen Critical Chain Projektmanagement behandeln.

Daher stellt sich die oft gestellte Frage „Was ist besser - agil oder traditionell?“ nicht mehr, sondern vielmehr die Frage „Wann setze ich welche Methode ein?“

Archivierung dieses Abschnittes wurde gewünscht von: Schotterebene (Diskussion) 07:15, 27. Sep. 2020 (CEST)

Agiles Prinzip

die Kunst, die Menge nicht zu tuender Arbeit zu maximieren bitte was? soll der satz heissen, die arbeiten so schnell wie moeglich zu beenden, damit man den rest der zeit daddeln kann? 109.41.89.201 05:03, 1. Mär. 2014 (CET)

Die Formulierung war zugegebenermaßen etwas schräg. Auf gut deutsch ist gemeint: Keine unproduktiven Arbeiten leisten. Was die Leute mit der so gewonnenen Zeit machen, ist nicht Thema des Artikels. --Mussklprozz (Diskussion) 11:16, 1. Mär. 2014 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Schotterebene (Diskussion) 07:15, 27. Sep. 2020 (CEST)

Echte Kritik

Ja... da es so etwas wie Wissenschaft tatsächlich gibt hier ein kleiner Tipp zum selber googeln: "Soziologie, Kollegenbeziehungen". Generell: Bei unklarer Aufgabenteilung gibt es die übelsten Streits, das härteste Mobbing - Geht selber recherchieren in wissenschaftlichen Quellen. Ich schreibe nur mal den Forschungsstand auf den ich kenne. Der Erfolg von solchen Methoden führt sich meisten relativ klar darauf zurück: Der massive Gruppendruck, die diffuse Verantwortung von jedem für alles, sorgt dafür das Mitarbeiter statt Kritik zu üben ziemlich schnell freiwillig gehen. Die Kritik hat nämlich keine Adresse mehr an die sie sich wenden könnte - man muss im Zweifel immer die Kollegen als Gesamtheit anmotzen weil es ja angeblich irgendwie keinen Chef sondern nur einen "Coach" gibt... und eine Gewerkschaft natürlich erst recht nicht - denn deren Existenz wäre ja implizite Kritik an den Teamkollegen und ein Kommunikations-Defizit. (Klar gibt es den Chef - zumindest den Bestverdiener - bei größeren Firmen um so mehr, er hat sich nur der Verantwortung entledigt).

Der Abschnitt "Kritik" in diesem Artikel besteht im wesentlichen aus kritikloser Lobhudelei auf "Agile-Verfahren". Seltsame Statistiken ohne wissenschaftlichen Hintergrund werden aufgeführt um zu bestätigen: "Agile Verfahren" führen öfter zum "Erfolgreichen" Abschluss von "Projekten". "Erfolgreich abgeschlossen" kann alles bedeuten genau wie "Projekt". Die Unzahl an Faktoren die neben "agil" natürlich auch immer eine Rolle spielen werden irgendwie vergessen. Und das Statistiken zu "Agil ist toll" nicht in einen Abschnitt mit der Überschrift "Kritik" gehört sollte klar sein.

Das Agile Verfahren Erfolgreich sind, glaube ich sofort - zumindest wenn sie mit einer "hire and fire" Firmenpolitik kombiniert sind, und alles was im Team nicht "mitsprintet" schnell weg ist. Scientology ist schließlich auch erfolgreich.

Alles in allem bestätigt diese wissenschaftsfreien Lobgesänge mal wieder den Verdacht, dass es sich hier mehr um eine Ideologie handelt und sehr viel weniger um eine Arbeitsweise... (nicht signierter Beitrag von 85.181.16.78 (Diskussion) 06:08, 25. Nov. 2014 (CET))

Archivierung dieses Abschnittes wurde gewünscht von: Schotterebene (Diskussion) 07:15, 27. Sep. 2020 (CEST)

Echte Kritik geht so:

Es handelt sich bei "agiler" Software-Entwicklung um nicht weniger als eine psychologische Aushebelung von Arbeitnehmer-Rechten. Über Gruppendruck und die diffuse Verantwortung von jedem für irgendwie alles, werden Konflikte zwischen Arbeitgeber und Angestelltem in das Feld zwischen Kollegen verlagert. Wenn etwas schief läuft liegt das nicht mehr an schlechtem Management, sondern an angeblich schlechter Kommunikation und individuellen Mitarbeitern, oder deren Gruppe. Erfolg dagegen ist immer eine Teamleistung und wird letztlich der Firma zugeschrieben. Schuld wird aufs Individuum abgeladen bzw. das Team - jede Kritik auf Team-interne Kommunikationsproblematik zurückgeführt. "Muck nicht auf, sonst hängen alle deine Freunde mit dir". Wie praktisch. Die Verantwortung, das Risiko, das ein Unternehmer klassischer Weise hat wird abgewälzt - er ist nur noch da um am Ende den Gewinn ab-zugreifen.

Garniert wird das Ganze mit einem Tumult an Sprachmanipulation und Schlagwörtern das einem kritischen Wissenschaftler eigentlich schlecht werden muss. "Sprint" statt Arbeitsablauf - Warum benennt man das wohl um? Es suggeriert jung, dynamisch und vor allem freiwilliges Leisten bis zum körperlichen Zusammenbruch. Ja dann sprintet mal - nur wundert euch nicht wenn ihr in der Psychiatrie ankommt. "Transparenz" - immer gern gehörtes Schlagwort. Nur: Hier ist die völlige Transparenz von Code gemeint. Es geht um die Transparenz der Arbeit des Mitarbeiters - nicht die von Firmenstruktur, Finanzen etc.. So kann man schön verhindern das sich irgendein Mitarbeiter unentbehrlich macht in dem er sich einen Expertenbereich schaft - denn das wäre ja nicht transparent. Und sehr bezeichnend: "Coach", "Scrum Master" und "Blub" statt ---------------> CHEF. Der Chef ist nach wie vor vorhanden, man nennt ihn nur anders, damit es keine Adresse mehr für Kritik gibt und man ihn nicht mehr für seine Leistung bezahlen muss.

An all die naiven unter 30 Jährigen (unter dreißig bin ich auch, aber nicht naiv): "Lebenslanges lernen" hört sich nur dann positiv an, wenn man glaubt, dass man niemals altern wird. "Agil" ist womöglich vorallem unternehmens-beraterischer Neu-Sprech mit dem Ziel Menschen zur Selbstausbeutung zu Manipulieren.

Achja und die Antwort auf diese Kritik wird sein: Ja, da hat man das halt irgendwo falsch umgesetzt. Ja, da haben sie etwas falsch verstanden. Wie bei Scientology eben auch... (nicht signierter Beitrag von 85.181.16.78 (Diskussion) 06:08, 25. Nov. 2014 (CET))

Ich hätte die Kritik nicht so knallig formuliert, aber das bedeutet nicht, dass sie völlig falsch ist. Bei Einführung von "agil" kündigen in der Regel um die 10% der Mitarbeiter - die anderen machen mit.

Agil besteht aus zwei Komponenten: Einmal werden die Entwicklungszyklen verkleinert ("Sprints"), was zu weniger Fehlproduktion führt - auf der anderen seite dafür die Testaufwände in die Höhe treibt. Das muss m.E. nach von Fall zu Fall betrachtet werden.

Zusätzlich entsteht eine soziale Kontrolle der Mitarbeit. Das muss nicht negativ sein - für Arbeitsvermeider im Unternehmen ist es das aber sicher. Überspitzt kann es natürlich den Kontrollzwang eines Chef unterstützen, wenn er sich selbst zum Teil des Teams macht. Meiner Ansicht nach geht das aber gegen die "Werte", welcheman mit agil zu unterstützen sucht.

Die Bemerkung "Der Standish Chaos Report 2011 hat festgestellt dass Projekte, die mit agilen Methodiken erstellt werden eine deutlich höhere Wahrscheinlichkeit haben, erfolgreich abgeschlossen zu werden. Sind bei der Anwendung der Wasserfallmethodik nur 14 % erfolgreich, 57 % problematisch und scheitern 29 % der Projekte, so sind bei agilen Methodiken 42 % erfolgreich, 49 % problematisch und nur 9 % scheitern.[12]" im Text halte ich übrigens für Blödsinn. "Wasserfall" gibt es kaum (Hausbau!) in der Praxis, in den meisten fällen wird iterativ gearbeitet. Bitte mal die Quellenlage zu Wasserfall prüfen!! Zusätzlich ist die [Messmethode des Chaosreports] soweiso umstritten. Alex 13:11, 25. Nov. 2014 (CET)

In der IT gilt es zu lernen, dass man Qualität nicht durch eine bestimmte Methodik sichert, sondern durch gute Entwicklung und vor allem gute Entwickler, denen eine ausreichende Zeit für die Entwicklung zur Verfügung gestellt wird. Die agile Vorgehensweise verlagert das Grundproblem nur auf andere Köpfe und macht es leichter, einen Misserfolg trotzdem als Erfolg zu werten. In mehreren Unternehmen konnte ich beobachten, das die Umsetzung der agilen Softwareentwicklung ein verstecktes Verheizen von Mitarbeitern ist. Durch eng getacktete Sprints stehen vor allem die Executiven Mitarbeiter (also diejenigen, die das Produkt letzendlich herstellen) unter permanentem Leistungsdruck und müssten sich in Dailys, Reviews etc. regelmässig rechtfertigen. Zudem geht bei agilen Methoden sehr schnell der Blick auf die Gesamtheit der Lösung verloren. Ein Softwareprodukt ist nun einmal mehr als eine Ansammlung von User Storys! Bezeichnend ist, das weder im Artikel über Agile Softwareentwicklung noch im Artikel Scrum auf die Bedürfnisse der ausführenden Personenkreise eingegangen wird. Der Entwickler wird zum Erfüllungsgehilfen degradiert, der sich gegenüber dem PO zu rechtfertigen hat, wenn er in einem Sprint seine User Story nicht erfüllen konnte, weil ihm z.B. das Tagesgeschäft dazwischen gekommen ist. Bedingt durch meine Beratertätigkeit kenne ich Unternehmen, in denen es Projektmisserfolge so gut wie nicht gibt - ja, die gibt es. Diesen Unternehmen sehen keine methodische, sondern eine skill- und fachbezogene Organisation vor. RUP, Wasserfall kennne diese Unternehmen genausowenig wie agile Softwareentwicklung, Kanban und Scrum. Man setzt auf Spezialisten und nicht auf unversell einsetzbare Mitarbeiter, die alles zwar können aber nichts richtig. Auch den so gerne beschworenen Vorteil aus Kundensicht kann ich nicht erkennen. Ich benötige eine Lösung - skiziere mir diese, wir fixieren das in einem Lastenheft, welches das Ganze beschreibt, du machst mir ein Preisschild dran und sagst mir wann du fertig bist - Punkt. Software lässt sich nicht ingenieursmässig entwickeln und auch nicht beliebig modularisieren - bin gespannt, wann man das endlich einmal kapiert. 2003:CB:A3DC:1001:E8C8:102E:C6BF:E7EB 00:19, 27. Jun. 2018 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Schotterebene (Diskussion) 07:15, 27. Sep. 2020 (CEST)

Methode ergänzen

Ist Scrum#Planungspoker auch eine erwähnenswerte Methode? --Dasichs (Diskussion) 22:15, 21. Feb. 2016 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Schotterebene (Diskussion) 07:15, 27. Sep. 2020 (CEST)