Dienstag, 20. Juni 2017

Über die magische Entstehung von "Agilität" durch den Einsatz von Tools

In der "agilen" Welt, so wie ich sie in den letzten Jahren bewundern durfte, ist einen lustigen Ansatz zu beobachten:
Erstens: Es existieren eine Serie an Tools, die "agil" sind und diese Agilität auch gewährleisten sollen, darunter z.B. "Jira"; den Einsatz solchen Tools wird nun erzwungen.
Zweitens: Es existieren eine Serie an Praktiken, die "agil" sind und diese Agilität auch gewährleisten sollen, darunter z.B. "CI/CD" (Continuous Integration / Continuous Deployment); den Einsatz solchen Praktiken wird nun erzwungen.

Der Ansatz wird wohl in der Hoffnung oder dem Glaube verfolgt, dass lediglich eine geistlose Anwendung einer Mechanik ausreichend ist um ein Ergebnis herbeizuzaubern.

Das ist ein Glaube an einer (einfachen) mechanischen Kausalität.

Doch wir haben es eigentlich hier mit sehr komplexen Interaktionen in einem sozialen Gebilde (kein "System" sondern eher ein "Organismus") zu tun. Hieraus erklärt sich der Denkansatz der überwältigen Wichtigkeit des "Teams" als solches: Deshalb schwafelt man gerne von den sich selbst organisierenden Teams und dass das Ergebnis mehr sein soll als den Beitrag jeden einzelnen usw.

Nun, es sieht so aus, als würden die sogenannten "agilen" Methoden erwarten, dass durch die mechanische Anwendung bestimmter Rituale (Praktiken) und Tools ein organisiertes (organisches) Team entstehen soll: Das kann (könnte) passieren, muss aber nicht. Und wenn Jemand erwartet dass etwas passiert, was passieren "könnte", pflegt diese Person eigentlich nichts anderes als "Wunschdenken".

Nehmen wir z.B. CI/CD als Untersuchungsobjekt:

CI/CD scheint eine Technik zu sein, die in Zusammenhang mit den sogenannten "agilen" Firmen mehr und mehr eingesetzt wird.

Dazu möchte ich auf 2 Punkten aufmerksam machen, die mir bei der Arbeit in den letzten Jahren aufgefallen ist.

1) CI/CD ist eine Technik die eigentlich für Projekte weniger bis gar nicht anwendbar ist: Viele 'Manager' wollen sie jedoch haben, weil sie scheinbar "agil" ist. Doch eigentlich sollte sie nur für die Serienproduktion einzusetzen sein. Die Idee stammt doch von der Toyota Serienautoproduktion. Als solche erzeugt sie bei der Projektarbeit eine schwer zu beherrschenden Overhead-Verwaltung. Vor Allem im Zusammenhang mit den ach so wichtigen automatischen Tests (mehr dazu lesen Sie hier: http://www.ruynk.com/ruynk_irrlicht_agil.htm - unter "Negative Eigenschaften der agilen Methoden" den letzten Punkt, über automatische Tests).

2) Bei vielen Firmen, die sich "agil" benennen wollen, werden Tools zur CI/CD eingeführt und eingesetzt, ohne wirklich verstanden zu haben, was CI/CD bedeutet. Und was bedeutet CI/CD? Die Idee hinter CI/CD ist wohl, das man ständig Änderungen und Verbesserungen (quasi in einem immerwährenden Prozess) im fertigen "Produkt" einfließen lassen kann.

Ich denke, dass man als erstes das Prozess so anpassen und optimieren soll, dass eine CI bzw CD Sinn macht. Das wird selten gemacht: Das wäre doch eher die Arbeit von Analysten, doch Analysten werden von den Firmen nicht mehr nachgefragt.

Davor jedoch sollte man sich Gedanken machen, was für einen Sinn CI/CD hat, sowohl für die Entwickler als auch für den Kunden. Solche Überlegungen werden auch (sehr) selten, manchmal gar nicht durchgeführt.

Vielleicht hofft das 'Management', dass CI/CD sich beim bloßen Anwenden von Tools einstellt.

Vielleicht hofft das 'Management', dass die "Agilität" sich beim bloßen Anwenden von Tools (und Praktiken) einstellt.

Das wird selten vorkommen. Das ist Wunschdenken.

Post-Agile... ein Begriff von Kritekern des "Agilismus"...

Einige Seiten, die sich mit "Post-Agile" auseinandersetzen:

Interessanter Vergleich klassisch-agile mit vielen Anmerkungen:
https://www.artefactgroup.com/articles/post-agile-a-design-thinking-approach-to-software-development/

Startseite des Blogs:
https://postagilist.wordpress.com/

"Scrum" als magisches Werkzeug:
https://postagilist.wordpress.com/2011/04/05/the-flawed-rhetoric-about-scrum-and-organizational-dysfunction/




"Agile" als kommunistisches Regime:
https://postagilist.wordpress.com/2011/04/09/scrum-as-the-new-command-and-control/

Interessant, viele Punkte, die ich selber schon bemängelt habe, hier:
http://www.ruynk.com/downl/SW_Entwicklung_Untersuchung.pdf

