Kitabı oku: «Agile Schule (E-Book)», sayfa 4

Pair-Programming und Einzelarbeit zu Hause

Die konkrete Umsetzung mit Scratch erfolgte im Pair-Programming, wobei der Navigator aufgrund der wenigen Konzepte und Datenstrukturen, die bekannt waren, weniger auf alternative Umsetzungsmöglichkeiten der konkreten Story, sondern mehr auf das Zusammenspiel der unterschiedlichen arbeitsteilig umgesetzten Spielereignisse achten musste. Wichtig war auch, dass der Driver stets seine Ideen bei der Umsetzung ausdrückte und die Schülerinnen und Schüler so lernten, ihr Vorgehen beim Programmieren mit Worten zu beschreiben und kritisch zu hinterfragen. Wenn sie wollten, konnten die Schülerinnen und Schüler sich ihr Projekt auf einen USB-Stick kopieren und daran zu Hause weiterarbeiten. Die dabei umgesetzten Funktionalitäten mussten in der folgenden Doppelstunde dem Team im Stand-up-Meeting vorgestellt werden, ehe das Team entschied, ob sie in das Projekt integriert werden durften.

Teamarbeit und Transparenz

Fast alle Schülerinnen und Schüler haben sich für ihr Projekt mitverantwortlich gefühlt. Einzelne, die sich herausnehmen, gibt es wahrscheinlich immer, aber hier ist ein solches Verhalten deutlich aufgefallen und es war für diejenigen unangenehmer als gewöhnlich.

Reflexion

Zum Abschluss des Projekts wurden die letzten Prototypen der drei Teams, die, wie von mir zum Projektstart angekündigt, keine komplette Umsetzung des jeweiligen Spiels waren, im Plenum vorgestellt, zusammen mit einer zu Hause vorbereiteten individuellen ↑ Reflexion des Projekts. Dabei berichteten alle Schülerinnen und Schüler, viel über Softwareentwicklung und Kooperation im Team gelernt zu haben. Letzteres wurde übereinstimmend wie folgt zusammengefasst: Absprachen treffen ist wichtig, aber mühsam und teilweise schwierig. Aber ohne Absprachen kann eine produktive Zusammenarbeit nicht funktionieren. Neben dieser Erfahrung war die Präsentation der Arbeitsergebnisse aber vor allem von Stolz auf das Erreichte geprägt.

Bewertung der kooperativen Projektarbeit

Eine Herausforderung stellt die ↑ Bewertung von Leistungen dar, die von der Gruppe bzw. individuell in einem Projekt erbracht werden, da zwei unterschiedliche Interessen kollidieren: Zum einen will ich die Schülerinnen und Schüler befähigen, etwas zu tun, und gleichzeitig messe ich, was sie tun. Ein weiterer Punkt ist die Frage, welchen Wert eine individuelle Idee hat und welcher Wert der Fähigkeit der Gruppe, sie erfolgreich umzusetzen, zukommt. Nachdem die Schülerinnen und Schüler ihre Projekte bereits weitgehend selbstorganisiert durchgeführt hatten, war es mir wichtig, sie auch in den Prozess der Bewertung einzubeziehen. Gemäß dem Prinzip einer Poolnote bekam jede Gruppe von mir entsprechend ihrer Gesamtleistung eine Anzahl von Punkten. Die Aufgabe der Gruppe bestand nun darin, sich auf eine Verteilung der Punkte auf die Gruppenmitglieder zu einigen und sich so mit der Frage auseinandersetzen, welche Fähigkeiten und Fertigkeiten jedes einzelnen Mitgliedes die Gruppe im Projekt besonders gut vorangebracht haben und welche eher hemmend waren. Die so erzielte Note umfasste sowohl die Leistung bezüglich des Produkts als auch den Beitrag zur Zusammenarbeit.

