Agile Schule (E-Book)

Peter Brichzin, Petra Kastl, Ralf Romeike

Agile Schule

Methoden für den Projektunterricht

in der Informatik und darüber hinaus

ISBN Print: 978-3-0355-1053-9

ISBN E-Book: 978-3-0355-1247-2

1. Auflage 2019

Alle Rechte vorbehalten

© 2019 hep verlag ag, Bern

www.hep-verlag.com

Inhalt

1.Einleitung

Schule entwickelt sich weiter

2.Hintergrund

Agile Kultur in Unternehmen und Schulen

2.1Geschichte und Entwicklung

2.2Agiles Arbeiten – ein Zusammenspiel aus Werten und Praktiken

2.3Unternehmen werden agil – Beweggründe und Erfahrungen

3.Im Unterrichtseinsatz

Erfahrungen mit agilen Schulprojekten

3.1Best Practice – das Spiel «Pengu»

3.2Im Anfangsunterricht durch Gestaltungsfreiräume begeistern

3.3In der Oberstufe komplexe Anwendungssoftware agil entwickeln

3.4Agile Softwareentwicklung als ganzjährige Lernmethode im Pflichtunterricht

3.5Ein geskriptetes Projekt als Methodik für den Anfangsunterricht

3.6Reflexionskompetenz stärken durch Weiterentwicklung des eigenen agilen Prozesses

4.Agiler Methodenkoffer I

Grundlegende Techniken und Praktiken

4.1Iterationen – der agile Prozess

4.2User-Storys – Anforderungen aus Kundensicht

4.3Das Project-Board – Planung und Stand im Blick

4.4Tasks – Arbeitspakete aus Entwicklersicht

4.5Stand-up-Meetings und andere Besprechungsformen

4.6Pair-Programming – Zusammenarbeit mit klarer Rollenverteilung

4.7Prototypen – funktionsfähige Produkte ab der ersten Iteration

4.8Agile Spiele – agiles Denken und Handeln erleben

5.Agiler Methodenkoffer II

Weitere Techniken und Praktiken

5.1Reflexion in Review und Retrospektive – Nachdenken über Inhalt und Prozess

5.2Timeboxing – fokussiert arbeiten in festen Zeitrahmen

5.3Testen – systematisch Qualität hinterfragen

5.4Feedback und Bewertung – Rückmeldungen zur Weiterentwicklung nutzen

5.5Dokumentation – Transparenz durch aufgezeichnete Absprachen

5.6Refactoring – Qualität verbessern und dabei lernen

5.7Aufwandsabschätzung – gemeinsam das Machbare ermitteln

5.8Repositorys und andere kollaborative Werkzeuge

6.Agile Methoden für alle

Schule agil gestalten

6.1Agile Methoden in Theorie und Praxis

6.2Agile Schule über den Informatikunterricht hinaus

Glossar

Schule entwickelt sich weiter

Schule prägt einen der wichtigsten Lebensabschnitte der Menschen. Von der Grundschule bis zum Abitur sammeln Schülerinnen und Schüler wichtige Erfahrungen, die sie für den Rest ihres Lebens prägen. Damit geht es in der Schule um mehr als nur um die Vermittlung von Wissen. Neben fachbezogenen Inhalten kommt auch allgemeinen Kompetenzen eine zunehmend größere Bedeutung zu, wie sich auch in Bildungsstandards und kompetenzorientierten Lehrplänen zeigt. Dazu gehören beispielsweise die Fähigkeiten, effektiv zu kommunizieren und zu kooperieren sowie Lern- und Problemlösestrategien zielgerichtet einzusetzen.

Projektunterricht als wichtige Unterrichtsmethode

Projektunterricht gilt als besonders dazu geeignet, das selbstgesteuerte, selbstorganisierte und kooperative Lernen der Schülerinnen und Schüler zu fördern. Hierbei wird typischerweise in für die Lernenden relevanten Kontexten die Anwendung fachbezogener und verschiedener allgemeiner Kompetenzen gefördert, bspw. Teamarbeit und die Planung selbstorganisierter Unterrichtsphasen.

Im Informatikunterricht haben Projekte darüber hinaus eine besondere Bedeutung, da sie hier nicht nur als Unterrichtsmethode fungieren, sondern zugleich auch einen Einblick in die meist in Projekten organisierte Berufsrealität der Softwareentwicklung ermöglichen.

