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

Mach’s einfach! Aus der Tradition heraus gab es bei den SBB seit jeher viele Regularien, Abläufe waren relativ kompliziert. Dinge einfach zu machen bedeutet, diese Regularien sinnvoll abzubauen und es zu wagen, Entscheidungen mit dem gesunden Menschenverstand zu treffen.

Nach der Einigung auf diese Prinzipien als Grundlage für den Wandel begann die Umsetzung, wobei – wie im agilen Umfeld üblich – in kleinen Schritten, also iterativ vorgegangen wurde. In jedem Quartal wurden Teilziele entsprechend der Priorisierung mit Feature-Teams an einem Nachmittag geplant und während des Quartals ausgearbeitet. Am Ende jeder Iteration wurden die Resultate präsentiert. So ist unter anderem ein Vorgehensmodell der SBB entstanden, das den werteorientierten Rahmen vorgibt. Nun kann jedes Team, das in ein neues Projekt startet, für sich selbst entscheiden, ob es sich an Scrum, Kanban oder einem anderen agilen Vorgehensmodell orientiert, denn jedes passt in den vorgegebenen Rahmen und erlaubt es beispielsweise, während der Produktentwicklung regelmäßig zu prüfen, ob Wert und Nutzen geschaffen werden. Zudem wurde Raum für Vernetzung und Dialog in der Organisation geschaffen, damit jeder den Zielen Sinn geben und eigene Ideen entwickeln kann, unabhängig von seiner Aufgabe und Position im Unternehmen. Der Stand der agilen Transformation wurde von Beginn an anhand von Kriterien gemessen. Diese Daten wurden um eine Selbsteinschätzung der Teams ergänzt und es zeigt sich inzwischen: «Agilität ist bei den Mitarbeiterinnen und Mitarbeitern angekommen. Agilität gilt als erstrebenswert.» Viel Zeit und Reflexion, laufende Anpassungen und eine Begleitung waren dabei wichtige Faktoren.

Im Unterrichtseinsatz

3

Erfahrungen mit agilen Schulprojekten

Im ersten Teil dieses Kapitels wird ein mehrfach erprobtes Beispiel vorgestellt, das die wesentlichen Kernideen agiler Projekte verdeutlicht. Daran schließen Erfahrungsberichte agiler Schulprojekte an, die illustrieren, wie agile Methoden bei unterschiedlichen Lerngruppen, fachlichen Vorkenntnissen und Zielsetzungen flexibel und gewinnbringend eingesetzt werden können. Ziel dieser Berichte ist es, den Leserinnen und Lesern Anregung zu geben, die Unterrichtsprojekte ihrer Schülerinnen und Schüler durch Auswahl und Anpassung agiler Praktiken individuell zu gestalten.

3.1 Best Practice – das Spiel «Pengu»

Ein lohnenswertes Projektziel ist für viele Schülerinnen und Schüler die Konzeption und Implementierung eines Computerspiels. Sehr gut eignet sich das Jump-’n’-Run-Spiel «Pengu», bei dem eine Spielfigur auf einer bewegten Wolke über einen Abgrund gesteuert werden muss. Umgesetzt wird dieses Szenario in diesem Beispiel mit Greenfoot. Greenfoot stellt auf der Programmiersprache Java basierende Miniwelten zur Verfügung, die insbesondere für zweidimensionale Spiele und Simulationen geeignet sind. Greenfoot ermöglicht es Programmieranfängern somit, die objektorientierte Programmierung auf interaktive Weise kennenzulernen. Im Folgenden soll nun die Spielidee konkret mit Hilfe agiler Techniken und Praktiken umgesetzt werden. Hierzu wird das Szenario zuerst in ↑ User-Storys festgehalten und in ↑ Tasks aufgeteilt. Anschließend wird das weitere Projektvorgehen beschrieben.

Abbildung 3.1: Das Pengu-Spiel

Funktionalitäten in User-Storys festhalten

