Schlagwort-Archiv: Integrationsprojekte

Ein agiler Bastard zwischen einem Karnickel und einer Rummelfliege

Alle sprechen von agilem Projektmanagement. Das geht so weit, dass man sogar noch das “Projektmanagement” weg lässt. Plötzlich ist einfach alles agil. Als ich im vergangenen Sommer einen glühenden Anhänger von Agilität gefragt hatte, was er denn nun eigentlich unter “agil” verstehe, war seine Antwort:

Meine Definition von Agil? Jetzt hast du mich aber… ;-) Da muss ich mal über eine Formulierung nachdenken.

So auf die Schnelle würde ich sagen, agile Entwicklung ist:

  • Inkrementell: es wird in Durchstichen gedacht, Nutzenorientierung
  • Lernend: daher auch die iterative Entwicklung oder die Retrospektive in Scrum
  • Haldenreduziert: es wird versucht, kein B*UF herzustellen (Big {Design, Documentation, …} Up Front)
  • Unmittelbar: Kommunikation soll direkt stattfinden (Kunde:Entwickler, Code:Entwickler usw.); also nicht lange rumspezifizieren und Papierberge produzieren, nicht lange rumdokumentieren, sondern den Code sprechen lassen

Interessant ist, dass er zunächst selber überfragt war. Dann kam eine Definition für “agile Entwicklung”. Das ist immerhin konsequent, denn agiles Projektmanagement war in der Tat für IT-Entwicklungsprojekte angedacht. Kent Beck et al. stellten 2001 ihr agiles Manifest vor, in welchem nebst agilen Prinzipien auch die vier agilen Werte stehen1:

Wir zeigen bessere Wege auf, Software zu entwickeln, indem wir es selber tun und anderen dabei helfen, es zu tun. Durch unsere Arbeit sind wir zu folgender Erkenntnis gekommen:

  1. Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
  2. Funktionierende Software ist wichtiger als umfassende Dokumentation.
  3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
  4. Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan

Es ist deutlich von Software entwickeln sowie funktionierender Software die Rede. Das ist das Entscheidende. Agiles Projektmanagement ist eine Philosophie für Entwickler. Nur: hier in Mittelwuropa sind IT-Projekte vowiegend Integrations- und Migrationsprojekte, in deren Verlauf manchmal tatsächlich auch Skripte entwickelt oder Schnittstellen angepasst werden müssen, z.B. mit in einem SAP-Projekt mit der Programmiersprache ABAP. Aber solche Entwicklungen stehen in Migrationsprojekten nicht an vorderster Stelle und können in einem mit agilen Methoden durchgeführeten Teilprojekt gekapselt werden. Für das übergeordnete Migrationsprojekt jedoch, sind die agilen Werte, so wie sie im Agilen Manifest stehen, nichtssagend oder selbstverständlich.

Die nicht direkt entwicklungsbezognene Werte Interaktionen vor Prozessen und Zusammenarbeit mit dem Kunden sind in Logistik- und Migrationsprojekten schon immer selbstverständlich gewesen. Ich habe schon in den Achzigern – lange vor Kent Beck – in Referaten auf der Notwendigkeit von kollaborativem Vorgehen mit den Handelspartnern – Kunden und Lieferanten – insistiert. Meine Zusammenarbeit mit den Kunden in Migrationsprojekten geht zuweilen so weit, dass meine Mandanten murren. In Projekten will der Lieferant eine möglichst gute Marge und der Kunde eine möglichst gute Qualität. Ich achte immer zugunsten des Kunden auf Qualität, was manchmal an der Marge meiner Mandanten zehrt.

In einem Integrations- oder Migrationsprojekt wird ein Softwareprodukt installiert, dessen Entwicklung abgeschlossen ist. Dokumentation ist ausserordentlich wichtig. Der Kunde wil nicht ständig vom wohlwollenden Support und den teuren Trainings des Lieferanten abhängig sein, sondern erwartet eine möglichst gute Dokumentation des Produkts. Er will keine grünen Bananen, die bei ihm reifen sollen, sondern funktionierende Software und umfassende Dokumentation. Hier unterscheiden sich Migrationsprojekte grundsätzlich von Entwicklungsprojekten.

Die Forderung Veränderung vor Plan zieht sich wie ein roter Faden als eines der Hauptthemen durch meinen Blog. Es geht mir seit jeher um vigilantes und flexibles Vorgehen. Den längst zerredeten Begriff “agil” vermeide ich tunlichst, weil er in den Bereich von Entwicklungsprojekten gehört.

Es ist äusserst gefährlich, zunächst recht präzise Begriffe einfach auszuweiten und über alles und jedes zu stülpen. Die Begriffe erfahren dabei eine Inflation und verlieren ihren Inhalt.

Uwe Friedrichsen schreibt in seinem interessanten Überblicksartikel Agilität heute und morgen: eine Bestandesaufnahme und ein Blick in die Zukunft2

Nachhaltig geändert hat sich die Situation für mich vor circa zweieinhalb Jahren. Mein damals neuer Arbeitgeber setzte nicht nur in der Projektdurchführung, sondern in allen Bereichen auf Agilität.