Der klassische Projektunterricht ist in der Regel klar sequenziell strukturiert. Zunächst wird ein umfangreicher Plan aufgestellt, dann wird er realisiert. In der Praxis haben sich allerdings in den letzten 15 Jahren rasch agile Methoden, verbreitet, und zwar in kleinen wie großen Softwareunternehmen. Oft sind agile Teams besonders motiviert, sie arbeiten fokussiert, pflegen einen wertschätzenden Umgang unter den Mitgliedern und sehen Fehler als eine wichtige Möglichkeit, etwas zu lernen. Sie bestimmen ihren Weg zum Ziel selbst, reflektieren diesen regelmäßig und begreifen Veränderung als Chance. Die meisten Teams und Kunden, die einmal agile Luft geschnuppert haben, wollen nicht mehr zurück, weil sie nun flexibel auf Anforderungsänderungen und andere sich im Prozess ergebende Herausforderungen reagieren können. So verändern agiles Denken und Handeln die Unternehmenskultur, da mit ihnen eine Reihe zentraler Werte, wie offene Kommunikation auf Augenhöhe und Selbstverantwortung im Team, verbunden sind.

Betrachtet man als Lehrkraft die agilen Methoden etwas genauer, offenbart sich ihr didaktisch-pädagogisches Potenzial für die Unterrichtsgestaltung schnell: Die Praktiken und Techniken fördern und fordern Kommunikation im Team, unterstützen die Strukturierung der inhaltlichen Arbeit in gut bearbeit bare Teilziele und erleichtern die Mitgestaltung des Lernprozesses durch die Schülerinnen und Schüler. Kurze Zyklen sorgen schnell für erste Erfolgserlebnisse, die motivieren, regen aber auch zum Innehalten und Nachdenken über das Produkt und die Zusammenarbeit an: Was haben wir bis jetzt erreicht? Sind wir damit auf dem richtigen Weg? Was sind unsere nächsten Schritte? Was lief gut? Was wollen wir im nächsten Zyklus besser machen? Hierdurch wird Lernen auch zu einem wichtigen Prozessbestandteil.

Unser Erfahrungshorizont

In unserem Buch «Agile Schule» greifen wir das Potenzial der Agilen Werte, Praktiken und Techniken auf und machen sie für die Schule nutzbar. Das tun wir weder, weil es gerade angesagt ist, noch, um ein Agiles Coaching zu verkaufen oder die nächste Zertifizierung zu bewerben. Uns geht es darum, eine Begeisterung weiterzugeben, die uns selbst in unserer Arbeit mit agilen Methoden gepackt hat. Wir wollen zeigen, welchen Wert agile Methoden für den Unterricht haben können, denn mit unserer Begeisterung sind wir nicht allein. Das Buch basiert auf Erfahrungen und der langjährigen Begleitforschung zum Einsatz agiler Projekte in unterschiedlichen Schulen in ganz Deutschland. Mit den beteiligten Lehrkräften haben wir uns mehrmals im Jahr getroffen, um gemeinsam die Methoden weiterzuentwickeln und für die Schule hinsichtlich ihres didaktischen Mehrwerts anzupassen. Die so entstandene Agile Schule ist keine Blaupause, die als festgelegtes Projektmodell im Unterricht Schritt für Schritt befolgt werden muss. Vielmehr stellt sie einen Rahmen an Möglichkeiten dar, verschiedene Praktiken und Techniken den Unterrichtsanforderungen entsprechend zu verwenden und anzupassen. Der erste eigene Versuch ist selten perfekt und selbst wenn, so wird im Laufe der Jahre immer auch mal eine Schülergruppe ihr Ziel nicht erreichen. Wichtig ist es, sich in regelmäßigen Abständen die Frage zu stellen, was warum gut oder ungünstig verlaufen ist, und entsprechende Anpassungen vorzunehmen. Auch wenn es sich bei den meisten Beispielen um Erfahrungen aus dem Informatikunterricht handelt, beschränkt sich die Agile Schule nicht darauf. Es zeigt sich zunehmend, dass die Agile Schule auch in anderen Fächern oder Kontexten eine Bereicherung darstellen kann.

Zum Aufbau des Buchs

Im auf die Einleitung folgenden Kapitel 2 stellen wir die wesentlichen Hintergründe agiler Methoden dar und geben einen Einblick, wie unterschiedlich der Weg zum Einsatz agiler Methoden in Unternehmen gestaltet werden kann. Die in diesem Kapitel präsentierten Agilen Werte werden in den folgenden Kapiteln immer wieder aufgegriffen.

