Werden sog. "agile" Software-Entwicklungsmethodik und SCRUM nun endlich als das erkannt, was sie schon immer waren: ganz entsetzlich naive Irrwege?
|
Mehr als 260 Prozent höhere Fehlerrate07.06.2024
Manfred Bremmer (Senior Editor IoT & Mobile der Computerwoche):
Einer Studie zufolge scheitern Softwareprojekte, die agile Methoden anwenden, mit einer um 268 Prozent höheren Wahrscheinlichkeit als Projekte, die dies nicht tun.
https://www.computerwoche.de/a/ist-agile-softwareentwicklung-nutzlos,3698799
5 Stimmen
Was zum Geier ist eigentlich dieser "agile Kram" genau? Alles was ich dazu bisher finden konnte waren absolut nichtssagende Müllkippen von ausgelutschten Buzzwords...
Meine Fresse, das ist GENAU der Müllhaufen den ich auch schon gefunden hatte... Kein bisschen KONKRETE Information darüber WAS GENAU dieser "agile Müll" ist...
Für die meisten ist Agile = SCRUM. Leider ist das wirklich nur Mist.
Okay und was zum Anorak ist dieses SCRUM?! Versuch wenigstens mal zu definieren worum es dir eigentlich geht... -.-
Scrum ist ein Rahmenwerk für die Zusammenarbeit von Teams basierend auf einer Definition von Rollen und sog. "Stand up Meetings".
6 Antworten
Keine der Optionen spiegelt meine Meinung wieder.
Agile Methodik hat schon ihren Sinn, aber sie wird in meinem Berufsumfeld für alles eingesetzt.
Also werden dann auch gerne mal Projekte gestartet, die mit nicht agilen Methoden vermutlich nie gestartet werden würden, da man früher erkannt hätte, dass der Wunsch der Kunden nicht ins Budget passt oder gar nicht das ist, was sie wirklich wollen.
Am Ende steht dann ein Produkt, was keiner nutzt, aber schon ne Menge Kosten verursacht hat.
Man lese auch: https://www.computerwoche.de/a/fragil-statt-agil,3550419
Lies insbesondere: https://www.bing.com/search?q=Agile+site%3Agreiterweb.de%2Fspw
SCRUM ist laut Definition - anders als viele das immer behaupten - keine Entwicklungsmethodik oder ein Entwicklungsmodell, sondern eher ein "Framework".
Das ganze soll mehr oder weniger einen "Rahmen" liefern an den man sich hält, um dann eigene Techniken / Prozesse mit einzubinden.
Die Aussage "SCRUM führt zu schlechterer Softwarequalität als schwergewichtige Entwicklungsmodelle" halte ich für sehr schwierig, schon alleine weil man heutzutage die "anderen" Modelle nur sehr begrenzt noch sinnvoll einsetzen kann -> Technologien und Anforderungen ändern sich einfach viel zu schnell dafür.
Dazu ist SCRUM definitiv so anpassbar, dass man es auch auf "höhere Softwarequalität" optimieren kann - es ist und bleibt ein Framework, kein Modell.
Für z.B: Anforderungsentwicklung ist in SCRUM eigentlich kein Bestandteil vorgesehen, trotzdem kannst du das in SCRUM Einbauen.
Ich stimme der Aussage nur zu, wenn man sich auf "Lehrbuch-SCRUM" bezieht, das machen heute aber nur noch sehr wenige Unternehmen.
SCRUM ist ein (allzu naiver) Versuch, zu regeln, wie Mitglieder eines Teams, das ein komplexes Produkt zu entwickeln trachtet, am sinnvollsten zusammenarbeiten sollten:
SCRUM und Co sind keine Irrwege.
(KANBAN habe ich produktiv nie genutzt, daher rede ich im Folgenden nur von SCRUM)
SCRUM und Co. sind auch keine "Methoden", das verstehen viele nicht.
SCRUM ist eine Art Prozess-Framework, das muss man auf den eigenen Prozess anpassen, bis es passt. Das dauert durchaus seine Zeit und funktioniert nicht immer, aber kann durchaus viel bringen.
Viele Firmen/Teams streichen dann aber häufig genau die Details raus, die im SCRUM sehr wichtig sind und haben dadurch dann keine Vorteile, aber alle Nachteile.
Abgesehen davon:
Mit Bugs hat das nichts zu tun.
Wenn die Teams, die SCRUM nutzen, mehr Bugs haben, dann hatten sie das auch schon vorher.
Auch das habe ich so schon "live und in Farbe" gesehen: Viele Firmen/Teams haben einen miesen Prozess und hoffen dann, dass SCRUM ihren Prozess "korrigieren" kann, was natürlich Mist ist. Der Prozess bleibt schlecht.
Und dann habe ich auch schon einige Fälle gehabt, wo es zwar hieß, dass sie SCRUM nutzen, tatsächlich ist von SCRUM aber nur noch das Daily übrig geblieben und für sich alleine genommen hat das 0 Mehrwert und kostet nur Zeit.
Generell kann man aber auch sagen, dass "Agil" falsch verstanden wird.
Häufig wird "Agil" als "wir springen sofort, wenn Kunde was will" interpretiert, was falsch ist.
Dafür gibt SCRUM unter Anderem auch einen Rahmen vor, wenn man den dann aber raus streicht, weil es angeblich nicht auf die eigenen Prozesse passt, braucht man sich nicht wundern, wenn nichts funktioniert.
Erstmal: SCRUM ist nicht gleichbedeutend mit Agiler Softwareentwicklung. Es gibt sicher einiges an SCRUM auszusetzen und ich bin kein großer Fan dafür.
Das größte Problem mit Agiler Softwareentwicklung ist, dass das was das unter "Agil" verkauft wird, gar nicht agil ist. D.h. die meisten "Agilen" Projekte sind gar nicht agil, weil es falsch verstanden wird.
Diese "Studie" ist aber nicht aussagekräftig. Zum einen weil die Zahl der Projekte zu klein ist um wirklich statistisch signifikante Aussagen treffen zu können, und zum Anderen weil es direkt mit der Methode "Impact Engineering" verglichen wird, eine Methodik welche die Herausgeber der Studie erfunden haen.
"Impact Engineering" ist doch nichts weiter als Name für das in der linken Hälfte des Bildes gezeigte Spektrum von Projekt-Charakteristika (für die gesagt wird, in welchem Ausmaß sie in realen Projekten Projekterfolg implizieren: durchaus in guter Übereinstimmung mit meiner eigenen 30-jährigen Erfahrung im Software-Entwicklungsbereich).
Dass die letzte der 5 genannten Eigenschaften erfolgreicher Projekt (= "No late Requirement Changes") sich als die am wenigsten einflussreiche erwies, liegt ganz sicher mit daran, dass sie in heutigen größeren Projekten realistischer Weise gar nicht mehr gegeben sein kann. Es könnte sonst ja das besonders wichtige Ziel 3 nicht mehr angesteuert werden: jenes also, das echte Agilität, die im positiven Sinne, erfordert. Sie als unverzichtbar anerkennen zu müssen ist Folge der Tatsache, dass man ja erst während der Durchführung des Projekts auf wichtige Detailanforderungen stößt, die vorweg noch nicht abzusehen waren. Man trägt dieser Situation dadurch Rechnung, dass man tatsächlich jede der Phasen des Wasserfallmodells erst bei Projektende als endgültig abgeschlossen anerkennt.
"Impact Engeneering" ist der Projektentwicklungs Ansatz der von der Firma, die diese Stude in Auftrag gegeben hat, propagiert wird. Im Artikel steht ja auch ganz am Anfang
So ergab die von der - nicht unbedingt neutralen - Beratungsfirma Engprax in Auftrag gegebene Umfrage, dass 65 Prozent der Softwareprojekte, bei denen agile Anforderungen an die Entwicklung von Verfahren angewendet wurden, nicht rechtzeitig, nicht innerhalb des Budgets und nicht mit einem hohen Qualitätsstandard abgeschlossen wurden.
Den Rest kann man sich eigentlich sparen, auch wenn es durchaus viele Kritikwürdige Punkte an der Agilen Softwareentwicklung gibt. Der Hauptgrund dafür dass Agile Projekte so oft Probleme haben ist meiner Ansicht nach, dass sie falsch verstanden und/oder eingesetzt wird. Wobei man natürlich berechtigt hinterfragen kann, warum das so ist..
Der Hauptgrund dafür dass Agile Projekte so oft Probleme haben ist meiner Ansicht nach, dass sie falsch verstanden und/oder eingesetzt wird.
Da ist was Wahres dran, denn:
Agile Software-Entwicklung (allgemeiner: auf ein vorher vereinbartes Ziel im Auftrag anderer hinzuarbeiten), bedeutet ja, die zunächst vereinbarte Zielvorgabe in dem Sinne immer dann in Frage zu stellen, wenn neue Erkenntnisse oder Anforderungen das als sinnvoll erscheinen lassen. Nun ist das aber stets auch aufwandsrelevant. Was aber, wenn man vereinbart hat, das Projekt zum Festpreis abzuwickeln?
Richtige, einzig sinnvolle Antwort darauf wäre geeignetes Change Management.
Wer als Auftraggeber das nicht einsieht (also keine zusätzlichen Kosten zu akzeptieren gedenkt), wird letztendlich eine nicht mehr wirklich passende Lösung bekommen — mit ihr also nicht zufrieden sein.
ganz kurz: weil kaum jemand XP oder Scrum richtig versteht oder anwendet. Und wenn man sie falsch anwendet, dann bringen agile Methoden gar nichts.
Manfred Bremmer beschäftigt sich mit (fast) allem, was in die Bereiche Mobile Computing und Communications hineinfällt. Bevorzugt nimmt er dabei mobile Lösungen, Betriebssysteme, Apps und Endgeräte unter die Lupe und überprüft sie auf ihre Business-Tauglichkeit. Bremmer interessiert sich für Gadgets aller Art und testet diese auch.
Leider hat der Herr sogut wie keine Ahnung - von Erfahrung ganz zu schweigen - über dieses Thema.
Bremmer ist ja nichts weiter als der Journalist, welcher darüber berichtet, was andere erkannt haben. Seine Arbeit deswegen gering zu schätzen ist ganz sicher nicht gerechtfertigt.
Tatsache jedenfalls ist, dass man bei Engprax (= https://www.engprax.com/ ) sehr genau den richtigen Zusammenhang erkannt hat: weit treffender jedenfalls als die Autoren des Agilen Manifests oder gar die Erfinder von SCRUM.
Von Journalismus halte ich grundsätzlich wenig, denn der Beitrag unterstützt lediglich eine Annahme, bietet keine Lösungen, ist nicht neutral und drängt eine Meinung auf. Daher ist der Beitrag aus meiner Sicht nicht weiter erwähnenswert.
Der einzige Zusammenhang hier ist: shit in, shit out.
Man sollte sich also überlegen, ob der Input richtig ist. Ist der Input minderwertig, wird es der Output ebenso. Das ist der einzige Zusammenhang. Scrum, XP, Lean etc. sind keine Hexereien, sie bewirken keine Wunder bei miserablen Prozessen. Das ist der "Agile is dead"-Fraktion einfach nicht klar.
Mindestens SCRUM und – schlimmer noch – XP sich doch selbst einfach nur ganz miserable Prozesse bzw. Prozessmuster.
Sie geben allzu naive Antworten auf die Frage nach notwendiger Agilität beim Entwickeln von Software.
Ouch, jetzt fühle ich mich persönlich angegriffen :)
Nein, Scrum und XP sind keine Prozesse - es sind Frameworks. Ich gehe davon aus, dass du die Begriffe trennen kannst. Prozess <> Framework.
Ich möchte nicht persönlich werden, aber du zeigst gerade, warum agile Methoden bei manchen Teams nicht funktionieren. Sie werden mit Prozessen verglichen. Eine gaaaanz falsche Richtung.
Daher sagt das agile Manifest: Menschen und Interaktionen über Prozesse und Tools. Wobei ich schon rieche, was als nächstes von dir kommt. Daher vorab: Prozesse INNERHALB des Frameworks sind notwendig.
Ein Framework ist ein Programmiergerüst, das in der Softwaretechnik, insbesondere bei der objektorientierten Softwareentwicklung sowie bei komponentenbasierten Entwicklungsansätzen, verwendet wird. Im allgemeineren Sinne bezeichnet man mit Framework auch einen Ordnungsrahmen. Wikipedia
In meinen Augen ist sog. Agile Methodik (sie erschöpft sich in SCRUM und dem Agilen Manifest) etwas allzu Naives, auf das sich nur Leute berufen, die gar nicht wirklich verstanden haben, worin notwendige Agilität im Software Engineering denn eigentlich bestehen muss: In der Einsicht nämlich, dass sämtliche Phasen des klassischen Wasserfallmodells erst als endgültig beendet gelten dürfen, wenn man die fragliche Software nicht mehr länger benötigt. Vorher muss jedes Ergebnis, das sie bisher lieferten, als womöglich nicht endgültig, d.h. durch neue Einsichten revidierbar anerkannt werden, kurz: Man darf nicht festhalten wollen an etwas, das man selbst oder andere als nicht wirklich akzeptabel erkannt haben (auch dann nicht, wenn man für Kunden im Rahmen eines Festpreis-Projektes arbeitet - ggfs. muss geeignetes Chance Management Interessenkonflikte lösen).