Warum "FlePA"

Hier ein bisschen Information, zum Runterladen:

http://www.ruynk.com/downl/Warum_FlePA.pdf

"Agile" Methoden vergleichen: Anstoße zum Nachdenken

Hier:

Gedanken zu einem Vergleich zwischen "Agile" und "nicht Agile" (Version vom 25.01.2017)

und

Vergleich zwischen agilen Entwicklungsmethoden (Version vom 25.01.2017)

Viel Spaß beim Lesen!

ruynk

'Copy und Paste' beim Buchschreiben - ein kurzer Kommentar

Irgendwie schaffen die "Agilen" von sich reden zu lassen, wenn auch der Autor eigentlich besser täte, sich nicht zu äussern... So entstehen falsche Eindrücke, Dogmatisches und 'Hören-Sagen', wenn man ungeprüft Text durch Kopieren entstehen lässt. Oder soll ich die Aussagen vom Autor im Buche einfach als "Modererscheinungen" gelten lassen?

Im Buch "Projektmanagement" von Patzak und Rattay, 6. aktualisierte Auflage, Seite 703, kann man einen Vergleich zwischen Agilen und Klassischen Entwicklungsmethoden lesen. Hier meine Kommentare, nicht in Tabellenform sondern als Liste:

1)
Agiles Wert: Vertrauen
Klassisches Wert: Misstrauen/Kontrolle
Meine Meinung dazu: Man hat es sich hier viel zu einfach gemacht (m.a.W. einfach die "agile" Propaganda übernommen). Die Aussage stimmt nicht: Unter Scrum z.B. kommt es häufig zu einem unerträglichen Mikromanagement. In den "klassischen" andererseits spricht nichts dagegen, dass das Management in dem, was die Entwickler tun (entwickeln halt), Vertrauen hat.

2)
Agiles Wert: Verantwortung des Teams
Klassisches Wert: Gesamtverantwortung Projektleiter
Meine Meinung dazu: Das mit der Verantwortung des Teams ist Wunschdenken.

3)
Agiles Wert: Selbstorganisation im Team
Klassisches Wert: Führung durch den PM
Meine Meinung dazu: Das mit der Selbstorganisation des Teams ist Wunschdenken (kann funktionieren, muss aber nicht).

4)
Agiles Wert: Schätzungen/Entscheidungen im Team
Klassisches Wert: Vorgaben/Entscheidungen durch Projektleiter/Auftraggeber
Meine Meinung dazu: Mitarbeiter im Team sind dazu da, ihre Arbeit zu machen, nicht (r)um zu schätzen. Entscheidungen waren schon immer eine Domaene des Managements. So eine Vorgehensweise macht nicht immer Sinn (eher ausnahsweise, gebe ich zu - wenn das Management ein 'Management' ist, sie meine "Untersuchung...": Downloadseite bei www.ruynk.com)

5)
Agiles Wert: Auftraggeber-Koordination durch das Umsetzungsteam
Klassisches Wert: Auftraggeber-Koordination durch Projektleiter
Meine Meinung dazu: Das Team als solches ist dazu da, die Arbeit zu erledigen, nicht um Auftraggeber zu koordinieren.
Der Gedankenfehler hier scheint mir der zu sein, dass die "Agilen" das Team als eine Person (Entität) betrachten, anstatt, wie es tatsächlich ist, als eine arbeitende Menge von Individuen.

6)
Agiles Wert: Prozessoptimierung durch das Team
Klassisches Wert: Prozessoptimierung angestossen durch den Projektleiter
Meine Meinung dazu: Um ein Prozess zu optimieren, soll man es gut kennen und die angrenzenden Prozesse sollen auch noch berücksichtigt werden; selten wird es der Fall sein, dass ein Team das notwendige Know-How hierzu hat.

7)
Agiles Wert: Teamprozessreflexion durch das Team selbst
Klassisches Wert:  Teamprozessreflexion auf Initiative des Projektmanagers
Meine Meinung dazu: In der Wirklichkeit kann man aber deutlich beobachten, dass der "Prozess Master" (Name verwendet für die Rolle des 'Scrum Master' in dem o.g., Buch so fern ich das verstanden habe) die ominöse "Reflexion" anstosst, regelmässig, auch ohne Notwendigkeit, aus dem "Prozess" heraus, oft mit Null Zugewinn, also eher Zeitverlust (solange lustige Spielchen nicht als Zeitgewinn zu verbuchen sind).

Ein schneller Blick auf die agilen Methoden aus Sicht der Qualitätssicherung

Aus Sicht der Qualitätssicherung sind die agilen Methoden NICHT TRAGBAR.

Anmerkung: "Testen" ist NICHT Qualität sichern!

Folgende wichtigen Punkte der Qualitätsicherung sind in den "Agilen" nicht berücksichtigt:

1. Qualitätsmanagement ist nicht existent

2. Risikomanagement ist nicht berücksichtigt

3. TDD: Hierbei wird i.A. nur der "Gutsfall" getestet.

Dazu kommen noch weitere Probleme, wie z.B.

1. automatisierte Tests die wenig testen und einen riesigen zu Wartungsaufwand haben,

2. Bugs die übersehen und vergessen werden,

3.die Wartbarkeit von Code wird, langsam aber sicher, mit jedem Sprint durch unbedachtes Design (und keine Planung) erschwert.

… und noch Einiges, aber nichts Gutes.

Schrecklich, was wir IT Leute uns antun im Namen der „agilen“ Religion.

5 Schwachpunkte von Scrum

Hier zu lesen:

http://www.ilker.de/funf-schwachpunkte-von-scrum.html

Finde ich gut.

Aberglaube bei den SW-Entwicklungsmethoden

Der Glaube, dass eine "Entwicklungsmethode" ueber das "nicht Scheitern" oder ueber die Qualitaet oder gar "Geschwindigkeit" einer Entwicklung bestimmen kann,

ist so abstrus als wuerde man glauben,

ein Motor im Auto soll in der Laengst- oder in der Querrichtung der Fahrrichtung liegen, um den Wirkungsgrad erheblich zu ändern.

Dummes Zeug. Maßgebend sind die Menschen (Mitarbeiter); Erfahrung, Umgebung (Fehlerfreiheit), und so weiter und so fort: Viel eher als eine bestimmte Entwicklungsmethodik...

Warum "agile" Methoden nicht "Lean" sind

Agility/Velocity: Schnell und oft Fehler erzeugen

Gut: Man lernt mehr aus Erfahrung

Schlecht: Zeitverschwendung, anstatt zu denken (Vorsicht walten lassen) produziert man Fehler. Das is Muda (Verschwendung, Lean Prinzipien), somit gegen "Lean"

Die "agilen" Methoden zielen nicht darauf, Verschwendung zu vermeiden sondern viel mehr setzen darauf, diese zu produzieren. Durch:
- Meetings (ohne klare Ziele, mit Kollegen, die nicht nötig sind, usw); die überflüssige Verschwendung
- Wenig Planung und somit überflüssige, doppelte Arbeit, und Arbeiten, die zu spät oder zu früh erfolgen; die dumme Verschwendung
- Nie endende Änderungen; die reinste Verschwendung
- Teams, die sich selbst organisieren sollen; die umständliche Verschwendung.