Get in touch
Die Welt der Softwareentwicklung hat sich in den letzten Jahren stark gewandelt. Lange Zeit wurden Projekte in der Softwareentwicklung nach einem festgelegten Plan durchgeführt, bei dem jede Phase penibel geplant und dokumentiert wurde (“Wasserfallprinzip”). Doch seit längerem hat sich ein anderer Ansatz etabliert: die agile Softwareentwicklung.
Ihr wolltet schon immer mal wissen, wie der Arbeitsalltag in einem agilen Scrum Team aussieht? Wir nehmen euch exemplarisch mit in den Alltag der verschiedenen Scrum Rollen bei der AOE GmbH. Heute nimmt euch Theresa, Backend-Entwicklerin mit Security-Fokus, mit in ihren Alltag:
Morgen findet wieder unser reguläres Backlog Refinement statt. Zwar werden wir Fragen und Unklarheiten im Termin selbst besprechen, trotzdem lohnt es sich oft, diese schon vorher mit dem:r Product Owner:in zu besprechen. Ich suche mir also schon jetzt die am höchsten priorisierten User Stories in unserem Backlog raus und frage mich, ob ich alles weiß, was ich zu deren Umsetzung brauche. Mit besonderer Aufmerksamkeit schaue ich auf Anforderungen, die Einfluss auf alte oder elementare Abschnitte des Produkts haben, wo ich vorbereitend nochmal mein Wissen auffrischen oder Informationen von Kolleg:innen einholen kann.
Hin und wieder erstelle ich auch User Stories, die (sicherheits-)technische Relevanz für die Software haben, die ich vor dem Backlog Refinement mit dem:r Product Owner:in bespreche. Dabei ist es nicht nur wichtig, gut zu erklären, was der Nutzen für die Kund:innen ist, sondern auch deutlich zu machen, welche Auswirkungen es hat (oder möglicherweise haben kann), wenn die User Story nicht umgesetzt wird.
Wenn es nun ins Backlog Refinement geht, bin ich schon vorbereitet: Ich weiß, über welche User Stories wir reden werden, und kann mich ganz darauf konzentrieren, dem:r Product Owner:in zuzuhören und fachliche Fragen zu stellen, um zu verstehen, welche Bedürfnisse sich in den Anforderungen verbergen. Für mich ist es sehr spannend zu verstehen, warum die in der User Story beschriebenen Anforderungen benötigt werden, denn das gibt mir die Möglichkeit, alternative Lösungsmöglichkeiten zu erkennen, die den Kunden begeistern können.
User Stories sind im Allgemeinen aus positiver Nutzersicht formuliert, z. B. „Als E-Shop-Nutzer:in möchte ich Produkte in einen Warenkorb legen können, um …“. Interessant wird es, wenn man aber auch andere Fälle in Gedanken durchspielt: Wie gehen wir mit Fehlern um? Oder wenn der E-Shop ganz anders verwendet wird als in der User Story erdacht? Vielleicht möchten Nutzer:innen gar nichts im E-Shop kaufen, sondern Daten anderer Nutzer:innen stehlen oder den E-Shop kaputt machen? Manchmal schreiben wir absichtlich solche „Evil User Stories“ (also „Böse User Stories“), die das Handeln von Angreifer:innen beleuchten, um mögliche Schwachstellen sichtbarer zu machen.
Das Sprint Planning selbst geht sehr schnell. Wir hatten alle User Stories schon im Backlog Refinement besprochen und der:die Product Owner:in hat schon alle priorisiert, so dass wir jetzt nur noch entscheiden brauchen, wie viele User Stories in unseren 14-tägigen Sprint passen.
Danach machen wir oft noch ein Task Planning (Task Breakdown), in dem wir jede User Story nochmal in Aufgaben aufteilen. Jede dieser Aufgaben sollte nicht länger als einen Tag benötigen.
Während wir uns alle im Team auch darüber abstimmen, welche Aufgaben erledigt wurden und welche wir bis zum nächsten Daily Scrum noch erledigen werden, liegt der Fokus eher darauf, ob uns etwas von der Erledigung unserer Aufgaben abhält. Egal, ob es Wissenslücken sind, Feedback von Ansprechpartner:innen fehlt oder der Rechner kaputt ist, wir fragen aktiv nach Unterstützung und bieten diese im Gegenzug natürlich auch an.
Das Daily Scrum ist für mich – wie für meine Team-Kolleg:innen – auch die perfekte Gelegenheit, um auf unvorhergesehene Ereignisse zu reagieren: Sicherheitsupdates einspielen, Fragen oder Anforderungen aus anderen Teams, Update der Software auf den Live-Systemen sind nur einige Beispiele für ungeplant eingehende Wartungsaufgaben. Diese können nun gemeinsam eingeschätzt und eingeplant werden.
Der Sprint geht los und ich suche mir selbstständig eine Aufgabe aus einer der hochpriorisierten User Stories des Sprints raus und beginne mit der Arbeit. Dabei können meine Aufgaben sehr vielseitig sein: Programmieren, Abstimmen und Beraten mit Kolleg:innen, über den Programmcode der Kolleg:innen schauen, Testen, Tests automatisieren, Dokumentieren, Wartung bestehender Software. Nicht zuletzt bedeutet Scrum auch eine Menge Kommunikation, denn es gilt – wie im Agilen Manifest beschrieben – „Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen“. Ändern sich plötzlich Anforderungen, ist es das Beste, miteinander zu sprechen, wie wir das gemeinsam möglich machen können.
Das selbstständige und doch sehr kommunikative Arbeiten bewirkt, dass ich meinen Arbeitsrhythmus selbst bestimmen kann und die Möglichkeit habe, das Produkt aktiv mitzugestalten und unsere Kund:innen zu beraten, was wirklich wertgeschätzt wird. So macht mir der Scrum-Alltag richtig Spaß.
Vor dem Review nutze ich schon mal die Gelegenheit, alles durchzuspielen, was ich zeigen möchte, und ich freue mich auch, meine Kolleg:innen darin zu unterstützen, wenn sie ihren Review-Anteil schon vorab zeigen möchten. Das gibt allen die Gelegenheit, selbstsicherer im Auftreten und Präsentieren zu werden.
Während die Features vorgestellt werden, achte ich besonders auf das Feedback aller Anwesenden: Haben wir die Probleme verstanden, die die User Stories lösen sollen, und haben wir eine passende Umsetzung gefunden? Haben wir Aspekte übersehen oder entdecken neue Anforderungen?
Die neuen Erkenntnisse lasse ich dann in neue User Stories einfließen oder notiere sie mir zur Nachbesprechung mit dem:der Product Owner:in.
Zwar werden sicherheitsrelevante Punkte oft nicht als fachliche Anforderungen verstanden und daher nicht für Reviews in Betracht gezogen, aber hin und wieder zeige ich, welche Sicherheitsmaßnahmen wir in dem Produkt eingebaut haben, um das Bewusstsein für Sicherheit bei Kolleg:innen und auch anderen Stakeholdern zu schärfen.
Es ist an der Zeit, mal den Rechner beiseite zu stellen und sich auf das Team und unsere Zusammenarbeit zu konzentrieren. Ich überlege, wie gut unsere Prozesse und Absprachen funktioniert haben. Ich spreche Dinge an, die gut gelaufen sind, aber auch welche wir verbessern sollten.
Die Offenheit im Team sorgt dafür, dass wir unsere Stärken und Schwächen im Laufe der Zeit kennenlernen und uns gegenseitig dabei unterstützen können, unsere Stärken weiter auszubauen und unsere Schwächen abzubauen oder gegenseitig abzufangen.
Dabei hilft uns der:die Scrum Master:in, Maßnahmen zu definieren und diese fest einzuplanen. Mit jedem Sprint fällt es mir schwerer, genau zu erkennen, welcher Beitrag in dem Projekt wirklich von mir war, und gleichzeitig viel leichter zu erkennen und mich darüber zu freuen, was wir als Team gemeinsam schaffen.