User-Storys beschreiben in kurzer Form Funktionalitäten der zu entwickelnden Software, die dem Nutzer zur Verfügung stehen sollen. Jede User-Story soll sich dazu auf eine konkrete Aktivität beschränken und wird aus Sicht des Kunden beschrieben. Typischerweise erfolgt die Erstellung der User-Storys unter Einbeziehung des Auftraggebers und erfordert domänenspezifisches Wissen aus dem Kontext der zu erstellenden Software. In diesem Beispiel übernehmen die Schülerinnen und Schüler selbst die Kundenrolle, um zu entscheiden, wie das Spiel ausgestaltet werden soll. Deshalb ist es erforderlich, dass das Team eine Vorstellung vom Spielfluss und den Möglichkeiten solcher Jump-‘n’-Run-Spiele besitzt, um die Anforderungen klar aufzustellen und auch eigene Ideen mit einzubringen. User-Storys helfen nun, das umfangreiche Spiel in kleine und damit gut umsetzbare Teile zu gliedern. Als Grundsatz sollte für jede Aktivität einer Figur (hier z. B. «Pinguin kann sich bewegen», «Wolke bewegt sich zwischen den Klippen») eine eigene User-Story erstellt werden. Anhand der User-Storys kann dann auch überprüft werden, ob etwas Wichtiges vergessen wurde.

Abbildung 3.2: Die ersten User-Storys zum Pengu-Spiel

Die ersten drei User-Storys dienen in unserem Beispiel der Grundfunktionalität des Spiels: «Spielfläche», «Pinguin bewegen» und «Pinguin fällt». Weitere User-Storys beinhalten die nächsten Spielfunktionen sowie weitere Ausbaumöglichkeiten. Die Zettel zeigen die entsprechenden Beschreibungen der User-Storys sowie deren Prioritäten, welche die Bearbeitungsreihenfolge vorgeben. Da alle drei User-Storys für das Spiel grundlegend sind, wurden sehr hohe Prioritäten festgelegt (je kleiner die Zahl, umso höher die Priorität). Aus den Prioritäten können auch implizite Abhängigkeiten ersichtlich werden (bspw. nur wenn das Szenario erstellt ist, ergibt eine dazu implementierte Aktivität Sinn).

Die erste Iteration planen und Tasks erstellen

Nach der Priorisierung der User-Storys wird im Team festgelegt, wie viele User-Storys in der ersten ↑ Iteration umgesetzt werden sollen. Da die Schülerinnen und Schüler zunächst noch wenig Erfahrung haben, den Arbeitsaufwand für die Umsetzung der User-Storys einzuschätzen, erfolgt hier die erste Auswahl «nach Gefühl». Hilfreich ist dabei, wenn die User-Storys anfangs sehr klein sind. Wir wählen entsprechend die drei User-Storys mit der höchsten Priorität aus. Nun werden diese User-Storys in Tasks gegliedert. Ein Task ist eine grobe Beschreibung eines überschaubaren Arbeitspakets, die auf einem eigenen Klebezettel (Post-it) steht. Während User-Storys die Ziele des Pengu-Spiels aus Sicht des Kunden beschreiben, müssen die Schülerinnen und Schüler nun ihre Perspektive ändern und die Teilziele aus Sicht eines Softwareentwicklers betrachten. Dabei sind bereits verschiedene Designentscheidungen zu treffen. Die resultierenden Tasks der drei User-Storys der ersten Iteration von Pengu sind in der folgenden Abbildung dargestellt.

Abbildung 3.3: Tasks als Planungsergebnis für die erste Iteration des Pengu-Spiels

Es wird deutlich, dass Tasks auch konkrete, technische Begriffe oder kurze Quellcodehinweise enthalten dürfen. Soll auch die Zeitplanung im Projekt berücksichtigt werden, wird zusätzlich eine ↑ Aufwandsabschätzung auf dem Task-Zettel festgehalten. Im Beispiel wird eine relative Schätzung des Aufwands in Form von den T-Shirt-Größen S, M und L vorgenommen. Die User-Storys und Tasks der ersten Iteration werden nun auf die linke Seite des Project-Boards gehängt.

