W02 Agile Manifesto
Das agile Manifest wurde 2001 während einem Treffen von Softwareentwicklern erstellt, als sich diese die Frage stellten: Wie können wir verhindern, dass unsere Projekte ins Leere laufen, weil die Zeit zwischen den Kundenwünschen und unserer Bereitstellung zu lange ist? Am Ende des Treffen haben jene Entwickler vier Werte identifiziert, die als das agile Manifest bekannt wurden. Diese vier Werte sollen helfen bessere Software zu entwickeln.
Es sind aber nur Werte, keine strikten Gesetze.
Individuen und Interaktion
Der erste Wert hinterfragt das Team selbst – also die Menschen, die die eigentliche Arbeit durchführen, d.h. euch. Im agilen Manifest ist definiert, dass die einzelnen Personen und ihre Interaktionen höher eingeschätzt werden als Prozesse und Werkzeuge. D.h. es ist wichtiger wie ihr im Team zusammen arbeitet und agiert als das neuste und hippste Projektmanagement-Tool zu benutzen. Es sollte nicht der Sinn sein, dass ihr ohne Prozesse und Werkzeuge arbeitet.
Funktionierende Software
Der zweite Wert spiegelt die Frage ab: Was ist für den Kunden am Ende wertvoller? Eine ausführliche Dokumentation oder funktionsfähige Software?
Am Ende ist eine neue Software auch ein Risiko für den Kunden und daher sollte das Ziel sein die Software möglichst stabil und gut zu entwickeln anstatt im Voraus jede Designentscheidung usw. aufwendig zu dokumentieren. Das bedeutet nicht, dass im agil gar keine Dokumentation vorhanden ist, sondern, dass funktionierende Software wichtiger ist und lediglich die Dokumentation vorhanden sein soll die notwendig ist für die Arbeit. In diesen Punkt fließt bereits das Anforderungsmanagement mit rein.
Da es jedoch schon jetzt von großer Bedeutung für euch ist, vier Fragen auf die ihr bald eine Antwort haben solltet:
Wie stellt ihr sicher, dass ihr das richtige Produkt baut? D.h. was ist funktionsfähige Software in eurem Fall? Dafür ist eine Kommunikation mit dem Auftraggeber unausweichlich.
Wie managt ihr die Anforderungen? Nicht alle Anforderungen sind gleich wichtig.
Wie könnt ihr nachvollziehen, woher die Anforderung kam und wer sie umgesetzt hat?
Durch agile Development habt ihr auch die Möglichkeit besser auf Kundenwünsche zu reagieren. Aber wie wollt ihr das handhaben? Wie erfasst ihr diese und wann erlaubt ihr als Team Änderungen? -> Change Management
Zusammenarbeit mit dem Kunden
Der dritte Wert des agilen Manifests knüpft etwas an die letzte Frage zu den Änderungen an, die ich euch gestellt hat. Es geht darum, dass es für euren Projekterfolg wichtiger ist mit dem Kunden zusammenzuarbeiten, als bei jeder Unstimmigkeit über die Vertragsdetails zu diskutieren. Ein anderer wichtiger Aspekt dieses Wertes ist, dass der Kunde von Beginn des Projektes mit in die Produktentwicklung integriert werden soll. Dadurch sollen auch die Feedbackschleifen zu eurem Produkt verkürzt werden und am Ende die Wahrscheinlichkeit auf einen erfolgreichen Projektabschluss gesteigert werden.
Reagieren auf Veränderungen
Der vierte und letzte Wert ist, dass die Reaktion auf Änderungen wichtiger ist als dem Plan zu folgen. Ihr erarbeitet zwar am Anfang einen Plan mit dem Kunden über das Produkt, aber vor allem bei neuen Entwicklungen und Ideen kann es schnell passieren, dass sich die Anforderungen ändern. Daher ist ein Beharren auf den Plan kontraproduktiv für das erfolgreiche Produkt am Ende. Aus dem Grund sollen Möglichkeiten geschaffen werden flexibel und möglichst schnell auf Änderungen zu reagieren.
Mögliche Änderungen können sein, dass sich die Situation bei euch oder den Kunden durch Urlaub, Klausuren, der Weihnachtspause oder Deadlines ändert und sich dadurch beispielsweise die Verfügbarkeit ändern. Es kann auch sein, dass sich sogar die Vision des Kunden ändert durch neues Wissen, neue Ideen, neue Gesetze, neue Technologien usw. Dies ist im SEP/BP aber eher selten.