Zwei Gruppen haben sich sehr schnell geeinigt, die Punkte gleich aufzuteilen. An dieser Stelle war es mir nicht wichtig, einzugreifen oder mir die Überlegungen darlegen zu lassen, da sich meiner Beobachtung nach alle für ein gutes Arbeitsergebnis engagiert hatten. Interessant war eine Gruppe, in der es Spannungen gegeben hatte: Eine leistungsstärkere Schülerin meinte, dass ihr Beitrag mehr Anerkennung finden müsste, die anderen Gruppenmitglieder betonten dagegen, dass erst die Tatsache, dass sie der Gruppe eine Überarbeitung zugesagt, das aber nicht eingehalten hat, ein besseres Gruppenergebnis verhindert hat. Nach langer Diskussion mit wenig Verständnis für die jeweils andere Position haben sie sich als Kompromiss auf die gleiche Punktzahl für alle Gruppenmitglieder geeinigt. Die Schülerinnen und Schüler haben damit eine sehr ambivalente Situation bewältigt, die ihnen auch im späteren Leben begegnen wird.

Beobachtungen und Erfahrungen

Durch die agile Herangehensweise gelang es meinen Schülerinnen und Schülern tatsächlich, bereits früh im Lernprozess gemeinsam, mit Begeisterung und Spaß etwas Tolles zu schaffen. Da sich im Projekt der Ablauf einer Iteration wiederholte und eine klare Struktur hatte, musste ich nicht wie früher in wasserfallähnlichen Projekten moderieren und den nächsten Schritt vorgeben. Die Schülerinnen und Schüler arbeiteten eigenständiger und zunehmend selbstbewusster. Die positive Bestärkung der Selbstwirksamkeit durch die iterative Vorgehensweise und die früh und regelmäßig in den Prototypen sichtbaren Arbeitsergebnisse sehe ich sehr positiv. Die regelmäßigen und häufigen Anlässe zur Kommunikation in der agilen Arbeitsform boten den Schülerinnen und Schülern, die zum größten Teil nicht deutscher Herkunftssprache waren, zudem Gelegenheit zur Verbesserung ihrer Sprachkompetenz im Sinne einer Sprachbildung im Fachunterricht.

Was mir gefehlt hat, war, dass die Schülerinnen und Schüler während des Projekts in fachlicher Hinsicht nicht nur bekannte Fähigkeiten ausbauen und vertiefen, sondern sich im Rahmen des Projekts auch neue Konzepte erarbeiten. Im nächsten Projekt werde ich daher Anregungen bereitstellen, die die Erarbeitung neuer Fachkonzepte initiieren.

Für mich sehr entlastend war, dass von Anfang an klar kommuniziert war: Wir werden nur ein Stück des Spiels implementieren, es wird funktionieren, aber nicht ausgereift sein. Es bestanden weder Anspruch noch Notwendigkeit, in der gegebenen Zeit alle Funktionalitäten umzusetzen, um ein sinnvolles Produkt zu haben. Auch wenn so nur kleine Funktionen entstanden sind: Die Schülerinnen und Schüler haben erfahren, dass und wie sie gemeinsam selbst Informatiksysteme erschaffen und nach ihren eigenen Wünschen und Interessen gestalten können, und waren nun hoch motiviert, weitere Themengebiete der Informatik zu erarbeiten. Insofern ist die Entscheidung, derartige Projekte früh im Schuljahr durchzuführen, sehr gut, weil es bei den Lernenden eine positive Einstellung zum Fach erzeugt. Die agilen Methoden, mit denen ich dieses Ziel tatsächlich erreichen konnte, sind für mich deshalb eine wirkliche Bereicherung.

3.3 In der Oberstufe komplexe Anwendungssoftware agil entwickeln

Ein Unterrichtsprojekt von Peter Brichzin

Steckbrief

Klassenstufe: 11 (Gymnasium, Wahlpflichtunterricht)

Klassenstärke: 20-25 Schülerinnen und Schüler

Thema: Entwicklung einer Anwendungssoftware mit grafischer Benutzeroberfläche, persistenter Datenspeicherung und dynamischer Datenstruktur

Besonderheiten: hohe Komplexität, stark leistungsinhomogene Schülergruppen, thematische Freiheit, methodische Varianten: Student-Story, Modelling-Story, digitales Project-Board

Agile Praktiken: Iterationen, Project-Board, User-Storys, Tasks, Prototypen, Stand-up-Meeting, Pair-Programming, Repository, Testen, Timeboxing, Reflexion, Refactoring