In Kapitel 3 wird ein Best-Practice-Beispiel vorgestellt, welches kompakt die Kernideen agiler Projekte illustriert. Im Folgenden berichten Lehrkräfte von ihren Motivationen und Umsetzungen agiler Projekte in unterschiedlichen Kontexten. Die Berichte zeigen, wie flexibel sich die Methoden, Techniken und Praktiken an die individuelle Unterrichtsgestaltung anpassen und neben fachlichen auch pädagogische Ziele umsetzen lassen.

Kapitel 4 enthält einen Methodenkoffer mit acht grundlegenden Praktiken und Techniken, ihrer theoretischen Fundierung, Varianten der schulischen Umsetzung, Stolpersteinen sowie Tipps und Tricks. Diese acht Methoden sind ein guter Einstieg in erste agile Projekte.

Kapitel 5 umfasst weitere acht Praktiken und Techniken. Sie dienen der methodischen Vertiefung.

In Kapitel 6 reflektieren wir die gewonnenen Erfahrungen aus wissenschaftlicher Sicht und skizzieren Möglichkeiten für den Einsatz agiler Methoden außerhalb des Informatikunterrichts.

Die Pfeile im Fließtext verweisen auf Methodenbausteine (bei ihrer Erstnennung), die weiterführende Informationen beinhalten. Das Glossar erklärt Begriffe aus der agilen Welt, die im didaktischen Kontext nur am Rande vorkommen. Weiter beschreibt es die wichtigsten Methoden.

Zum Einsatz dieses Buchs

Sie können dieses Buch zusammenhängend von vorn nach hinten lesen, aber auch als Nachschlagewerk für Agile Werte, Praktiken und Techniken in der Schule nutzen. Wenn Sie sich vor allem für konkrete Umsetzungsbeispiele interessieren, können Sie direkt mit den Praxisberichten in Kapitel 3 einsteigen. Sie beginnen alle mit einem Überblick über den Kontext, die Zielrichtung und den zeitlichen Ablauf des Unterrichtsprojekts. Sollten Sie nicht Informatik unterrichten, mag für Sie Kapitel 6.2 ein guter Start sein, da dort Unterrichtsbeispiele außerhalb der Informatik vorgestellt werden. Sie können Ihre Aufmerksamkeit auch erst den Agilen Werten widmen, da sie die Basis agilen Handelns und Denkens sind, und dann direkt zu den Methodenbausteinen springen. Den Baustein ↑ Iterationen – der agile Prozess empfehlen wir Ihnen, wenn Sie zunächst einen Überblick gewinnen möchten. Seien Sie sich beim Lesen aber bewusst, dass der agile Prozess nur als Ausgangspunkt für Ihren eigenen, auf den individuellen Kontext zugeschnittenen Prozess dienen soll. Es geht weniger um die perfekte Umsetzung des agilen Prozesses und der damit verbundenen Techniken und Praktiken als um die Schülerinnen und Schüler, die sich selbst organisieren, effektiv kollaborativ arbeiten und dabei wichtige projektbezogene Kompetenzen erwerben; die Lernenden stehen im Zentrum.

Dank

Ein Buch wie «Agile Schule» kann nicht ohne die Mitarbeit und Unterstützung zahlreicher Kolleginnen und Kollegen entstehen. Wir danken insbesondere den Lehrerinnen und Lehrern, die durch ihre Erfahrungen und Beobachtungen die Grundlage für die Praxisberichte geschaffen haben: Andreas, Lennard, Leo und Uli.

Des Weiteren danken wir den Teilnehmerinnen und Teilnehmern der Workshops, die an den Grundlagen für die Methodenkoffer mitgearbeitet haben: Andreas, Christian, Conny, Dorothea, Julia, Lennard, Leo, Mareen, Matthias, Melanie, Mike, Sebastian, Thomas, Timo, Tobias und Uli.

Darüber hinaus danken wir der Sybit GmbH, insbesondere Johannes, Thomas, Fritz und Stephan, die uns auf der «Agile Bodensee» einen Einblick in die agile Welt der Profis und die Realisation unseres Workshops in Radolfszell ermöglicht haben.

Unser Dank gilt außerdem Gerald von der Lenovate GmbH für die engagierte Bereicherung unseres Workshops in Kloster Zinna, insbesondere für das Spiel «Kekse backen» und die markanten Sprüche zu Agilen Werten. Weiterhin gebührt unser Dank Bernd (stellvertretend für die ganze QAware GmbH), der einem der Autoren für ein Jahr die Mitarbeit im Unternehmen ermöglicht und ihm damit zu einem vertieften Einblick in die agilen Praktiken, Techniken und Werte von Profis verholfen hat.

