TopMenue

Die vier Leitsätze des agilen Manifests

scrum.that.runs

Ein Teil dieser Seiten wurde ursprünglich für doktor-scrum.de geschrieben und ziehen nun hierher nach scrumcess.de um; leider sind sie aber inhaltlich noch nicht vollständig auf scrumcess.de umgearbeitet. Zudem ist es durchaus möglich, dass die enthaltenen Links noch ins Leere zeigen, bzw. noch auf doktor-scrum.de verweisen.
Ich bitte Sie, das zu entschuldigen.

1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge   ^

Was ist damit gemeint?

Damit wird ausgedrückt, dass die an einem Vorgang oder Projekt beteiligten Personen, ihr Umgang und Austausch, ihre Kommunikation und ihre Zusammenarbeit einen größeren Einfluss auf die erfolgreiche Durchführung, bzw. den erfolgreichen Abschluss des Projektes haben und damit wichtiger sind, als die Wahl der eingesetzten Prozesse und Werkzeuge … zumal die Prozesse letztlich auch nur Werkzeuge sind.

Dieser Leitsatz stellt die am Projekt beteiligten Personen in den Vordergrund und grenzt die agile Vorgehensweise gegenüber den klassischen Vorgehensweisen — die mit ihren eng gefassten und kleinteilig definierten Handlungsspielräumen den Prozess als solchen in den Vordergrund stellen — ab.

Die agilen Vorgehensweisen zielen darauf, den beteiligen Personen den notwendigen Freiraum zu schaffen, damit sie ihre kreativen und handwerklichen Potentiale und Kompetenzen zum Vorteil des jeweiligen Vorganges voll ausschöpfen können, wohingegen die klassischen Vorgehensweisen ein enges Korsett abzuarbeitender Handlungsanweisungen vorgeben. Letzteres funktioniert jedoch nur dann gut, wenn im Plan bereits alle eventuell auftretenden Zustände bedacht und dokumentiert worden sind, was, realistische betrachtet, insbesondere bei einem Softwareentwicklungsprojekt, so gut wie unmöglich ist.

Zudem sind es letztlich immer die Individuen und ihr gemeinsames, permanent aufeinander fein abgestimmtes Handeln, die den Vorgang oder das Projekt vorantreiben und nicht die Präsenz von Prozessen oder Werkzeugen; es sind immer die Individuen, die die Werkzeuge einsetzen und nicht umgekehrt.

Anders gesagt, sind die beteiligten Individuen und ihre Fähigkeiten für die Durchführung eines Vorganges oder Projektes essenziell, die zur Verfügung stehenden Werkzeuge und Prozesse sind es nicht in jedem Fall.

Was ist damit nicht gemeint?

Damit wird nicht gesagt, dass Werkzeuge unwichtig wären, im Gegenteil; jedoch ist ihre Bedeutung geringer als die der Individuen, die sie einsetzen, zumal die Werkzeuge aus sich heraus ohne die Individuen, die sie einsetzen oder bedienen, nichts leisten können; die Individuen können das ohne die Werkzeuge schon, wenn auch wahrscheinlich viel langsamer.

2. Funktionierende Software ist wichtiger als umfassende Dokumentation   ^

Was ist damit gemeint?

Das Ziel von Softwareentwicklung ist in erster Linie, lauffähige, einsetzbare Softwareprodukte zu entwickeln und erst in zweiter Linie, sie zu beschreiben oder zu dokumentieren. Eine Dokumentation ist ohne Frage sehr wichtig, aber wenn sich der Auftraggeber zwischen dem Produkt und der Dokumentation entscheiden müsste, würde er sich ohne Zweifel für die für ihn hergestellte Software entscheiden.

Soweit sollte man es sicherlich nicht kommen lassen, aber wenn eine Entscheidung zwischen der Fertigstellung der Software und der Fertigstellung der Dokumentation zu treffen ist — so drückt es dieser Leitsatz aus — ist es für den Auftraggeber von weitaus höherem Wert, das bestellte Softwareprodukt in einem für ihn einsetzbaren Zustand zu erhalten und einsetzen zu können, als die Auslieferung des Produktes von der lückenlosen Fertigstellung der Dokumentation abhängig sein zu lassen.

Was ist damit nicht gemeint?

Dass soll nicht bedeuten, dass die Dokumentation überflüssig wäre; ihre Bedeutung ist ohne Frage sehr hoch, aber im Zweifel geringer einzuschätzen, als die Bedeutung der lauffähigen, einsetzbaren Software, die in ihr beschrieben wird.

3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung   ^

Was ist damit gemeint?

Software zu entwickeln ist zumeist ein sehr teures Unterfangen und man tut gut daran, ein solches Projekt mit einem für alle Seiten akzeptablen Vertrag zu regeln. Diese Vertragsverhandlungen können sehr schwierig und zeitaufwändig sein, insbesondere dann, wenn es sich für die beteiligten Parteien um große Projekte handelt.