Programmiersprache/Entwicklungsumgebung: Java/BlueJ, Java Editor, IntelliJ oder Eclipse

Dauer und Frequenz: acht Wochen mit drei Stunden pro Woche

Zeitlicher Ablauf:

Software (nach dem Wasserfallmodell) vollständig zu planen, dann einzelne Komponenten umzusetzen, diese zusammenzuführen und zu testen, ist eine sehr anspruchsvolle Aufgabe, die viel Erfahrung voraussetzt. Schülerinnen und Schüler machen diese Erfahrung nur sehr selten: Selbst den Leistungsstärksten bereitet der Entwurf erhebliche Schwierigkeiten und die anderen können sich nur wenig einbringen. Deshalb verpufft leicht die Begeisterung für die Entwicklung einer eigenen Software, wenn am Anfang erst zwei bis drei Wochen geplant wird. Daneben gibt es noch eine weitere kritische Stelle: das Zusammensetzen typischer Komponenten wie Logik, grafischer Benutzeroberfläche und Datenhaltung. Egal wie oft man als Lehrkraft die Wichtigkeit guter Schnittstellenabsprachen und eines rechtzeitigen Zusammensetzens betont, tendieren die Schülerinnen und Schüler dazu, das Zusammensetzen zu verschieben, weil sie mit ihren Komponenten noch nicht zufrieden sind. So musste ich mehrfach miterleben, wie durch das späte Erkennen von unzureichenden Schnittstellenbeschreibungen aufwendige Korrekturen notwendig wurden und die verbleibende Zeit (bis zum Schuljahresschluss) nicht reichte, um darauf zu reagieren. Das resultierende unfertige Ergebnis, eine nur in Teilen laufende Software, ist nicht nur für die Schülerinnen und Schüler unbefriedigend, sondern natürlich frage ich mich als Lehrer auch, wie ich den Rahmen verbessern kann. Eine stärkere Steuerung und Führung von meiner Seite aus ist keine Option, denn wesentliche Ziele einer Projektarbeit sind sich selbst zu organisieren, eigene Entscheidungen zu treffen und Verantwortung zu übernehmen. Das oben geschilderte Scheitern beinhaltet eine oft (schmerzhafte) Erfahrung, die im Lernprozess aber sehr hilfreich sein kann. Damit jedoch am Ende ein Erfolg und damit Begeisterung für das Erstellen einer Software im Team steht, sollten (unvermeidbare) Irrwege und ihre Reflexion möglichst früh im Projektverlauf stattfinden. Genau dies ist einer der Vorteile eines iterativen Vorgehens agiler Projekte mit einem schrittweisen Planen, einer frühen Integration und dem Lernen aus Fehlern. Weitere Vorteile sind eine höhere Transparenz des Projektstands und Erfolgserlebnisse durch funktionsfähige Prototypen.

Projektvorbereitung
Rahmenbedingungen

Mittlerweile zum dritten Mal habe ich ein Softwareprojekt in der Oberstufe agil angeleitet. Die Schülerinnen und Schüler bringen als Vorwissen einerseits aus Jahrgangsstufe 10 Grundlagen zur objektorientierten Modellierung und Programmierung mit, andererseits aus Jahrgangsstufe 11 praktische und theoretische Kenntnisse zu den Datenstrukturen Liste, Baum und Graph. Der mit 26 Stunden ausgewiesene abschließende Lehrplanpunkt «Softwaretechnik» ermöglicht eine ca. achtwöchige reine Projektphase bei drei Stunden Unterricht pro Woche. Die Leistungsstärken der Schülerinnen und Schüler waren immer sehr heterogen. Einige brachten bereits Erfahrungen, z.B. in der Programmierung grafischer Benutzeroberflächen und der Verwendung professioneller Entwicklungsumgebungen, ein, für andere war es bereits eine Herausforderung, auch kleine Teilaufgaben innerhalb des Teams selbstständig zu lösen. Auf Eigeninitiative der Leistungsstärkeren nutzt ein zunehmender Teil der Schülerinnen und Schüler im Projekt auch IntelliJ oder Eclipse, weil dort die automatische Codegenerierung, die Einbindung von Bibliotheken und das Refactoring leichter sind als in den sonst im Unterricht verwendeten didaktischen Entwicklungsumgebungen BlueJ und JavaEditor.

