Entwickler haben eine klar umrissene Aufgabe: sie übersetzen die Anforderungen eines Product Owners in Code. Klingt ganz einfach. In der Praxis tun sich viele Teams damit allerdings schwer. Vor allem beobachte ich in unseren Trainings immer wieder, dass völlige Unklarheit darüber herrscht, welche Schritte auf dem Weg von den Anforderungen zum Code durchlaufen werden müssen. Mir ist klar, dass der Vergleich von Softwareentwicklung mit anderen Branchen nicht einfach ist. In einem Punkt unterscheiden wir uns jedoch von anderen Branchen: dort gibt es meist klar definierte Abläufe. Zu einem Hausbau gehören einige Schritte, die von jedem Planer durchlaufen werden. Nach dem Entwurf eines Architekten werden die Details konsequent geplant. Kein Handwerker geht auf die Baustelle, ohne dass vorher geplant wurde, was an welcher Stelle zu installieren ist. Und ja, auch beim Hausbau läuft einiges nicht rund. Trotzdem ist es wenig sinnvoll, im Bereich Softwareentwicklung immer wieder auf’s Neue zu überlegen, wie man denn nun dieses Mal von den Anforderungen zum Code gelangt. Daher möchte ich die einzelnen Schritte im folgenden vorstellen.
Von den Anforderungen zum Code
Anforderungen
- Anforderungen vertikal zerlegen
- Entwurf in die Breite
- Eine Anforderung auswählen
- Verfeinerung des Entwurfs in die Tiefe
- Arbeitsorganisation
- Implementation inkl. Tests
- Integration inkl. Tests
- Code Review
Code
1. Anforderungen vertikal zerlegen
Agiles Vorgehen bedeutet, regelmäßig und kurzfristig Feedback einzuholen. Dazu ist es erforderlich, die Anforderungen zum einen so zu zerlegen, dass ein ausreichend kleiner Teil entsteht. Zu viel auf einmal umsetzen bedeutet, späteres Feedback. Andererseits ist Feedback nur möglich, wenn vertikal zerlegt wird. Siehe dazu die Abbildung.
2. Entwurf in die Breite
Bei der Zerlegung aus Schritt 1 sind eine ganze Reihe Anforderungen identifiziert worden. Bevor wir uns auf eine davon konzentrieren und diese umsetzen, lohnt es sich, breiter zu schauen. Es wird also nicht im Detail betrachtet, wie die einzelnen Anforderungen umgesetzt werden können, sondern es wird auf alle Anforderungen gemeinsam geschaut, das jedoch nur oberflächlich. Dieser Schritt dient dazu, Abhängigkeiten unter den Anforderungen zu identifizieren und Entscheidungen zu treffen, die einen größeren Scope haben. Hier wird bspw. das Thema Zustand der Anwendung besprochen.
3. Eine Anforderung auswählen
In diesem Schritt geht es darum, dass der Product Owner sich für eine Anforderung entscheidet, die als nächstes umgesetzt werden soll. Im Kern steckt die Idee dahinter, dass das Team gemeinsam arbeitsteilig an einer einzigen Anforderung arbeitet, um diese mit maximaler Geschwindigkeit umzusetzen. Das erhöht die Geschwindigkeit, bringt Fokus und reduziert die Gefahr systematischer Fehler in mehreren angefangenen Aufgaben.
4. Verfeinerung des Entwurfs in die Tiefe
Zur ausgewählten Anforderung wird nun eine Lösung entworfen. Softwareentwicklung bedeutet, Lösungen zu Problemstellungen zu entwickeln und diese erst dann umzusetzen. In diesem Schritt wird die Lösung so detailliert entworfen, dass am Ende klar ist, welche Klassen/Dateien und Methoden implementiert werden müssen.
5. Arbeitsorganisation
Um arbeitsteilig zusammenarbeiten zu können, muss die als nächstes anstehende Implementation vorbereitet werden. In diesem Schritt werden die Kontrakte definiert und aufgeteilt, wer für welche Teile verantwortlich ist. Hier wird auch die Projektstruktur erstellt sowie gemeinsam benötigte Datentypen angelegt.
6. Implementation inkl. Tests
Nach den planerischen Vorarbeiten kann nun codiert werden. Dazu gehören selbstverständlich automatisierte Tests. Diese sind Stand der Technik und werden auf gar keinen Fall weggelassen. Idealerweise wird Test-first gearbeitet. In dieser Phase werden typischerweise Unit Tests geschrieben für kleine Einheiten der Gesamtfunktionalität.
7. Integration inkl. Tests
Da im vorhergehenden Schritt die einzelnen Bestandteile arbeitsteilig umgesetzt wurden, müssen diese nun integriert werden. Es muss also der Integrationscode implementiert werden und auch hier müssen automatisierte Tests geschrieben werden. In dieser Phase handelt es sich dann um Integrationstests.
8. Code Review
Bevor das Ergebnis dem Product Owner zur Abnahme übergeben wird, macht das gesamte Team ein Code Review. Hierbei wird bspw. geprüft, ob alle relevanten Prinzipien eingehalten sind, ob die Testabdeckung ausreichend hoch ist, ob die Anforderungen umgesetzt wurden, ob alle vereinbarten Konventionen eingehalten wurden, etc.
Im Anschluss ist es die Aufgabe des Product Owners, die Umsetzung seiner Anforderungen zu bewerten und dem Team Feedback zu geben. Ggf. muss das Team Korrekturen vornehmen. Im Anschluss wird der gesamte Prozess erneut durchlaufen, wobei häufiger bei Schritt 3 gestartet werden kann, bis alle Anforderungen aus der Zerlegung (Schritt 1) realisiert sind.
Dieser Prozess steht nicht in Konkurrenz zu Scrum. Im Gegenteil. Er füllt den Rahmen aus, den Scrum mit den Sprints vorgibt. Innerhalb eines jeden Sprints wird der oben dargestellte Prozess immer wieder durchlaufen. Wenn das Team Schätzungen abgeben muss, können die Schritte 1 und 2 als Basis dienen, ggf. auch Schritt 4.
Wenn Sie mehr erfahren möchten über die vorgestellte Vorgehensweise, können Sie dazu einiges nachlesen in meinem Buch „Mit Flow Design zu Clean Code“. Ferner wird das Thema in unserem Training Clean Code Developer Advanced besprochen und eingeübt.
Ihre Fragen können Sie gerne unten in die Kommentare schreiben.
German 
English