Entwicklungsbericht SS 2020
- Details
- Geschrieben von Peter H.
Dieses Semester hat uns alle vor unvorhergesehene Herausforderungen gestellt und es war vor allem Flexibilität gefragt. Das hatte Vor- und Nachteile. Zunächst einmal bin ich froh, dass ich überhaupt unterrichten konnte, denn so konnte ich mein Ziel erreichen, mich in diesem Semester in Scratch zu vertiefen, was mir zukünftig ein wichtiger Bestandteil meines Informatiklehrerrüstzeugs sein wird. Ich habe gelernt, motivierende Aufgaben mit SCRATCH zu erstellen, die einen Schritt über die allseits bekannten Standardaufgaben hinausgehengehen. Dazu habe ich mich insbesondere vom Rückwärtigen Lerndesign inspirieren lassen. Ich wollte nicht wieder einen Unterricht machen, der klassisch bei den Variablen anfängt, und über Schleifen irgendwann in Funktionen mündet, sondern umgekehrt, von einem konkret-praktischen Ziel sozusagen rückwärts diese Konzepte erarbeiten, ohne sie explizit zu problematisieren. Praktisch funktioniert das bisher sehr gut, und SCRATCH ist ja auch so ausgelegt, dass man seiner Kreativität freien Lauf lassen und Programmierelemente intuitiv bedienen können soll. Achtung: Man weiß allerdings durch Analysen auf der SCRATCH-Website, dass die meisten von den SuS erstellen Programme relativ trivial sind und keine Verwendung wichtiger funktionaler Aspekte wie Variablen und Bedingungen stattfindet. Daher ist es wichtig, nach einem motivierenden, offenen Einstieg, wo die Schüler en passe mit der Bedienoberfläche vertraut werden, dennoch anspruchsvolle Aufgaben, die in sich stimmung und aufbauend sind, zur Verfügung zu stellen. Das heißt, wie bei jeder Technologie, dass der Lehrer nicht von seiner unterrichtlichen Verantwortung entbunden ist. Im Gegenteil. Die SuS, so begeistert sie am Anfang auch sind, wenn sie ihre Sprites bewegen können, sind auch schnell gelangweilt, wenn man ihnen nicht dabei hilft, durch das Dickicht der funktionalen Elemente zu finden. Scratch bietet, abgesehen von Rekursionen und komplexen Datenstrukturen, alles an, was auch eine funktionale Programmiersprache wie Turbo Pascal oder VB, die früher zum Einstieg verwendent worden sind, auch anbietet.
Natürlich müsste man jetzt noch testen, ob die SuS auch in der Lage sind, formale Probleme zu programmieren, wie das im klassischen Programmierunterricht geschieht, doch ich habe starke Gründe zu glauben, dass meine SuS durch die eher holistische Vorgehensweise einen großen Startvorteil in die Welt des Programmierens haben, einfach sie die Grundprinzipien implizit schon verstanden und angewendet haben und bei neuerlicher, vllt mehr formaler Instruktion, dieses Wissen anzapfen können, welches schon als Schemata in ihrem Langzeitgedächtnis verankert ist.
Distance learning
Der Vorteil des distance learnings für mich war sicher, dass meine Stundenvorbereitungen wohlüberlegt sein mussten, da die Möglichkeiten zur Interaktion und Improvisation nur eingeschränkt waren. Ich habe außerdem mitbekommen, wie wichtig persönliche Kommunikation für die Kinder ist und habe mich daher auch bewusst gegen eine rein asynchrone Unterrichtsform entschieden, die auch für mich einfacher gewesen wäre. Aber ich vermute, dass ich dann die SuS nicht so motivieren hätte können. Außerdem sind viele von ihnen lange in Quasi-Isolation gewesen und ich habe das eher als meinen Beitrag gesehen, etwas dagegen zu tun. Obwohl die Kommunikationssituation etwas unüblich ist, ist mir doch auch gelungen, eine persönliche Ebene herzustellen, und dass, obwohl der Kurs ja nicht verpflichtend ist, immer noch fast alle dabei sind, freut mich natürlich auch. Probleme dieser Form des Unterrichts sind offensichtlich und überschneiden sich mit einigen Dinge, die ich mir eigentlich für dieses Semester vorgenommen hatte.
Probleme des distance learnings
Bei technischen Problemen z. B. kommt man schnell an seine Grenzen. Z. B. habe ich einmal das Experiment gewagt, und wollte die Grenzen des Virtuellen ausloten, indem ich von SCRATCH einen Schritt Richtung physical computing mit Micro:bit gehen wollte (siehe dafür meine Reflexion zum Thema Micro:Bit). Es gab leider doch ein paar technische Probleme, die ich nicht vorhergesehen hatte und zukünftig bin ich wohl weniger optimistisch bei Situationen, wo ich nicht direkt eingreifen kann und plane in diesem Sinne eher „konservativ“. Im Präsenzunterricht würde ich einfach vorher sicherstellen, dass jeder dieselben technischen Vorbedingungen hat (Vorbereitete Umgebung) und könnte auch rasch individuell eingreifen, um keine größere Störung entstehen zu lassen. Der andere Punkt war, dass mein Hauptfokus eigentlich auf einer Öffnung meines Unterrichts hätte liegen sollen.
Kompetenzorientierter Unterricht?
Mein Plan war, dass ich zwar schon anspruchsvolle Inputs gebe, dann die SuS aber im Rahmen eines projektorientieren Unterricht an selbständig gewählten Zielen arbeiten lasse. Dazu wollte ich natürlich auch die Gruppendynamik nutzen, weil mir beim ersten Termin, der noch in Präsenzform stattfand, gleich aufgefallen ist, dass die SuS, wenn auch hochbegabt, keinesfalls nur kognitive Interessen haben, sondern sich durchaus nach Austausch und Anerkennung durch die anderen sehen. Womöglich ist das sogar das wichtigste für sie, denn hochbegabt stoßen bei Gleichaltrigen oft auf Unverständnis, und da hätte ich ihnen gerne etwas Gutes getan. Zwar motiviere ich sie in unseren Zoom-Gesprächen, wie bereits erwähnt, schon auch zum Austausch und zu gegenseitigem Feedback auf der SCRATCH-Platform, aber es ist einfach nicht dasselbe.Möglichkeiten, die die SCRATCH-Platform zu kollaborativem Unterricht bietet, sind:
- Erstellen einer Online-Klasse zur Erleichterung der Organisation (Achtung: Die SuS vergessen immer wieder ihre Passwörter und können sich dann nicht einloggen...)
- Erstellen eines Studios, indem die gemeinsamen Produkte veröffentlicht werden können um sich Ideen zu holen und die eigene Leistung präsentieren zu können
- Remixen von Programmen, d. h. als LehrerIn kann man ganze oder halbfertige Lösungen zum Üben/Lernen zur Verfügung stellen
- Kommentarfunktion
Der andere Punkt sind die individuellen Projekte. Natürlich können sie die auch im Alleingang machen und ich gebe ihnen immer wieder interessante Zusatzaufgaben, doch bestehen will ich nicht darauf, dass sie das in ihrer Freizeit auch noch machen, und habe die Projekte daher optional gemacht. Ursprünglich hätte es eine Abschlusspräsentation vor Publikum gegeben. Allerdings wäre das im Präsenzmodus natürlich viel reizvoller, weil schneller und spontaner Synergieeffekte zustande kommen. Ich finde es schon sehr schade, dass das dieses Semester nichts geworden ist in der Form, denn ich bin schon immer wieder erstaunt von der Motivation und der Kreativität der TeilnehmerInnen, und ich bin mir sicher, dass da ganz wunderbare Dinge entstanden wären, wenn die Gruppe persönlich aufeinandergetroffen wäre. Ich wäre auch neugierig gewesen, inwieweit ich das produktiv steuern kann mittels Portfolio-Arbeit etc. und überhaupt hätte ich einen kindgerechten „ingenieurswissenschaftlichen“ Ansatz mehr verfolgt, um ihnen auch ein paar wichtige Metafähigkeiten nahezubringen, die fürs Programmieren ganz erheblich sind, z. B. Ziele definieren, Modelle bilden, Rücksprache halten mit Projektbeteiligten, ein Projekt termingerecht abschließen. Wie gesagt, einige dieser Elemente sind auch im distance-learning möglich, aber angesichts der Corona-bedingten Situation womöglich weniger reizvoll. Ich habe mich daher auf das Handwerkszeug bzw. meine Idee mit den Arcade-Spielen konzentriert, damit sie da auf jeden Fall etwas Handfestes und Motivierendes mitbekommen, bin mir aber bewusst, dass das nur die Hälfte der Miete ist.
Fazit
In diesem Semester habe ich bereits 10 von 14 Stunden Programmierunterricht abgehalten, dabei 2 in Präsenzform, und 8 als distance learning Einheiten. Dabei habe ich bemerkt, dass Unterricht, der sich für mich stimmig anfühlt, im Wesentlichen (darüber könnte man natürlich Bände schreiben) auf zwei Säulen fußt. Erstens, sozusagen auf der abstrakt-logischen Ebene, müssen die Lernziele klar sein, aus denen sich aufbauende Unterrichtsequenzen ergeben, die wiederum in sich stimmig sein müssen und natürlich in einer Form dargeboten werden, die die SuS motivieren. Computerpsiele mit Scratch sind da eine dankbare Sache, weil sie an der Lebenswelt der SuS anschließen und doch auch durch ihre exemplarische Bedeutung für computational thinking, das wiederum in alle anderen Themenbereiche der Informatik ausstrahlt, einen Bildungswert haben. Zweitens, muss der Unterricht auch in einer Form organisiert sein, der die SuS motiviert und bei ihnen Selbstwirksamkeitserfahrung auslöst, damit ihren Selbstwert ebenso wie die Bereitschaft zu Kooperation hebt. Das bedeutet für mich, dass im Sinne einer Kompetenzorientierung die Unterstützung zur Lösung der Programmieraufgabe nach und nach zurückgenommen wird (Fading) und als nächster Schritt die Komplexität von Aufgaben erhöht wird. Wenn auch komplexere Probleme gelöst werden können, werden die Aufgaben immer authentischer im Sinne von metakognitiven Leistungen, die benötigt werden, wie z. B. Planen, Teambildung, Fortschritt kontrollieren, mit Konflikten und Unsicherheiten umgehen etc.
Die Erfahrung die sich für mich aus der Zusammenstellung eines größeren Moduls ergibt werde ich zukünftig auf andere "geschlossene" Einheiten anwenden können. Dabei würde ich in etwa wie folgt vorgehen:
- Ein motivierendes Ziel/Problem überlegen und präsentieren: z. B. Die SuS müssen am Ende ein selbst entwickeltes Spiel präsentieren, das mindestens diese und jene Anforderung erfüllt
- Problembewusstsein schaffen: Den SuS Freiheit geben, sich das Problem als eigenes anzueignen, z. B. 1-2 freihe Scratch-Einheiten, um sich spielerisch vertraut zu machen
- Aus einer Grobplanung (Welche Kompetenzen haben die SuS nach Absolvierungd es Moduls) einzelne Unterrichtseinheiten ableiten, Überblick behalten über die Lernziele, genug Übungsmöglichkeiten/Wiederholungen einbauen im Sinne eines "Spiralmodells" von Unterricht
- Aufgaben variieren und immer möglichst wenig neue Strukturen hinzunehmen, sodass die Schüler nicht überfordert sondern eher angeregt werden
- Aufgaben gleich so entwickeln, dass sich daraus Zusatzaufgaben oder einfache Aufgaben ableiten lassen für die innere Differenzierung
- Kompetenzorientiert denken: Schrittweise Verantwortung übers Lernen den SuS überlassen, indem nach und nach offene Aufgaben gegeben werden und schließlich die geschlossenen ganz ablösen, die offenen Aufgaben aber so formulieren, dass die SuS sie mit dem bisher gelernten lösen können. Gefühle der Hilflosigkeit vermeiden!!!
- Individuelle und Gruppenphasen intelligent abwechseln: Programmieren lernen erfordert einerseits Konzentration und inviduelles Arbeiten, andererseits kann die Kreativität der SuS auch motivierend sein. Davon unbedingt Gebrauch machen als Lehrer, im Sinne von regelmäßigen "Teambesprechungen" oder Präsentationen. Die Gruppendynamik alleine wirkt oft auch schon motivierend, weil SuS nach Anerkennung suchen. Wenn Gruppenprojekte dann so, dass jeder für einen Teil verantwortlich ist (Trittbrettfahrer!). Außerdem ist auf SuS Acht zu geben, die sich in der Gruppe schwer tun. Als Lehrer kann man da indirekt sogar helfen, die soziale Kompetenz zu üben. D. h. aber auf jeden Fall, die SuS nicht einfach sich selbst zu überlassen.