Agile Praktiken in der Vorbereitung

In der Mittelstufe werden (bisher) bei uns Projekte nicht agil durchgeführt, entsprechend sind agile Praktiken und Techniken für die Lernenden neu. Ein wesentlicher Schlüssel für einen Projekterfolg ist meiner Meinung nach das Kennenlernen und Einführen einzelner Techniken bereits im Vorfeld. Dies ist im regulären Unterricht ohne Projektkontext für die Bausteine ↑ User-Storys, ↑ Tasks, ↑ Prototypen, ↑ Pair-Programming, ↑ Testen und ↑ Repositorys sehr gut möglich.

User-Storys: Bei jeder anwendungsbezogenen Aufgabe im regulären Unterricht können zu Beginn eine Kundensicht eingenommen und Anforderungen in Alltagssprache formuliert werden.

Tasks: Teilaufgaben aus Entwicklersicht ergeben sich automatisch bei der Implementierung von User-Storys.

Pair-Programming: Peer-to-Peer-Wissenstransfer, indem für einzelne Stunden Leistungsstärkere mit Leistungsschwächeren ein Paar bilden und dabei der Leistungsschwächere zur Rolle des Drivers verpflichtet wird.

Prototyping: Im folgenden Kasten wird ein exemplarisches Prototyping präsentiert, das im Unterricht (passend zum für mich gültigen Lehrplan) neue informatische Inhalte im Anwendungskontext einer Patientenverwaltung für ein Wartezimmer vergegenständlicht. Parallel zu den Lerninhalten wird über mehrere Wochen im Kurs sukzessive eine einfache Software entwickelt.

Abbildung 3.8: Prototyping für eine Patientenverwaltung

Testen: Die Qualitätskontrolle gehört bei Lehrplaneinheiten mit Programmieren zum Informatikunterricht dazu. In der Oberstufe bietet es sich beispielsweise an, dass die Lehrkraft Testklassen verteilt und Schülerinnen und Schüler durch das Ausführen von Testfällen die Qualität ihrer Programme selbst überprüfen können. Sukzessive können die Schülerinnen und Schüler auch eigene Testklassen schreiben. Auch der Einsatz eines Debuggers ist zu empfehlen, weil er ein Verständnis für den dynamischen Ablauf eines Programms schafft und bei der Fehlersuche hilfreich ist.

Repositorys: Versionskontrollsysteme können im Unterricht bereits zur Verteilung von Programmgerüsten und Musterlösungen verwendet werden. Außerdem lässt sich durch die Vorgabe einer abstrakten Oberklasse der Vorteil verteilten Arbeitens sehr schön demonstrieren: Wenn in einer Klasse mit 20 Schülerinnen und Schülern jede und jeder 15 Minuten für das Schreiben einer Unterklasse benötigt, dann hat man nach den 15 Minuten nicht nur eine, sondern 20 verschiedene Unterklassen. Wenn diese gesammelt und für alle sichtbar vorliegen, ist das beeindruckend.

Für ein Vertiefen dieser agilen Techniken und Praktiken fehlt meist die Zeit, aber bereits dieser erste Einstieg ermöglicht zu Projektbeginn eine höhere Konzentration auf Inhaltliches.

Warm-up

Die Schülerinnen und Schüler erhielten zwei methodisch unterschiedliche Einführungen in die agile Projektorganisation. Zunächst gab ein Kurzvortrag von knapp 20 Minuten einen Überblick über die iterativ-inkrementelle Vorgehensweise als zentralen Prozessgedanken, die Planung von ↑ Iterationen mithilfe von User-Storys und Tasks, Prototypen als Ergebnisse sowie die Methodenbausteine ↑ Timeboxing und Reflexionstreffen (↑ Reflexion).

