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
Lebenslanges Lernen.
50 Jahre Berufserfahrung.
30 Jahre IT.
Und jetzt: Künstliche Intelligenz
Erfahrung trifft Innovation.
Mittwoch, 25. Januar 2017
Freitag, 6. Januar 2017
'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).
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).
Montag, 28. November 2016
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.
Montag, 3. Oktober 2016
5 Schwachpunkte von Scrum
Hier zu lesen:
http://www.ilker.de/funf-schwachpunkte-von-scrum.html
Finde ich gut.
Dienstag, 13. September 2016
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...
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...
Montag, 25. Januar 2016
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.
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.
Mittwoch, 6. Januar 2016
Über das V-Modell XT
Habe interessiert gelesen.
Irgendwie scheint die BRD hier, (also zu einem Modell!), Eigentumsansprüche erheben zu wollen.
Schon Software-Patente sind ein "Unding". Dummes Zeug. Eine Möglichkeit, höchstens, arbeitslosen Juristen zu Geld zu verhelfen.
Wie bereits erwähnt, ist ein "Wasserfall" Modell in der Software-Entwicklung eher unmöglich: Das gab noch nie.
Der Glaube, dass so etwas existiert, verbreitet sich durch Hören-Sagen. Bei der "oose" in Hamburg gab mal ein Artikel über das Thema, den ich aber nicht mehr finden kann :-(
Es ist aber auch nicht so schlimm: Inhalt; Wasserfall gab es nie, es war nur ein Name für eine Modellierung bei einer Studie.
Das V-Modell XT ist nichts anderes, in meinen Augen, als die Ausarbeitung eines "Wasserfalls" Modell mit den Folgerungen, die dieses inexistentes Modell logischerweise haben müsste/hat.
Und von daher also, ist das ominöse V-Modell XT nichts anderes als das wirkliche, lebende, anwendbares "Wasserfall"-Modell :-D
Meiner Meinung nach, nicht schlecht, gut sogar bei einer Vielzahl von Anwendungen. Besser auf jeden Fall als die berühmten "agilen" Methoden.
Vielleicht würde sich ein V-Modell XT, kombiniert mit "Lean"-Prinzipien, eines Optimum nähern.
Und sicher für viele Projekte die bessere Lösung darstellen.
Irgendwie scheint die BRD hier, (also zu einem Modell!), Eigentumsansprüche erheben zu wollen.
Schon Software-Patente sind ein "Unding". Dummes Zeug. Eine Möglichkeit, höchstens, arbeitslosen Juristen zu Geld zu verhelfen.
Wie bereits erwähnt, ist ein "Wasserfall" Modell in der Software-Entwicklung eher unmöglich: Das gab noch nie.
Der Glaube, dass so etwas existiert, verbreitet sich durch Hören-Sagen. Bei der "oose" in Hamburg gab mal ein Artikel über das Thema, den ich aber nicht mehr finden kann :-(
Es ist aber auch nicht so schlimm: Inhalt; Wasserfall gab es nie, es war nur ein Name für eine Modellierung bei einer Studie.
Das V-Modell XT ist nichts anderes, in meinen Augen, als die Ausarbeitung eines "Wasserfalls" Modell mit den Folgerungen, die dieses inexistentes Modell logischerweise haben müsste/hat.
Und von daher also, ist das ominöse V-Modell XT nichts anderes als das wirkliche, lebende, anwendbares "Wasserfall"-Modell :-D
Meiner Meinung nach, nicht schlecht, gut sogar bei einer Vielzahl von Anwendungen. Besser auf jeden Fall als die berühmten "agilen" Methoden.
Vielleicht würde sich ein V-Modell XT, kombiniert mit "Lean"-Prinzipien, eines Optimum nähern.
Und sicher für viele Projekte die bessere Lösung darstellen.
Montag, 23. November 2015
Software-Entwicklung: Ist Chaos eine positive Eigenschaft bei der Entwicklung?
Chaos aus Kundensicht
Zunächst ist es wichtig zu betonen, dass ein "Kunde" für sein "gutes Geld" eine ordentliche Ware oder DL (Dienstleistung) erhalten will, die eine Qualität aufweist, wie der Kunde sie erwartet.- Eine Ware, die ordentlich produziert worden ist, dürfte in den meisten Fällen die Erwartungen des Kunden entsprechen.
- Eine Ware oder DL jedoch, die in einer chaotischen Produktionsumgebung entwickelt worden ist, dürfte in einer beträchtlichen Anzahl der Fälle nicht die Erwartungen des Kunden erfüllen, ganz einfach, weil in einer chaotische Umgebung Details ignoriert, vernachlässigt oder gar vergessen werden.
Hand aufs Herz: Würden Sie eine Buchhaltungs-Software kaufen, die eine Gruppe von Chaoten zusammen geschrieben haben mit wenigen bekannten Software-Fehler - oder doch lieber die Software von einem Entwicklungs-Team bei dem ganz genau geplant wurde, was zu tun ist, haben aber jedoch mehr Software-Fehler entdeckt, doch keine bekannten gravierenden Fehler enthalten sind?
Chaos als Ausrede
Es gibt Menschen, die stets versuchen auf dem "Schreibtisch" Ordnung zu haben; kämpfen gegen das Chaos.Wiederum gibt es andere Menschen, welche die Meinung vertreten, sie seien "kreative Chaoten". M.a.W. bedeutet das, dass sie nur aus einer chaotische Umgebung heraus eine kreative Arbeit erledigen können.
Organisieren
Organisieren ist doch der Versuch, Ordnung in einer ungeordneten Umgebung zu schaffen, um zu einem kontrollierten Ergebnis zu erlangen.Das Organisieren tut man nicht aus Spaß oder Langeweile, sondern weil man dadurch einen geplanten und durchdachten Ergebnis erzielt und somit die Kundenwünsche besser abdeckt.
Anmerkung
Ich möchte hier noch betonen, dass meine heutige Ausführungen sich nicht gegen die sogenannten "agilen Methoden" im Allgemeinen richtet; vielmehr beziehe ich mich auf alle Entwicklungs-Umgebungen die mehr chaotisch als geordnet arbeiten.Sowohl unter Anwendung von XP, Scrum, Kanban (ist das Agil?) usw kann eine stabile, organisierte Arbeitsweise statt finden.
Alles kann man organisieren.
Nur die sogenannten "agilen Methoden" lassen nicht nur mehr Freiraum (mehr Freiraum ist nicht schlecht, man muss ein bisschen mehr organisieren) -wo Chaos entstehen kann (nicht muss)- nein, das Problem ist, dass manchmal postuliert wird, das Chaos kreativ macht, produktiv ist.
Das mag für einzelnen Menschen vielleicht zutreffen, -obgleich nur unter sehr begrenzten Bedingungen- in den meisten Fällen jedoch (meiner Meinung nach) ist das eine Ausrede, um Schlampigkeit gut zu heißen.
Bei Teams dürfte die "Produktivität" unter chaotischen Umgebungen sehr, sehr rar sein... wenn sie überhaupt vorkommt, und wenn sie vorkommt, nur für eine ganz kurze Zeit.
Lösung
An der Lösung wird gearbeitet.Ich wollte heute nur einige Gedanken zur Dekonstruktion des Mythos des "Kreativen Chaos" beitragen.
Und wie gefährlich diesen Mythos für die Qualität ist, die ein Kunde erhält.
Leser: Habt Ihr Kommentare?
Freitag, 30. Oktober 2015
Was ist ( eigentlich ) "Agil"?
Zunächst einmal bin ich der Meinung, dass Software-Entwicklung IMMER agil ist, weil man die Software, die "weiche Ware" auch sehr schnell ändern kann.
Das ist ein Vorteil (man kann schnell anpassen) gleichzeitig aber ein Nachteil (man kann die Software "ad infinitum" ändern ("Änderitis"). Doch auf keinem Fall ist Software-Entwicklung nicht agil, egal welche Methode man anwendet.
Solche ständige Änderungen sind wohl auch Verschwendung im Sinne der "Lean"-Prinzipien (also gegen die "Lean" Prinzipien, die grundsätzlich gegen Verschwendung sind: also müsste eine Lean-Entwicklung grundsätzlich gegen Änderungen sein, somit aber auch gegen das, was eine SW-Entwicklung ausmacht...).
Und es sind aber auch solche Änderungen, die diese "agilen" Methoden befürworten, die dann auch zu aller Überfluss von vielen Menschen, Gruppen von Menschen und "Berater" sogar aller Couleur, gerne "Verkauft" werden; und dabei schießen sie sich, meiner Meinung nach, selbst ins Knie. Oder verdienen sich eine goldene Nase, je nachdem.
Scrum: agil oder nicht agil?
Es gibt außerdem auch Menschen, die behaupten, dass "Scrum" nicht agil sei.
Wieso?
Weil, zum Beispiel, täglich ein "Stand up" abgehalten wird. Sehr Starr. Nicht agil.
Dazu sehr feste Riten, wie zum Beispiel Retrospektiven, Planungsmeetings, usw.
Man kann eigentlich ohne weiteres postulieren, dass Scrum eine Art "Wasserfall" ist (wenn tatsächlich eine solche Konstruktion existieren würde), bei dem anstatt nach Funktionen nach "Timeboxing" entwickelt wird.
Schlicht und ergreifend "das Gleiche in Grün".
Und... sind andere "agile" Methoden auch "das Gleiche in Grün" ?
Mal sehen...
Nun stellt sich die Frage: Was ist "Agil"?
Zunächst gilt es, Abstand von dem unnützlichen "Manifesto" zu nehmen.
Nach der Definition von "Agilität":
- Gelenkigkeit {1}
- Aufgewecktheit {2}
- Gewandtheit {1}
- Lebendigkeit {2}
- Mobilität {1}
- Regsamkeit {2}
- Wendigkeit {1}
- Agilität {1}
- Flinkheit {1}
Es ist klar somit, dass jegliche Software-Entwicklung "agil" per se ist.
Vielleicht sollte eher das Ziel darin bestehen, zu versuchen, die Software-Entwicklung in Wirklichkeit "unagiler" zu machen, um nicht in des Teufels Änderungsküche zu geraten... (und bedanken wir uns hier bei den Lean Prinzipien ;-)
Was spricht eigentlich gegen die "Agilität" der "agilen" Methoden
Es handelt sich offensichtlich um ein Paradoxon:
Durch die "agilen" Methoden wird die Software-Entwicklung (welche natürlicherweise die weiter oben mit {1} aufgelisteten Eigenschaften inne haben) in einem Korsett von Richtlinien und Prinzipien eingepresst, und gleichzeitig wird behauptet, das sei "agil".
Pustekuchen ist das "agil" :-)
Es ist Verschwendung auf höchster Ebene, ganz im Gegenteil zu den Lean Prinzipien.
XP: Praktisch, ja, einige Wochen; wenn ein Anfänger hinter einem "Senior" sitzt. Sonst liegt die Produktivität bei ca 10 bis 20 % mehr von dem, was ein Entwickler alleine schafft: Also ein Wirkungsgrad von... 60% ?.
Nach meinem Wissen sind es gar nicht so viele "agile" Methoden im Umlauf (wenn man die -vielen- Variationen von "Scrum" außer Acht lässt: ein "Scrum" wo jedes Team irgend einer Abart von Scrum einsetzt, als "Scrum-But" bekannt, was schon zeigt, was man davon halten soll), doch wirklich funktionieren tut keine aus inhärenten Eigenschaften; Es sind immer die Teams, die etwas zum Laufen bringen.
Also das Dogmatismus um die "agilen" Methoden setzt auf den falschen Prinzipien. Offensichtlich.
Das ist ein Vorteil (man kann schnell anpassen) gleichzeitig aber ein Nachteil (man kann die Software "ad infinitum" ändern ("Änderitis"). Doch auf keinem Fall ist Software-Entwicklung nicht agil, egal welche Methode man anwendet.
Solche ständige Änderungen sind wohl auch Verschwendung im Sinne der "Lean"-Prinzipien (also gegen die "Lean" Prinzipien, die grundsätzlich gegen Verschwendung sind: also müsste eine Lean-Entwicklung grundsätzlich gegen Änderungen sein, somit aber auch gegen das, was eine SW-Entwicklung ausmacht...).
Und es sind aber auch solche Änderungen, die diese "agilen" Methoden befürworten, die dann auch zu aller Überfluss von vielen Menschen, Gruppen von Menschen und "Berater" sogar aller Couleur, gerne "Verkauft" werden; und dabei schießen sie sich, meiner Meinung nach, selbst ins Knie. Oder verdienen sich eine goldene Nase, je nachdem.
Scrum: agil oder nicht agil?
Es gibt außerdem auch Menschen, die behaupten, dass "Scrum" nicht agil sei.
Wieso?
Weil, zum Beispiel, täglich ein "Stand up" abgehalten wird. Sehr Starr. Nicht agil.
Dazu sehr feste Riten, wie zum Beispiel Retrospektiven, Planungsmeetings, usw.
Man kann eigentlich ohne weiteres postulieren, dass Scrum eine Art "Wasserfall" ist (wenn tatsächlich eine solche Konstruktion existieren würde), bei dem anstatt nach Funktionen nach "Timeboxing" entwickelt wird.
Schlicht und ergreifend "das Gleiche in Grün".
Und... sind andere "agile" Methoden auch "das Gleiche in Grün" ?
Mal sehen...
Nun stellt sich die Frage: Was ist "Agil"?
Zunächst gilt es, Abstand von dem unnützlichen "Manifesto" zu nehmen.
Nach der Definition von "Agilität":
- Gelenkigkeit {1}
- Aufgewecktheit {2}
- Gewandtheit {1}
- Lebendigkeit {2}
- Mobilität {1}
- Regsamkeit {2}
- Wendigkeit {1}
- Agilität {1}
- Flinkheit {1}
Es ist klar somit, dass jegliche Software-Entwicklung "agil" per se ist.
Vielleicht sollte eher das Ziel darin bestehen, zu versuchen, die Software-Entwicklung in Wirklichkeit "unagiler" zu machen, um nicht in des Teufels Änderungsküche zu geraten... (und bedanken wir uns hier bei den Lean Prinzipien ;-)
Was spricht eigentlich gegen die "Agilität" der "agilen" Methoden
Es handelt sich offensichtlich um ein Paradoxon:
Durch die "agilen" Methoden wird die Software-Entwicklung (welche natürlicherweise die weiter oben mit {1} aufgelisteten Eigenschaften inne haben) in einem Korsett von Richtlinien und Prinzipien eingepresst, und gleichzeitig wird behauptet, das sei "agil".
Pustekuchen ist das "agil" :-)
Es ist Verschwendung auf höchster Ebene, ganz im Gegenteil zu den Lean Prinzipien.
XP: Praktisch, ja, einige Wochen; wenn ein Anfänger hinter einem "Senior" sitzt. Sonst liegt die Produktivität bei ca 10 bis 20 % mehr von dem, was ein Entwickler alleine schafft: Also ein Wirkungsgrad von... 60% ?.
Nach meinem Wissen sind es gar nicht so viele "agile" Methoden im Umlauf (wenn man die -vielen- Variationen von "Scrum" außer Acht lässt: ein "Scrum" wo jedes Team irgend einer Abart von Scrum einsetzt, als "Scrum-But" bekannt, was schon zeigt, was man davon halten soll), doch wirklich funktionieren tut keine aus inhärenten Eigenschaften; Es sind immer die Teams, die etwas zum Laufen bringen.
Also das Dogmatismus um die "agilen" Methoden setzt auf den falschen Prinzipien. Offensichtlich.
Freitag, 25. September 2015
Mögliche Gründe für den (unerklärlichen) Siegeszug der "agilen" Methoden
Ich habe mir ein Paar Gedanken gemacht über die Akzeptanz der agilen Entwicklungsmethoden.
Wieso werden diese eingesetzt, blind, ohne den Versuch zu unternehmen, daraus etwas vernünftiges, ordentliches, funktionierendes zu gestalten?
Hier einige Ideen:
In meinen Augen sieht es eher so, dass einer ohne wirklich nachzudenken sich für die agilen Methoden geäußert hat, und dann haben viele andere das einfach, weiterhin ohne richtig nachzudenken, wenn überhaupt, sich auch für diese Ideen geäußert.
Keine gute Voraussetzung, um das Problem mit der Software-Entwicklung zu lösen.
Ich glaube, man hat sich leichtsinnigerweise an den Symptomen ausgetobt, anstatt die Wurzel des Problems zu analysieren, und vernünftigerweise hier anzusetzen.
Doch solange die Geldgeber überzeugt sind, dass Software-Entwicklung eine ganz besondere Sache ist, die "agil" zu erfolgen hat und viel Geld verschlingen muss, wird eine Vielzahl von "agilen" Entwickler gemütlich absahnen können.
Wieso werden diese eingesetzt, blind, ohne den Versuch zu unternehmen, daraus etwas vernünftiges, ordentliches, funktionierendes zu gestalten?
Hier einige Ideen:
- Das Management ist sich über die Nachteile nicht im KlarenJunge Entwickler scheinen wohl stark indoktriniert worden zu sein
- Die Entwickler lassen es sich gut ergehen, genießen wohlgemerkt die Wonne der Verantwortungslosigkeit, die Ruhe sich nur zu dem zu "commiten", was man bequem schaffen kann
- Das Management genießt auch die Verantwortungslosigkeit: laxe, unbekümmerte Vorgehensweise, sich in "Rollen" wiederfinden, die leicht von der Arbeit und einfach zu handhaben sind
In meinen Augen sieht es eher so, dass einer ohne wirklich nachzudenken sich für die agilen Methoden geäußert hat, und dann haben viele andere das einfach, weiterhin ohne richtig nachzudenken, wenn überhaupt, sich auch für diese Ideen geäußert.
Keine gute Voraussetzung, um das Problem mit der Software-Entwicklung zu lösen.
Ich glaube, man hat sich leichtsinnigerweise an den Symptomen ausgetobt, anstatt die Wurzel des Problems zu analysieren, und vernünftigerweise hier anzusetzen.
Doch solange die Geldgeber überzeugt sind, dass Software-Entwicklung eine ganz besondere Sache ist, die "agil" zu erfolgen hat und viel Geld verschlingen muss, wird eine Vielzahl von "agilen" Entwickler gemütlich absahnen können.
Mittwoch, 16. September 2015
Sonntag, 13. September 2015
Agile Entwicklungsmethoden => Dogmatischer Glaube und kein bisschen Nachdenken
Ich erlebe, verstärkt in den letzten Zeiten, dass die sogenannten "agilen" Methoden nicht nur vom Management (das Management hat eigentlich keine Ahnung von Entwicklung und soll diese auch nicht haben, da das Management durchaus andere Aufgaben zu erledigen hat) "gepuscht" werden (was man noch u.U. vermeiden könnte als erfahrener Entwickler), sondern auch, dass viele "Entwickler", also tatsächlich Menschen die SW Code schreiben, (Im Allgemeinen junge Leute, die wahrscheinlich noch mit einem Bein an der Uni stehen) sich diese Methoden dogmatisch hingeben.
Dass das Management oft und gerne auf "Hypes" reitet ist hinlänglich bekannt. Aber dass auch Entwickler so etwas anscheinend machen, versetzt mich im Erstaunen.
Eine rhetorische Frage von den eher unerfahrenen Entwicklern: "Sollen wir etwa Wasserfall anwenden?" - Betonung auf das Wörtchen "etwa". Tertium non datur. Schwarz-Weiß Auffassung der Welt...
Lernen sie so etwas an der Uni? Lehren die Profs, dass die sogenannten "agilen" Methoden das non-plus-ultra der Entwicklung ist? Die jungen Entwickler scheinen tatsächlich zu glauben, dass agile Methoden "agil" und besser seien, und Wasserfall "abscheulich" ist. Und das glauben sie mit religiösem Eifer... Schwarz-Weiß-Denken.
Für Akademiker sollte klar sein, dass ALLES Vor- und Nachteile hat. Und echte Profis sollten auf der Arbeit (eigentlich) auch bemüht sein, die Arbeit, Arbeitsmethoden usw zu verbessern, optimieren, Probleme zu entdecken und verschwinden zu lassen. Das geht aber nicht wenn man dogmatisch an bestimmten "Prinzipien" oder gar "Manifestos" fest hält.
Ich arbeite daran :-)
Dienstag, 23. Juni 2015
Das Toyota-System: Lean und Kaizen. Einige Begrifflichkeiten.
Die Grundlagen von Lean sind weder irgendwelche Werkzeuge noch eine Vermeidung von Verschwendung.
Wakamatsu und Kondo, beide Experten bei Toyota, brachten es auf den Punkt:
Das Wesen des Toyota-Systems ist einfach; dass jeder einzelne Mitarbeiter die Gelegenheit hat, in seinen eigenen Arbeitsumfeld Probleme zu finden, diese zu lösen und Verbesserungen zu machen.
So "einfach" wie es auch klingt, so schwierig ist doch die Umsetzung.
Das Toyota-System kann man durch 2 Grundlagen kurz beschreiben:
Ständige Verbesserungen, -oft als Kaizen benannt- ist Toyotas Ansatz, das tägliche Geschäft zu führen. Nach dem Prinzip: "Alles in Frage stellen". Mit anderen Worten: "Stets denken".
Wichtiger aber als die tatsächlichen Verbesserungen, die die Mitarbeiter umsetzen (dürfen), ist der wahre Mehrwert das Schaffen einer Umgebung in der man ständig lernen kann; eine Umgebung, die nicht nur Änderungen akzeptiert, sondern sie geradezu fördert.
Eine solche Umgebung kann nur dort entstehen, wo man die Menschen ohne wenn und aber respektiert - daher ist dieser der 2. Grundsatz des Toyota-Systems.
Und an diesem 2. Grundsatz scheitert grundsätzlich die Mehrzahl von unserem "westlichen" Management.
Kaizen wird (oft) schlicht als "kontinuierliche Verbesserung" übersetzt. Das aber verwechselt die Bedeutung von "kontinuierlichen Verbesserung" und ist nicht mit dem wahren "Kaizen" deckungsgleich.
Es wird empfohlen, das japanische Wort Kaizen zu gebrauchen und sich dabei der wahren Bedeutung bewusst werden: Kaizen ist gleichzeitig gelebte Praxis und eine (persönliche) Einstellung.
Nicht einfach "stets verbessern"...
Eine Cargo-Kultur sind Rituale, von einer (primitiven) Gesellschaft durchgeführt, die das Verhalten von nicht-native Besucher (oft aus Europa) nachahmt.
Analog dazu nennt man Cargo-Kultur-Prozesse solche, wo Rituale und Oberflächlichkeiten, ohne eingehendes Verständnis für die Hintergründe, praktiziert werden. (Oft vorzufinden bei vielen Organisationen, die "Agile Methoden" praktizieren, ohne sich mit der "agilen" Denkweise auseinander zu setzen -siehe "Scrum"-.)
Eine "Lean Cargo-Kultur" führt "lean" Werkzeuge (durch das Management) ein, ohne dass sich wirklich weder die Denkweise noch das Verhalten von Management oder gar der Mitarbeiter ändert.
Natürlich können sich beide nicht von heute auf morgen ändern, das braucht:
1. (eine lange) Zeit.
2. Maßnahmen, um die Mitarbeiter dahin zu führen (vom Management getragen).
Und sicher auch noch der Wille dazu und die Bereitschaft, Mitarbeiter gewähren zu lassen.
Nein... einfach ist das nicht.
Wakamatsu und Kondo, beide Experten bei Toyota, brachten es auf den Punkt:
Das Wesen des Toyota-Systems ist einfach; dass jeder einzelne Mitarbeiter die Gelegenheit hat, in seinen eigenen Arbeitsumfeld Probleme zu finden, diese zu lösen und Verbesserungen zu machen.
So "einfach" wie es auch klingt, so schwierig ist doch die Umsetzung.
Das Toyota-System kann man durch 2 Grundlagen kurz beschreiben:
- Kontinuierlich Verbessern, und
- Menschen respektieren.
Ständige Verbesserungen, -oft als Kaizen benannt- ist Toyotas Ansatz, das tägliche Geschäft zu führen. Nach dem Prinzip: "Alles in Frage stellen". Mit anderen Worten: "Stets denken".
Wichtiger aber als die tatsächlichen Verbesserungen, die die Mitarbeiter umsetzen (dürfen), ist der wahre Mehrwert das Schaffen einer Umgebung in der man ständig lernen kann; eine Umgebung, die nicht nur Änderungen akzeptiert, sondern sie geradezu fördert.
Eine solche Umgebung kann nur dort entstehen, wo man die Menschen ohne wenn und aber respektiert - daher ist dieser der 2. Grundsatz des Toyota-Systems.
Und an diesem 2. Grundsatz scheitert grundsätzlich die Mehrzahl von unserem "westlichen" Management.
Kaizen wird (oft) schlicht als "kontinuierliche Verbesserung" übersetzt. Das aber verwechselt die Bedeutung von "kontinuierlichen Verbesserung" und ist nicht mit dem wahren "Kaizen" deckungsgleich.
Es wird empfohlen, das japanische Wort Kaizen zu gebrauchen und sich dabei der wahren Bedeutung bewusst werden: Kaizen ist gleichzeitig gelebte Praxis und eine (persönliche) Einstellung.
Nicht einfach "stets verbessern"...
Cargo Cult (Cargo-Kultur)
Eine Cargo-Kultur sind Rituale, von einer (primitiven) Gesellschaft durchgeführt, die das Verhalten von nicht-native Besucher (oft aus Europa) nachahmt.
Analog dazu nennt man Cargo-Kultur-Prozesse solche, wo Rituale und Oberflächlichkeiten, ohne eingehendes Verständnis für die Hintergründe, praktiziert werden. (Oft vorzufinden bei vielen Organisationen, die "Agile Methoden" praktizieren, ohne sich mit der "agilen" Denkweise auseinander zu setzen -siehe "Scrum"-.)
Eine "Lean Cargo-Kultur" führt "lean" Werkzeuge (durch das Management) ein, ohne dass sich wirklich weder die Denkweise noch das Verhalten von Management oder gar der Mitarbeiter ändert.
Natürlich können sich beide nicht von heute auf morgen ändern, das braucht:
1. (eine lange) Zeit.
2. Maßnahmen, um die Mitarbeiter dahin zu führen (vom Management getragen).
Und sicher auch noch der Wille dazu und die Bereitschaft, Mitarbeiter gewähren zu lassen.
Nein... einfach ist das nicht.
Samstag, 13. Juni 2015
(Nicht so sehr) Lean Untersuchung der Lean-Prinzipien
Zunaechst sei angemerkt, dass die "Lean-Prinzipien" schon eine etwas längere Geschichte haben als die sogenannten "agilen".
Auserdem sind sie ursprünglich in Japan entwickelt worden, und die "Übersetzungen" geben oft (und können oder wollen es auch nicht) nicht wirklich die assozierte japanische Mentalität wieder, ...nur die "Techniken".
"Unfortunately, there are almost as many definitions for Lean as there are authors on the subject."
Wahrscheinlich aus diesen Gründen gibt es eine Vielzahl von Ausprägungen der Lean Prinzipien. Daraus hat man dann, um es bunter zu machen, die "Lean-Prinzipien-für-die-SW-Entwicklung" abgeschrieben, abgeleitet von den Lean Prinzipien fuer die Produktion. Daraus ist auch die SW-Entwicklungsmethode entstanden: "Kanban" gennt. Die neueste Methode, die zurzeit Teams anwenden, nachdem sie mit Scrum nicht weiter kamen. Gerade sind sie dabei herauszufinden, dass sie mit Kanban auch nicht wirklich besser werden :-)
Woran liegt es?
Natürlich habe ich nicht die Antwort, letztendlich habe ich nicht die Weissheit mit Löffeln verspeist. Ich gucke nur. Und lese. Und untersuche. Und nachdenke.
Erklärungsideen hätte ich schon.
Die werde ich bei entsprechender Reife hier aufschreiben.
Nun zu den Prinzipien.
Die sieben Prinzipien der Lean-Entwicklung:
Andere "Übersetzungen" postulieren:
Und hier die 7 Verschwendungen der SW-Entwicklung:
Hier die japanischen Begriffe für Verschwendung:
- Muda: die übliche Übersetzung von Verschwendung, gemeint ist aber die Arbeit ohne Mehrwert (so wie die Steuer: Keine Mehrwert für den Konsumenten ;-) )
- Mura: Bedeutet "unstetigkeit", hierunter versteht man die Unterschiede des Arbeitsaufkommens
- Muri: Bedeutet "überlastung"; bei diesem Begriff kann man auch "unlogik" oder "unvernunft" verstehen.
Meinen "Senf" dazu?Tja... ich kann keinen Denkfehler sehen.
Man kann sich sicherlich streiten, ob der eine oder andere Punkt von der Reihenfolge an der richtigen Stelle steht, ...
Ebenfalls kann man sich streiten, ob vielleicht manche Punkte nicht anders ausgedruckt werden sollte (je nach Betonung), ...
Auch ob es 6, 7 oder 8 Prinzipien bzw. Verschwendungen sein sollten kann man ausdiskutieren.
Doch, in Großen und Ganzen macht das Sinn und es ist eine vernünftige Arbeitsbasis um Prozesse bzw. Projekte zu optimieren.
Auserdem sind sie ursprünglich in Japan entwickelt worden, und die "Übersetzungen" geben oft (und können oder wollen es auch nicht) nicht wirklich die assozierte japanische Mentalität wieder, ...nur die "Techniken".
"Unfortunately, there are almost as many definitions for Lean as there are authors on the subject."
Wahrscheinlich aus diesen Gründen gibt es eine Vielzahl von Ausprägungen der Lean Prinzipien. Daraus hat man dann, um es bunter zu machen, die "Lean-Prinzipien-für-die-SW-Entwicklung" abgeschrieben, abgeleitet von den Lean Prinzipien fuer die Produktion. Daraus ist auch die SW-Entwicklungsmethode entstanden: "Kanban" gennt. Die neueste Methode, die zurzeit Teams anwenden, nachdem sie mit Scrum nicht weiter kamen. Gerade sind sie dabei herauszufinden, dass sie mit Kanban auch nicht wirklich besser werden :-)
Woran liegt es?
Natürlich habe ich nicht die Antwort, letztendlich habe ich nicht die Weissheit mit Löffeln verspeist. Ich gucke nur. Und lese. Und untersuche. Und nachdenke.
Erklärungsideen hätte ich schon.
Die werde ich bei entsprechender Reife hier aufschreiben.
Nun zu den Prinzipien.
Die sieben Prinzipien der Lean-Entwicklung:
- Verschwendung vermeiden (siehe weiter unten)
- Feedback einfordern (alle Teilnehmer einbeziehen - Kommunikation intensivieren)
- Spät entscheiden (sich so viel Zeit wie möglich nehmen: zum Denken und zum Planen)
- Schnell ausliefern (so schnell wie möglich die Entwicklung durchziehen, nachdem "entschieden" wurde)
- Team trägt Verantwortung (impliziert Selbst-Organisation...)
- "Integrität einbauen" ("stets" standardisieren, so wie ich es verstanden habe)
- Die Gesamtheit optimieren (Den gesamten Prozess verbessern)
Andere "Übersetzungen" postulieren:
- Die Arbeiten gleich beim 1. Mal richtig machen (inhaltlich zum 1. Punkt: keine Verschwendung)
- Den Arbeitern erlauben, Entscheidungen zu treffen (nicht nur "ganze Teams" sondern auch auf persönlicher Ebene)
- Stets verbessern (inhaltlich zum 7. Punkt)
- Lernen unterstützen (entfernt verwand mit dem 2. Punkt...)
Und hier die 7 Verschwendungen der SW-Entwicklung:
- Überproduktion (Zusätzliche Funktionalität)
- Inventur (Administration / Anforderungen)
- Zusätzliche Produktionsschritte (Komplexität / Überfluss)
- Bewegungen (Suche von Informationen)
- Fehler (Bugs / Fehler in der SW / Tools mit )
- Wartezeiten (Warten auf Entscheidungen / Warten auf Kunden-Feedback)
- Transport (Schnittstellen / Workflow der Arbeit)
Hier die japanischen Begriffe für Verschwendung:
- Muda: die übliche Übersetzung von Verschwendung, gemeint ist aber die Arbeit ohne Mehrwert (so wie die Steuer: Keine Mehrwert für den Konsumenten ;-) )
- Mura: Bedeutet "unstetigkeit", hierunter versteht man die Unterschiede des Arbeitsaufkommens
- Muri: Bedeutet "überlastung"; bei diesem Begriff kann man auch "unlogik" oder "unvernunft" verstehen.
Meinen "Senf" dazu?Tja... ich kann keinen Denkfehler sehen.
Man kann sich sicherlich streiten, ob der eine oder andere Punkt von der Reihenfolge an der richtigen Stelle steht, ...
Ebenfalls kann man sich streiten, ob vielleicht manche Punkte nicht anders ausgedruckt werden sollte (je nach Betonung), ...
Auch ob es 6, 7 oder 8 Prinzipien bzw. Verschwendungen sein sollten kann man ausdiskutieren.
Doch, in Großen und Ganzen macht das Sinn und es ist eine vernünftige Arbeitsbasis um Prozesse bzw. Projekte zu optimieren.
Samstag, 23. Mai 2015
Warum Scrum abbrennen soll (eine Übersetzung)
Why Scrum Should Basically Just Die In A Fire (hier nur ein Abzug)
Von: http://gilesbowkett.blogspot.de/2014/09/why-scrum-should-basically-just-die-in.html
(Ich empfehle das Original zu lesen!)
The Agile Manifesto might also be to blame for the Scrum standup. It states that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation." In fairness to the manifesto's authors, it was written in 2001, and at that time git log did not yet exist. However, in light of today's toolset for distributed collaboration, it's another completely implausible assertion, and even back in 2001 you had to kind of pretend you'd never heard of Linux if you really wanted it to make sense.
Well-written text very often trumps face-to-face communication. You can refer to well-written text later, instead of relying on your memory. You can't produce well-written text unless you think carefully. Also, technically speaking, you can literally never produce good code in the first place unless you produce well-written text. [...]
In fact, GitHub itself was built without face-to-face communication. Basecamp was built without face-to-face communication as well. I'm not saying these people never met each other, but most of the work was done remote. [...]. And face-to-face communication plays a minimal role in the majority of open source projects, which usually outperform commercial projects in terms of software quality.
In addition to defying logic and available evidence, both these Agile Manifesto principles (1) encourage a kind of babysitting mentality. I've never seen Scrum-like frameworks for transmuting the work of designers, marketers, or accountants into cartoonish oversimplifications like story points.
Übersetzung (des Abzuges)
Das Agile Manifesto widerspricht auch die Standup des Scrum . Es besagt, dass "die effizienteste und effektivste Methode der Übermittlung von Informationen zu und innerhalb eines Entwicklungsteams ist ein persönliches Gespräch". Um fair zu den Autoren zu sein muss man hier bemerken, dass dieses wurde im Jahr 2001 geschrieben, und zu dieser Zeit gab es noch kein git log. Bei den heutigen Tools, die für die verteilte Zusammenarbeit existieren, es diese Behauptung recht unglaubwürdig, und eben auch im Jahr 2001; musste man doch annehmen, die Autoren haben nie etwas von Linux gehört, wenn Sie wirklich richtig liegen sollten.
Ein gut geschriebener Text ist oft einfach besser als ein persönliches Gespräch. Ein Text kann jederzeit nachgelesen werden, anstatt dass man sich auf das eigene Gedächtnis verlässt. Man kann auch ein Text nicht schreiben ohne (genau) zu wissen, was man wirklich äußern will. Technisch gesehen, man kann auch nicht gut programmieren wenn man nicht richtig schreiben kann. [...]
Richtig ist es, dass GitHub selbst ohne persönliche Gespräche entwickelt wurde. Das Gleiche gilt für Basecamp. Ich behaupte nicht, das die Entwickler sich nie getroffen haben, doch die meiste Arbeit wurde aus der "Ferne" getan. [...]. Ebenfalls spielen persönliche Gespräche in den meisten Open-Source-Projekte eine untergeordnete Rolle. Und Open-Source-Projekte übertreffen in der Regel, in Bezug auf die Qualität der SW, kommerzielle Projekte.
Nich nur dass diese beide "agilen" Prinzipien (1) vorhandene Beweise und einfache Logik trotzen, sondern dass sie auch eine Art Kindergarten-Mentalität fördern. Ich habe noch nie gesehen, dass man Scrum bei Design, Buchhaltung oder Ein- und Verkauf benutzt: oberflächliche, Bilderbuch-ähnliche Vereinfachungen, wie die Sache mit den "Story Points" (Bewertung der 'Geschichten').
(1)
Als 2. Prinzip ist gemeint:
"business people and developers must work together."
Zu deutsch:
'Geschäftsleute und Entwickler müssen zusammenarbeiten.'
Die 1. angesprochene Prinzip war:
'die effizienteste und effektivste Methode der Übermittlung von Informationen zu und innerhalb eines Entwicklungsteams ist ein persönliches Gespräch'.
Abonnieren
Posts (Atom)