Agile Softwareentwicklung mit Scrum
29.03.2018 | Robert Junklewitz | 13 min Lesezeit
merken
Stern Icon
Stern Icon
Briefumschlag Iconper E-Mail erinnern X Icon
Ladekreisel
Bitte geben Sie eine E-Mail Adresse ein!
Das Datum darf nicht in der Vergangenheit liegen!
Stern Icondiesen Artikel merken
Stern Icondieser Artikel ist auf der Merkliste

Software­entwicklung bei digatus? Agil durch den Einsatz von SCRUM

grüne Trennlinie

Viele werden sich noch an die Zeit erinnern, in der Software in großen Zeitabständen in einer Box zum Endkunden kam. Dort konnte es dann auch noch vorkommen, dass der jeweilige Systemadministrator die gekaufte Software zunächst nicht sofort einsetzt, da die neue Software erst getestet und evaluiert werden musste.

Diese starre Herangehensweise ließ nur wenig Raum für außergewöhnliche Innovationen. Somit erhielt der Kunde genau das, was er zu Projektbeginn, vorzugsweise in einem Lastenheft, definiert hatte. Ein Lastenheft war ein langes Dokument, in dem alle Anforderungen an das Produkt detailliert festgehalten wurden. Das Problem an dieser Vorgehensweise war, dass Kunden zu Beginn meist noch nicht genau wissen, welche spezifischen Anforderungen es an die Anwendungen gibt. Einige werden erst im Verlauf der Entwicklung klar und auch bestehende Anforderungen können sich ändern, weil man bessere Lösungen findet oder manche Funktionalitäten nicht ohne Abstriche realisierbar sind.

Die Revolution kam im Jahre 2001 mit der Entstehung des sogenannten „Agile Manifesto“. Eine Gruppe von 17 projekterfahrenen Software-Entwicklern und innovativen Denkern traf sich in einer Hütte im Snowbird Ski Resort in den Wasatch Mountains in Utah, um mögliche Alternativen zu den bisherigen dokumentationslastigen und schwerfälligen Entwicklungsprozessen zu finden. Das Ergebnis – the Manifesto for Agile Software Development – war wegweisend für die gesamte IT-Branche und hat seine Bedeutung auch bis heute nicht verloren. Die Beteiligten erarbeiteten zwölf Prinzipien agiler Softwareentwicklung, basierend auf vier grundlegenden Wertvorstellungen:

“Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.”

Manifest für agile Softwareentwicklung

Traditionelle Methoden vs. Agile Softwareentwicklung

grüne Trennlinie

Nach traditionellen Methoden, wie zum Beispiel dem Wasserfall-Modell, werden Software-Projekte in einzelne Phasen gegliedert, die zeitlich aufeinander folgen und idealerweise jeweils von unterschiedlichen Teams bearbeitet werden. Sobald eine dieser Phasen durchlaufen wurde, ist es nur noch schwer möglich zu ihr zurückzukehren und Anpassungen vorzunehmen, da sich das Team bereits in einer anderen Phase befindet. Durch diesen strukturellen Projekt-Aufbau können blockierende Probleme schnell zu Engpässen und Verzögerungen führen, da der Abschluss einer Phase Voraussetzung für den Beginn der nächsten Phase ist.

Am Ende eines Projekts kommt es zu einem einzigen Release, bei dem das komplette Produkt veröffentlicht wird. Zu diesem Zeitpunkt kommt der Endkunde meist zum ersten Mal in Kontakt mit dem Produkt, da im Gegensatz zu agilen Vorgehen nicht iterativ neue Prototypen vorgestellt werden können. Dadurch werden mögliche Probleme oft viel zu spät entdeckt, was zu höheren Kosten führen kann. Würde man iterativ dem Kunden neue Prototypen zeigen können, könnte man sehr schnell darauf reagieren, wenn Anforderungen falsch verstanden und entwickelt wurden.

Traditionelle Methoden eignen sich für Produkte, bei denen die Anforderungen bereits zu Beginn klar definiert sind und strukturiert vorliegen. Des Weiteren haben sie auch ihre Stärken bei Produkten mit hohen nicht-funktionalen Anforderungen, wie Sicherheit, Performance oder auch Zuverlässigkeit, da man sie von Anfang an berücksichtigen und somit besser einplanen kann.

