< zur Übersicht

Alle Welt redet oder schreibt über agile Software-Entwicklung, agile Vorgehensweise, agile Projekte – Sie als Kunde fragen sich, ist agiles Vorgehen ein Fass ohne Boden? Hat das nur Vorteile für den Dienstleister und ich gebe dazu das Geld?

 

Was bedeutet agiles Projektvorgehen?

Im Unterschied zum klassischen Wasserfall-Modell – erst Anforderungsklärung und Grobkonzept, dann ein vollständiges und bestätigtes/freigegebenes Fachkonzept, danach Übergabe an die Entwicklungseinheit und Implementierungsbeginn, nach Entwicklungsabschluss startet der Test – werden im agilen Vorgehen Anforderungen, Detail-Konzeption und Entwicklungs- und Testaufgaben parallelisiert und sowohl Kundenvertreter, Entwickler als auch Tester von Beginn an einbezogen. Im besten Fall werden sogar schon Mitarbeiter des zukünftigen Systembetriebs involviert, um auch deren Anforderungen aufzunehmen und ihnen zu ermöglichen, begleitend die entstehende Software-Lösung kennenzulernen. Ausführlichere Informationen zum agilen Vorgehen und dessen Vorteile können Sie in unserem Blog-Artikel „8 Vorteile von einem agilen Projektvorgehen“ nachlesen.

 

Was bekommen Sie für Ihr Geld? Es liegt auch in Ihrer Hand …

Eins der Prinzipien aus dem Manifest für Agile Softwareentwicklung lautet, „… den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen“. Wertvolle Software entsteht aber nur, wenn Sie auch benennen können, was WERTvoll für Sie ist.

Projektziele und zielorientiertes Anforderungsmanagement – das A und O

Bevor es also los geht, müssen Sie Ziele für das Vorhaben definieren, an denen die Anforderungen und Anwendungsfälle (User Stories) in Bezug auf Wichtigkeit und Vollständigkeit gemessen werden können. Ist ein frühzeitiger Go-Live ein wichtiges Ziel für Ihr Projekt, dann ist es hilfreich, Minimalziele für das erste Release festzulegen, z.B. auf Basis folgender Überlegungen:

• welche Geschäftsprozesse mit welchen Produkten für welche Anwendergruppen sind zuerst für den Online-Vertrieb erfolgversprechend oder

• mit welchen Geschäftsprozessen für welche Anwendergruppen kann Last vom „Altsystem“ genommen werden.

Des Weiteren kann zwischen MUSS-, SOLL- und KANN-Anforderungen bzw. User Stories unterschieden werden. Priorisierte MUSS-Anforderungen werden zuerst in User Stories für die Implementierung ausgearbeitet. Unter den vorbereiteten User Stories wiederum können diejenigen depriorisiert werden, die nicht unbedingt für das erste Release erforderlich sind.

Depriorisierte Anforderungen und User Stories können dann schon vorbereitet, aber einem Folge-Release zugeordnet werden. Gleichermaßen werden sich im Sprint-Verlauf ergebende Änderungsbedarfe auf ihre Wichtigkeit zur Zielerreichung geprüft und entsprechend dem ersten Release oder Folge-Releases zugeordnet.

Die fachliche Ausrichtung, Vorbereitung und Priorisierung der zu implementierenden Anwendungsfälle (User Stories) an den definierten Zielen ist Aufgabe Ihres Product-Owner. Diese Rolle ist enorm wichtig und bestimmt den fachlichen Fahrplan.

Technologische Basis – Standard-Software oder Maßanfertigung entlang der Geschäftsprozesse

Es ist ein wesentlicher Unterschied, ob für Ihre Projektzielerreichung die Nutzung einer Standard-Software möglich ist, deren Out-of-the-Box-Funktionen Ihren Geschäftsprozessen weitestgehend entsprechen und unterstützen, oder ob Sie eine spezielle Entwicklung für Ihre Geschäftsprozesse benötigen.

Des Weiteren sind das technologische Systemumfeld und die notwendigen Systemschnittstellen für den Datentransfer zu betrachten. Unzureichend dokumentierte Systemschnittstellen verursachen auch im agilen Vorgehen Klärungen und Nachdokumentation. Und: nicht oder nur unzureichend vorhandene Funktionen in der bestehenden Systemlandschaft sollten bestmöglich auch dort ergänzt oder hinzugefügt werden, nicht in der neuen Software-Lösung.

 

Und wann ist Go-Live?

Wenn Ihr Product-Owner bestätigt, dass Ihre Mindestanforderungen für den Geschäftszweck implementiert und erfolgreich getestet wurden, dann geht das erste Release online. Mit diesem Release sammeln Sie Erfahrungen, wie Ihre System-Lösung angenommen wird und können mit diesem Feedback die Anforderungen und Anwendungsfälle für die Folge-Releases bewerten und priorisieren.

 

