Agile Prozesse in der Softwareentwicklung

Die Kunst, konstruktiv aneinander vorbei zu denken

Dieses Bild ist vielleicht bekannt. Frage: Wie bekommen wir den Elefanten in den Kühlschrank? Manche sagen: „Tür auf, Elefant rein, Tür zu“. Aber ist da wirklich so einfach, wenn wir nicht wissen, wie groß Elefant und Kühlschrank sind und was sich möglicherweise noch im Kühlschrank befindet? Die Voraussetzungen sind nicht klar. Ebenso verhält es sich mit den Anforderungen, die in diesem Fall ebenfalls nicht definiert sind. Wir wissen schließlich nicht, in welchem Zustand wir den Elefanten in den Kühlschrank befördern sollen – im Ganzen, in Stücken oder püriert? Es gibt also sowohl beim Anforderungsprofil als auch beim Vorgehen einige offene Fragen. Eine vermeintlich einfache Aufgabe erweist sich als komplex und jeder würde hier individuell vorgehen. Ob man damit das erreicht, was sich der Aufgabensteller vorstellt, ist allerdings fraglich.

Agiles Arbeiten im Team – Was ist Scrum und wie funktioniert es?

Aus dem Englischen übersetzt bedeutet der Begriff Scrum Gedränge. Die Vorstellung davon passt sehr gut, da der Sinn dieser agilen Softwareentwicklungsmethode darin besteht, dass sich die Teams täglich zusammensetzen (im übertragenen Sinne zusammen drängen) und kurz und strukturiert über die Fortschritte des Projekts sprechen. In Corona-Zeiten geschieht das natürlich alles über Videochats. Die Methode wurde 1990 in Japan entwickelt und stärkt die Rolle jedes einzelnen in einem Team. Das ist auch für die Projektleiter sehr wichtig, da sie nun nicht mehr diejenigen sind, die nur Anforderungen kommunizieren, sondern direkt in die Entwicklungsprozesse eingebunden werden. Wir nennen es übrigens SCRUMCON, als eigene Wortkreation aus Scrum und AMCON. Da jedes Unternehmen, das nach dieser Methode arbeitet, die Regeln selbstständig und auf das eigene Unternehmen zugeschnitten festlegt, darf die natürlich auch einen eigenen Namen haben 😉Grundsätzlich ist für uns die Arbeit mit SCRUMCON dann effektiv, wenn die Anforderungen an ein Projekt komplex sind und es sich in viele Einzelteile zerlegen lässt, die schrittweise abgearbeitet werden können. Dabei werden unterschiedliche Rollen verteilt. Der Product-Owner definiert die User-Stories im Sinne des Kunden. Bei uns übernimmt diese Aufgabe der Projektleiter, der die Anforderungen im Vorfeld mit den Kunden definiert und sie dann dem Team mitteilt. Je genauer der Product-Owner die User-Stories beschreibt, desto genauer kann der Entwickler programmieren. So erhält der Kunde am Ende auch das Produkt, das er angefragt hat.

Backlog Grooming, Planning und Velocities – Wir erklären das mal kurz

In dieser ersten Phase (auch Backlog Grooming genannt), kann das Entwicklerteam Fragen stellen, sodass am Ende alle auf dem gleichen Wissensstand sind. Im nächsten Schritt legt das Entwicklerteam gemeinsam mit dem Scrum-Master die Definition of Ready (DoR) fest. Das bedeutet, dass die Anforderungskriterien an das UFHO-System festgelegt, einzelne Entwicklungsschritte terminiert und eine Arbeitsvereinbarung zwischen Projekteiter, Produktverantwortlichem und Entwicklerteam getroffen werden. Der Scrum-Master kümmert sich um die Aufteilung der einzelnen Aufgaben im Team und hält den Kollegen den Rücken frei. In unserem Fall macht das der Produktverantwortliche. Dabei kümmert er sich auch um die richtige Planung (Planning), damit auch Urlaube, Zeit für Fehlerbehebungen (Bug-Fixing) und Geschwindigkeiten (Velocities) beachtet werden. Bei der hier angesprochenen Geschwindigkeit geht es darum, dass wir die historische Performance des Teams berücksichtigen. Schaffte das Team in den letzten 3 Sprints im Durchschnitt 70 Story Points, so geht dies als Kenngröße in das Planning ein. Zu erwarten, das Team würde im nächsten Sprint 150 Punkte schaffen, wäre unrealistisch. Beim Planning schätzt das Team jede einzelne User-Story mit Story Points. Ein Story Point drückt dabei keine feste Zeitangabe aus, sondern die Komplexität. Das ist insofern ein Vorteil, da erfahrene Entwickler mehr in kürzerer Zeit schaffen als Anfänger. Für die Einschätzung der Komplexität wird eine allgemeingültige Skala herangezogen, die sich an den Fibonacci-Zahlen orientiert.