Nichtsdestotrotz ändern sich Anforderungen in der heutigen Praxis sehr schnell, da es in kurzer Zeit zu enormen technologischen Fortschritten kommt. Agile Softwareentwicklung hilft dabei, auf diese wechselnden Anforderungen zeitnah zu reagieren. Dementsprechend sind die Projekte in kurze, iterative Zyklen gegliedert, mit Fokus auf Kommunikation, Kollaboration und regelmäßigem Feedback. Diese flexible Arbeitsweise ermöglicht es auf (Markt-)Änderungen, wie zum Beispiel neue Technologien oder Trends, einzugehen und somit eine hohe Kundenzufriedenheit sicherzustellen. Eine bekannte und weit verbreitete agile Methode ist SCRUM.

Wie läuft ein Projekt mit SCRUM ab?

grüne Trennlinie

Die agile Softwareentwicklung nach SCRUM läuft in fest definierten, kurzen und sich wiederholenden, Phasen ab, sogenannten Sprints. Zu Beginn eines Sprints treffen sich die Teams zur Planung der bevorstehenden Phase. Grundlage dieses Sprint-Plannings ist das priorisierte Product-Backlog des Product Owners. Dieses Product-Backlog besteht in der Regel aus User-Stories, welche die Anforderungen an das Produkt beschreiben. Im Team werden dann die Aufwände für diese User-Stories geschätzt. Das kann zum Beispiel über den geschätzten Zeitaufwand oder durch Ansätze wie dem Planning Poker geschehen. Nach mehreren abgeschlossenen Sprints verfügt ein Team über eine durchschnittliche Sprint-Velocity. Diese sagt aus, wie viele User-Stories sie im Durchschnitt pro Sprint schaffen. Anhand der jeweiligen Velocity und der Aufwandschätzungen für die einzelnen User-Stories wird dann das Sprint-Backlog erstellt.

Prozessablauf nach Scrum
Prozessablauf nach der SCRUM-Methode

Effiziente Kommunikation und Kollaboration sind in der SCRUM-Methode sehr wichtig, weshalb es tägliche Stand-Up-Meetings gibt. Diese bewusst kurz gehaltenen Meetings, etwa 15 Minuten, dienen der besseren Abstimmung des Softwareteams untereinander. Jeder Entwickler erklärt knapp, welche Aufgaben er am Vortag erledigt hat, was für den Tag geplant ist und ob es dabei Hindernisse oder Probleme gibt, die ihn bei seiner Arbeit blockieren könnten. Falls Probleme auftauchen wird im Team nach Lösungen gesucht.

Am Ende einer Phase findet eine Sprint-Demo statt. Im Idealfall gibt es dabei eine Testumgebung, welche die Produktivumgebung möglichst gut repräsentiert. Dabei demonstrieren sich die Teammitglieder gegenseitig und auch den Stakeholdern die Ergebnisse des Sprints. Dadurch erhält das SCRUM-Team sofort Feedback und hat die Möglichkeit, direkt darauf zu reagieren und somit spätere Nachbesserungen zu vermeiden. Ansonsten könnte es auch passieren, dass zum Beispiel Anforderungen falsch verstanden wurden und durch umfangreiche Anpassungen wertvolle Zeit verloren geht.

Zusätzlich gibt es eine Sprint-Retrospektive. In diesem Rückblick wird reflektiert, was besonders gut lief, wo die Probleme lagen und welche Verbesserungspotentiale es für die kommenden Sprints gibt.

Welche Rollen gilt es bei SCRUM zu besetzen?

grüne Trennlinie

Der Product Owner legt seinen Hauptfokus auf das Produkt. Er kennt die Anforderungen genau und ist dementsprechend für die Priorisierung der anstehenden Aufgaben zuständig. Dazu entwickelt und verwaltet er das Product-Backlog, die priorisierte Sammlung sämtlicher fälliger Aufgaben, welche zusammen mit dem Kunden erarbeitet wurden. Durch die enge Zusammenarbeit mit dem Team stellt er sicher, dass sämtliche Elemente im Backlog von jedem verstanden werden. Der Product Owner entscheidet außerdem, wann das Produkt ausgeliefert wird. Dabei ist es empfehlenswert, eine häufigere Auslieferungsfrequenz zu wählen.

