Mittwoch, 8. März 2017
Kommentare zum "Status-Quo-Agile-2016_17-Abschlussbericht_Studienteilnehmerversion_1.0.pdf"
Vor wenigen Tagen bekam ich diese Studie und las sie, da mir das Thema natürlich interessiert ;-)
Folgende Punkte möchte ich gerne kommentieren
Auf Seite 26:
Gründe für und gegen die Verwendung agiler Methoden
Gründe sich für agile Methoden zu entscheiden (1/2)
"61% der Teilnehmer sagen, dass sie die Produkteinführungszeit optimieren möchten, 47% wollen die Qualität optimieren und 42% die Risiken im Projekt reduzieren."
Meiner Meinung nach haben sich die Herren, die sich das wünschen, sich nicht wirklich richtig mit der Thematik auseinandergesetzt: Ausgerechnet Produktivität und Risiken... Wunschdenken, anders kan nich es mir nicht erklären.
"Während die meisten Teilnehmer eine bessere Betriebsleistung anstreben, gibt es nur einige, die es wegen sonstiger/ externer Gründe tun: 27% sind mit klassischem Projektmanagement frustriert und einige wenden agile Methoden an, weil es von Geschäftspartnern gefordert wird."
Das man mit dem klassischem Projektmanagement frustriert ist, kann ich gut verstehen. Da muss sich aber das 'Management' an die Nase fassen...
Und wenn Geschäftspartnern das nun fordern... na, da soll man sich sehr genau ausrechnen, in was man da reingezogen wird...
Seite 98: Anwendungsformen - Nutzung agiler Tehniken: Lean Nutzer benutzen
"Daily Scrum: 87%
Sprint Planning 81%
User Stories: 80%
Sprint Review: 79% (also auch "Sprints")
... usw usf"
Dabei ist mir aufgefallen, dass ausgerechnet "Lean", (das sich eigentlich bemühen sollte, "schlank" zu bleiben, mit wenig "Overhead" und überflüssigen Verwaltungsarbeiten), solchen Techniken mit starker ZeitVerlustCharakter wie "Daily Scrum", "Sprint Planning", "Sprint Review" usw anwenden... da haben sie sich die "Leans" (zumindest die, die an dieser Studie teil genommen haben), ins Knie geschossen.
Das ist, in meinen Augen, kein "Lean " mehr, sondern eine (giftige) Mischform.
Und noch ein bisschen Nachdenken am Rande der Studie:
Wenn ich mir die Anzahl an verschiedenen "Methoden" anschaue, so habe ich den Eindruck, dass ich mit Sekten zu tun habe.
Besonders augenfällig (für mich zunächst, wegen Mangel an Bodenständigkeit) sind Methoden wie: "Design Thinking", "Lean Startup", "Agile Modeling", "Adaptive Software Development", ...
"Design Thinking": https://de.wikipedia.org/wiki/Design_Thinking
"Lean Startup": https://en.wikipedia.org/wiki/Lean_startup (englisch nur)
"Agile Modeling": https://en.wikipedia.org/wiki/Agile_modeling (englisch nur)
"Adaptive Software Development": https://de.wikipedia.org/wiki/Adaptive_Software_Development - Insbesondere auffällig: "Dabei wird alle vier Wochen geprüft, ob eine neu erstellte Programmversion einen Fortschritt zur Vorgängerversion darstellt. Dies geschieht gemeinsam mit dem Kunden. Zwischen jedem der Treffen werden die Phasen 'Spekulieren', 'Zusammenarbeiten' und 'Lernen' durchlaufen". Tja... man muss sich doch diesen Satz auf der Zunge zergehen lassen... ganz langsam, ganz genüsslich!
Meinen Eindruck über die vielen mehr oder minder definierten agilen Methoden ist:
Es handelt sich um ein wirrwarr an Sekten, die viel (viel zu viel) Text produzieren, jedoch nichts Konkretes: Die Produktion liegt auf einem sehr - sehr - niedrigen Niveau.
Ich persönlich lese die ganzen Artikel gar nicht mehr; ich überfliege sie, suche nach Ergebnissen, finde sie nicht, denke mir "schon wieder Überflüssiges...".
Anmerken muss ich, dass ein grosses Teil der Studie "Status Quo..." auf "Einschätzugen" von Teilnehmern basiert; leider ist das einerseits nicht sehr wissenschaftlich und andererseits nicht wirklich aussagekräftig, in meinen Augen...
Noch eine Anmerkung (die 2.): Wie ausagekräftig die Statiskiken aus einer mathematischen statistischen Betrachtungsweise sind, damit habe ich mich nicht auseinandergesetzt. Ich will die Studie doch nicht zerpflücken (nur kommentieren).
3. Anmerkung: Es ist leider nicht möglich zu wissen wie viele der Teilnehmer an die Studie eigentlich z.B. (externe) Berater bzw Mitarbeiter sind, die allgemein von dem "agilen" Hype leben oder leben wollen, und dementsprechen fallen die Aussagen in dem Sinne: positiv für die "agilen" Methoden. Die ganze Studie ist folglich aus meiner Sicht mit sehr viel Vorsicht zu geniessen.
Die Autoren der Studie sprechen diesen Punt auch auf Seite 188 an: "Ein Bias (eine Verzerrung) in der Stichprobe, der die Ergebnisse beeinflusst hat, kann somit nicht ausgeschlossen werden - ist sogar wahrscheinlich. Auch beruhen die Ergebnisse auf Eigeneinschätzungen der Teilnehmer. Es ist nicht auszuschließen, dass einige Angaben nicht der Realität entsprechen."
Interessante, ergänzende Information auf Seite 169:
"27% der Teilnehmer, die eine Angabe zur Zertifizierung gemacht haben, haben eine Scrum Alliance oder Scrum.org Zertifizierung."
Also hatten 80% der Teilnehmer eine agile Zertifizierung:
Seite 170:
Scrum.org: 27%
Scrum Alliance: 27%
Sonstige Zertifizierung für agile Methoden: 13%
Kanban Zertifizierung: 7%
Andere Scrum-Zertifizierung: 6%
Noch eine interessante, ergänzende Info: Die Teilnehmerstruktur. Hierauf will ich nicht mehr eingehen, wer Interesse hat, soll sich die Studie beschaffen und lesen.
Eine zusätzliche, interessante und ergänzende Info zu berücksichtigen ist auf Seite 191 zu lesen; die Liste der bedankten Unterstützer der Studie. ...Einfach als Hintergrundinformation.
Und die letzte interessante und ergänzende Info: Der Studieninitiator, Prof. Dr. A. Komus ist u.a. auch (Mit)Initiator der Praxiswerkstatt Agilität, Consultant und Coach in agilen Methoden, hat u.a. auch eine Studie "agiles PMO" (PMO: Projekt Management Office) geschrieben. Infos aus der Seite 189.
Honi soit qui mal y pense. Interessant ist die Studie allemal.
Montag, 6. März 2017
Ein Paradies auf Erden: agiles Wunschdenken
Ich habe etwas interessantes gelesen!
Aus
https://deutscherarbeitgeberverband.de/aktuelles/2017/2017_01_23_dav_aktuelles_wissen-nicht.html
folgenden Text:
"Es ist oft gesagt, aber selten gehört worden, dass der abstrakte Wunsch, allen Menschen das Paradies zu bereiten, der beste Weg zur Erzeugung einer konkreten Hölle ist. Das hängt mit den "guten Absichten", die auch ohne jede Kompetenz zum Handeln antreiben, eng zusammen."
Dörner untersuchte experimentell auch, ob die Gruppe, also die "Weisheit der Vielen", positiven Einfluss auf die Qualität der Entscheidungen hat. Dem war allerdings nicht so, vielmehr ergaben sich negative Gruppendynamiken, z.B. das sogenannten Gruppendenken, welche die Gruppe am Erfolg hinderten."
Daraus lässt sich folgern, dass sowohl eine Arbeitsweise nach "Wasserfall" (also nach einem wie auch immer gestaltenen hierarchischen System) als auch nach den "agilen" Merthoden (das Team als Leistungsträger) nicht wirklich, in der Praxis, funktionieren können.
Warum?
Weil:
Die Lösung? FlePA.
Aus
https://deutscherarbeitgeberverband.de/aktuelles/2017/2017_01_23_dav_aktuelles_wissen-nicht.html
folgenden Text:
"Es ist oft gesagt, aber selten gehört worden, dass der abstrakte Wunsch, allen Menschen das Paradies zu bereiten, der beste Weg zur Erzeugung einer konkreten Hölle ist. Das hängt mit den "guten Absichten", die auch ohne jede Kompetenz zum Handeln antreiben, eng zusammen."
Dörner untersuchte experimentell auch, ob die Gruppe, also die "Weisheit der Vielen", positiven Einfluss auf die Qualität der Entscheidungen hat. Dem war allerdings nicht so, vielmehr ergaben sich negative Gruppendynamiken, z.B. das sogenannten Gruppendenken, welche die Gruppe am Erfolg hinderten."
Daraus lässt sich folgern, dass sowohl eine Arbeitsweise nach "Wasserfall" (also nach einem wie auch immer gestaltenen hierarchischen System) als auch nach den "agilen" Merthoden (das Team als Leistungsträger) nicht wirklich, in der Praxis, funktionieren können.
Warum?
Weil:
- Handeln ohne Kompetenz - Kompetenz im Wissen und Kompetenz im Treffen von Entscheidungen - (typisch fuer die "agilen" Methoden)
- Eine "Weisheit der Vielen" gibt es nicht, nur das Durchsetzen der Lautesten
- Aus einer fehlenden Ordnung ergeben sich "negative Gruppendynamiken".
Die Lösung? FlePA.
Dienstag, 14. Februar 2017
Mittwoch, 25. Januar 2017
"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
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
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 :-)
Abonnieren
Posts (Atom)