Einführung in Agilität in der Akademie
In der modernen Landschaft der Hochschulbildung, insbesondere innerhalb von Informatik- und Ingenieurprogrammen, ist der Übergang von traditionellen Wasserfallmethoden hin zu agilen Frameworks zu einem entscheidenden Lernziel geworden. Studierende betreten die Hochschule oft mit einem theoretischen Verständnis der Softwareentwicklung, verfügen jedoch über keine praktische Erfahrung mit iterativen Arbeitsabläufen. Diese Lücke kann zu Konflikten führen, wenn komplexe Abschlussprojekte oder Gruppenarbeiten verwaltet werden müssen. Scrum bietet einen strukturierten, aber flexiblen Rahmen, der diese Herausforderungen effektiv bewältigt.
Dieser Artikel beschreibt eine umfassende Fallstudie einer Hochschulgruppe, die erfolgreich eine mobile Anwendung unter Verwendung agiler Prinzipien entwickelt hat. Der Fokus liegt nicht auf dem verwendeten Technologie-Stack, sondern auf den Prozessen, Kommunikationsstrategien und Organisationsstrukturen, die es der Gruppe ermöglichten, kontinuierlich Wert zu liefern. Durch die Analyse der spezifischen Schritte, der dabei auftretenden Hindernisse und der ergriffenen Lösungsansätze können wir verstehen, wie Scrum von Unternehmensumgebungen auf studentengeführte Initiativen übertragen wird.
Der Projektzustand
Die Fallstudie befasst sich mit einer Gruppe von fünf Bachelor-Studierenden, die im letzten Jahr ihres Studiums im Fach Softwaretechnik eingeschrieben waren. Ihre Aufgabe bestand darin, eine funktionale mobile Anwendung zu entwerfen, zu entwickeln und bereitzustellen, die ein spezifisches Problem innerhalb der Hochschulgemeinschaft lösen sollte. Der Umfang war groß genug, um mehrere Monate Arbeit zu erfordern, war jedoch durch akademische Fristen begrenzt.
Das Projektziel bestand darin, ein Werkzeug zu schaffen, das Studierenden erlaubt, in Echtzeit verfügbare Lernräume zu finden. Die Gruppe bestand aus Personen mit unterschiedlichen Fähigkeiten, die sich von Studierenden mit vorheriger Programmiererfahrung bis hin zu Anfängern im Bereich erstreckten. Diese Mischung von Fähigkeiten ist in akademischen Umgebungen üblich und erhöht die Komplexität der Projektverwaltung.
Um erfolgreich zu sein, benötigte die Gruppe eine Methode, um:
- Widersprüchliche Prioritäten und Fristen zu managen.
- Sicherzustellen, dass alle Teammitglieder gleichmäßig beitrugen.
- Sich an sich ändernde Anforderungen anzupassen, während sich das Projekt entwickelte.
- Einen nachhaltigen Arbeitsrhythmus trotz Prüfungszeiten aufrechtzuerhalten.
Definition von Scrum-Rollen für eine Hochschulgruppe
Eine der ersten Herausforderungen war die Zuweisung von Rollen. In einer Unternehmensumgebung sind Rollen oft spezialisiert. In einer Studierendengruppe tragen die Mitglieder oft mehrere Aufgaben. Um jedoch den Scrum-Prinzipien zu folgen, einigte sich die Gruppe auf klar definierte Verantwortlichkeiten. Diese Klarheit half, Verwirrung darüber zu vermeiden, wer für was verantwortlich war.
Die folgende Tabelle zeigt, wie die Gruppe Scrum-Rollen ihren studentischen Entsprechungen zuordnete.
| Scrum-Rolle | Studentische Verantwortung | Schwerpunktgebiet |
|---|---|---|
| Product Owner | Teamleiter | Definition von Funktionen, Priorisierung des Backlogs, Abstimmung mit den Betreuern. |
| Scrum Master | Projektkoordinator | Beseitigung von Blockierungen, Durchführung von Besprechungen, Sicherstellung der Prozesskonformität. |
| Entwicklungsteam | Entwickler und Designer | Entwicklung der App, Schreiben von Code, Erstellen von UI-Mockups, Testen. |
Der Product Owner war für die Vision verantwortlich. Er sammelte Feedback von potenziellen Nutzern (anderen Studierenden) und übersetzte es in eine Liste gewünschter Funktionen. Der Scrum Master stellte sicher, dass die Gruppe die Zeit und den Raum hatte, um ohne unnötige Störungen zu arbeiten. Das Entwicklungsteam war selbstorganisiert, was bedeutet, dass es selbst entschied, wie die Ziele des Product Owners technisch umgesetzt werden sollten.
Die Planungsphase: Erstellung des Backlogs
Die Grundlage des Projekts war das Product Backlog. Dies ist eine priorisierte Liste von Arbeitsaufgaben, die die Gruppe abschließen möchte. Im Gegensatz zu einem statischen Anforderungsdokument war diese Liste dynamisch und entwickelte sich weiter, je mehr die Gruppe über den Problemraum erfuhr.
Das Team verbrachte die erste Woche damit, die anfängliche Backlog zu erstellen. Sie verwendeten eine Technik namens User Stories, um Funktionen zu beschreiben. Eine User Story folgt einem einfachen Format: Als [Art des Benutzers] möchte ich [ein Ziel] erreichen, damit [ein Grund].Dieses Format zwang die Studierenden, an den Nutzen für den Endbenutzer zu denken, anstatt sich nur auf technische Spezifikationen zu konzentrieren.
Beispiele für anfängliche Backlog-Elemente waren:
- Als Student möchte ich eine Karte der Gebäude sehen, damit ich mich leicht auf dem Campus zurechtfinden kann.
- Als Student möchte ich Räume nach Kapazität filtern, damit ich ruhige Lernplätze finden kann.
- Als Student möchte ich Benachrichtigungen erhalten, wenn ein Raum frei wird, damit ich einen Platz sichern kann.
- Als Administrator möchte ich den Raumstatus aktualisieren, damit die Daten aktuell bleiben.
Jedes Element wurde anschließend auf den Aufwand geschätzt. Das Team verwendete Story Points statt Stunden. Dieser Ansatz konzentriert sich auf die relative Komplexität der Aufgabe, anstatt genaue Zeitrahmen vorherzusagen, was bei akademischen Projekten oft ungenau ist, da persönliche Ereignisse die Arbeitspläne stören können.
Durchführung des Sprints 1: Die ersten zwei Wochen
Das Projekt wurde in zweiwöchige Zyklen namens Sprints aufgeteilt. Der erste Sprint war entscheidend, da er das Arbeitsrhythmus des Teams festlegte. Das Ziel bestand darin, einen potenziell lieferbaren Fortschritt zu erzeugen, auch wenn es nur eine grundlegende Version der App war.
Sprint-Planung
Der Sprint begann mit einer Planungssitzung. Der Product Owner stellte die wichtigsten Elemente aus dem Backlog vor. Das Entwicklungsteam wählte anschließend die Elemente aus, die es innerhalb des zweiwöchigen Zeitraums erledigen konnte. Diese Verpflichtung war für die Verantwortlichkeit entscheidend.
Während dieser Sitzung zerlegte das Team die hochleveligen Geschichten in kleinere Aufgaben. Zum Beispiel wurde die KarteGeschichte in folgende Aufgaben aufgeteilt:
- Integrieren einer Karten-API.
- Erstellen eines Datenbank-Schemas für Raumstandorte.
- Entwerfen der Karten-Oberfläche.
- Code schreiben, um Raumdaten abzurufen.
Diese Aufgaben wurden an die Teammitglieder aufgrund von Interesse und Fähigkeiten verteilt. Der Scrum Master führte die Diskussion durch, um sicherzustellen, dass alle die Akzeptanzkriterien verstanden.
Tägliche Stand-ups
Die Kommunikation wurde durch eine tägliche Sitzung zu einem festen Zeitpunkt organisiert. Diese Sitzung dauerte maximal fünfzehn Minuten. Jedes Mitglied beantwortete drei Fragen:
- Was habe ich gestern gemacht?
- Was werde ich heute tun?
- Gibt es Hindernisse, die meinen Fortschritt blockieren?
Diese Praxis hielt das Team auf Kurs. In der ersten Woche des Sprints 1 meldete ein Entwickler ein Blockierungsproblem: Er konnte nicht auf die Dokumentation der Karten-API zugreifen. Der Scrum Master trat sofort ein, um alternative Ressourcen zu finden und das Zugriffsproblem zu lösen, sodass die Arbeit ohne Verzögerung weitergehen konnte.
Umgang mit Hindernissen während der Entwicklung
Kein Projekt verläuft ohne Herausforderungen. In diesem Fallstudie begegnete das Team mehreren häufigen Problemen, die typisch für Studentengruppen sind.
Akademische Konflikte
Zwischenzeitlich im ersten Sprint hatten zwei Teammitglieder wichtige Prüfungen angesetzt. Dies drohte die Geschwindigkeit des Teams zu beeinträchtigen. Anstatt den Sprint abzusagen oder die Arbeit anhäufen zu lassen, passte das Team den Plan an. Die betroffenen Mitglieder reduzierten ihre Arbeitsbelastung für diesen Sprint und konzentrierten sich auf Dokumentation und Testen, während die anderen Mitglieder die Entwicklungsarbeit übernahmen. Dies zeigte die Flexibilität des Frameworks.
Scope Creep
Nach der ersten Sprint-Review-Sitzung erhielt der Product Owner Feedback, das eine Funktion zum direkten Buchen von Räumen vorschlug. Obwohl dies wertvoll war, gehörte es nicht zum aktuellen Sprint-Ziel. Die Hinzufügung hätte die Zeitplanung gefährdet. Der Product Owner setzte diese Anforderung in die Backlog für zukünftige Überlegungen. Diese Disziplin verhinderte, dass das Projekt unübersichtlich wurde.
Technische Schuld
Um das Ende der Frist einzuhalten, wählte das Team ursprünglich eine schnelle Lösung für die Datenspeicherung, die nicht skalierbar war. Während der Retrospektive erkannten sie diese Entscheidung an. Sie reservierten Zeit im nächsten Sprint, um den Code zu überarbeiten. Die offene Anerkennung technischer Schuld ist entscheidend für die langfristige Gesundheit des Projekts.
Sprint 2 Tiefgang: Verfeinerung und Stabilität
Der zweite Sprint konzentrierte sich auf Stabilität und Benutzererfahrung. Da die Kernfunktionen im ersten Sprint etabliert waren, konnte das Team sich auf die Verfeinerung der Benutzeroberfläche und die Sicherstellung der Zuverlässigkeit konzentrieren.
Sprint-Ziele
Das primäre Ziel für den zweiten Sprint war sicherzustellen, dass die Anwendung gleichzeitige Benutzer ohne Absturz verarbeiten konnte. Das sekundäre Ziel war die Verfeinerung des visuellen Designs.
Arbeitsteilung
Die Aufgaben für diesen Sprint waren komplexer. Das Team musste seine Arbeit enger koordinieren. Ein Mitglied arbeitete an der Backend-API, während ein anderes an der Frontend-Entwicklung arbeitete. Sie trafen sich häufig, um sicherzustellen, dass die Datensätze übereinstimmten. Diese Koordination ist oft schwieriger in studentischen Projekten als in Unternehmensumgebungen, da die Erfahrung mit der Integration geringer ist.
Testprotokolle
Das Team implementierte ein Peer-Review-Verfahren. Bevor irgendein Code gemergt wurde, musste ein weiteres Teammitglied ihn überprüfen. Diese Praxis erfasste Fehler früh und half den Junior-Mitgliedern, von den Senior-Mitgliedern zu lernen. Außerdem stellte sie sicher, dass die Codebasis auch dann konsistent blieb, wenn verschiedene Personen unterschiedliche Module schrieben.
Sprint-Review und Retrospektive
Am Ende jedes Sprints fanden zwei unterschiedliche Zeremonien statt: das Sprint-Review und die Sprint-Retrospektive. Diese werden oft verwechselt, dienen aber unterschiedlichen Zwecken.
Das Sprint-Review
Die Review war eine Demonstration der Arbeit für die Stakeholder (Dozenten und eingeladene Studierende). Das Team zeigte die funktionierende App. Feedback zur Benutzerfreundlichkeit wurde gesammelt. Der Product Owner aktualisierte die Backlog basierend auf diesem Feedback. Dieser Zyklus stellt sicher, dass das Produkt mit den Bedürfnissen der Nutzer übereinstimmt.
Die Sprint-Retrospektive
Die Retrospektive war eine interne Besprechung für das Team. Ziel war die Verbesserung des Prozesses, nicht des Produkts. Das Team diskutierte, was gut lief, was schiefging und was verbessert werden konnte. In der ersten Retrospektive stellte das Team fest, dass die Besprechungen zu lange dauerten. Daraufhin implementierten sie für den nächsten Sprint einen strikten Zeitmesser. In der zweiten Retrospektive stellten sie fest, dass die Kommunikation per E-Mail zu langsam war. Sie wechselten zu einem dedizierten Nachrichtenkanal für dringende Updates.
Diese kontinuierliche Verbesserungsschleife ist das Herzstück von Scrum. Sie ermöglicht es dem Team, seine Arbeitsmethoden zu entwickeln, während es Erfahrung sammelt.
Endgültige Ergebnisse und akademische Integration
Am Ende des Semesters hatte das Team eine funktionierende Anwendung geliefert, die von Hunderten Studierenden auf dem Campus genutzt wurde. Der Bewertungsprozess unterschied sich von traditionellen Projekten. Anstatt einer einzigen Endabgabe bewerteten die Dozenten das Team anhand seiner Prozessdokumentation, der Codequalität und der Effektivität ihrer Zusammenarbeit.
Die Anwendung von Scrum lieferte greifbare Beweise für den Fortschritt. Das Team konnte den Dozenten die Backlog-Liste, die Sprint-Protokolle und die Notizen aus den täglichen Stand-ups zeigen. Diese Transparenz erleichterte es, den Wert ihrer Arbeit während des gesamten Semesters zu demonstrieren, und nicht nur am Ende.
Die Endnote spiegelte die Anstrengung und den Prozess wider. Das Team erhielt hohe Noten für seine Fähigkeit, sich an Veränderungen anzupassen und ein nachhaltiges Tempo beizubehalten. Die Dozenten stellten fest, dass die Studierenden, die sich tief mit dem Scrum-Framework auseinandergesetzt hatten, eine höhere Softwarequalität erzeugten als diejenigen, die einen traditionellen Ansatz verfolgten.
Wichtige Erkenntnisse für zukünftige Projekte
Die Reflexion dieses Fallbeispiels liefert mehrere Erkenntnisse für Studierende und Dozenten, die agile Methoden übernehmen möchten.
- Rollen sind wichtig: Selbst in einem kleinen Team verhindert die Klärung, wer für was verantwortlich ist, Verwirrung. Ein zugewiesener Product Owner stellt sicher, dass das Team das Richtige baut.
- Iterativ ist besser: Es ist riskant, bis zum Ende zu warten, um die Arbeit zu zeigen. Die Fortschrittsdarstellung alle zwei Wochen ermöglicht eine frühe Korrektur.
- Kommunikation ist entscheidend:Tägliche Stand-ups halten alle informiert, ohne lange Besprechungen zu erfordern.
- Prozess vor Werkzeugen: Das Team verließ sich nicht auf teure Software, um das Projekt zu verwalten. Sie nutzten einfache, zugängliche Werkzeuge. Der Fokus lag auf den Regeln der Zusammenarbeit, nicht auf der Technologie.
- Fehler akzeptieren: Als Dinge schief liefen, nutzte das Team dies als Lerngelegenheit. Das Retrospektiv wandelte Probleme in umsetzbare Verbesserungen um.
Fazit zum agilen Lernen
Die Reise der Entwicklung einer App mit Scrum in akademischer Umgebung zeigt den Wert der iterativen Entwicklung auf. Sie lehrt Studierende, dass Software nicht nur Code ist, sondern eine Zusammenarbeit zwischen Menschen. Das Framework bietet die Struktur, die benötigt wird, um Komplexität zu managen, während gleichzeitig die Kreativität für Innovationen ermöglicht wird.
Für Lehrkräfte ermöglicht die Integration von Scrum in den Lehrplan die Vorbereitung der Studierenden auf die berufliche Welt. Für die Studierenden bietet es ein praktisches Framework, um ihr eigenes Lernen und die Ergebnisse ihrer Projekte zu managen. Die Fallstudie zeigt, dass mit klaren Rollen, konsequenten Zeremonien und Fokus auf Wert Studententeams Ergebnisse auf professionellem Niveau liefern können.
Der Erfolg dieses Projekts beruhte nicht auf einer bestimmten Technologie oder einer genialen Idee. Es lag an der Disziplin des Prozesses. Durch die Einhaltung des Scrum-Frameworks behielten das Team die Fokussierung, konnten ihre Arbeitslast managen und ein Produkt liefern, das die Bedürfnisse ihrer Gemeinschaft erfüllte. Dieser Ansatz ist für jedes Gruppenprojekt mit ähnlichen Herausforderungen nachahmbar.