Der SCRUM Master ist zuständig für den korrekten Ablauf und die Umsetzung des SCRUM-Prozesses. Er unterstützt das Team bei der Prozessoptimierung, indem er mögliche Hindernisse aus dem Weg räumt und Ablenkungen vermeidet. Dazu vermittelt er zwischen Product Owner, Entwickler-Team und Unternehmen und übernimmt die Planung der benötigten Ressourcen für die jeweiligen Sprints, Stand-up-Meetings, Sprint-Reviews und Sprint-Retrospektive.

Die eigentlichen SCRUM-Teams bestehen aus den operativen Softwareentwicklern. Im Optimalfall setzen sie sich aus fünf bis sieben Mitgliedern mit unterschiedlichen Kompetenzfeldern zusammen, die sich ergänzen. Sie arbeiten möglichst an einem gemeinsamen Standort, um eine effiziente Kommunikation und Zusammenarbeit zu gewährleisten und zusammen auf den erfolgreichen Projekt-Abschluss hinzuarbeiten. Durch gegenseitiges Coaching wird das Risiko von Engpässen und dadurch entstehenden Auslieferungsverzögerungen verringert.

Wo liegen die Vorteile bei SCRUM?

grüne Trennlinie

Der größte Vorteil der Methode liegt in der gebotenen Flexibilität, denn nur selten sind die Anforderungen an ein Produkt in Stein gemeißelt. Änderungswünsche werden in SCRUM also nicht als Störung aufgefasst, sondern sind in die Methode integriert. Durch dieses iterative Vorgehen lassen sich die Anforderungen kontinuierlich so anpassen, dass ein möglichst gutes Produkt entsteht.

Durch den Fokus auf kurze Sprints werden häufig Meilensteine erreicht, was den stetigen Projektfortschritt greifbarer macht und somit auch die Motivation im Team steigert. Diese wird auch gefördert durch die Selbstorganisation und Eigenverantwortung der einzelnen Team-Mitglieder.

Da die Stakeholder im kompletten Entwicklungsprozess mit eingebunden werden und Feedback geben, erhöht sich die Qualität des Produkts sowie die Zufriedenheit der Kunden.

Best Practice: SCRUM bei digatus

grüne Trennlinie

digatus entwickelt Software nach der agilen Methode SCRUM. Dabei werden unterschiedliche Rollen innerhalb des Teams definiert, welche über den kompletten Projektverlauf definierte Aufgaben übernehmen. Kernelemente der Methode sind die zeitlich in sich abgeschlossenen Sprints, die bei digatus in der Regel 1-2 Wochen dauern.

Zum Schätzen der Aufwände verwendet digatus bevorzugt die Methode des Planning Poker. Dabei erhält jeder Entwickler ein Set Karten, die dem Fibonacci-System ähneln (1, 2, 3, 5, 8, …). Jeder Mitarbeiter schätzt für sich den Aufwand der einzelnen User-Stories und vergibt dementsprechend die Karten. Anschließend werden die Ergebnisse verglichen. Kommt es zu stärkeren Abweichungen, wird im Team über die Schätzung diskutiert bis man zu einem gemeinsamen Ergebnis kommt.

Dieses Sprint-Backlog bildet die Grundlage der Entwicklung und der in diesem Zeitraum zu realisierenden Anforderungen. In den zyklischen Sprintmeetings wird dabei die Planung der nächsten anstehenden Phase realisiert, sowie der Rückblick und die Abnahme der vorangegangenen. Auf diese Weise sind alle Stakeholder fortwährend über den aktuellen Stand der Entwicklung informiert und stellen gemeinsam mit dem Team die Einhaltung von Ziel, Zeitplan und Budget sicher.

Autor Profilbild

Robert Junklewitz

grüne Trennlinie