Mein Name ist Frank Schimmel, ich bin Professor für Agile Coding an der
Fakultät für Informatik und Ingenieurswissenschaften
und unterrichte im Studiengang Code and Context.
Also vor dem Studium
gab es so ein paar Themen, die mich interessiert haben.
Informatik zum Beispiel,
aber auch Physik und Chemie und Mathematik.
Und eigentlich war Meteorologie, sondern das ideale Studienfach,
um all das zu mischen.
Das war auch nie der Plan, nur einer von denen zu sein, die draußen
auf der Wiese stehen und ein Messinstrument
hochhalten oder im Feldeinsatz experimentieren.
Sondern eigentlich war der Plan, von vornherein in die Simulation zu gehen
und die Computer
zu nutzen, die die Meteorologie
reichlich hat.
Ja, wenn man es
dramatisch formulieren möchte, ist Agilität in der Softwareentwicklung
im Prinzip eine Befreiung der Softwareschaffenden
aus der Sinnlosigkeit ihrer Existenz.
Das klingt jetzt sehr groß.
Aber das
Ganze hat ja in einer Zeit stattgefunden, an der ich noch studiert habe.
Und da wo ich angefangen habe, mich mit Softwareentwicklung
Prozessen zu beschäftigen, waren da andere ein paar Schritte weiter,
die schon wirklich Software gebaut haben.
Und die Zeit war auch geprägt
von vielen scheiternden Softwareprojekten,
wo jahrelang konzipiert und entwickelt wurde
und dann nach der Auslieferung festgestellt wurde,
dass das überhaupt nicht das löst, was eigentlich das Problem ist
und dass das eigentlich keiner gebrauchen kann, was da gebaut wurde. Und
das was agile Softwareentwicklung macht, ist im Prinzip
gegen diese Zustände aufzubegehren und die zu ändern, letzten Endes
zum Nutzen aller auch und um es noch mal
dramatisch zu formulieren, Mauern einzureißen.
Oder weniger dramatisch vielleicht einfach mal mit den Leuten
zu reden, also mit den
Kund*innen und Nutzer*innen
dieser Software, die da zu bauen ist, und tatsächlich zu verstehen,
was denn eigentlich deren Problem ist und das dann gemeinsam mit ihnen zu lösen.
Also es bewegt sich dann weg von
einem Produktionsprozess, der vorher geplant und dann ausgeführt
wird, hin zu einem gemeinsamen Lernprozess zusammen mit den Nutzer*innen
und Kund*innen.
Die Überlegenheit agiler Ansätze,
dass ich halt nicht drei Jahre warte, bis ich ein Feedback erhalte,
ob ich richtig unterwegs bin, ob ich das richtig verstanden habe,
sondern zwei Jahre, elf Monate und zwei Wochen früher.
Ich liefere etwas, das nicht vollständig ist, aber ich versuche mal
das grundlegende Problem zu lösen oder ein Stückchen zu lösen
und kriege dann eine Mitteilung oder ein Feedback.
Bin ich auf dem richtigen Weg?
Oder habe ich das völlig falsch verstanden?
Und an all diesen Stellen, wo man Feedback bekommt,
kann man auch die Richtung ändern.
Deswegen heißt das auch agil, weil ich die Richtung ändern kann.
Das kann klassisches Projektmanagement nicht.