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.






Wir
schweben in den Wolken... Immer wenn man irgendwie Geld verdienen (oder einfach so bekommen) kann, sind gleich findige Gestalten an Ort und Stelle und kriegen es fertig mit hübschen Wörter und viel Versprechungen etwas zu verkaufen, was nicht hält, was es verspricht.

Früher wurden solche Menschen Quacksalber genannt.

Heute sind sie als Berater beim mittleren Management von Unternehmen zu finden.


Die vielen hübschen Begriffe, die man zurzeit in der "agilen" SW-Entwicklung verwendet, werden "Buzzwörter" genannt.

Anhand diesen Begriffen lässt sich ein Glaubensgebäude errichten und festigen.

Weiter, und wahrscheinlich um die Pfründe zu konsolidieren, entstand eine Märchenwelt, die vor allem die zahlenden Kundschaft anspricht und mit gewagten Versprechungen um sich wirft.


1. Buzzwörter der "Agilen"

Viele englischen Begriffe sind hier zu finden (besonders Wörter die etwas anderes bedeuten sollen als die herkömmliche Bedeutung, sind "Buzzwörter"). Darunter
  • Velocity
  • Story
  • Story Points
  • Grooming
  • Retrospektive
  • Sprint
  • Scrum (Gedränge)
  • Teamverantwortung


2. Glauben

Unter dem "Glauben" fallen viele Ideen (Annahmen), die schön zu glauben sind (weil sie einfach klingen) aber nicht belegt oder gar zu belegen sind.
  • Pair Programming verbessert Ergebnisse
  • Tester und Entwickler sollen zusammen arbeiten. Steigerung: Entwickler sollen testen und Tester sollen entwickeln!
  • Verschiedene Entwickler erzielen die gleiche "Velocity"
  • Stories sind beliebig teilbar
  • Story Points stellen für alle die gleiche Wertung
  • Zustand ist ständig Lieferbar
  • Transparenz verbessert die Entscheidungsnahme durch die Teammitglieder
  • Scrum, richtig angewendet, funktioniert
  • Scrum, richtig angepasst (taylored), funktioniert
  • "Wasserfall" ist grottenschlecht; alles ist dem vorzuziehen. "Wasserfall" fungiert als einziges und alleiniges Gegenpol von "Agile" und als der Satan, der die Verwendung von agilen Methoden regelrecht erzwingt.


3. Märchen

Und dann gibt es noch hübsche Geschichten die zu einer Mythologie aufgeblasen werden, die wiederum schön zu glauben sind (weil sie schlüssig klingen) aber nicht belegt oder gar zu belegen sind.
  • Mitarbeitermotivation: Motivierte Mitarbeiter leisten mehr; man soll schlicht die Mitarbeiter mit Spielchen bei Laune halten und alles wird gut
  • Bottom-Up Intelligenz (gemeint ist, dass die Mitarbeiter viel Wissen haben und Entscheidungen treffen sollen)
  • Selbstorganisierte Teams leisten viel mehr als "fremdorganisierte" Teams
  • Es ist immer möglich, funktionierende Produktinkremente zu liefern
  • TDD verbessert ohne Weiteres die Qualität und hilft hochqualitative Software zu entwickeln
  • Community of Practice (oder Kreis, Board, etc) verbessert die Ergebnisse
  • Scrum kann Probleme (schlechte Qualität, zu viele Bugs, falsche Prozesse etc.) ans Tagelicht bringen, so dass man sie beheben kann


Einige von diesen Ideen sind nicht neu und auch nicht eine Exklusivität der agilen Methoden.


Es gibt Konzepte die schon seit vielen Jahre existieren, die aber von der agilen Ideologie übernommen wurden und der Versuch unternommen wurde, diese Ideen zu "verbessern". Durch Dogmatismus und Fokusverlust blieb die "Verbesserung" auf der Strecke liegen, die Buzzwörter dafür aber desto stärker in Verwendung.


Viele der agilen Ideen sind darüber hinaus (in der harten Projektpraxis) schlichtweg Wunschdenken.




Design und Realisierung: ruynk - November 2016

Verlinkung zu diesen Seiten erlaubt.

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