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 Dominic, Frontend-Entwickler bei AOE, mit in seinen Alltag:
Einmal die Woche habe ich das “Refinement” im Kalender stehen. Hier stellt der:die Product Owner:in neue Anforderungen in Form von User Stories vor. Meine Aufgabe ist es dabei, zu hinterfragen, ob das in der Story beschriebene Feature tatsächlich das ursprüngliche Problem behebt – und das möglichst sauber und wartbar. In der Diskussion mit meinem Team und allem voran dem:der Product Owner:in kläre ich die üblichen Fragen wie: Wurden Edge-Cases nicht beachtet? Gibt es technische Limitierungen, die für die Schätzung eine Rolle spielen könnten? Bestehen Abhängigkeiten zu anderen Teams oder Microservices, die wir beachten müssen? Darüber hinaus ist es meine Aufgabe als Frontend-Entwickler, auch das Design genau zu betrachten (vorausgesetzt, es gibt schon ein dediziertes Design zu dem Feature). Dabei achte ich auf gängige UX-Design-”Regeln” und diskutiere mit den anderen Frontendler:innen in meinem Team, worauf wir z. B. in Sachen Accessibility (Barrierefreiheit) besonders achten müssen. Sind all diese Fragen geklärt (und keine neuen entstanden), schätze ich mit meinem Team den Aufwand der Story in sogenannten “Story Points”.
Im Daily Scrum a.k.a. Daily Stand-up a.k.a. Daily Sit-down (Homeoffice for the win) bespreche ich mit meinem Team kurz und bündig meine aktuellen Aufgaben. Dabei handelt es sich nicht um ein Kontroll-Meeting für den Kunden, der sehen möchte, dass ich schnell meine Tickets abarbeite. Für mich ist es eine Gelegenheit, meinem Team mitzuteilen, woran ich gerade konkret arbeite, was dabei gut läuft, was schlecht läuft und von wem ich eventuell Hilfe brauche, um meine Aufgabe zu erledigen. Das Ganze dauert im Optimalfall nicht lange, hilft mir und meinen Team-Kolleg:innen aber enorm, da wir uns unkompliziert austauschen können. Gerade jetzt, wo das Team hauptsächlich remote arbeitet, ist das Daily für mich vielleicht das wichtigste Meeting.
Ich würde gerne schreiben: “Dank unserer tiefgründigen Problemanalyse im Refinement können wir schnell und unkompliziert den kommenden Sprint planen”. Tatsächlich ist es aber häufig so, dass ich zum Zeitpunkt des Plannings die Hälfte des Story-Inhaltes vergessen habe. Wie gut, dass der:die Product Owner:in alles im Refinement Besprochene sauber in der Story-Beschreibung dokumentiert hat. Im Optimalfall braucht es also nur nochmal einen groben Abriss über die Story und wir können darüber entscheiden, ob wir sie im kommenden Sprint umsetzen können oder nicht. Wichtig für diese Entscheidung ist, dass möglichst alle Fragen und Unklarheiten beseitigt sind. Je sicherer ich mir über den Scope (Inhalt) der Story bin, desto einfacher fällt es mir, diese in kleine Tasks (Unteraufgaben) zu schneiden. Am Ende des Plannings haben wir dann eine Liste an (mit Tasks versehenen) Stories, auf die wir uns als Team committen können, sprich von dem das Team sagt: Diese Liste können wir in den kommenden zwei Wochen abarbeiten.
Während des Sprints arbeite ich das Board von oben nach unten ab. Das heißt, die Stories mit der höchsten Priorität werden zuerst bearbeitet. Je nach Komplexität der Story bleibt es aber nicht nur beim reinen “Programmieren – Testen – fertig”. Je mehr Abhängigkeiten bestehen, beispielsweise zum eigenen Backend, zu anderen Microservices des eigenen Teams oder sogar zu anderen Teams, desto wichtiger ist es, zu kommunizieren. Meiner Meinung nach ist Pair-Programming übrigens fast immer eine gute Idee, unabhängig davon, wie komplex die Aufgabe ist. Vier Augen sehen besser als zwei, vor allem wenn die zwei Augen den ganzen Tag in denselben drei Dateien lesen. Neben dem Programmieren, Code Reviewen und Testen darf auch die eigene Weiterbildung nicht zu kurz kommen. Auch wenn ich denke, dass man an den Aufgaben selbst am besten lernt, schadet es nicht, freie Minuten und Stunden im Sprint zu nutzen und den eigenen fachlichen Horizont per Podcasts, Artikel oder Workshops zu erweitern. Denn wer weiß, welche Herausforderungen der nächste Sprint bringt?
In der Review stelle ich dem Kunden die Features vor, die im letzten Sprint von meinem Team und mir entwickelt wurden. Dafür führe ich den Kunden meist einmal durch die Anwendung und zeige auch “versteckte” Features, wie z.B. Navigation per Tastatur durch ein Formular, oder wie der Screenreader die Seite interpretiert. Falls nicht schon während des Sprints geschehen, holen wir uns hier wertvolles Feedback ein. Manchmal ergeben sich neue Ideen bei der Präsentation, die wir als Anforderungen mitnehmen können.
Am Ende des Sprints kommt das ganze Team in der “Retro” zusammen und reflektiert nochmal die letzten beiden Wochen. Wir schauen auf unsere Arbeit, auf unsere Zusammenarbeit, was gut und was schlecht lief – mit dem Ziel, als Team im nächsten Sprint noch effizienter und effektiver zusammenzuarbeiten. Hier habe ich aber nicht nur die Möglichkeit, nochmal frei Dinge anzusprechen, die vielleicht im Arbeitsalltag untergegangen sind, sondern auch, anderen Kudos auszurichten, wenn die Zusammenarbeit nicht nur sehr produktiv war, sondern auch echt Spaß gemacht hat. #goodvibes