Neue Homepage für "AMTRS"

Neue Homepage für "AMTRS" (Analysieren - Modellieren - Trainieren - Reorganisieren - Systematisieren)

Hier: http://www.amtrs.de

Die Seite über "Systemanalyse" ist wert zu lesen, und
Downloads sind interessant!

Neue Homepage für "RyuSui"

Neue Homepage für "RyuSui" (IT-Wissen; Kurse und Seminare)

Hier: http://www.ryusui.de

Einige der Downloads sind interessant, aber nicht nur!


Donnerstag, 25. Mai 2017

Zwei Kommentare zu zwei bei den "Agilen" verwendeten Begriffen

Zunächst möchte ich auf einen Vergleich verweisen:

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

Hier geht es um eine Untersuchung über die verschiedenen agilen Methoden (es wurden 26 verschiedene Methoden bewertet und aufgrund dieser Bewertung habe ich den Vergleich durchgeführt). Wobei ich muss schon sagen; das Ergebnis fiel mehr oder minder wie erwartet. Dennoch interessant.

Doch eigentlich wollte ich auf auf 2 Begriffe eingehen.

1. Kanban

Ich wundere mich immer wieder wenn Menschen (insbesondere Leute der IT Branche, die es eigentlich besser wissen sollten) meinen, Kanban wäre eine agile Entwicklungsmethode.
Ich weiß leider nicht wie "lazy" die Kollegen mit den Wörter umgehen, aber Kanban ist keine Entwicklungsmethode:
KanBan ist ein Tool (Werkzeug) zum Visualisieren der Arbeitspaketen!
Nicht mehr und nicht weniger.
Oder sind Sie, werter Leser, über "Kanban" eine andere Auffassung?


2. Scrum

Mein Lieblings Punchingball: Das Gedränge    :-)
Scrum ist meiner Meinung nach ein Sammelsurium an Praktiken, keine Methode. Natürlich lässt sich schon streiten, in wie weit Scrum eine Methode ist.
 Wikipedia ("https://de.wikipedia.org/wiki/Methode_(Softwaretechnik)") liefert uns folgende Definition:
"Als Methode – „wörtliche Bedeutung: Der Weg zu etwas“ (Duden) – bezeichnet man in der Informatik und der Softwaretechnik eine „systematische zielgerichtete Vorgehensweise, sowie planmäßiges Verfahren, welches für eine Vielzahl von Problemen zu einer sinnvollen Lösung führt“ und/oder „eingeübte oder formalisierte Abläufe, die sich als zweckmäßig und erfolgreich erwiesen haben
Die 1. Definition trifft für Scrum nicht zu, denn Scrum ist nicht "planmäßig" (Klar! Scrum - und die "Agilen" im Allgemeinen - wollen keine Planung). Und ich halte Scrum auch nicht für "systematisch" - es ist dahinter kein System zu erkennen.
Die 2. Definition könnte schon  gelten, dies liegt daran, dass die Definition zu ungenau ist: "... als zweckmäßig und erfolgreich erwiesen haben" - ja... wie weit zweckmäßig und wie genau erfolgreich?
Aber jetzt will ich es kurz machen, abgesehen von allen Erklärungen, Methode ist "der Weg zu etwas" und das reicht mir und ist genau genug für mein Geschmack;
Scrum ist nicht der Weg zu etwas, sondern lediglich ein loser Haufen an mehr oder minder brauchbaren Praktiken. Einen "Weg" stellen sie nicht dar.

Auch hier bin ich an Kommentare über die Methode-Eigenschaften des Scrums gespannt: Meinungen...?

Bis bald
ruynk

Donnerstag, 6. April 2017

Der "SW-Entwickler als Fabrikarbeiter" vs. der "SW-Entwickler als Kreativitaetsmanager"