Alles im Blick: Project-Board und Stand-up-Meetings

Das ↑ Project-Board dient als zentraler Informations- und Organisationsort des Projekts. Es visualisiert die Ziele und den Status der aktuellen Iteration und unterstützt zielgerichtete Diskussionen anhand der angebrachten User-Storys und Tasks. Zu Beginn einer Iteration befinden sich alle Karten auf der linken Seite. Sobald ein Schülerpaar mit einer Aufgabe beginnt, wird ein Klebezettel mit dem entsprechenden Task aus der To-do-Spalte genommen, mit Namenskürzel versehen (sodass alle Beteiligten genau sehen können, wer welche Tasks übernommen hat) und in die Spalte «In Progress» gehängt. Sobald der Task bearbeitet wurde, wird der Klebezettel nach rechts auf «Done» verschoben. Das Project-Board macht den Stand des Projektes sichtbar:

Abbildung 3.4: Project-Board in einer Iteration

Vor dem Project-Board finden auch die regelmäßigen ↑ Stand-up-Meetings statt, in denen zu Beginn einer Unterrichtsstunde organisatorische Aspekte der Projektdurchführung besprochen werden. Sie stellen eine geschickte Möglichkeit dar, den Stand des Projekts, das Geleistete der letzten Unterrichtsstunde und Probleme, aber auch die Ziele des Tages zu besprechen. In der Regel sind diese Meetings so kurz, dass es sich gar nicht lohnt, sich erst hinzusetzen. Durch das Stehen bemüht sich auch jeder, sich kurz zu fassen und sich auf das Wesentliche zu beschränken. Reihum beantwortet hier jede Schülerin und jeder Schüler die Fragen: Was habe ich seit dem letzten Mal getan? Was werde ich heute in Angriff nehmen? Welche Probleme hatte ich oder sehe ich auf mich zukommen und welche Hilfe brauche ich?

Schritt für Schritt vom Basic Pengu zum Advanced Pengu

Nachdem die Planungsphase der ersten Iteration abgeschlossen und das Project-Board eingerichtet wurden, beginnt nun die arbeitsteilige Implementierung, bei der die Schülerinnen und Schüler immer paarweise (↑ Pair-Programming) an einem selbst gewählten Task arbeiten. Während ein Schüler oder eine Schülerin die aktiv programmierende Rolle übernimmt und dabei das Vorgehen und die Arbeitsschritte erläutert, behält der oder die andere das große Ganze im Blick und stellt ggf. Fragen, sodass fortwährend kommuniziert wird. Alle 15 Minuten werden die Rollen getauscht. Bevor ein Task als erledigt gekennzeichnet werden darf, wird der resultierende Quelltext getestet. Am Ende der Implementierungsphase wird der neue Quelltext in die bestehende Codebasis integriert. Eine Viertelstunde vor Ende der Doppelstunde sind alle drei User-Storys fertig umgesetzt und integriert, sodass das Team auch das Ergebnis ausgiebig testen kann. Sind alle Tests erfolgreich bestanden, ist der erste ↑ Prototyp des Pengu-Spiels fertig und die somit vollständig bearbeiteten User-Storys können am Project-Board in die Spalte «Done» gehängt werden.

Ein Vorteil der iterativen Entwicklung ist es, dass die Schülerinnen und Schüler die Möglichkeit bekommen, Prototypen des Spiels in verschiedenen Entwicklungsphasen zu erstellen, auszuprobieren und dabei zu überprüfen, ob die Teilziele erreicht wurden. Im «Pengu»-Beispiel wird die erste Iteration bestimmt durch die Herstellung der Grundfunktionalitäten des Spiels. Der Vorteil der iterativen Vorgehensweise wird unmittelbar deutlich: Bereits so früh im Projekt ist das Spiel «spielbar», der erste Erfolg kann bereits getestet und gegenüber Mitschülerinnen und Mitschülern und der Lehrkraft demonstriert werden. Sogar das Hinzufügen weiterer Spielideen (Features) oder ein Umpriorisieren ist vor einer Iteration noch möglich, was bei linearen Vorgehensmodellen nahezu ausgeschlossen wäre. Zum Abschluss jeder Iteration kann und sollte reflektiert werden, wie gut der Prozess bis dahin gelaufen ist und ob sich das Team auf dem richtigen Weg befindet (↑ Reflexion).

