Hier werde ich in den kommenden Wochen schrittweise konkrete Unterrichts- und Anwendungsszenarien darstellen.
Programmieraufgabe 108
Ich renne durchs Schulhaus und versuche die letzten Win 7-Leichen auf Win 10 zu aktualisieren und ersetze bzw. repariere nebenher noch den ein oder anderen Beamer oder stecke Kabel wie zurück. “Agile Schule” hatte ich mir da irgendwie auch anders vorgestellt. Daher komme ich im Moment auch nicht weiter mit meiner Blogserie zum Thema “Agile Schule”.
Aber ich hatte eine kleine Idee für eine anspruchsvollere Programmieraufgabe für die elfte Klasse zum Thema Binärbaum, die ich unbedingt weitergeben wollte:
Aufgabe
Schreibe eine Programm, das einen einfachen mathematischen Term der Form “3+4*5” einliest, in einen Binärbaum schreibt und durch einen inorder-Durchlauf auswertet.
Jetzt ist die Aufgabe zwar auf den ersten Blick vielleicht ganz überschaubar, aber es gibt den ein oder anderen Fallstrick, daher habe ich noch folgende Vereinfachungen angeboten:
- Es gibt nur Ziffern und nur die Operatoren *,+,-,/ . Das erlöst einen von dem Problem des Tokenizers. Also das Zerlegen eines Terms in logische Einheiten wie “<Zahl><Operator><Zahl><Operator><Zahl>”.
- Es gibt erstmal kein Punkt vor Strich.
- Im ersten Schritt müsste der Term eingelesen und ein Baum aufgebaut werden. Dabei könnte ich natürlich einfach von Vorne nach Hinten durchgehen. Dann hätte ich aber das Problem, dass ich eher einen entarteten Baum bekomme.
Daher wäre wenigstens eine Art von Halbierungsverfahren sinnvoll: Ich suche die Mitte des Terms und wenn es ein Rechenzeichen ist, dann gehe ich rekursiv in die Teiläste. - Habe ich den Baum aufgebaut, dann muss der Term ausgewertet werden. Hierzu wird wiederum ein Term aus dem Baum gewonnen und ausgewertet. Da das in JavaScript über die Funktion eval() recht leicht ist, habe ich meinen Schülern folgendes Codefragment gegeben:
import javax.script.*; import java.io.StringWriter; static void evalMath() { ScriptEngine engine = new ScriptEngineManager().getEngineByName("javascript"); ScriptContext context = engine.getContext(); StringWriter writer = new StringWriter(); context.setWriter(writer); try { engine.eval("print(3+2)"); } catch (ScriptException ex) {} String output = writer.toString(); System.out.println("Script output: " + output); }
Das Trennen in Einlesen und Wertberechnung, vor allem, wenn man letzteres nicht mit meinem Trick macht, wäre eine schöne Aufgabe für die Projektphase am Ende des 11. Klasse, die sich zwei Schüler auch teilen können. Man könnte im übrigen auch noch einen “zufälligen Rechenterm-Generator implementieren. Ebenso könnte noch versucht werden Punkt-Vor-Strich und Klammer unterzubringen und natürlich “normale” Zahlen und nicht nur Ziffern zu zu lassen. Aber dann wird es gleich anspruchsvoller. Zumindest beim Aufbau des Terms – vielleicht wäre das Parsen beim Eintippen eine Alternative, vorausgesetzt man ignoriert Fehleingaben.
Kennt jemand im Übrigen eine “echte” Lösung? Wie machen es zum Beispiel die Taschenrechner?
Agiles Denken in Schulen (2)
Nach der kurzen Einführung ins Projektmanagement entlang des Wasserfallmodells soll nun eine kurze Erklärung in das Agile Projektmanagement folgen.
Das Problem mit dem Wasserfallmodell
“Warum gibt es überhaupt andere Projektmanagement-Modelle? Das Wasserfallmodell mit seinem strikten Ablauf und den Meilensteinen ist doch prima.”
Das mag schon stimmen, nur laufen in der Regel Projekte nur selten so ab, wie man sich das vorstellt:
- Mitarbeiter verschwinden durch Krankheit oder durch einen Jobwechsel (selbst erlebt)
- Das Geld reicht nicht, weil es für was anderes benötigt wird (selbst erlebt)
- Der Zeitpunkt ändern sich – meistens soll es dann auch noch früher fertig werden (selbst erlebt)
- Ziele ändern sich (selbst erlebt)
- Anforderungen ändern sich (selbst erlebt)
- usw.
Und je länger ein Projekt dauert, desto größer ist meiner Erfahrung nach die Chance, dass mindestens eines der genannten Probleme auftaucht. Nicht, dass man diese Probleme mit dem Wasserfallmodell nicht lösen könnte. Aber es muss doch noch einen besseren Ansatz geben.
Agiles Projektmanagement
Soweit ich weiß, und ich mag da falsch liegen, kam das Agile PM ursprünglich aus der Software-Entwicklung. Denn dort, so habe ich es jedenfalls erlebt, tauchen die oben genannte Probleme massiv auf. Die zugehörige Wikipedia-Seite gibt dazu einen schönen Überblick.
Wie man auf der Wikipedia-Seite nachlesen kann, gibt es einige Kriterien, die in einem sogenannten Manifest zusammengefasst werden und verschieden, daraus abgeleitete PM-Verfahren. Für mich persönlich kristallisierte sich dabei das SCRUM-Verfahren als so etwas, wie die eierlegende Wollmilchsau heraus. Wie das in etwas funktioniert zeigen die folgenden beiden Video eigentlich ganz gut:
Eine kurze Zusammenfassung der wichtigsten Elemente, wobei ich gleich mal versuche parallelen zur Schule herzustellen:
- Es gibt keinen Projektmanager!
- Es gibt so etwas wie den Auftraggeber (Product Owner) und einen Unterstützer (Scrum Master).
Lehrer sind in der Regel Scrum Master und Product Owner in einem. Wir geben vor, was wir gerne hätten und helfen den Schüler das Ziel zu erreichen in dem wir passenden Unterricht machen. - Das Endprodukt wird in möglichst viele, kleine und sinnvolle Elemente zerlegt und priorisiert im Product Backlog abgelegt.
Auch das machen wir Lehrer. Wir überlegen uns, wie man den Schülern am sinnvollsten die Kompetenz, die man vom Product Owner (Lehrplan) bekommen hat, beibringen kann und legen Zwischenschritte sowie eine Reihenfolge fest. - Dann werden die Schritte nacheinander durchgeführt und am Ende eines jeden Schrittes wird getestet, ob alles geklappt hat.
Im letzten Fall schreiben wir Lehrer dann eine Prüfung und prüfen damit, ob das Ziel des Product Owner (Lehrplan) erfüllt wurde. - Auf Basis der Prüfungen werden die Anforderungen neu priorisiert und dann geht es wieder von vorne los.
Diesen letzten und in meinen Augen entscheidenden Schritt machen wir Lehrer dann oftmals nicht. Meist, weil wir es zeitlich nicht schaffen. Der Lehrplan muss ja eingehalten werden. Leider, denn hier wäre Raum für Möglichkeiten.
Zusammengefasst in einem Bild sieht das bei mir dann so aus:
Einen wichtigen Aspekt habe ich dabei jetzt noch gar nicht angesprochen: die Kommunikation. Agiles PM lebt von der Kommunikation:
- Product Owner und Scrum Manager entscheiden vielleicht mit dem Team, wie die Priorisierung ist.
- Die Zerlegung einer Anforderung in Einzelschritte (Sprint Backlog) wird zusammen durchgeführt.
- Wer was macht, wird zusammen im Team entschieden. Dabei kann jeder frei wählen und auch mal was machen, was er noch nicht so gut kann. Dann bekommt er halt Unterstützung. Damit sorgt man dafür, dass die Kompetenz im ganzen Team im Optimalfall steigt; Stichwort Digitalisierung der Schulen.
- Wie weit jeder mit seiner Arbeit ist, wird täglich oder wenigstens wöchentlich kurz besprochen. Wer Probleme hat und Unterstützung benötigt, sagt dies in diesen kurzen Meetings. Ach ja, diese Meetings werden in der Regel im Stehen durchgeführt, damit sie nicht zu lange dauern.
So weit kurz zu den Kernelementen. Selbstverständlich kann man da noch beliebig mehr zu schreiben, aber ich wollte ja auch nur einen kurzen Einblick geben.
Im nächsten Beitrag geht es dann um “Agile Didaktik“:
“Es lohnt sich oft, im Unterricht die jeweiligen, aktuellen Gegebenheiten, Chancen und Widerstände aus dem Moment heraus zu berücksichtigen, anstatt einem vorgefassten Plan strikt zu folgen.”
Wer mag, kann sich auf der Internetseite agiledidaktik.ch schon mal einlesen und versuchen, die obige Element des Agilen PM in der Agilen Didaktik wiederzuentdecken.
Im vierten Teil erzähle ich dann aus meiner persönlichen Erfahrung. Schwerpunkte werden P-Seminare und das Medienkonzept sein. Aber eventuell auch “normaler” Unterricht und was mir sonst noch einfällt. Für Anregungen bin ich ganz offen.