Budget-Sicherheit bei gleichzeitiger Anforderungsflexibilität – geht das?

Das Budget ist begrenzt, die Anforderungen sind es nicht? – auch dafür gibt es Lösungsansätze.

Exchange for Free / Austauschmöglichkeit von User Stories, z.B. auf Basis von Story Point-Bewertungen

Die im Rahmen von sogenannten Grooming-Terminen detaillierten und hinsichtlich Komplexität mit Story Points bewerteten User Stories im Product-Backlog können durch den Product-Owner durch neue, bislang nicht im Projektumfang enthaltene User Stories ausgetauscht werden, sofern die Arbeit für die zugehörigen User Stories noch nicht begonnen wurde und die ausgetauschten User Stories ungefähr gleichwertig hinsichtlich Komplexität und Aufwand sind.

Voraussetzungen dafür sind ein gut und qualifiziert gefülltes Product-Backlog - es sollten 60% bis 80% angestrebt werden – und ein kompetenter Product-Owner, der die Erreichung der Projektziele durch die fachliche Richtigkeit der Software-Lösung verantwortet und entscheiden kann, welche Anforderungen dafür zwingend erforderlich sind.

Agiler Festpreis

Je klarer seitens des Kunden die Projektziele und der erwartete Funktionsumfang beschrieben und dokumentiert sind, je mehr Implementierungserfahrung der Dienstleister mit der angestrebten Software-Lösung hat, desto einfacher ist es, Anteile des Projekts als agilen Festpreis anzubieten. Schlecht oder gar nicht zu bewertende Leistungs-anforderungen sind für einen agilen Festpreis nicht geeignet.

Unser Ansatz ist hier, fachliche Anforderungen hinsichtlich Komplexität in Epics – größere Funktionsbausteine - zu differenzieren, je Epic-Komplexität die Anzahl sowie den Schwierigkeitsgrad von User Stories und die erwarteten Aufwände für Entwicklung & Test zu schätzen. Um erforderliche Dienstleistungen wie Scrum-Master-Rolle, Product-Owner-Support, Testunterstützung, Go-Live-Support u. ä. ergänzt, kann auf dieser Basis ein Hauptvertrag mit Aufwandsobergrenze vorbereitet und verhandelt werden. Nicht ausreichend bewertbare Anforderungen werden abgegrenzt oder als Time & Material-Leistungspaket hinzugenommen.

Sobald das Backlog mit ausreichend qualifizierten User Stories gefüllt ist, wird der erste Sprint-Umfang vom Product-Owner mit dem agilen Team geplant. Dieser vereinbarte Sprint-Umfang wird als Sprint-Abruf-Angebot aus dem Hauptvertrag deklariert und als Festpreis von beiden Vertragsparteien bestätigt. Dienstleistungen im Sprint-Zeitraum können in den Sprint-Abruf aufgenommen werden, um den Budget-Verbrauch je Sprint transparent darzustellen. Auf diese Weise können beide Vertragsparteien nachvollziehen, welche Funktionen mit welchem Budget-Einsatz realisiert wurden.

Es empfiehlt sich, die ersten Sprints als sogenannte Enabling Sprints zu vereinbaren. Das hat zum Ziel, alle Projektbeteiligten mit den Rollen und Aufgaben im agilen Vorgehen vertraut zu machen und auch die Leistungsfähigkeit (Velocity) des agilen Teams bei der Realisierung der User Stories zu ermitteln. Damit wird eine Relation zwischen Story Point-Bewertung von User Stories und Implementierungsaufwand erreicht, um einerseits die

Austauschbarkeit von User Stories auf Basis von Story-Points zu erleichtern (s.o.), zum anderen die mögliche Einhaltung der geschätzten Aufwandsobergrenze zu verifizieren. Damit ist eine stetig bessere Vorhersage für den Fertigstellungstermin möglich.

 

Offene Kommunikation von Beginn an

Es ist für den Projekterfolg und den Vertrauensaufbau wesentlich, die Theorie des agilen Vorgehens auf die praktischen Möglichkeiten zu „übersetzen“, d.h. mit den unmittelbar am Vorhaben Beteiligten Gespräche zur Projektvorgehensweise durchzuführen. Diese dienen dazu, Ihr und unser „agiles Verständnis“ abzugleichen, die erforderlichen Rollen und Tätigkeiten für eine erfolgreiche agile Zusammenarbeit zu vereinbaren und – wenn erforderlich – die Theorie an die personelle Verfügbarkeit, die Kommunikations- und Informationsbedarfe in Form eines Projekt-Vorgehensmodells anzupassen. Dieses vereinbarte Projekt-Vorgehensmodell ist Basis für den Projektvertrag und den gemeinsamen Erfolg.

Wir sind nur zufrieden, wenn Sie es auch sind.

KOMMEN SIE GERN AUF UNS ZU

< zur Übersicht