Im Rahmen der Königsteiner fachdidaktischen Gespräche haben viele Kolleginnen und Kollegen mit uns an den Methodenbausteinen weitergearbeitet; auch ihnen gebührt unser Dank.

Schließlich bedanken wir uns bei der Google-CS4HS-Initiative für die finanzielle Beteiligung an den Workshops sowie an den Druckkosten dieses Buches.

Agile Kultur in Unternehmen und Schulen

Agile Methoden einzusetzen bedeutet auch zu verstehen, wo sie herkommen, welche Werte mit ihnen verbunden sind und wie diese in der Praxis zum Tragen kommen. In diesem Kapitel werden zunächst die wichtigsten Entwicklungsschritte und Vorgehensmodelle agiler Methoden beschrieben. Anschließend werden Agile Werte als ideelles Fundament und ihre Bedeutung für Unterrichtsprojekte dargestellt. Unterschiedliche Beweggründe und Erfahrungen bei der Einführung agiler Methoden werden schließlich durch Schilderungen aus der Praxis dreier Unternehmen skizziert.

2.1 Geschichte und Entwicklung
Softwareentwicklung wird Teamarbeit

Allein entwickelte Software ist typischerweise nicht sehr komplex, wird von wenigen genutzt oder hat eine kurze Lebenszeit. Anders ist es mit großen Softwaresystemen: Sie werden von vielen für viele geschrieben und meist über Jahrzehnte genutzt und weiterentwickelt.

Die Entwicklung solcher Softwaresysteme begann Mitte des letzten Jahrhunderts mit Steuerelementen für Raumfahrt und militärische Streitkräfte. Anfangs wurde im Großen ebenso «intuitiv» wie im Kleinen entwickelt. In den folgenden Jahrzehnten beauftragten Banken, Telefon- und Transportgesellschaften, Unternehmen für Medizintechnik und viele weitere Branchen zunehmend umfangreichere Softwarelösungen, die nur noch von Teams entwickelt werden konnten. Rasch wurde klar: Das Risiko zu scheitern war ohne ein strukturiertes Vorgehen groß. Dass es damals, als sich die Informatik als Wissenschaft erst entwickelte, noch kaum systematisch ausgebildete Informatiker, aber viele Ingenieure in der Softwareentwicklung gab, mag erklären, weshalb man in den 1960er-Jahren bewährte Vorgehensweisen aus Bau- und Produktionsprozessen übernahm und sie für die Softwareentwicklung anpasste. So entstand ein wasserfallähnlicher Verlauf in Phasen, der einen Schwerpunkt auf die sehr präzise Analyse und Definition der Anforderungen legte, um dadurch, analog zum Bauwesen, teure oder gar unmögliche spätere Änderungen zu vermeiden. Anschließend wurde gemäß den Anforderungen ein detaillierter Plan ausgearbeitet und im Folgenden genau umgesetzt. Kommuniziert wurde dabei im Wesentlichen durch das Weiterreichen der umfangreichen Dokumentation. Diese heute als klassisch bezeichneten Vorgehensweisen brachten Struktur in den Prozess, aber auch neue Probleme. Planungsfehler wurden beispielsweise oft erst am Ende des Projekts erkannt und waren zu diesem Zeitpunkt nur mit erheblichem Zusatzaufwand meist in Form von Überstunden behebbar. Außerdem beschrieben die verschriftlichten Wünsche des Kunden aufgrund von Kommunikationsschwierigkeiten oder unzureichender Kenntnisse oft nicht das, was eigentlich gebraucht wurde, sodass die Arbeit von Monaten oder Jahren «umsonst» war. Nach Abschluss einer klassischen Planung eingebrachte Wünsche durften nicht mehr berücksichtigt werden, auch wenn eine Planänderung aus Sicht des Entwicklerteams möglich und sinnvoll gewesen wäre. Die Praxis der Softwareentwicklung zeigte Ende des 20. Jahrhunderts immer deutlicher, dass langfristige Pläne oft nur für kurze Zeit gute Pläne sind, insbesondere in einer Welt, deren Anforderungen und Einsatzszenarien immer volatiler, komplexer, unsicherer und mehrdeutiger werden.

Abbildung 2.1: Probleme bei klassischem Vorgehen: Was der Kunde beschreibt, was er anfangs bräuchte, was umgesetzt wird, was noch gerettet werden kann und was er am Ende tatsächlich gebraucht hätte