Der Leitsatz rückt die Zusammenarbeit zwischen dem ausführenden Unternehmen, bzw. den Entwicklern und dem Auftraggeber, in den Mittelpunkt des Projektes. Statt sich schon im Vorwege in Vertragsverhandlungen zu verlieren, sollte man statt dessen frühzeitig prüfen, ob nicht bereits mit der Arbeit begonnen werden kann, auch wenn der Vertrag noch nicht bis ins letzte ausformuliert ist oder sich noch in der Bearbeitung befindet.

Selbstverständlich können sich auch im Verlauf des Projektes Änderungen ergeben, die dazu führen, dass Teile des Vertrages neu verhandelt und angepasst werden müssen. Hier mahnt der Leitsatz an, dass sich daraus keine Unterbrechungen des Projektverlaufes ergeben sollten, sondern dass das Projekt parallel zu den Verhandlungen unterbrechungsfrei fortgeführt wird.

Was ist damit nicht gemeint?

Damit ist nicht gemeint, dass man keine Verträge machen sollte, oder dass Verträge unwichtig wären, sondern nur, dass einer konstruktiven Zusammenarbeit mit dem Auftraggeber mehr Raum und Zeit als den Vertragsverhandlungen eingeräumt werden sollte. Es bedeutet weiterhin, dass der Fokus des Projektes im Anschluss an die Vertragsverhandlungen nicht allein darauf gesetzt werden soll, ausschließlich den geschlossenen Vertrag zu erfüllen, sondern dass die Maximierung des Nutzens, den der Auftraggeber aus dem für ihn erstellten Produkt ziehen kann, wichtiger sein sollte als das, was ursprünglich im Vertrag festgehalten wurde.

Verträge kann man relativ leicht ändern, verloren gegangene Zeit aber nicht zurückholen.

4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans   ^

Was ist damit gemeint?

Mangelnde Flexibilität ist einer der wesentlichen Gründe für das Scheitern vieler (Softwareentwicklungs-) Projekte. Ansichten, Erfahrungen, Meinungen, Bedürfnisse und Anforderungen können sich gerade in der Softwareentwicklung sehr schnell ändern; was gestern noch sehr wichtig und „alternativlos“ war, kann heute schon wieder aus guten Gründen obsolet sein.

Ein Plan stellt eine Richtschnur dar, an der man sich entlang arbeitet, um am Ende das im Plan festgelegte Ziel zu erreichen. Ändern sich im Laufe der Umsetzung jedoch die Anforderungen und/oder die Voraussetzungen der ursprünglichen Planung, ist es nicht unwahrscheinlich, dass diese Änderungen sich auch in einer Aktualisierung des Zieles niederschlagen.

Verfolgt man statt dessen jedoch den (zu diesem Zeitpunkt wahrscheinlich bereits veralteten) Plan weiter, ohne die Änderungen zu berücksichtigen, erhält der Auftraggeber bei der Ankunft am Ziel mit sehr hoher Wahrscheinlichkeit ein analog zum Plan zu diesem Zeitpunkt wahrscheinlich bereits veraltetes Projektergebnis, dass dann im Nachhinein oftmals nur noch mit großem Aufwand (Zeit UND Geld) auf den neuesten Stand gebracht werden kann.

Dieser Leitsatz fordert daher die beteiligten Personen auf, offen für Veränderungen des Plans zu sein, um auf eventuell veränderte Rahmenbedingungen schnell und flexibel reagieren zu können und sie nicht erst nach vollständiger Abarbeitung des (in diesem Fall bereits veralteten) Planes zu berücksichtigen.

Was ist damit nicht gemeint?

Damit ist — wie den agilen Prozessen gerne immer wieder unterstellt wird — auf gar keinen Fall gemeint, dass man keine Pläne machen sollte (Zitat: „in agilen Prozessen wird nicht geplant“), vielleicht z.B., weil sie in dem Moment, wo sie aufgestellt werden, potentiell schon wieder veraltet sein könnten. Pläne und Planung sind (auch und gerade in den agilen Prozessen) von essentieller Bedeutung, weil sie dem Team und dem Auftraggeber ein gemeinsames Bild davon geben können, in welche Richtung zu gehen ist.

Gemeint ist lediglich, dass es wichtiger ist, flexibel auf Veränderungen zu reagieren, statt sie zu ignorieren oder nicht anzunehmen und auf das Einhalten eines zuvor erstellten und potentiell veralteten Planes zu bestehen.

Gemeint ist damit natürlich auch nicht, dass das Prinzip der Veränderung des Planes zum Kernprinzip agiler Softwareentwicklung als Selbstzweck wird, also quasi am Vortag der Endabgabe die Anforderungen ins Gegenteil zu verkehren, um dem Prinzip der Agilität maximal zu entsprechen, gleichzeitig aber auf die Einhaltung des Abgabetermins zu pochen …

[zurück zum Seitenanfang]


No comments yet.

Schreibe einen Kommentar

V1503130747DE