kramann.info
© Guido Kramann

Agile Softwareentwicklung

Das folgende Kapitel entstand aufgrund eines Fachgespräches mit Dr.-Ing. Dipl. Inform. Uwe Gühl, der gerade in Zusammenarbeit mit Dipl. Volkswirt Daud Alam ein Buch zu Projektmanagement erstellt. Das Buch soll unter dem Titel "Projektmanagement praxisnah" veröffentlicht werden.

Ein großes Problem in der Softwareentwicklung ist die Bewältigung der hohen Komplexität der zu entwickelnden Software. Bleiben auf dem Weg zum Endprodukt Tests von Einzelkomponenten aus, so passiert es häufig, dass nach einer längeren Entwicklungszeit das Projekt erfolglos abgebrochen werden muss.

Das Wesentliche bei der Agilen Softwareentwicklung sind deshalb zwei Dinge:

Die Verwendung von Timeboxen (Sprints) - das sind quasi fix vorgegebene äquidistante Meilensteine,
die Vereinbarung auf jeder Entwicklungsstufe der Software einen prinzipiell auslieferbaren Stand zu haben.

Insbesondere durch die Vereinbarung, auf jeder Entwicklungsstufe der Software funktionstüchtigen Code zu generieren wird die oben beschriebene "Komplexitätsfalle" gemieden.

Scrum

Eine weit verbreitete Spielart für "Agile Softwareentwicklung" ist die Scrum-Methode. Der Begriff Scrum kommt aus dem amerikanischen Football und stellt die Situation dar, in der sich die Manschaften bei Beginn des Spiels gegenüberstehen. Am einfachsten ist sie durch Spezifizierung der verschiedenen Rollen zu verstehen, die von den Projektteilnehmern eingenommen werden.

Product owner

Sie/Er formuliert und priorisiert so genannte "User stories".
Diese nehmen den Platz der Meilensteine ein und definieren einen Mehrwert für den Kunden, der am Ende der nächsten Timebox durch eine Implementierung vorhanden sein soll.
Beispiel: "Wenn diese User story umgesetzt ist, kann ich mich als User im System registrieren, um Kontodaten zu sehen."
Die Abnahme einer User story erfolgt durch den Product owner.

Scrum-Master

Sie/Er stellt den Prozess sicher.
Sie/Er sorgt dafür dass das Team arbeiten kann und moderiert den Scrum-Prozess.

Das Entwicklerteam

Das Entwicklerteam leitet gemeinsam Tasks (Aufgaben) aus den "User stories" ab.
Das Entwicklerteam setzt die Tasks um.

Bild 0-1: Rollen beim Software-Entwicklungsprozeß nach der Scrum-Methode (T1..Tn: Tasks/Aufgaben).

Ablauf eines Scrum basierten Projektes:

Vorarbeit

Der Product owner formuliert alle User stories. Diese Gesamtheit der User stories wird Backlog genannt.

Sprint Planung

Der Product Owner priorisiert/identifiziert User stories aus dem Backlog heraus, die im aktuellen Sprint umgesetzt werden sollten.
Der Product Owner legt zu jeder User story Abnahmekriterien fest (definition of done).
Das Team nennt seine freie Zeit für den aktuellen Sprint.
Die für den aktuellen Sprint ausgewählten User stories werden in Tasks aufgegliedert, deren Gesamtdauer abgeschätzt wird (planing poker).
Es werden soviele User stories für einen Sprint geplant, wie in die aktuelle Timebox hineinpassen.

Sprint Abschluß

Vorstellung des lauffähigen Codes
Abnahme der User stories durch den Product owner anhand der vereinbarten Abnahmekriterien
Thematisierung dessen, was gegenüber dem vorangehenden Sprint verbessert wurde (lessons learned)

daily scrum

Ziel: sich gegenseitig über den Stand der Arbeiten zu informieren und ggf. zusätzlich notwendige Aktivitäten zu definieren (ev. Vereinbarung nachfolgender bilateraler Gespräche).
Umhängen der Tasks am Task planungs board.
Ablauf des Treffens: Alle stehen und jedes Teammitglied äußert sich zu den Punkten:
- Wie geht es mir?
- Was habe ich getan (seit gestern)?
- Was werde ich tun (bis morgen)?

Bild 0-2: Taskplanungs-Board: Beim daily scrum werden die Tasks durchgesprochen und umgehangen von "initial" nach "in Arbeit", oder von "in Arbeit" nach "fertig".

Besonderheiten der Scrum-Methode

Primäres Ziel bei Scrum ist es die innerhalb eines Sprints vereinbarten User stories umzusetzen.
Stellt sich im Sprint-Abschlussmeeting heraus, dass einige User stories nicht oder unvollständig umgesetzt wurden, so fließt dies in die Planung des nächsten Sprints ein.
Jedes Teammitglied sollte jeden Task bearbeiten können, jeder sollte alles können.
Jeder gibt bei der Sprint Planung an, wieviel Zeit er hat.
Während eines Sprints wird nur an den vereinbarten Tasks gearbeitet. Korrekturen an der Verteilung der User stories auf die Timeboxes erfolgen nur in den Sprint Abschlußmeetings.

Mock

Nicht immer kann die Entwicklung so geplant werden, dass immer "User stories" formuliert werden können, die direkt produktiv einsetzbare Softwaremodule repräsentieren. Um dennoch das Paradigma der Agilen Softwareentwicklung an den Meilensteinen stets funktionierende Software vorliegen zu haben einzuhalten, wird oft die Anwendung des aktuell entwickelten Moduls simuliert.

Soll beispielsweise der zu entwickelnde Fuzzy-Regler für den Antrieb einer Laufkatze eingesetzt werden, so kann der "Mock" in einer Simulation der Laufkatze bestehen. Oft werden Mocks aber wesentlich einfacher konzipiert, als die reale Anwenderseite. So kann es in diesem Beispiel genügen, definierte Signale an den Regler zu geben, auf die die zu erwartende Reaktion bekannt ist.

Äquivalenzklassen

Auf einer viel niedrigen Ebene speziell für prozedurale Programme, gibt es die Testmethode der Äquivalenzklassen. Hier wird ein Softwaretest so durchgeführt, dass sämtliche Programmzweige des untersuchten Programms durchlaufen werden.

Testunit

Im Zeitalter der Objektorientierung würde man zum Testen einzelner Klassen Testunits generieren. Ganz im Sinne der Äquivalenzklassen sollten auch hier alle möglichen auftretenden Fälle für die Art und Weise, wie die Objkte der Klasse benutzt werden können getestet werden.

In unserem Fall (Java) bietet es sich an innerhalb der zu testenden Klasse eine main-Methode einzubauen, die Objekte der Klasse erzeugt und austestet.