Als zweiten Impuls wählte ich ein praktisches agiles Arbeiten. Dafür eignen sich ↑ agile Spiele: Mehrfach habe ich die Marshmallow Challenge durchgeführt, um das Prototyping begreifbar zu machen. Beim letzten Kurs bin ich aber dazu übergegangen, den Schülerinnen und Schülern stattdessen eine konkrete Aufgabe zu geben, an der sie in sehr kurzer Zeit (75 Minuten) den agilen Prozess kennenlernen können. Jedes Team sollte ein eigenes Backlog mit priorisierten User-Storys für eine Lernkarten-Software erstellen. Zur ersten User-Story sollten Tasks skizziert und ggf. sogar die ersten Quelltextzeilen programmiert werden. Die Teams wurden zufällig zusammengestellt, um eingespielte Banknachbarn zu trennen. Ziel war es, mit einer anschließend stattfindenden Reflexion (20 Minuten) alle wesentlichen Bestandteile einer Iteration zu durchlaufen: eigenständige Planung in unterschiedlichen Detailgraden, Implementierung (war kein Schwerpunkt, weil die Schülerinnen und Schüler diese aus dem Unterricht kennen) und eine Prozessreflexion. Trotz der extrem kurzen Zeit gab es gute inhaltliche Ergebnisse, wie die folgende Abbildung zeigt.

Abbildung 3.9: Knapp formulierte User-Storys für eine Lernkarten-Software

Die Reflexion brachte die folgenden wichtigen Punkte hervor. Teilweise sind sie allgemeiner Art, teilweise als individuelle Anliegen meiner Schülerinnen und Schüler zu verstehen.

•Bei der Formulierung von User-Storys sind Stichworte zu wenig.

•Die aktive Beteiligung aller Teammitglieder ist wichtig. (Einige äußerten im Vorfeld die Sorge von Trittbrettfahrern im Projekt.)

•Das unerklärte Einbringen von Konzepten, die über den bisherigen Unterricht hinausgehen, grenzt Schülerinnen und Schüler mit weniger Programmiererfahrung aus. Das KISS-Prinzip ist eine mögliche Lösung für dieses Problem.

•Mehrere Schülerinnen und Schüler äußerten den Wunsch, ein digitales Project-Board führen zu dürfen, um auch von zu Hause darauf Zugriff zu haben.

•Die knappe Zeitvorgabe macht es notwendig, sich für einzelne Aufgaben Zeitrahmen zu setzen (↑ Timeboxing), um fokussierter zu arbeiten und «sich im Kreis drehende» Diskussionen zu beenden.

•Zentrale Werte wie Respekt, Mut, Zielstrebigkeit, Einfachheit und Feedback werden angesprochen.

Gegenüber einem agilen Spiel bestand der Vorteil diese Warm-ups darin, das bereits eine ganze Iteration inklusive Reflexion durchlaufen wurde. Zudem erhielten die Schülerinnen und Schüler eine Vorstellung, wie die Arbeit in zufällig ausgewählten Teams mit unterschiedlichen Leistungsniveaus funktioniert. Im Gegensatz dazu stellt ein Einstieg durch ein agiles Spiel das Soziale und Emotionale stärker in den Vordergrund. Ich wähle den Einstieg inzwischen immer möglichst passend zu den Stärken und Schwächen der Schülerinnen und Schüler des jeweiligen Kurses.

Projektdurchführung
Themenwahl und Teams

Die Schülerinnen und Schüler waren frei in der Themenwahl. Einzige fachliche Vorgaben waren, dass eine grafische Benutzeroberfläche, persistente Datenspeicherung und dynamische Datenstrukturen Bestandteile der Software sein müssen. Um die Themenwahl zu fokussieren, hatten vor Projektbeginn alle Schülerinnen und Schüler den Arbeitsauftrag, über einen Forumseintrag in der Lernplattform des Kurses ein Thema für das Projekt vorzuschlagen, was u. a. zu folgenden Themenvorschlägen führte:

Spiele: Black Jack, Poker, Schach, Arcade-Game, Brettspiel TAC, Jump-’n’-Run, Rubiks-Cube-Löser