Auf dem Weg zu mehr Flexibilität

Vor dem Hintergrund dieser auch für die Softwareentwickler oftmals frustrierenden Erfahrungen diskutierten in den 1990er-Jahren immer mehr Informatikerinnen und Informatiker darüber, welche neuen Wege beschritten werden könnten, um Software für alle Beteiligten besser zu entwickeln. Hierbei entstanden Vorgehensmodelle wie Extreme Programming, Scrum und Feature Driven Development, die zunächst unter das Prädikat «leichtgewichtig» fielen. Die Ideen für Veränderungen waren nun da, aber noch fehlte eine positive charakteristische Bezeichnung, die, vergleichbar mit einem Siegel, die verknüpften Werte bündelte, ihnen eine unverkennbare Identität gab und beim Kunden Neugier und Vertrauen für das damit verbundene Versprechen, besser zu sein, weckte.

Das änderte sich, als 17 erfahrene Softwareentwickler mit sehr unterschiedlichem Hintergrund im Jahr 2001 in den schneebedeckten Rocky Mountains zusammenkamen, um eine gemeinsame Basis und einen Begriff für die neuen Herangehensweisen zu finden. Nachdem ein Teilnehmer vorgeschlagen hatte, das, was man in der praktischen Arbeit mehr schätzen gelernt hat, dem gegenüberzustellen, was traditionell wichtig war, ging es sehr schnell. Dann standen vier Sätze, aus denen das Agile Manifest wurde, an der Wandtafel.

Abbildung 2.2: Das 2001 formulierte Manifest für Agile Softwareentwicklung

Der Moment wird von Teilnehmern später als überwältigend beschrieben. Es gab keine Gegenargumente, es bedurfte keiner Abstimmung. Alle sahen die Sätze und sagten: «Ja, das ist es!» Am zweiten Tag wählte die Gruppe das Wort «agil», das mit «beweglich», «flink» oder «wendig» ins Deutsche übersetzt werden kann, als positiv besetzten Begriff für das nun zum Ausdruck gebrachte gemeinsame Wertesystem und die daraus abgeleiteten Prinzipien. Die neuen Vorgehensmodelle, die sich darauf stützen, wurden von nun an als agile Methoden bezeichnet. Da sich der Begriff «Methode» sowohl auf Vorgehensmodelle als auch auf hierin verwendete Techniken, Praktiken und Hilfsmittel beziehen kann, verwenden wir im Folgenden den weiteren Methodenbegriff, der auch gut zum Verständnis von Methoden im Unterricht passt.

Zehn Jahre Agiles Manifest – eine Zwischenbilanz

Was agile Methoden in den folgenden Jahren verändern sollten, damit hatte 2001 niemand gerechnet, sagten die Teilnehmer übereinstimmend anlässlich des zehnten Jahrestags. Denn im Gegensatz zu vielen anderen Bewegungen, die verebbten, wuchs in der Praxis die Zahl der agil arbeitenden Teams und Unternehmen unaufhaltsam und immer schneller, insbesondere im IT-Bereich. Oft begann ein Team damit, es «mal auszuprobieren», und erlebte dabei, wie Kolleginnen und Kollegen neugierig wurden und fragten: «Was macht ihr denn da, warum seid ihr so gut drauf?» So sprang die Idee von einem Team zum nächsten und veränderte nicht nur deren Stimmung, sondern auch die Qualität der Produkte, die Effektivität, die Motivation der Projektbeteiligten und letztlich die gesamte Unternehmenskultur. In agilen Unternehmen geht man beispielsweise davon aus, dass man die besten Ergebnisse erhält, wenn man kleinen, sich selbst organisierenden Teams statt einer klaren Arbeitsanweisung ein inhaltliches Ziel gibt. Es liegt dann in der Verantwortung und der Freiheit des Teams, den für sich besten Weg zum Ziel zu bestimmen. Die in den Vorgehensmodellen beschriebenen Techniken und Praktiken unterstützen sie dabei. Agile Werte haben im Bereich der Kooperation und Teamarbeit, aber auch weit darüber hinaus viel bewegt, lautet die Bilanz nach zehn Jahren, auch wenn der Wandel noch lange nicht abgeschlossen ist: Agil sein bedeutet, sich ständig zu bewegen, zu verändern und neuen Umgebungen anzupassen, sodass die Weiterentwicklung des agilen Ansatzes wohl auch nie abgeschlossen sein wird.