Das Java-Programmierpraktikum zum Modul “Programmieren-2” ist auf der Basis von eduSCRUM organisiert. Jedenfalls teilweise. Klar, dass da ein Sprint-Review-Meeting nach den Sprints fällig wird.
Was bedeutet das? Nun, zum einen, dass sich die Studierenden die Inhalte selbstorganisert aneignen, gewissermaßen im Off. Und dann in der Anwesenheitszeit (aka “Vorlesung”) die Chance zur Kommunikation mit Kommiliton/innen nutzen, um sich über die gelernten Java- und Programmierinhalte auszutauschen.
Leitplanken
Erwähnenswert erscheint mir noch die Tatsache, dass für das erste und zweite Semester “Leitplanken” vorhanden sind, die ein Abtrifften verhindern,
allzuweit weg zu kommen, von der Straße in die richtige Richtung: die relevanten Inhalte sind definiert in einem Skript mit Doppelfunktion. Einerseits sind hier alle relevanten Themengebiete definiert und andererseits erfolgt hier auch ein Stück weit die Behandlung der Themen. Das Skript ist gedacht als Einführung in das Thema und Ausgangspunkt für weitere eigene Recherchen.
Die praktischen Übungen
Um die Theorie in die Praxis umzusetzen, wird in den Assignments die Aufgabenstellung beschrieben. Diese Assignments kann man sich wie einen “Kundenauftrag” für die Entwicklung einer Anwendungssoftware vorstellen und die Assignment sind in der Tat auch die Entwicklungsaufträge an die studentischen “Entwicklungsteam”.
SCRUM-Teams und SCRUM-Master
Weil wir und mit dem Software-Entwickungsprozess an der Methode SCRUM orientieren, haben die Entwicklungsteams also die Rolle der SCRUM-Teams inne, als Dozent nehme ich die Doppel-Rolle von SCRUM-Masters und Product-Owner ein.
Wenn das gelernte in Rahmen der Projekt ADRELI_1 bis ADRELI_5 in jeweils einem SCRUM-Sprint realisiert wurde, geht es darum die SCRUM-Sprints zu reviewen. Der Product-Owner gibt den Teams ein Feedback, wie das Entwickelte angekommen ist.
Schwerpunkt beim ersten Sprint-Review-Meeting
Beim ersten Sprint wird eine Erweiterung des Erst-Semester-Projekts implementiert, was in den meisten Fällen recht ordentlich geschieht. Dagegen verhält es sich mit der Qualität der verlangten Dokumention in aller Regel nicht so. Deshalb wird beim erstenSprint-Review-Meeting insbesondere die kompakte Doku untersucht. Getreu dem “agile Manifesto” wird natürlich akzeptiert, dass die laufende Software im Vordergrund steht! Aber die Doku muss trotz allem einem Mindestqualitätsstandard entsprechen – und das ist in manchen Fällen nicht der Fall.
Unsere Doku-Regeln
Die Formalia müssen perfekt sein – Deckblatt, Verzeichnisse, Arrangement von Texten, Bildern, Überschriften und Bildunterschriften und auch Seitennummern, running header und footer gehören dazu, bis hin zu den Codier-Regeln und dem farbigen, doppelseitigen Ausdruck gibt es doch einiges zu beachten und viele Fettnäpfchen, wenn man allzu sorglos (oder gar schlampig) vorgeht.
Wie kann man sich das SCRUM-Review-Meeting vorstellen
Beim SCRUM-Review-Meeting besprechen der Product-Owner und die SCRUM-Teams die abgelieferten Ergebnisse. Einen Überblick kannst du dir im “Making of” ansehen. (Dauer 3:01 Minuten).
Ein ausführlicheres SCRUM-Sprint-Review-Meeting kannst du dir im zweiten Video unten zu Gemüte führen(Dauer 6:05 Minuten):
Wie gesagt: wenn die Kurzdoku einmal optimiert ist, kann sie für alle vier weiteren Projekt genutzt werden. Damit haben die SCRUM-Teams einen Großteil der Projektnote von entsprechender Qualität “in der Tasche”. Den anderen Teil der Projektnote macht natürlich die Java-Software-Qualität aus! Klar, da bleibt noch genug übrig zu tun! Wenn aber die Doku “in trockenen Tüchern” ist, kann das schon ein beruhigendes Gefühl sein.
An dieser Stelle auch den Besten Dank an die beiden Thesis-Studentinnen Kyara und Sina: im Rahmen ihrer Thesisarbeiten befassen sich beide (in jeweils eigenen Arbeiten) mit Innovationen und Lehrkonzepten vor dem aktuellen und zukünftigen technologischen Stand an Universitäten.
Viel Spaß bei den Projekten!
Ein Gedanke zu „SCRUM Sprint-Review-Meeting (doc)“