In meiner Untersuchung ("Untersuchung bezüglich der SW-Entwicklungsmethoden im Unternehmen mit dem Schwerpunkt 'Agil' und ansatzweise Suche einer Lösung für die Unzulänglichkeiten der gegenwärtigen SW-Entwicklungsmodelle", hier können Sie sie downloaden: http://www.ruynk.com/downl/SW_Entwicklung_Untersuchung.pdf) ist zu lesen, dass eine gute Möglichkleit, das Beste aus der SW-Entwicklung als Prozess heraus zu kriegen ist indem man den Entwickler erklärt, was man haben will, und sie dann gewähren lässt.

Diese Vorgehensweise ist stark vereinfacht und hat sowohl einige Vorteile als auch gravierende Nachteile (Stichwörter: Vergoldung, falsch verstandene Anforderungen, Änderungen ausser jedwede Steuerung, usw usf).

Dennoch hat die Vorgehensweise zweifelsohne wichtige Vorteile für das Ergebnis der SW-Entwicklung.

Die Grundlage dieser Vorgehensweise ist die Auffassung der Entwickler selbst, sie sehen sich als seien sie kreative Experten und Wissenmitarbeiter in einem.

Dagegen finden wir auf der anderen Ende der Skala Methoden wie Scrum, wo die SW-Entwickler wie Fabrikarbeiter behandelt werden und die zu bauenden SW als Mauer aus Steine, die die SW-Entwickler zusammen zu kleistern haben; mit Hilfe von schlauen Tools und unzähligen Meetings (Stichwort Mikromanagement) sollen diese Fabrikmitarbeiter nun in der Lage verstezt werden, die SW zu konstruieren.

Es dürfte klar sein, dass diese "Scrum" (Gedränge) Vorgehensweise auch weit entfernt von einem Optimum ist.
Vorteile: Mikromanagement; das Management ist jederzeit in der Lage den aktuellen Stand zu wissen.
Nachteile: Die Entwickler arbeiten weit unter ihre eigentlichen Fähigkeiten.
Ist nun ein SW-Entwickler ein Fabrikarbeiter oder ist er ein Kreativitätsmanager? Beide Ansätze sind falsch!
Ein SW-Entwicler ist ein SW-Entwickler und kein Designer, Architekt, Tester, oder was auch immer ein Modell aus ihm machen will!

Mit FlePA jedoch, als Nachfolge der sogenannten "Agilen", werden die SW-Entwickler wieder zu dem, was sie sind und somit die Entwicklung von SW selbst, als solche, optimiert.

Mittwoch, 15. März 2017

Kann "Planen" flexibel sein?

Bei FlePA (Flexibles Planen und Arbeiten) kommt doch ein "flexibles Planen" vor.

Nun, daraus ergibt sich eine durchaus berechtigte Frage:
Wie kann man das "flexible" Planen verstehen?

Planen ist doch, sagen wir mal, sehr "rigide"... Man plant und daran soll man sich halten. Oder?

Von einem "flexiblen Planen" zu sprechen klingt wirklich so, als würde ich von einer "lebendigen Leiche" oder von "trockenem Wasser" reden. Richtig?

Nun; Planen ist nicht das Gleiche wie Planung.

Dadurch, dass ich (mit flexiblem Denken) Planung und Planen auseinander definiert und das Planen durchexerziert habe, habe ich eine Lösung gefunden und diese in FlePA eingearbeitet.


Samstag, 11. März 2017

Die "Agilen" (Methoden) als notwendiges Uebel



Vielleicht haben Sie, werter Leser, aus meinen Blogeintraegen den Eindruck gewonnen, dass ich ganz und gar gegen die sogenannten "agilen" Methoden bin.

So ganz stimmt das nicht.

Ich halte die sogenannten "agilen" Methoden fuer einen ersten Schritt in der richtigen Richtung... leider hat man mit diesem 1. Schritt (nicht zuletzt wegen Missgeburten wie Scrum) richtig fett im Haeufchen getreten, dennoch haben wir, so wie ich es sehe, mit einem Schritt in der richtigen Richtung zu tun.

Der Softwareexperte Erik Meijer bezeichnet agile Methoden als "Krebsgeschwuer":
http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/management/articles/471509/

Ich habe einen grossen Respekt dem Kollegen Erik Meijer gegenueber, er sagt aus meiner Sicht eine Wahrheit aus: die "Agilen" seien ein Krebsgeschwuer, so wie sie zurzeit wuchern, ist die Aussage wohl zutreffend.

In meiner Meinung sind sie, die "Agilen", giftig, ruhen auf falschen Praemissen, sind unkontrollierbar und, durch eine Aura an Esoterismus bedingt (wegen des Dogmatismus der verschiedenen "Methoden"), zersplittern sie in einer Vielzahl an "Sekten" (Methoden, Techniken oder wie man das Ganze, das uns blueht, nennen mag). Die vielen "Sekten" zeigen deutlich, und das kann Niemand zweifeln, dass jegliche "agilen" Methode weit entfernt davon sind, eine Loesung oder gar ein Patentrezept zu sein.

Aber... die "Agilen" sind nicht aus Jux und Tollerei entstanden, sondern als Antwort auf bestimmten und ganz konkreten Problemen, und diese sind unbedingt zu adressieren, wenn wir eine Loesung fuer die SW-Entwicklung wollen und suchen.

Folglich halte ich die sogenannten "agilen" Methoden ein (zurzeit noch, aber nicht mehr lange) notwendiges Uebel in der SW-Industrie.

Zum Glueck gibt es schon einen Nachfolger: FlePA.

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:
  1. Handeln ohne Kompetenz - Kompetenz im Wissen und Kompetenz im Treffen von  Entscheidungen - (typisch fuer die "agilen" Methoden)
  2. Eine "Weisheit der Vielen" gibt es nicht, nur das Durchsetzen der Lautesten
  3. Aus einer fehlenden Ordnung ergeben sich "negative Gruppendynamiken".
Alle 3 Punkte entspringen dem Wunschdenken, Menschen (Mitarbeiter) ein Paradies auf Erden anbieten zu wollen. Auch das agile Manifesto postuliert klar ein Paradies, welches sich aus eben ähnlichem Wunschdenken ableiten soll.

Die Lösung? FlePA.

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).


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.

Mittwoch, 16. November 2016

Neue Homepage: ruynk.com

Meine:

http;//www.ruynk.com

mit Informationen und Meinungen über die sogenannten "Agilen",

habe ich neu aufgesetzt.