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.
Keine Kommentare:
Kommentar veröffentlichen