Ein Code Review im Rahmen eines SCRUM-Sprint-Review-Meetings ist insbesondere dann zeitintensiv, wenn Code-Review und Meeting gewissermassen der erste Test in der “Kundenumgebung” sind! Sie alle kennen das: auf dem eigenen Entwicklungsrechner läuft alles prächtig – wird die Lösung in die Testumgebung beim Kunden (bei uns in Java-Programmieren-2 ist das die PC-Hall im C1.04) zu Ablauf gebracht, funktioniert’s vielleicht eben doch nicht?!
Um es an dieser Stelle gleich vorneweg zusagen: das im vorletzten Absatz angesprochene Review Meeting Facts File finden Sie u.a. im “Felix”. Dieses Fact-Sheet ist weitestgehend selbsterklärend und ausgesprochen kurz. Im Wesentlichen enthält dasFact-Sheet einige technische Angaben zu “Java-File” + “Zeilennummer”, wo einige der im Assinment verlangten Aspekte zu finden und zu sehen sind. Anhand dieser Angaben im Review-Meeting-Fact-Sheet kann die Detailanalyse Ihres Quellcodes effektiver erfolgen. Soviel dazu.
Doch nun zurück zum Code-Review!
Die Lehre daraus – Adreli_3-Server auf PC-Hall PC
Bevor Code-Review und Meeting stattfinden, testen die SCRUM-Teams Ihre Lösung in PC-Hall im C1.04: auf einer Maschine der Kundenumgebung läuft der Adreli-Server. Ein Port ist für die Maschinen vom Rechenzentrum geöffnet. Damit steht nichts im Wege, auf einer Maschine der PC-Hall im C1.04 den Adreli-Server laufen zu lassen. Sie müssen die Adreli-Server-Quelle in Eclipse integrieren, übersetzen und zum Ablauf bringen.
Adreli_3-Client auf Development-Laptop
Die Adreli-Client-Quellen können nach wie vor auf dem perönlichen Laptop sein und dort aus Eclipse heraus gestartet werden. Durch die Angaben von IP- und Port-Nummer des Adreli-Servers, weiß dann der Adreli-Client mit welchen Server er zusammenarbeiten muss.
Das genau ist der Abnahme-Test! Der Adreli-Client arbeitet jetzt mit dem Adreli-Server zusammen – so der Plan.
Demofall 1: mit User-Story “Records aus einer Datei laden: > 4” wird das Random-Access-File “adreli.csv” in den Puffer geladen und dann werden als
Demofall 2: mit der User-Story “Records auflisten: > 2” auf der Konsole die archivierten Records zur Anzeige gebracht.
Der für das SCRUM-Sprint-Review-Meeting letzte Testfall ist dann
Demofall 3: die User-Story “eine neue Person aufnehmen: > 1″
Demofälle 4+5: kommen ins Spiel mit ADRELI_5_JDBC. Jetzt zeigen Sie noch den Import des Adreli.csv-Files in die Datenbank und den Export des Datenbankinhalst als Adreli.csv-File.
Natürlich wissen Sie, dass diese drei Demofälle für einen ernstzunehmenden Test zuwenig ist. Dies ist hier ausschließlich der knappen Abnahmezeit geschuldet. Sie testen natürlich umfassender, vor dem Sprint-Review-Meeting 🙂
Zeitrahmen: nicht mehr als 15 Minuten
Für diese drei Demofälle stehen uns insgesamt nicht mehr als 15 Minuten zur Verfügung. Anders ausgedrückt: 5 Minuten pro Teammitglied. Sprecher ist jeweils das Teammitglied, das sich zur betreffenden User-Story “commited” hat (entsprechend “Autorendatenblatt” in der Doku).
Die Review Meeting Facts
Das Review-Meeting-Facts-File kann das SCRUM-Team schon vorher ausfüllen und dann beim SCRUM-Sprint-Review-Meeting dem Product-Owner (Prof. Illik) aushändigen. Als PDF befindet sich das File im “Felix” oder gleich hier: Review-Meeting-Facts_ADRELI_3
Adreli_4_GUI und Adreli_5_JDBC
Dieses Basis-Modell für die Demo wird für die noch ausstehenden SCRUM-Sprint-Review-Meetings für Adreli_4_GUI und Adreli_5_JDBC modifiziert. Dort gibt’s ja noch anderes zu zeigen.
Das sollte in einer viertel Stunde zu schaffen sein! Ich freue mich darauf!
Das sollte in einer viertel Stunde zu schaffen sein! Ich freue mich darauf!
“Have fun storming the castle”
Ein Gedanke zu „SCRUM Sprint-Review-Meeting (code)“