Agile / Software-Entwicklung / Software-Test / Testmanagement

Neuling im agilen Umfeld

„Ich studiere das gerade, ich kenn‘ mich also in diesem Bereich aus“. Diesen Satz haben wohl schon viele junge Studenten so oder so ähnlich von sich gegeben. Im Nachhinein betrachtet kann auch ich einige Situationen aufzählen, in denen ich mit geschwellter Brust und hochmütigem Grinsen von meinen theoretischen Erfahrungen im Projektmanagement berichtete, ohne auch nur jemals einen Fuß in ein projektorientiertes Unternehmen gesetzt zu haben.

ScrumPokerCards_ANECON

Kurz zu meiner Person: Ich studiere Projektmanagement und Informationstechnik im 6. Semester an einer Fachhochschule und habe zwar schon einige Berufsjahre hinter mir, allerdings noch nicht im Projektmanagement- oder Entwicklungsumfeld. Seit dem 01.02.2016 bin ich bei ANECON als Praktikant im Software-Test angestellt und bereits in einigen internen Projekten tätig. Als ich eines Tages die Nachricht bekam, in ein Scrum-Projekt hineinschnuppern zu können, war meine Begeisterung enorm. Immerhin waren agile Vorgehensweisen ein wichtiger Bestandteil meines Studiums und der Scrum-Prozess wurde uns in der Fachhochschule so lange eingebläut, bis ich die einzelnen Scrum-Artefakte im Schlaf aufsagen konnte. Als dann noch eine Kollegin, die bereits eine Woche vor mir die Möglichkeit hatte, einen Schnuppertag in diesem Projekt zu absolvieren, davon berichtete, dass sie bei einem „Backlog Grooming Meeting“ dabei sein konnte, wurde meine Vorfreude noch weiter gesteigert.

 

Mein erstes Backlog Grooming Meeting

Am 24.02.2016 war es dann so weit: um Punkt 9 Uhr stand ich bei unserem Kunden, einem mittelgroßen Versicherungsunternehmen, auf der Matte. Zunächst erzählte mir meine Betreuerin, die Testmanagerin des Projekts, einige grundsätzliche Dinge über das Projekt; das Ziel ist die Neuimplementierung des Bestandssystems, das derzeit noch auf Basis eines AS400-Systems läuft und auf eine Windows-Umgebung umgestellt werden soll.

15 Minuten später ging es bereits los: das Daily Scrum Meeting stand auf dem Plan. Während des Meetings bekam jedes Teammitglied die Gelegenheit, die Erfolge vom Vortag aufzuarbeiten. Weiteres wurde besprochen, welche Arbeiten an diesem Tag auf dem Programm standen und wo Schwierigkeiten auftreten könnten. All diese Dinge wurden vom Scrum Master zwecks Statusupdate und Problembeseitigung aufgenommen. Das Meeting fand direkt vor dem Story-Board statt, damit sich die Teammitglieder beim Sprechen auf die jeweiligen Tasks beziehen konnten, an denen sie gerade arbeiteten. Man erkannte relativ schnell, dass es sich um ein eingespieltes Team handelte, welches nach Tuckmanns Phasenmodell für die Teamentwicklung mitten in der Performance-Phase steckte. Es dauerte keine 10 Minuten, bis alle wieder auf ihren Plätzen waren. Diese Praxis deckt sich mit der Theorie, die wir in der Fachhochschule durchgemacht haben: keine zeitfressenden Meetings mit langwierigen Diskussionen, sondern lediglich die Beantwortung der drei wesentlichen Fragen: Was habe ich gemacht? Was plane ich zu tun? Und was brauche ich dazu bzw. könnte mich davon abhalten?

Nachdem alle wieder auf ihrem Platz waren, nutzte ich die Chance, um einigen Kollegen bei der Arbeit über die Schulter zu schauen und war sehr erstaunt über die Unterschiede zwischen professionell geschriebenen Softwarecode und jenem, den ich im Rahmen meines Studiums fabriziert habe. Das Staunen setzte sich fort, als ich bei der Testautomatisierung angekommen bin – die Tester gaben mir einige Einblicke in die Automatisierung von Regressionstests und ließen einen automatisierten Test vor mir ablaufen.

Und schon war es 11 Uhr und das Grooming konnte beginnen. Bei dem Meeting waren Entwickler, Tester, ein Datenbankspezialist, der Scrum Master, der Project Owner sowie ein Vertreter aus der Fachabteilung anwesend. Insgesamt wurden drei User Storys durchgenommen. Die einzelnen Storys wurden mit sehr viel Sorgfalt erklärt und der Product Owner bemühte sich, dass alle Anwesenden die teils sehr komplexen Anforderungen verstanden. Um den Aufwand der einzelnen Storys zu schätzen, wurde das sogenannte Planning Poker „gespielt“ – sämtliche Entwickler sowie Tester schätzten autonom den Aufwand der einzelnen User Storys und die Ergebnisse der Schätzungen wurden gleichzeitig präsentiert. Anschließend ergaben sich Diskussionen aufgrund von zum Teil abweichenden Schätzungen, wobei man sich am Ende immer auf eine Zahl geeinigt hatte. Obwohl es im Endeffekt nur drei User Storys waren, dauerte das Meeting aufgrund der Komplexität der Software und der Storys über eine Stunde.

Abschließend möchte ich mich herzlich bei der Testmanagerin für die sehr gute Betreuung sowie den Kollegen für die kompetente Beantwortung meiner Fragen bedanken. Ich habe hervorragende Eindrücke aus dem Projekt mitnehmen können und kann zukünftig nicht nur theoretisch, sondern auch praktisch über Projektmanagement philosophieren. Außerdem möchte ich mich bei ANECON bedanken, die mir durch das Praktikum diese wertvolle Erfahrung möglich gemacht hat.

 

Passende Artikel

Antwort schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*