Agile Manifesto: Die Grundlagen

agile manifesto grundlagen projektmanagmentWir wissen ja, dass die Amerikaner den Pathos mögen und ihnen nichts peinlich ist. Das scheint ja auch ein Teil ihres Erfolges zu sein. Trotzdem erscheint uns Mitteleuropäern das "Agile Manifesto" etwas übertrieben. Aber wenn wir die pathetischen Worte darin vergessen und uns auf den Inhalt konzetrieren, finden wir eine Menge Hilfestellung für die tägliche Arbeit mit Projekten.

Die Kernsätze

Das "Agile Manifesto" wurde im Jahr 2001 von einer Gruppe Denker und Softwareentwickler in einer Winterfreizeit geschrieben. Heraus gekommen sind einige Kernsätze, die noch heute Woche für Woche von weiteren Unterstützern unterschrieben werden. Das sind sie (frei ins Deutsche übersetzt):

  1. Menschen und Kommunikation sind wichtiger als Prozesse und Tools
  2. Lauffähige Software ist wichtiger als eine ausführliche Dokumentation
  3. Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen
  4. Auf Änderungen zu reagieren ist wichtiger als dem Plan zu folgen

Folgerungen
Das könnte - mit anderen Worten folgendes bedeuten:

  • Wir akzeptieren, dass zu Beginn eines Projektes nicht alles definiert ist und lassen Änderungen zu.
  • Der Kunde kann erst dann seine Anforderungen spezifizieren, wenn er einen lauffertigen Test vor sich sieht.
  • Deshalb wird mit vielen kleinen Zwischenschritten und -abnahmen gearbeitet.
  • Alle Tools und Regeln ordnen sich den Gegebenheiten und vor allem den Bedürfnissen der Menschen unter.
  • Das Team und die Zufriedenheit des Kunden sind der Maßstab des Erfolges. Und nicht die zuvor vereinbarten Verträge.
  • Ohne Kommunikation ist alles nichts wert und Ehrlichkeit ist die Grundlage für eine erfolgreiche Zusammenarbeit.

Wohlgemerkt: Das "Agile Manifesto" bezieht sich auf die Softwareentwicklung. Was ich daraus lernen möchte, ist die Anwendbarkeit bei Nicht-Software-Projekten. Hier muss man einige Punkte möglicherweise etwas anders formulieren - aber der Inhalt bleibt.

Anwendbarkeit auf große Projekte
In den Kommentaren auf die letzten Einträge zu den Agilen Methoden findet sich auch die Frage nach den großen Projekten. Lässt sich ein solches Manifest auch auf ein Projekt von der Größe eines LKW-Mauts anwenden? Ich denke, zum Teil schon. Natürlich benötigt man bei großen (öffentlichen) Projekten mehr Planungssicherheit am Anfang und ist auch in der Lage (evtl. mit einem Vorprojekt) die Spezifikation recht genau zu machen. Und welche Presse hätten die Verantwortlichen des LKW-Maut-Projektes erhalten, wenn wärend der Entwicklungsphase ständig neue Ideen eingebracht worden wären. Aber der Gedanke der kleineren Abnahmeschritte mit schnellen Änderungs-Zyklen wäre hilfreich gewesen. Und der Satz "Menschen und Kommunikation sind wichtiger als Prozesse und Tools" gilt ohnhin nicht nur für Agile Projekte sondern für das ganze Wirtschaftsleben. Davon bin ich überzeugt.

Fazit
Der Gedanke der "Agilen Softwareentwicklung" muss  nicht auf die Produktion von Code beschränkt sein. Ich denke dass die Kersätze des "Agilo Manifesto" bei der Planung und Durchführung von Projekten aller Art ihre Berechtigung haben. Vor allem bei kleinen bis mittleren Projekten, bei denen auch weniger geübte Auftraggeber und Auftragnehmer miteinander arbeiten. Wie das konkret geht, werden wir sehen…

to be continued

  1. 4 Responses to “Agile Manifesto: Die Grundlagen”

  2. By Nicolas Kübler on Jan 6, 2006

    “Der Kunde kann erst dann seine Anforderungen spezifizieren, wenn er einen lauffertigen Test vor sich sieht.” bzw. der Kunde kann jederzeit Anforderungen spezifizieren, in der Praxis typisch nach Releases…

    In der agilen Softwareentwicklung steckt viel Potential. Man kann sich auch überlegen, ein projekt nicht ganz so agil zu halten, aber die einzelnen Teams für einzelne Module/Teilbereiche dagegen in einer Art Extreme Programming arbeiten zu lassen. Der Vorteil ist ein lauffähiges Programm.

    Wichtig bei Extreme Programming, hoffentlich greife ich nichts voraus, ist, dass jeder Programmierer auch die Rolle eines Testers übernimmt. Sagen wir 2 Teams die je ein Modul entwickeln, danach bekommt das jeweils andere Team ein Release und testet. Somit ist eine frühe Qualitätssicherung sichergestellt. Ganz wichtig ist dabei die schwierigen Parts einer Software zuerst zu realisieren, damit diese bei jedem Release immer wieder getestet werden. Gerade im oben genannten Beispiel hätte das vielleicht einiges anders aussehen lassen..

  3. By eric42 on Jan 6, 2006

    Oh ja, sehr wichtig. Denn es steht fest, dass die Hersteller von Code auch die besten Qualitätssicherer sind. Man muss sie nur lassen. Ich habe noch nie einen Programmierer erlebt, den man beim Bugfixing am Ende nicht sogar noch bremsen musste. Und, ja, je früher dazu die Möglichkeit besteht, umso besser für das Projekt, den Ablauf und damit das Ergebnis.
    Und zu den “Portionierungen” der Zwischenabnahmen kommen wir noch. Das ist, glaube ich, eine der schwierigsten Übungen…

  4. By Nicolas Kübler on Jan 6, 2006

    Genau solche Erfahrungen habe ich auch gemacht, allerdings muss man auch sagen, dass man auch weniger technikbegabte Leute testen lassen sollte, denn diese sehen häufiger sogar noch Fehler die man so als Programmierer gar nicht sieht. Allerdings ein bunt gemischtes Team könnte da auch sehr hilfreich sein.

    Freut mich allerdings, dass es einen Blog über solche Themen gibt, kennen Sie noch weitere?

  5. By eric42 on Jan 6, 2006

    Einen Blog kenne ich keinen mehr. Da ist meiner wohl einzigartig ;-)
    Aber es gibt zum Thema “Agile Softwareentwicklung” eine wirklich sehr gute Seite: http://www.agile-methoden.de/.

Post a Comment