ruynk

Systemanalyse - Software Entwicklung - Qualitätssicherung - Projektmanagement - FlePA



Interne Links



Inhalt

Was soll man unter "Agile" verstehen?

Analyse des "Agilismus"

Das Irrlicht "Agile"

Die bizarre Mythologie der SW-Entwicklung

Missgeburten der "Agilen" - Ausblick

Getting Real: Einige Gedanken bezueglich SW-Entwicklung

Das Projekt: Warum ist die Projektarbeit unberechenbar

Wer ist "ruynk"?

FlePA (Flexibles Planen und Arbeiten)

Mit ruynk zusammen arbeiten

Downloads und externe Links

Impressum - Kontakt








Ich distanziere mich nicht: Unsinnige Rechtslage in der BRD.






Die agilen Methoden haben sicherlich sowohl Vorteile als auch Nachteile. Alle beide müssen bekannt und berücksichtigt werden um eine Entscheidung für oder gegen eine bestimmte Vorgehensweise zu treffen.



Positive Eigenschaften der agilen Methoden

  • Eine intensive (erzwungene) Kommunikation hilft einem Team, besser zu arbeiten.
  • Es gibt Mitarbeiter, die es genießen, Entscheidungen treffen zu können.
  • Manchmal wird durch die Agilen einen so rigiden Rahmen erzwungen, dass manche Mitarbeiter sich darin wohl fühlen, da alles vorgegeben; Denken nicht nötig.
  • Mitarbeiter werden durch den Prozess getrieben, glauben aber, dass es Eigenantrieb ist.
  • Die ’agilen’ Methoden sind ein Versuch, unfähige Mitarbeiter zur Arbeit zu befähigen. Die Qualität der Ergebnisse hält sich in Grenzen.
  • Besonders Scrum ist einfach zu implementieren, ist jedoch nicht zu verstehen.
  • Die viele Meetings lassen den Mitarbeitern sich wichtig fühlen.
  • Dadurch, dass das Team sich "selbst organisiert", verschwinden oft Risiken, die durch falsche Entscheidungen des Managements entstehen. Dafür entstehen neue Risiken durch falsche Entscheidungen der Mitarbeiter. Wer die besseren Entscheidungen trifft ist selten im Voraus zu bestimmen.
  • Nicht belegt: Die Produktivität soll steigern (schneller, besser, weiter: siehe hierzu den Vergleich Agile vs. nicht Agile).


Anmerkung: Nicht immer kommen alle Vorteile vor; es kommt auf die Implementierung, das Team und das Management an.



Negative Eigenschaften der agilen Methoden

  • Die agilen Methoden erlauben das Nicht-Denken indem man sich dem Prozess liefert (Prozessorientierung statt Zielorientierung). Kopflosigkeit als Folge. Mehrarbeit als Ergebnis.
  • Verschwendung von Zeit und Ressourcen durch Aufblähen der Verwaltungsarbeiten um die agilen Prinzipien zu genügen.
  • Der Buhmann ’Wasserfall’ bedingt eine immer wieder kehrende rhetorische Frage: "sollen wir etwa Wasserfall machen?" (am Besten mit Empörung in der Stimme) welche jedoch ein Appell ohne Grundlage ist (siehe die ’Untersuchung’). Das soll eine Bestätigung der Methode darstellen.
  • Das agile Scrum verkommt zu einer Verhandlungsmarathon mit Poker Spielchen, Story Points und Story Abnahmen, Grooming und Retros wobei der Fokus erstaunlich schnell weg von dem Ziel und hin zu Verwaltungsaufgaben verschoben wird. Das ist kontraproduktiv (alle diese Tätigkeiten verringern die Produktivität).
  • Infantile Vereinfachung (user stories: "As a ... I want ..."; ), stellen eine Beleidigung für Profis dar.
  • Die agilen Methoden sind eine Goldgrube für teure aber produktiv gesehen sehr beschränkte "Berater" (auch als Scrum Master bekannt) und damit eine Geldsenke für Unternehmen.
  • Buzzwort-Reiterei (siehe die Mythen); propagandistisch benutzte aber inhaltslose Wörter lassen den Eindruck entstehen, dass die agilen Methoden durchdacht wären und Sinn machen.
  • Aufgeblähtes Refactoring bedingt durch planloses Arbeiten, welches mit jedem "Sprint" exponentiell wächst.
  • Automatisierte Tests für eine SW-Entwicklung in einem Projekt (wenn alles am Entstehen ist) ist schlichtweg hirnamputiert (nicht zu kurz gedacht sondern überhaupt nicht nachgedacht). Die Geschichte ist folgende: Ignorante Amis haben versuch von der hohen Qualität der Japaner zu lernen und geglaubt, sie könnten automatisierten Tests, so wie sie in der Serienproduktion von den Toyota Autos vorkommen, auch für die SW-Entwicklung anwenden. Es dürfte ohne Weiteres klar sein, dass das irrsinnig ist (Serienproduktion ist nicht Projektarbeit).