Anwendungssoftware: individualisierte Anzeige des Vertretungsplanes auf dem Handy/Computer, digitales Hausaufgabenheft, Kassensystem für Pausenverkauf, Wettprogramm für die Fußball-WM, Kochbuch, Reiseführer, Führerscheintraining, Nachhilfevermittlung, eine Software für die Lehrmittelbibliothek und ein Vokabeltrainer mit einem Beispielsatz zu jeder Vokabel.

Ich stellte die eingebrachten Vorschläge vor, kommentierte diese (beispielsweise sind reale Kunden wie bei der Bibliothekssoftware motivierend; eine Nachhilfevermittlung ist nur sinnvoll als Webservice, der aber erst im Lehrplan der Jahrgangsstufe 12 Thema ist) und jedes Team konnte sich dann ein Thema wählen.

Bei einer Teamgröße von sechs bis acht Mitgliedern musste ich pro Kurs drei Themen betreuen. Zur Gruppeneinteilung habe ich abhängig von der jeweiligen Lerngruppe folgende Verfahren erprobt, die jeweils unterschiedliche Vor- und Nachteile haben:

•Gruppeneinteilung nach Themenwunsch, mit dem Vorteil, dass damit stark auf die Schülerwünsche eingegangen wird.

•Leistungshomogene Gruppeneinteilung, bei der sich jeder in der Gruppe fachlich gleichermaßen einbringen kann und die Gefahr der Überforderung Einzelner durch technisch anspruchsvolle Lösungsansätze anderer gering ist; nach der Einteilung wählt die Gruppe ein Thema für sich aus.

•Leistungsinhomogene Gruppeneinteilung, sodass pro Gruppe in etwa ein gleiches Verhältnis von Leistungsstarken und -schwachen vorhanden ist. Diese Variante hat den Vorteil des Wissenstransfers innerhalb der Gruppe, sowie eine höhere Erfolgsquote für ein lauffähiges Endprodukt bei allen Gruppen.

Nachdem nun die Teams und Themen stehen, kann das Projekt beginnen. Da Ziele und Umsetzung einzelner Methoden in den Kapiteln 4 und 5 ausführlich beschrieben werden, gehe ich im Folgenden nur auf Besonderheiten ein.

User-Story und die Varianten Modeling-Story und Student-Story

Der Beginn mit der (Grob-)Planung auf Ebene von User-Storys funktioniert sehr gut, weil sich alle unabhängig von ihrer Programmiererfahrung gut einbringen und die ersten Implementierungsschritte spätestens nach drei Schulstunden beginnen können. Jedoch ist bei zunehmender Prototyp-Größe die Zahl der Klassen nicht mehr so einfach zu überblicken bzw. kann es notwendig sein, dass eine sehr zentrale Klasse zeitgleich von mehreren Paaren verändert werden muss. Hieraus entsteht im Entwicklungsverlauf der Bedarf, einen Überblick über die Klassen, deren Schnittstellen und ihre Beziehungen zu bekommen. An diesem Punkt ist es sinnvoll, ein Klassendiagramm zu erstellen, welches die Grundlage für weitere Überlegungen und Besprechungen ist. In der Regel muss ich den Anstoß dazu geben. Passend zum agilen Projektablauf schlage ich dazu in einem Planungsmeeting vor, eine von mir als Modeling-Story bezeichnete besondere User-Story aufzunehmen. Im Nachgang zur Modellierung ist häufig ein Refactoring nötig. Modellieren und Refactoring brauchen zwar Zeit, sodass in dieser Iteration weniger Funktionalitäten umgesetzt werden. Da das verteilte Arbeiten danach aber wieder leichter geht, weil die Aufgaben und Schnittstellen klarer sind, sehen die Schülerinnen und Schüler auch den Mehrwert.

Ebenso ermuntere ich dazu, Student-Storys – spezielle User-Storys, in denen Wissen aufgebaut wird – über das Project-Board einzupriorisieren. Deren Inhalte können Einarbeitung in neue Themen wie eine Datenbankanbindung sein oder aber auch der Wissenstransfer von Leistungsstärkeren zu -schwächeren. Da diese Lernprozesse Zeit benötigen, ist es wichtig, sie über das Project-Board transparent zu machen und dann auch nach Beendigung mit einem Setzen auf «Done» zu feiern.