In den weiteren Iterationen kommen nun nach und nach, der zuvor bestimmten Priorität entsprechend, die weiteren in den User-Storys festgehaltenen Funktionalitäten hinzu: das Bewegen der Wolke, Überqueren des Abgrunds und Springen in Iteration 2, Punktezähler, Sternenhimmel und Sternesammeln in Iteration 3 sowie das Berücksichtigen verschiedener Leben und das Gewinnen in Iteration 4. Erweiterungen des Spiels wie beispielsweise die Eiszapfen (Abbildung 3.5) können als niedrig priorisierte User-Story je nach Zeitvorrat gegen Projektende umgesetzt werden oder fallen weg.

Abbildung 3.5: Aufteilen einer umfangreichen User-Story in Tasks

In der Umsetzung des Spiels werden innerhalb jeder Iteration jeweils alle Phasen des klassischen Softwareentwicklungsprozesses (Anforderungsanalyse, Entwurf, Implementieren, Integrieren und Testen) einmal durchlaufen. Die Schülerinnen und Schüler erhalten entsprechend die Gelegenheit, diesen Prozess mehrfach in einem Projekt zu bestreiten und aus Erfahrungen zu lernen.

Praxiserfahrungen

Das beschriebene Spiel wurde inzwischen an verschiedenen Schulen in der Unterrichtspraxis, aber auch in Lehrerfortbildungen eingesetzt. Dabei war das Spiel als Unterrichtsgegenstand sehr motivierend und die Methoden erwiesen sich als sehr flexibel und für Projekte unterschiedlichster Ausprägungen geeignet. So können sowohl die Lerngruppen, Vorkenntnisse als auch die zeitlichen Gegebenheiten ganz unterschiedlich sein, weshalb in diesem Beispiel auf die Konkretisierung der Rahmenbedingungen verzichtet wurde. Schwierigkeiten ergaben sich mitunter aus der Notwendigkeit, die agilen Praktiken zuerst selbst erfassen zu müssen, z.B. wie User-Storys formuliert sein sollen und wie man diese in Tasks überführt. Mit diesem Beispiel ist nun eine Vorlage gegeben, die zur Orientierung für das Erlernen agiler Techniken und Praktiken und die Durchführung agiler Softwareentwicklungsprojekte im Informatikunterricht dienen kann.

Abbildung 3.6: Weitere User-Storys zum Pengu-Spiel

3.2 Im Anfangsunterricht durch Gestaltungsfreiräume begeistern

Ein Unterrichtsprojekt von Andreas Gramm

Steckbrief

Klassenstufe: 9 (Gymnasium, Wahlpflichtkurs)

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

Thema: Jump-’n’-Run-Spiel

Besonderheiten: Kollaboration lernen, «geplant-unfertiges» Produkt, Berufsbild Informatiker/Informatikerin

Agile Praktiken: Project-Board, User-Storys, Prototypen, Stand-up-Meeting, Pair-Programming, Reflexion

Programmiersprache/Entwicklungsumgebung: Scratch

Dauer und Frequenz: sechs Wochen mit einer Doppelstunde pro Woche

Zeitlicher Ablauf:

Gerade im Anfangsunterricht geht es mir darum, erlebbar zu machen, dass im Beruf der Informatikerin/des Informatikers das Gestalten von Produkten und das Arbeiten im Team im Vordergrund stehen. Dabei ist es wichtig, sich gut zu organisieren, um gemeinsam zu einem tollen Ergebnis zu kommen. Ziel und Motivation war es, den Schülerinnen und Schülern früh im Lernprozess zu zeigen, wie sie mit ihrem Wissen schon selbst etwas schaffen können, und sie so für das Fach zu begeistern und ihnen ein inspirierendes Berufsbild zu vermitteln.

Ausgangspunkt meiner Projektgestaltung war die Frage, wie ich im gegebenen zeitlichen Rahmen Vorgehensweisen bei der Entwicklung größerer Softwaresysteme für Lernende auf motivierende Art und Weise umsetzen und erlebbar machen kann. Ein typisches Problem, das ich in meinen bisherigen plangetriebenen, wasserfallähnlichen Projekten beobachtet habe, ist, dass Schülerinnen und Schüler mit ihrer Erfahrung kaum Anforderungen sinnvoll analysieren und Software entsprechend entwerfen konnten. Bis sie über die Voraussetzungen verfügen, um solche Projekte anzugehen, ist bei vielen das Interesse für das Fach schon der Auffassung gewichen, dass Informatik viel zu schwer sei. Unzufrieden war ich auch damit, dass Tests aus Zeitgründen zurückgestellt werden mussten und für eine Reflexion trotzdem viel zu wenig Zeit blieb.

Deshalb fand ich ein iteratives Vorgehen sehr verlockend. Man hat hierbei kurze Zyklen, sodass die Schülerinnen und Schüler in der ersten ↑ Iteration, den agilen Prozess und die agilen Praktiken kennenlernen und das erste interessante Zahnrädchen einer größeren Lösung entwickeln können. In den nächsten Iterationen kommen Schritt für Schritt weitere Zahnrädchen dazu. Dieses iterative Vorgehen ist mehr als die Aneinanderreihung von Umsetzungen kleiner, unabhängiger Probleme, denn die Teile fügen sich zu etwas Größerem zusammen. Wenn dabei sechs Schülerinnen und Schüler in Kooperation arbeiten, entsteht schnell etwas Spannendes. Das Endprodukt muss nicht perfekt sein, es muss nicht jede Idee umgesetzt sein. Trotzdem haben die Schülerinnen und Schüler einen lauffähigen ↑ Prototyp, den sie selbst gemeinsam entwickelt haben, und sie wissen, dass und wie es weitergehen könnte.

Projektvorbereitung
Rahmenbedingungen

Für die Schülerinnen und Schüler war es ihr erstes Schuljahr mit Informatikunterricht. Das Projekt wurde in der frühen Phase des Kurses mit Scratch durchgeführt und es sollten exemplarische Komponenten eines Jump-’n’-Run-Spiels entwickelt werden. Entgegen der Planung musste das Projekt zweimal für einen längeren Zeitraum unterbrochen werden. So fanden je eine Doppelstunde für Vorübungen im Herbst und für die Formulierung der User-Storys im Januar statt sowie vier Doppelstunden für die Realisierung im Frühjahr.

Agile Praktiken in der Vorbereitung

Vor dem Projekt hatten die Schülerinnen und Schüler grundlegende Programmierkenntnisse mit Scratch erworben und mit Kollisionen und Variablen wichtige Konzepte für das Spiel kennengelernt. Sie konnten auch Zustände und Abstandsveränderungen (z.B. die Anzahl der «Leben» einer Spielfigur) speichern und wussten, wie eine Kollision als Ereignis erfasst werden kann. Auf dazugehörige Arbeitsblätter mit erklärenden Beispielen konnten sie im Projekt zurückgreifen. Außerdem wurde vorbereitend auf das Projekt geübt, wie der Code einzelner Figuren (Sprites) in Scratch exportiert und importiert wird, wobei deutlich wurde, dass eine Quelltextintegration relativ einfach abläuft, solange man nicht in gleichen Figuren arbeitet. Diese Übung haben die Schülerinnen und Schüler im ↑ Pair-Programming durchgeführt und damit diese Praktik bereits vorbereitend geübt.

