Erfahrungsbericht zur agilen Softwareentwicklung: Schritt für Schritt ans Ziel
Wenn eine Software agil entwickelt werden soll, wird in der Regel der gesamte Entwicklungsprojekt agil durchgeführt. Das bedeutet, dass die Ergebnisse einer jeden Iteration in das produktive System übernommen werden.
Aktuell bin ich in einem Projekt tätig, das klassisch nach dem Wasserfallmodell organisiert ist, in dem Entwicklung aber agil nach Scrum durchgeführt wird. Was auf den ersten Blick kurios klingen mag, funktioniert in der Praxis außerordentlich gut und stößt auf große Akzeptanz/Begeisterung bei allen Beteiligten (Kunde, Projektleitung, Entwicklungsteam).
In diesem Blogbeitrag möchte ich dieses Projektszenario kurz skizzieren und anschließend meine bisherigen Erfahrungen dazu darstellen.
Szenario:
In dem Projekt wird eine SAP-Anwendung in ABAP entwickelt, die einen vorhandenen Geschäftsprozess, der aktuell noch manuell durchgeführt wird, ersetzen soll.
Dieses Projekt wird klassisch nach dem Wasserfallmodell durchgeführt und ist daher in die entsprechende Phasen (Anforderungsanalyse, Technisches Design, Implementierung, Test, Auslieferung & Wartung) aufgeteilt.
Zum Zeitpunkt, zu dem ich zum Projektteam gestoßen bin, war die Anforderungsanalyse bereits abgeschlossen. In der Anforderungsanalyse hat der Fachbereich zusammen mit den Endusern die Anforderungen spezifiziert und schriftlich in der Anforderungsspezifikation festgehalten.
Es wurde allerdings entschieden, den gesamten Implementierungsprozess (Technisches Design, Implementierung & Test) agil nach Scrum durchzuführen.
Ein entscheidender Grund für diese Entscheidung war, dass wir zur Implementierung ein neuartiges Entwickler-Framework der SAP nutzen. Dieses Framework bietet den großen Vorteil, dass damit Artefakte sehr viel schneller als mit bisherigen SAP-Tools entwickelt werden können und diese auch mit geringerem Aufwand angepasst und erweitert werden können.
Da das Gesamtprojekt klassisch nach dem Wasserfallmodell durchgeführt wird, erfolgt die eigentliche Auslieferung an den Kunden erst zum Projektende. Die Ergebnisse einer jeden Iteration werden jedoch regelmäßig dem Kunden vorgestellt.
Der Mitarbeiter aus dem Fachbereich, die zusammen mit den End-Usern die Anforderungen definiert haben, sind Teil des Entwicklungsteams. Während des gesamten Entwicklungsprozesses agieren sie als Product Owner für uns Entwickler.
Unsere Sprints haben eine Dauer von drei Wochen. Dies hat sich als eine gute Länge erwiesen. Wir haben zu Beginn auch eine Sprintdauer von zwei bzw. vier Wochen ausprobiert, diese als Team aber für zu kurz bzw. lang empfunden.
Wie im klassischen Scrum haben wir zu Beginn eines jeden Sprints die Sprint-Planungsmeetings 1 & 2.
Im 1. Planungsmeeting stellt der Fachbereich die User Stories vor, die in der Iteration bearbeitet werden sollen. Dabei wird definiert, wie das Ergebnis am Ende des Sprints aussehen soll, d.h. welche Funktionalitäten implementiert werden sollen und welche für die aktuelle Iteration “Out of Scope” sind. Dieser Prozess dauert für gewöhnlich einen halben Tag.
Im 2. Planungsmeeting definiert das Entwicklerteam die einzelnen Aufgaben, die zum Abschließen der zuvor definierten User Stories/Sprintziele notwendig sind. Auch dieser Prozess dauert für gewöhnlich einen halben Tag. Im Anschluss wird für jede Aufgabe der benötigte Aufwand geschätzt.
Zu Anfang einer jeden Iteration werden die Kapazitäten (Anzahl verfügbarer PT) für die Iteration ermittelt. Auf dem Taskboard landen dann in Summe so viele Aufgaben bzw. Aufwände, wie wir Kapazitäten zur Verfügung haben.
Damit ist die Planung der Iteration abgeschlossen. Alle Aufgaben landen als Karteikarten auf einer großen Pinnwand. Jeder Entwickler darf sich frei und ohne Einschränkung an diesem Taskboard bedienen. Nachdem der Entwickler die Aufgabe vollständig bearbeitet hat, bekommt sie der zuständige Mitarbeiter des Fachbereichs zum Testen. Erst wenn von dort das OK kommt, ist die Aufgabe abgeschlossen.
Am Ende der Iteration werden die erreichten Ergebnisse in einem Review-Meeting vorgestellt. Dabei sind die Projektleiter, der Fachbereich und die Entwickler anwesend. Im Anschluss an die Ergebnispräsentation findet die Retrospektive statt. Dabei wird die aktuelle Iteration (Ergebnis & Vorgehen) von allen Beteiligten bewertet und überlegt, was in der nächsten Iteration verbessert werden kann und wie. Dazu werden die Änderungsvorschläge in drei Kategorien gruppiert:
- “Keep” – Punkte die in der aktuellen Iteration gut waren, und die das Team beibehalten möchte
- “Get rid of” – Punkte die in dieser Iteration schlecht waren, und die das Team in der nächsten Iteration vermeiden möchte
- “Try” – Punkte, die das Team neu ausprobieren möchte
Fazit:
Der größte Vorteil bei der agilen Entwicklung ist, dass man bereits nach kurzen Intervallen Ergebnisse präsentieren kann. Dadurch können schon sehr früh während der Entwicklungsphase Teile der Anwendung vom Kunden/Enduser getestet/bewertet werden und Feedback kann eingeholt werden.
Agile Softwareentwicklung
Auf diese Weise kann schon sehr früh auf potentielle Änderungswünsche oder Lücken im Konzept reagiert werden. Gerade bei übergreifenden Aspekten, wie z.B. UI-Layout ist ein frühes Feedback sehr hilfreich. So muss die Layout-Änderung nur ein Mal durchgeführt werden und kann ich den nachfolgenden Sprints direkt wie gewünscht umgesetzt werden, anstatt dass am Ende der Entwicklung an 50 Stellen das Layout geändert werden muss.
Allerdings sollte darauf geachtet werden, dass man den Kunden abholt und ihm beibringt, dass die einzelnen Sprint-Ergebnisse ein “Work in Progress” sind, an dem sich bis zum eigentlichen Release noch Dinge ändern können. Das ist vor allem wichtig, wenn es sich wie hier um ein Hybridprojekt (Projekt nach Wasserfall, nur die Entwicklung agil) handelt.
Das Ziel eines jeden Sprint ist es, ein vollständiges Artefakt (Backend, Geschäftslogik, UI) zu erstellen und präsentieren zu können. Der Umfang bzw. die Aufgaben eines Sprints werden so gewählt, dass dieses Ziel erreicht wird. So werden solch klassische Entwicklungsphasen vermieden, in denen für einen langen Zeitraum nur Backend- & Geschäftslogik implementiert werden und erst viel später mit der UI-Entwicklung begonnen wird. Dadurch kann Backend- und Geschäftslogik erst viel später nach dessen Fertigstellung präsentiert und getestet werden.
So schön und flexibel das agile Vorgehen auch sein mag. An zwei Stellen muss man im Vergleich zu einem herkömmlichen Entwicklungsprozess mit Mehraufwänden rechnen: Meetings und Tests.
Für die zahlreichen eingeplanten Meetings (zwei Sprint Meetings, tägliche StandUp Meetings, Review Meeting), an denen sich immer das komplette Entwicklungsteam beteiligt, muss schon einiges an Zeit eingeplant werden. Daher verbringt man bei der agilen Entwicklung in Summe mehr Zeit mit Meetings, als bei einem herkömmlichen Vorgehen; gerade weil bei jedem Meeting das gesamte Team teilnimmt.
Diese Zeit ist zweifelos sehr gut investiert, da es viel Raum für fachliche und technische Diskussionen bietet. Dadurch können frühzeitig potentielle Lücken im Konzept aufgedeckt und behandelt werden. Und so umfangreich und detailiert ein Konzept auch sein mag, es kann selten alle Details und Spezialfälle beachten. Viele Punkte fallen auch erst ins Auge, wenn versucht wird, die Details zu implementieren.
Durch die täglichen StandUp Meetings werden Probleme oder Fehleinschätzungen der Aufwände bei einzelnen Aufgaben sehr früh erkannt und es kann rechtzeitig und gezielt gegengesteuert werden.
Neben den Meeting muss bei der agilen Entwicklung auch mehr Zeit für Tests eingeplant werden Da iterativ entwickelt wird, wird sehr häufig vorhander Code wieder angefasst und erweitert, bzw. abgeändert. Das ist erst einmal nichts verwerfliches. Änderungen/Erweiterungen können aber schnell zu ungewünschten Seiteneffekten/Verhalten führen.
Da am Ende eines jeden Sprints, eine lauffähige und funktionsfähige Anwendung existieren soll, muss kontinuierlich sichergestellt werden, dass sich die Anwendung vor und nach den Änderungen identisch verhält.
Manuelle Tests sind dafür sehr ungeeignet, da dafür sehr viel Zeit aufgewendet werden muss. Viel besser bei einer iterativen Entwicklung sind automatisierte Tests. Sie werden einmal geschrieben und regelmäßig, idealerweise täglich, ausgeführt.
Das Schreiben solcher Tests verschlingt definitv auch Entwicklungszeit. Je nach Komplexität der zu testenden Funktionalität auch schnell mal ein paar PT. Ich habe aber die Erfahrung gemacht, dass sich dieser Aufwand bereits nach ein paar Sprints rechnet, sofern diese Tests regelmäßig ausgeführt und kontrolliert werden. Auf diesem Weg werden unerwünschte Seiteneffekte einer Änderung sehr schnell erkannt und es kann entsprechend reagiert werden.
S/4HANA Entwickler-Schulungen
In der SAP Welt findet aktuell eine schnelle Entwicklung statt. Dadurch entstehen neue Projekte und Anforderungen für SAP Kunden und für SAP Entwickler.
Natürlich müssen solche Tests auch angepasst werden, sofern sich an der Funktionalität etwas ändert (z.B. wird in einem späteren Sprint eine vorhandene Funktionalität um neue Features ergänzt). Dieser Punkt sollte auf jeden Fall beachtet werden, wenn das Konzept für die Tests definiert wird.
Es sollte auch beachtet werden, dass in einem agilen Projekt andere Anforderungen an die Entwickler gestellt werden als bei einem herkömlichen Vorgehen. So müssen die Entwickler viel selbstständiger und selbstorganisierter arbeiten. Sie müssen ihre Aufgaben selbstständig organisieren und dafür sorgen, dass diese rechtzeitig fertig gestellt werden. Bei Problemen muss der Entwickler in der Lage sein, diese selbstständig und zeitnah lösen zu können. Weiterhin sei zu beachten, dass nicht nur reine Entwicklungstätigkeiten anfallen. Auch Testen und ggf. Design oder Konzeptionsaufgaben gehören zum Aufgabenfeld eines Entwicklers, wenn agil nach Scrum gearbeitet wird.
Zusätzlich ist es auch wichtig, dass jeder Entwickler alle möglichen Aufgaben übernehmen kann. Daher sind in einem Scrum-Projket Allrounder mehr gefragt, als Spezialisten, die nur ein Gebiet abdecken (z.B. UI-Technologie). Da bei Scrum die Projektgröße sehr klein angesetzt ist, ist es wichtig, dass jeder Entwickler alles machen kann, um flexibel auf Ausfälle, Urlaub o.ä. reagieren zu können.