Scrum-Sprint

1. Anmerkung: Scrum wird (weiß der Teufel warum) als "agil" verkauft, ist es aber nicht wirklich. Man kann agile Elemente aufnehmen, ja, doch dadurch wird es nicht agil "a priori". Durch die Sprint-Zwangsjacke verkommt Scrum zu einer langen Kette von kleinen aufeinanderbauenden Wasserfälle.


2. Anmerkung: Nicht immer kommen alle Probleme zusammen vor; es gibt anscheinend Teams, wo die "agilen" funktionieren. Die kenne ich nur vom Hörensagen. Denkbar ist es vielleicht, dass einige Kollegen subjektiv die negativen Eigenschaften selektiv nicht wahrnehmen, die positiven im Gedächtnis aufwerten. Es könnte auch sein, dass manche Mitarbeiter durch Propaganda und schöne Buzzwoerter, durch Verschiebung des Fokus vom Ziel zu Ritualen, einen falschen Eindruck ins Gedächtnis speichern.



Agile Probleme

Als Folge der Anwendung von den agilen Entwicklungsmethoden entstehen neue Probleme.
  • Viel Verwaltung um die "Methode" zu begnügen; m.a.W. Zeitverlust
  • Fokusverlust (Verschiebung des Fokus vom Produkt zum Prozess)
  • Das Projektmanagement mangelt an Führungsbefügnisse (wobei das kann sich u.U. recht positiv auswirken, insbesondere bei Firmen, wo die "Agilität" einzug hält)
  • Scrum ist in Wirklichkeit (mikro-)plangetrieben - in Sprints - (oder, wie ich in der Untersuchung schreibe, eine ungeplante Rigidität - man plant einen Sprint aber nicht mehr-); funktioniert nach Mikro-Planungszyklen (so viele wie möglich, - eine Art Mikrowasserfall - Stichwort "Continuous Delivery"): Entwicklung in Sprints/Time Boxes: Ein Produkt (Inkrement, Feature oder was auch immer) ist fertig jedoch wenn es wirklich fertig ist; Das Zwingen von Inkrementen in festen Zeitspannen ist realitätsfern.
    Außerdem fördert "Scrum" das Mikromanagement.
  • Als Folge der gewollten ständigen Änderungen in Architektur, dann Design, dann die Programme selbst, ist die mit agilen Methoden erstellten Software sehr schwer zu warten
  • Das Testen wird weitgehend ignoriert (weil in den Prinzipien nicht berücksichtigt... wurden auch von "Entwickler" geschrieben!)
  • Die Qualität ist mangelhaft (weil in den Prinzipien nicht berücksichtigt)
  • Bug-, Tests- und Qualitätsmanagement nicht immer wirklich im Prozess integriert. Als Folge ist die mit agilen Methoden erstellten Software sehr "buggy"
  • Qualitätsicherung wird i.A. in einer agilen Umgebung verwässert; "Qualität" wird schlichtweg mit "Testen" gleichgestellt (Entwicklersicht halt)
  • Risiken werden ignoriert (weil in den Prinzipien nicht berücksichtigt)



Fazit

Im Großen und Ganzen lässt sich sagen, dass die Implementierung von einer agilen Methode einige Probleme lösen kann, dafür aber werden andere geschaffen.







Design und Realisierung: ruynk - November 2016

Verlinkung zu diesen Seiten erlaubt.

Zuletzt Bearbeitet: Ruy C. N.-Kuhlmann, Feb. 2017