Ich bedauere, dass man angesichts erhöhter Komplexität nicht auch erhöhten Wert auf präzise Sprache legt. Nicht nur, dass man den Begriff “agil” missbräuchlich verwendet, wo man einfach nur “flexibel” oder vielleicht “vigilant” meint. Die Vertreter der Agilität-auf-Teufel-komm-raus benutzen auch Begriffe wie “Kanban” oder “inkrementell”, ohne sich jedoch im Klaren darüber zu sein, was sie wirklich bedeuten. Kanban ist eine Just-in-Time-Methode in der Fertigung und hat gar nichts mit agiler Projektmanagement zu tun. Kanban ist im agilen Projektmanagement allenfalls eine Metapher. Inkrementell ist ein Vorgehen, bei dem periodisch ein festes Inkrement dazu kommt3. Agiles Projektmanagement meint aber rekursives Vorgehen, wo der nächste Schrit auf dem bisher Erreichten aufsetzt. Mein Freund, den ich eingangs erwähnte, meinte dazu:

ich denke, die begrifflichkeit ist hier geschmackssacke. “rekursiv” ist aus meiner sicht weniger anschlussfähig

Das ist genau, was ich meine: Die Bedeutung von Begriffen erklärt man ebenso zur Geschmacksache, wie die Gross- und Kleinschreibung. Dann kann jeder machen, wie er will. Das ist schon gut. Nur darf man sich nicht wundern, wenn sich die Menschen nicht mehr verstehen. Während der eine über agiles Projektmanagement spricht, meine ich, es gehe um Softwareentwicklung, das ziemlich ausserhalb meiner Erfahrungen liegt. Ich spreche von vigilantem oder systemisch-evolutionärem Projektmanagement, und obwohl er weitgehend dasselbe meint, reden wir die längste Zeit aneinder vorbei. Schade eigentlich!

1Z.B. Wikipedia, Agile Softwareentwicklung

2Friedrichsen, Uwe. Agilität heute und morgen: eine Bestandesaufnahme und ein Blick in die Zukunft, OBJEKTspektrum, Ausgabe Februar 2011

3z.B. Wikipedia, Inkrement und Dekrement

Titel frei nach Fletcher's satirisches Fußballdiktionär

Integration ist Lernen

Kürzlich kaufte ich mir ein Garmin etrex GPS zum Inline Skaten. Die Vision war, dass ich eingeben kann, ich möchte von A nach B und das Gerät würde mich über asphaltierte Fahrrad- und Fussgängerwege lenken. Natürlich wusste ich, dass es so etwas (noch) nicht gibt (warum eigentlich? Technisch wäre das ja einfach realisierbar). Ein Unternehmen muss laufend innovative Angebote auf den Markt bringen. Es kann auch dann zu einem Wettbewerbsvorteil kommen, wenn das Angebot noch nicht ganz den Visionen entspricht oder sogar noch wenig ausgereift ist. Das Unternehmen, das mit einer Idee zuerst auf dem Markt ist, hat meistens die Nase vorn. Aus demselben Grund kaufte ich das GPS trotz meines Wissens, dass es meine Anforderungen nicht erfüllt. Ich war aber neugierig, was sich damit machen lässt. Nun bin ich Inline-GPS-Besitzer und als das lebt es sich anders. Natürlich ist es keine tiefgreifende Veränderung meines Lebens. Aber dennoch muss ich das Gerät in mein Leben einbauen. Es ist ein typisches Intergrationsprojekt. Genauso ergeht es einem Unternehmen, das eine neue Technologie integriert, um ein innovatives Angebot machen zu können oder seine Prozesse innovativ zu verändern.
Am Anfang war zwar eine konkrete Vision oder ein konkreter Wunsch, was das System können sollte. Daraus lässt sich ein vollständiger Anforderungskatalog erstellen und eine sehr genaue Spezifikation schreiben. Alles für die Katz’. Nachdem ich das Gerät hatte, begann ich zu lernen, was es überhaupt kann, bzw. was es alles nicht kann.
Beispiel 1: Beim Kauf zeigte mir der Verkäufer das beiliegende Kartenmaterial. Da heisst es “Topografische Karte; Grundmassstäbe 1:50 000 und zum Teil 1:25 000″. Das ist doch ‘was. Sofort stellte ich mir die Topologische Karte der Schweiz vor und machte ziemlich grosse Augen, als ich sah, dass 6 Meter breite und asphaltierte Strassen auf der Garmin-Karte bloss als Strich eingezeichnet ist, als wäre es ein Feldweg. Dass sich die modernen Kartenangebote nicht auf Garmin Geräte übertragen lassen, wusste ich auch nicht, denn ich dachte, dass ein bisher erfolgreiches Unternehmen kaum den Fehler begeht, sich mit einem proprietären Standard zu verschliessen.
Beispiel 2: Wenn Sie es im Modus “Fussgänger – der Strasse folgen – Mautstrassen vermeiden” betreiben, werden Sie laufend auf die Autobahn gewiesen. Sogar dann, wenn Sie zwei Wegepunkte eingegeben haben, die z.B. 20 Meter auseinander liegen. Das Gerät schickt Sie nach Passieren des ersten Wegepunktes über alle erdenklichen Autobahnen und Überlandstrassen zum Wegepunkt 2, nur nicht direkt. Ich lernte, dass ich das Gerät im Modus “Fussgänger – Luftlinie – Mautstrassen vermeiden” betreiben und die Wegepunkte auf meiner Route derart wählen muss, dass jeweils der nächste per Luftlinie erreichbar ist. Wofür die Einstellungen “Fussgänger” und “Mautstrassen vermeiden” gut sind, habe ich noch nicht gelernt.
In einem Integrationsprojekt geht es also darum, das neue System immer besser kennen zu lernen und zu lernen, es möglichst gewinnbringend einzusetzen. Ein Intergrationsprojekt ist somit ein Lernprojekt. Ein Modell eines Intergationsprojekts ist weitgehend ein Modell des Lernens.

Technorati Profile