Warm-up-Spiel

Als Einstieg wurde mit allen 20 Schülerinnen und Schülern gemeinsam das Ball-Point-Game (↑ agile Spiele) gespielt, bei dem sie einen Heidenspaß hatten und eine deutlich sichtbare Optimierung erzielten. Es war eine gelungene Motivation, die zeigte, wie wichtig Absprachen für eine erfolgreiche Kooperation sind und wie man einen iterativen Prozess durch stringentes Planen, Handeln und Reflektieren optimieren kann.

Projektdurchführung
Themenwahl und Teams

Der Kurs wurde nun in drei etwa gleich große Gruppen geteilt, wobei die Schülerinnen und Schüler selbst die Teamzusammensetzung wählten. Sie waren von Anfang an interessiert und konnten ihre Erfahrung mit Computerspielen beim Sammeln und Diskutieren erster Ideen für ihr Jump-’n’-Run-Spiel einbringen. Anschließend formulierten sie erste User-Storys, die sie in einer weiteren Doppelstunde konkretisierten, um weitere ergänzten und am ↑ Project-Board befestigten. Auf eine Unterscheidung zwischen ↑ User-Storys und ↑ Tasks wurde in diesem Projekt verzichtet, da sich in Scratch die Beschreibung aus Kunden-und Entwicklersicht wenig unterscheidet. Zusätzlich wurde darauf geachtet, dass die User-Storys klein waren, also nur wenige, einfache Aufgaben umfassten. Eine ↑ Aufwandsabschätzung erfolgte relativ über die T-Shirt-Größen S, M, L:

Abbildung 3.7: Aufwandseinschätzung mit Hilfe von den T-Shirt-Größen S (small), M (middle) und L (large)

Eine logische Bearbeitungsreihenfolge ergab sich im Verlauf von selbst, d. h. auf ein Priorisieren vorab konnte verzichtet werden, wodurch die Vorarbeiten weiter verkürzt wurden.

Stand-up-Meetings und Planung

Die Umsetzung erfolgte in zwei Iterationen von jeweils zwei Doppelstunden. Die zu Beginn jeder Doppelstunde stattfindenden ↑ Stand-up-Meetings gaben den Lernenden eine Struktur vor, in der sie den Stand ihrer Arbeit selbstständig rekapitulieren konnten. Anschließend planten sie für die kommende Doppelstunde, sodass es entsprechend zwei Planungen pro Iteration gab. Dieser Ablauf mit zwei Planungen verhinderte, dass sich die Schülerinnen und Schüler Teile ihrer Planung bis zur nächsten Doppelstunde merken mussten, und ermöglichte gleichzeitig, nur jede zweite Doppelstunde zu integrieren und einen lauffähigen Prototyp zu erzeugen. In den Planungen konnten weitere User-Storys ergänzt werden, soweit dies die Umsetzung der Spielidee erforderlich machte. Falls am Ende einer Doppelstunde nicht alle ausgewählten User-Storys umgesetzt waren, wurden sie in die Folgestunde geschoben, auch wenn sie so nicht mehr Teil des jeweiligen Prototyps waren. Genauso gut konnten Programming-Pairs auch nicht ausgewählte User-Storys vorziehen, wenn zu wenig Aufgaben geplant waren.

Fragen und Probleme, die sich während der Umsetzung ergaben, konnten von den Teams in zusätzlichen Spontan-Meetings vor dem Board gelöst werden. Zwei oder drei Mal traten im Projektverlauf organisatorische bzw. fachliche Probleme auf, die entweder alle hatten oder auf die sie in Kürze stoßen würden. In diesen Situationen habe ich das Thema, beispielsweise das Abspeichern der Dateien in einem für alle zugänglichen Netzlaufwerk, zu Beginn der folgenden Doppelstunde kurz im Plenum aufgegriffen und, wenn es sich anbot, von einzelnen Teams erarbeitete Lösungen für das Problem dem gesamten Kurs vorstellen lassen.