Ohne die Entwicklerteams läuft hier gar nichts

Die größte und wichtigste Gruppe ist das Entwicklerteam selbst. Man spricht hier auch vom Developer-Team, kurz Dev-Team. Die Mitglieder des Dev-Teams kümmern sich eigenverantwortlich um die einzelnen Teilschritte in der Entwicklung des UFHO-Systems für unsere Kunden. Im Laufe des Prozesses werden neben der kurzen täglichen Abstimmung (wir nennen das Daily) in regelmäßigen Abständen auch größere Runden gemacht, um erste Teilabschnitte des gesamten Projekts intensiv zu besprechen, zu testen und eventuell Verbesserungsvorschläge zu bringen. Hier kommen wieder alle zusammen und jeder Einzelne darf und soll sich einbringen. Dabei spielen – wie immer bei uns – die Hierarchien keine Rolle. Bei Definition of Done (DoD) entscheidet das Team, wann eine bestimmte Anforderung fertig ist und ein Pull Request (so nennt man in der Versionsverwaltung die Vorgehensweise, die den Code aus einem Branch in die Quellcode-Basis einfließen lässt) wird erst erzeugt, wenn alles umgesetzt wurde, was bis zu diesem Schritt passiert sein soll. Die DoR und DoD werden einmalig für das Dev-Team festgelegt und stellen im Grunde genommen eine Arbeitsvereinbarung zwischen dem Dev-Team und dem Anforderer dar. Zum einen kann das Dev-Team dadurch sicherstellen, qualitativ hochwertige Anforderungsdefinitionen zu bekommen, die ihren Vorgaben entsprechen. Auf der anderen Seite dient die DoD dazu, dass dem Anforderer nur getestete und (möglichst) fertig entwickelte Anforderungen geliefert werden, die auch seinen Qualitätskriterien entsprechen.

Welche Chancen bietet SCRUMCON?

Wie bei jeder agilen Methodik, haben auch wir für uns das beste und praktikabelste Vorgehen erarbeitet. Mit SCRUMCON steigern wir die Produktivität, optimieren unsere Kommunikation sowohl intern als auch extern mit dem Kunden, steigern die Flexibilität und auch die Qualität des Produktes und sorgen für mehr Verständnis zwischen den unterschiedlichen Abteilungen, die an einem Projekt arbeiten. Am Ende eines Projekts ist die Retrospektive sehr wichtig, um Prozesse stetig optimieren zu können. Dabei setzen wir uns noch mal alle zusammen, wenn der Sprint abgeschlossen ist. Jeder kann dann sagen, was gut lief, was man hätte anders machen können und wo zukünftig Verbesserungspotenzial besteht. Unser Entwicklungsleiter Sebastian Schnieder, technischer Projektleiter Alex Stasewitsch und Ausbildungsleiter Rolf Norrenbrock haben die Methode für agiles Arbeiten bei uns eingeführt. „Scrum baut auf hochqualifizierte, interdisziplinär besetzte Entwicklungsteams, die zwar eine klare Zielvorgabe bekommen, für die Umsetzung jedoch allein zuständig sind. Das eigenverantwortliche Arbeiten erhöht die Zufriedenheit der einzelnen Teammitglieder und das ist sehr schön zu beobachten“, sagt Rolf Norrenbrock.