Agile denken, oder: Wie man den Wasserfall überwindet

Agile denken, oder: Wie man den Wasserfall überwindet

Agile Methoden haben gegenüber dem althergebrachten Wasserfall Modell mehrere Vorteile. Es mag zwar besser für die Softwareentwicklung geeignet sein, jedoch sind nicht alle Unternehmen auch bereit, auf eine andere Methode umzusteigen. Der Wasserfall hat uns jahrelang recht gute Dienste geleistet und gilt immer noch als eine gute Methode, die in vielen Unternehmen beliebt ist. Agile Methoden sind relativ neu, zeichnen sich jedoch durch die Möglichkeit zur Steuerung des Entwicklungsprozesses und bei der effizienten Findung von Requirements aus.

Wenn man sich im Unternehmen für Agile Methoden entschieden hat, so ist dies der passende Artikel um einen reibungslosen Übergang zu gewährleisten.

Schritt 1. Das passende Projekt

Um das passende Projekt für die Implementierung der Agilen Methoden zu finden, müssen mehrere wichtige Kriterien analysiert werden:

• Größe

Ein Projekt sollte mindestens 4 Wochen dauern. Diese Zeitspanne ist optimal, um Feedback-Daten zu sammeln und die Methodik selbst zu verstehen. Die optimale Projektdauer beträgt 12 Wochen.

• Risiko

Das Projekt sollte für das Unternehmen zwar wichtig, aber nicht absolut kritisch sein. Idealerweise gibt es auch keinen Zeit- und Kundendruck geben. Während eines ersten Pilotprojekts muss man sich auf die Umsetzung der Methodik konzentrieren, anstatt große Waldbrände bekämpfen zu müssen.

• Beteiligung

Es ist wichtig, möglichst viele Mitarbeiter des Unternehmens in ein Projekt einzubeziehen: Projektmanager, Designer, Entwickler, Tester, Analysten. Ein Projekt soll mit diesen Personen alle Entwicklungsphasen durchlaufen: Konzeptplanung, Design, Analyse, Entwicklung. Es ist wichtig, eine klare Vorstellung von jedem methodischen Aspekt zu haben und während des gesamten Prozesses Feedback von allen Teilnehmern zu erhalten.

Schritt 2. Teamrekrutierung

Die ersten Projekterfahrungen sind ein wichtiger Aspekt, also soll die neue Projektmethode verantwortungsbewusst angegangen werden. Alle nötigen Skills seien in einem begeisterten Team zu sammeln. Es ist wichtig auch ein paar „Agile Befürworter“ an Board zu haben, sonst würden wir zu viel Zeit mit Streiten verbringen. Ein Team voller Enthusiasten würde zu einer erfolgreichen Integration der agilen Methoden führen. Der Schlüssel zu einem agilen Ansatz sind Individuen und Interaktionen: Selbstorganisation und Motivation sind wichtig, ebenso wie reibungslose Interaktionen zwischen den Teammitgliedern.

Schritt 3. Rollenbildung

Der nächste Schritt ist die Aufteilung der Rollen in unserem Team. Die wichtigsten wären:

  • Product Owner
  • Scrum Master oder Agile Project Manager
  • Software Developer
  • Business Analyst oder Kunde (nicht wirklich Teil des Teams, hat aber dennoch maßgeblichen Einfluss über den Prozess).

Diese Rollen sind in zwei Gruppen unterteilt: technische Spezialisten und Kundenkommunikation. Die Kundendienstseite, die von einem Product Owner und einem Business Analyst vertreten wird, ist für die Festlegung der Anforderungen verantwortlich und formt diese zu User Stories. Gibt ein Product Owner dem Entwicklungsteam "gerade genug" Informationen zur Verfügung, so kann der Arbeitsprozess gestartet werden.

Schritt 4. Planung und Schätzung

Die Erstellung einer Roadmpap ist der erste Schritt eines Projekts. Es ist notwendig, jede Aufgabe zu planen und vorauszuschätzen, wann jede User Story ungefähr abgeschlossen werden kann. Aber da dies das erste agile Projekt ist, ist hierfür Genauigkeit im Sekundenbereich nicht erforderlich. Vielmehr sollte man sich überhaupt einmal mit dem Ablauf des Einschätzens vertraut machen.

Also was sollte dann in die Planung einbezogen werden? Ein Projekt ist in Segmente unterteilt, die aus funktionalen User Stories bestehen. Jede User Story beinhaltet bestimmte Kriterien, welche ausgearbeitet oder erfüllt werden müssen. Diese Punkte zu erledigen, gibt einen guten Überblick darüber, zu wieviel Prozent „fertig“ das Projekt ist.

Eine User Story ist ein Instrument um Funktionalitäten von Software zu beschreiben. User Stories können frei formuliert werden und umfassen meist nicht mehr als wie zwei kurze Sätze, oft wird aber auch gern folgendes Schema herangezogen:

„Ich als ____ möchte ____, um ____.“

Akzeptanzkriterien hingegen sind ein Instrument zur Beschreibung spezifischer funktionaler Anforderungen und zur Darstellung bestimmter Schritte zur Erzielung eines erwarteten Ergebnisses. Es ist üblich, sie in der Gherkin Sprache zu formulieren.

Scenario: Anmelden

Given: Ich bin auf der Anmeldeseite

And: Mein Username ist gültig

And: Mein Passwort ist gültig

When: Ich klicke auf "Anmelden"

Then: Ich bin als Benutzer angemeldet

And: Meine User-Homepage wird geöffnet

Werfen wir einen Blick auf das Schätzen. Funktionalitäten werden in einem Größensystem wie bei T-Shirts angegeben: XS, S, M, L, XL. Die Größen von User Stories werden jeweils in Relation zu anderen User Stories eingestuft. Einen guten Start bietet eine Story, die eindeutig genug ist um zu bestimmen, wie lange es dauern würde sie genau zu entwickeln. Diese User Story wird als Benchmark angesehen und jede folgende User Story wird im Vergleich mit diesem grundlegenden Benchmark bewertet. Das gesamte Bewertungssystem zeigt also die Relationen zwischen von größeren und kleineren Aufgaben.

Schritt 5. Sprints und Sprintplanung

• Sprint Zero

In einer solchen Situation ist der Sprint 0 ein Schlüsselereignis, das die Herangehensweise für aktuelle und zukünftige Probleme festlegt: Wie man die Vision des Projekts formt, wie sind die Bestellvorgänge für das Manufacturing, wie wird das Team auf die agile Arbeit vorbereitet. Fokus liegt hier auf der Erstellung der Rahmenbedingungen für das Team, nicht auf dem Schreiben von großen Mengen and Codezeilen – das kommt in den späteren Sprints. Es ist ein wichtiges Problem, das ein jeder agiler Projektpilot lösen muss. Es ist wichtig, eine Sprintgröße zu definieren, damit das Team im Falle von Betriebsrisiken genügend Zeit hat, sich selbst aufzufangen.

• Sprint Planning

Alle User Stories sind formuliert und vom Team begutachtet, der Release Plan steht fest: jetzt kommt die Zeit um die einzelnen Sprints zu Planen. Jede im Nachhinein hinzukommende User Story muss wieder vom Team durchgesichtet werden. Ist sich das Team diesbezüglich einig, so werden die User Stories als Tasks definiert.

• Velocity

Bei Velocity spricht man von einer Kenngröße, wie viele User Stories ein Team innerhalb eines Sprints erledigt. Bei dem ersten Sprint eines Teams ist die Velocity natürlich noch nicht bekannt. Wie oft, je mehr Zahlen bekannt sind, umso genauer die Daten.

Diese Kenngröße sollte aber nicht in erster Linie das Team leiten – Tasks sollten nicht danach ausgesucht werden, bloß um einen schnelleren Velocity Wert zu erzielen.

Schritt 6. Sprint-Bewertung und Erfolgsdefinition

Die Schlüsselelemente, die sich auf den Erfolg eines Sprints auswirken, sind die Standup Meetings, Interaktion und Modifikationen.

Das tägliche Standup ist ein 15-minütiges Meeting, welches zur Beantwortung der folgenden Fragen dient:

  • Was habe ich gestern gemacht?
  • Was werde ich heute tun?
  • Habe ich momentan noch andere Probleme?

Die Interaktion ist einer der wichtigsten Erfolgsfaktoren, der von der Teamarbeit und dem Zusammenspiel zwischen jedem Teammitglied und anderen Dingen abhängt. Laut dem Agile Manifesto sind Individuen und Interaktionen wichtiger als Prozesse und Werkzeuge.

Sprint Review und Demo

Jeder Sprint sollte mit den folgenden Schritten abgeschlossen werden: einem Review und einer Demo.

Diese Eckpunkte sind der Diskussion der Arbeitsergebnisse gewidmet und anschließend wird ein fertiges Produkt dem Kunden gezeigt. Feedback wird empfangen und neue Aufgaben werden definiert, falls dies erforderlich ist.

Anschließend findet eine Retrospektive statt. Ziel ist es, einem Projektteam folgende Aspekte zu zeigen:

  • Was haben wir gut gemacht?
  • Was könnte verbessert werden?
  • Was könnte konkret im nächsten Sprint verbessert werden?

Und als dann? Wenn alle Sprints beendet sind und das Produkt fertig ist, wird eine umfassende Retrospektive durchgeführt und die Meinung des Teams über weitere Schritte eingeholt – zum Beispiel wie man agile Methoden in anderen Projekten des Unternehmens einsetzt! Erste Versuche mögen zwar selten perfekt sein, aber ein bisschen frischer Wind schadet ja auch nicht.