Extreme Programming im Klassenraum

Transkript

1 Extreme Programming im Klassenraum Michael Weigend Holzkamp-Gesamtschule Willy-Brandt-Sre Witten michael.weigend@fernuni-hagen.de Abstract: Agile Methoden der Softwareentwicklung (Extreme Programming, Scrum, Crystal) finden insbesondere im Zusammenhang mit Open Source- Software - zunehmend Verbreitung. Eine Besonderheit agiler Methodologien ist, Kommunikations- und Lernprozesse des Teams während einer Softwareentwicklung zu berücksichtigen. Anhand eines Beispiels werden Ideen des Extreme Programmings und Umsetzungsmöglichkeiten im Informatikunterricht vorgestellt.. 1 Softwareentwicklung in der Schule - Probleme Methoden des Software-Engineerings, der Kunst und Wissenschaft der Programmierung im Großen, werden schon seit längerem in der Didaktik der Informatik nicht nur als Unterrichtsgegenstand sondern auch als Vorbild für die Gestaltung von Programmierprojekten im Klassenraum diskutiert [KP93]. Ein typisches Unterrichtsvorhaben nach dem Muster des Phasenkonzepts des traditionellen SE beginnt mit der Analyse eines Wirklichkeitausschnitts, führt dann zum Entwurf eines Softwaresystems, das arbeitsteilig implementiert, getestet und schließlich kritisch beurteilt wird. Es gibt eine Reihe gut dokumentierter erfolgreicher Beispiele für solche Projekte. Dennoch sind auch einige Probleme nicht von der Hand zu weisen: Informatikunterricht ist an allgemeinbildenden Schulen in einen unerbittlichen Zeitrahmen eingebettet. Ein Programmierprojekt muss zu einem bestimmten Zeitpunkt fertig sein. Dabei wird in Kauf genommen, dass Projekte nicht fertig werden, weil man zu Beginn den Aufwand nicht richtig eingeschätzt hat. Die Qualität eines Entwurfs kann letztlich aber erst im Nachhinein beurteilt werden, wenn das Produkt bereits fertig ist.

2 Das Phasenkonzept stellt gerade in der Analyse- und Entwurfsphase hohe Anforderungen an die Entwickler. Im Grunde ist für einen guten Entwurf, der eine tragfähige Basis für eine Implementierung darstellen soll, ein Erfahrungsschatz erforderlich, über den Anfänger nicht verfügen. In der Praxis wird die Lehrperson Schülerergebnisse zur Analyse und zum Entwurf massiv nachbearbeiten und so zurechtstutzen, dass sie implementierbar werden. Aber selbst, wenn die Lehrerin oder der Lehrer schon viele ähnliche Projekte durchgeführt hat, ist sie in der Regel vor Überraschungen nicht gefeit. Lerngruppen sind in der Regel sehr heterogen. Selbst wenn im Unterricht vor einem Projekt jede Menge Programmiertechnik gelernt worden ist, dürfte ein beträchtlicher Teil der Schülerschaft auch noch mit elementaren Algorithmik- und Programmierkonzepten zu kämpfen haben. Diese Kenntnisse sind nicht nur während der Implementierungsphase von Bedeutung, sondern auch schon in den früheren Phasen, wenn es um die Beurteilung der Machbarkeit geht.. 2 Warum ist XP eine geeignete Entwicklungsmethodologie für die Schule? Extreme Programming ist eine Methode des agilen Programmierens und wurde zum großen Teil von Kent Beck bei Chrysler entwickelt (Beck 2003). Es wird gerne als Gegenbewegung zu phasenorientierten Ansätzen des traditionellen Software- Engineering gesehen, das an die Planungsmethodologie des Maschinenbaus und Bauingenieurwesens anknüpft. Die wesentlichen Merkmale sind folgende: Eine Metapher beschreibt in einem Satz, was das System leisten soll. Der Auftraggeber des Projekts (Kunde, Customer) skizziert in sogenannten Stories die Systemfunktionalität. Sie sind die Grundlage für die Arbeitsaufteilung im Entwicklungsteam. Es wird in kurzen Zyklen (Iterationen), die in der Industrie etwa zwei Arbeitswochen, in der Schule vielleicht 30 bis 90 min dauern. Am Ende jeder Iteration steht ein lauffähiges (Zwischen-)Produkt, das getestet und beurteilt werden kann. Die Programmierer arbeiten immer zu zweit an einem Rechner (Pair Programming). Neue Programmteile werden kontinuierlich in das entstehende System integriert. Wenn ein neues Programmstück (z.b. eine neue Funktion oder Methode) implementiert werden soll, wird zunächst ein Test definiert (Test Driven Development), den das fertige Fragment bestehen muss, bevor es integriert wird. Der entwickelte Programmtext gehört dem ganzen Team (Collective Ownership of Code) und kann ständig von jedem überarbeitet werden (Refactoring).

3 Viele typische Aktivitäten des Software Engineerings, wie etwa Spezifikation von Systemfunktionalität oder UML-Diagramme zur Visualisierung von Klassenstrukturen spielen auch bei XP-Projekten eine Rolle. Nur die Sichtweise ist eine andere. Während im klassischen Phasenkonzept ein UML-Klassendiagramm eine langfristig tragende Basis für eine spätere Implementierung ist, entsteht es bei einem typischen XP-Projekt parallel zur Implementierung und wird sogar eher am Ende fertig gestellt und findet erst wieder bei einer Jahre später erfolgenden Überarbeitung des Projekts Verwendung. UML-Diagramme werden eher zur Dokumentation als zum Erfinden von Strukturen erstellt. Die Vorteile der agilen Methodologie für das Lernen im Informatikunterricht sind folgende: Ein Projekt ist immer erfolgreich. Jedes Team schafft mehrere Iterationen. Auch wenn das ursprünglich gesetzte Ziel für das erste Release nicht erreicht wird, steht am Ende ein Produkt, das man vorzeigen kann. XP unterstützt eigenes Experimentieren. Wenn ein Entwickler feststellt, dass die eigenen Kenntnisse nicht ausreichen, eine Story zu implementieren, plant er oder sie Zeit für Erkundungen ein. XP fördert den Erwerb metakognitiver Kompetenzen. Dazu gehört vor allem die Beurteilung eigener Fähigkeiten (Kann ich diese Story implementieren oder muss ich erst ein bisschen probieren?) und die Einschätzung des Zeitbedarfs für die Lösung einer Aufgabe. 3 Einige XP-typische Features im Informatik-Unterricht 3.1 Die Metapher des Projekts Es gibt viele Möglichkeiten an ein Projektthema zu kommen. Häufig sind solche Projekte interessant, bei denen es zu irgendeiner Zusammenarbeit mit anderen Fächern oder außerschulischen Partnern kommt. Wir tun dann so, als hätte uns dieser Partner einen Auftrag erteilt. Normalerweise ist das Ergebnis eines Schulprojekts nicht wirklich brauchbare Software. Aber man bekommt ein Gefühl, dass etwas Sinnvolles entstehen könnte, wenn man noch mehr Zeit und Energie investieren würde. Am Anfang der Softwareentwicklung steht eine so genannte Metapher, eine Kurzbeschreibung des Zielproduktes. Beispiel: Wir stellen uns vor, die Volkshochschule Witten wünscht eine Software zur Bereicherung ihrer Englisch-Kurse. Das Zielsystem lässt sich durch folgende Metapher beschreiben: Ein Chatroom, in dem die Teilnehmer nur auf Englisch kommunizieren können.

4 3.2 Release Planning Stories schreiben und bewerten Die Entwicklung beginnt mit der Planung des ersten Release, also der ersten komplett einsatzfähigen Fassung der Software. Hier wird festgelegt, wie das Produkt in etwa aussehen soll. Bei realen Projekten in der Industrie spielt nun der Customer (Kunde) die Hauptrolle. Der Customer ist ein Vertreter des Auftragebers (in unserem Beispiel die Volkshochschule), der das Projekt finanziert. Es handelt sich um Personen, die sich im Anwendungsfeld der entwickelten Software gut auskennen. Normalerweise begleitet ein Customer die gesamte Entwicklung, ist immer ansprechbar, wenn es Fragen zu Details einer Story gibt, ist bei allen Planungen anwesend und prüft in Akzeptanztests, ob die Qualität der Software seinen Ansprüchen genügt. Enge Zusammenarbeit mit dem Customer wird als Qualitätsmerkmal gesehen. Beim ersten XP-Projekt in der Schule spielt die Lehrperson die Rolle des Customers. In der Release-Planung beschreibt der Customer die Systemfunktionalität umgangssprachlich in sogenannten Stories. Jede Story steht auf einer Karte, auf der später noch Kommentare zur Implementierung, Testfälle etc. vermerkt werden können. In unserem Beispiel-Projekt gibt die Lehrperson einige Stories vor. Es macht aber auch Sinn, wenn Schüler/innen zeitweilig in die Rolle des Customers schlüpfen und eigene Stories erfinden. Story 1: Ein Teilnehmer muss sich zu Beginn einer Sitzung einloggen und seinen Namen angeben. Erst dann gelangt er oder sie in den Chatroom. Das System merkt sich den Namen. Story 2: Im Chatroom sieht ein Teilnehmer die letzten sechs Beträge des Chats in folgender Form: <Name der Person>: <Beitrag>. Story 3: Im Chatroom kann jeder Teilnehmer einen Gesprächsbeitrag von 60 Zeichen absetzen. Danach wird der dargestellte Dialog aktualisiert. D.h. man sieht die letzten sechs Beiträge. Story 4: Nur Beiträge in englischer Sprache werden akzeptiert. Äußerungen in einer anderen Sprache werden unterdrückt und nicht im Dialog dargestellt. Story 5: Auf allen Seiten sieht man oben rechts das Logo des Auftraggebers (VHS Witten). Story 6: Der Text eines Beitrages kann formatiert werden. Man kann flüstern (kleine Schrift), schreien (große Schrift) oder normal reden (normale Schriftgröße). Gute Stories sollten eine Reihe von Merkmalen aufweisen. Die wichtigsten sind folgende: Eine Story ist kurz und deutet ein Feature des Zielsystems nur an. Details werden später im Gespräch geklärt. Jede Story muss innerhalb einer Iteration (in der Schule heißt das: in maximal 30 bis 60 min) implementiert werden können. Notfalls muss eine zu umfangreiche Story in einfachere Stories aufgespalten werden.

5 Stories sollten möglichst unabhängig voneinander implementiert werden können. Der Customer bringt die Stories in eine Prioritätenreihenfolge oder ordnet ihnen jeweils eine Zahl zu, die zum Ausdruck bringt, welchen Nutzen er sich von dieser Story verspricht ("business points"). Möglicherweise reicht die Zeit nicht, alle Stories zu implementieren. Dann sollte das erste Release wenigstens die wichtigsten Features enthalten. Nun müssen die Entwickler (Schüler) für jede Story abschätzen, wie viel Zeit für ihre Implementierung notwendig ist. Eine schwierige Aufgabe. Aber erst dann kann das Team entscheiden, welche Stories es innerhalb der vorgesehenen Projektzeit insgesamt implementieren kann. Das ist das Ergebnis der Release-Planung. Nun kann aber folgendes Problem auftreten. Die Entwickler wissen nicht, wie sie bestimmte Stories realisieren sollen und können deshalb auch keinen Zeitbedarf angeben. Deshalb ist für das Release Planning eine Explorationsphase vorgesehen. Man recherchiert und entwickelt versuchsweise Lösungen, so genannte Spike Solutions oder kurz Spikes. 3.4 Erkunden und Experimentieren - Spikes Spikes sind Programmierxperimente, die allein dem Zweck dienen herauszufinden, wie und mit welchem Aufwand man eine Story implementieren kann. Schüler/innen müssen im Rahmen eines Projektes meist neue informatische Konzepte lernen. Deshalb kommt den Spikes im Klassenraum eine besondere Bedeutung zu und es muss genügend Zeit für sie eingeplant werden. Sie können auf verschiedene Weise gestaltet werden. Mit Hilfe ihrer Sprachreferenz erarbeiten sich die Schülerinnen und Schüler selbstständig die erforderlichen Programmierkonzepte. Die Schüler/innen bearbeiten ein ausgearbeitetes Lernarrangement mit Erkundungsaufgaben und Experimenten, das auf eine Story zugeschnitten ist (z.b. "Wie speichert man eine Liste?") Man analysiert einen Programmtext, der ein ähnliches Problem löst, wie das in der Story beschriebene. Gute Sprachreferenzen enthalten solche "praxistypischen Beispiele". Die Länge des Programmtextes gibt einen Anhaltspunkt, mit welchem Implementierungsaufwand zu rechnen ist. Die Schüler/innen entscheiden selbst, welche Spikes sie durchführen. Als "Starthilfe" kann die Lehrperson ein kleines Programm vorgeben, dass erkennen lässt, wie die Architektur des Zielsystems in etwa aussehen könnte (architectual spike). Die Schüler/innen können es ausprobieren, abwandeln und als Ausgangspunkt für ihre eigene Entwicklung verwenden.

6 Für den Chatroom dient ein Miniatursystem bestehend aus einer statischen HTML-Seite mit Formular (Abb. 1) und einem CGI-Skript (Abb. 2) als Architekturspike. Es illustriert einige Grundtechniken der CGI-Programmierung: Variablenwerte aus einem Formular übernehmen (#2), ein HTTP-Paket durch Formatierung eines konstanten Strings mit variablen Teilen erzeugen (#3), einen Variableninhalt (hier der Name des Chat-Teilnehmers) während eines Dialoges in einem Hidden-Feld verfügbar halten (#1). <html> <head> <title>chat Login</title> </head> <body bgcolor=#e0e0e0> <font face="verdana"> <h2> Welcome to our chat room</h2> Please enter your first name or a pseudonym and click on "Login"!<br> <form action=" method="post"> Name: <input type="entry" name="name" > <input type="submit" value="login"> </form> </font> </body> </html> Abbildung 1: Statische Webseite mit Formular HTML-Text und Screenshot

7 #!/usr/bin/python ANTWORT = '''content-type: text/html <html> <head><title>chat Login</title></head> <body bgcolor=#e0e0e0> <font face="verdana"> <h2> English Chat Room</h2> Thank you for coming, %s. Have a lot of fun! <form action=" method="post"> <input type="hidden" name="name" value="%s"> #1 <input type="submit" value="enter chat room"> </font></body> </html>''' import cgi form = cgi.fieldstorage() name = form.getvalue('name') #2 print ANTWORT % (name, name) #3 Abbildung 2: CGI-Skript (Python) und die von diesem Skript dynamisch erzeugte Webseite 3.5 Durchführung einer Iteration programmieren und beobachten Das Programm wird inkrementell im Verlaufe mehrerer Iterationen implementiert. Ein praktikables Maß für die zeitliche Länge einer Iteration in der Schule sind drei Unterrichtsstunden (eine Woche). Da man auch Zeit für Planungen und und andere organisatorische Dinge abziehen muss, bleiben vielleicht Minuten reine Programmierzeit, mit der man kalkulieren kann. Die Iteration beginnt mit einer Planungsrunde des Teams. Es werden noch nicht implementierte Stories der Release- Planung ausgewählt. Stories besonders hoher Priorität werden bevorzugt. Details der Funktionalität, die aus der Story nicht hervorgehen, müssen mit dem Customer geklärt und Testfälle entwickelt werden. Die erste Iteration ist ein Sonderfall. Sie sollte ein Ergebnis liefern, das in groben Zügen bereits die Architektur des Gesamtsystems erkennen lässt. Bei den letzten Iterationen spielt die Überarbeitung (Refactoring) des Programmtextes im Hinblick auf gute Performanz und übersichtliche Struktur eine zunehmende Rolle.

8 Die ausgewählten Stories werden an die Programmierpaare verteilt und von ihnen bearbeitet. Die Teams beobachten ihren Entwicklungsprozess. Dabei spielt die Uhr eine besondere Rolle. Die Schüler/innen messen, wie viel Zeit sie tatächlich für die Implementierung einer Story benötigt haben und vergleichen diesen Wert mit der zuvor geschätzten Zeit. So ermittelt das Team seine Arbeitsgeschwindigkeit (velocity) und kann in späteren Iterationen den Zeitaufwand besser vorhersagen. Pascal Van Cauwenberghe und Vera Peeters haben ein amüsantes Spiel ausgearbeitet (XP Game), in dem man in Miniiterationen von 90 Sekunden Aufwandsabschätzungen üben kann [vcp03]. Stories werden von den Programmierpaaren möglichst unabhängig voneinander implementiert. Das separat getestete Programmfragment wird direkt nach Fertigstellung in die aktuelle Version integriert (kontinuierliche Integration). Am Ende jeder Iteration steht ein lauffähiges Programm (Zwischenergebnis), das dem Customer (hier: der Lehrperson) gezeigt wird. Der Customer führt Akzeptanztests durch. Dabei können unerwünschte Eigenschaften sichtbar werden. Zu deren Beseitigung werden neue Stories geschrieben und in nachfolgenden Iterationen bearbeitet. 3.6 Test Driven Development (TDD) Beim XP beginnt man die Implementierung einer Story mit der Formulierung eines Testszenariums (Testdaten und erwartete Ergebnisse) und der Entwicklung einer Testumgebung. Diese Vorgehensweise nennt man Test Driven Development (TDD). Für Schüler, die die Semantik der von ihnen verfassten Programmzeilen erst noch lernen und noch Sicherheit bezüglich ihrer mentalen Konzepte finden müssen, ist das Testen besonders wichtig. Durch Testen wird Programmieren zum Experimentieren. Betrachten wir als Beispiel die Story 4 des Chatrooms. Sie besagt, dass Wortbeiträge, die nicht in englischer Sprache verfasst sind, unterdrückt werden sollen. Die Funktion testenglisch() im folgenden Skript prüft mit Hilfe eines regulären Ausdrucks einen Text und entscheidet ob er englisch ist oder nicht. def testenglish(s): #1 """Liefert True, wenn s einen englischen Text enthaelt, und False sonst >>> testenglish("my name is Mike") True >>> testenglish ("Wo lebst du?") False >>> testenglish ("127") True """ import re assert type(s) == type("a") reg = "[mm]y\s \sthe\s \sis\s" if re.findall(reg, s): return True else: return False

9 Das Beispiel illustriert eine einfache Möglichkeit des automatischen Testens mit dem Python-Modul doctest [We05a]. Unterhalb der Kopfzeile der Funktionsdefinition (#1) steht zwischen dreifachen Anführungszeichen ein sogenannter Docstring. Er wird normalerweise als Kommentar interpretiert und vom Laufzeitsystem übersprungen. Dieser Docstring enthält einige Testaufrufe der Funktion und in der Zeile darunter jeweils das erwartete Ergebnis. Nach der Idee des TTD formuliert man zuerst dieses Testszenarium, bevor man sich an die eigentliche Impelmentierung begibt. Nun ist es möglich die Funktion mit Hilfe des Moduls doctest zu testen. Dann wird der Docstrimg interpretiert ob alle aufgeführten Funktionsaufrufe das erwartete Ergebnis zurückgeben. 3.7 Refactoring Das Endprodukt einer Software-Entwicklung muss nicht nur die vereinbarte Funktionalität besitzen sondern auch anderen (nichtfunktionalen) Qualitätsansprüchen genügen. Dazu gehören z.b. gute Änderbarkeit und Wartungsfreundlichkeit, verständlicher Programmtext und übersichtliche Klassenstruktur. Die Idee von XP ist, dass hohe technische Qualität nicht durch ausführliche Vorplanung in einer Entwurfsphase erreicht werden kann sondern erst später im Laufe des Entwicklungsprozesses entsteht. Zur Verbesserung der Qualität muss der gesamte Programmtext immer wieder von Grund auf umgearbeitet werden. Man nennt dies Refactoring. Mit dem Refactoring ist verbunden, es keine isolierten Verantwortlichkeiten einzelner Programmierer für einzelne Module gibt, sondern der gesamte Programmtext dem ganzen Team gehört (collective ownership of code). Typische Refactoring-Maßnahmen sind Einfügen und Verbessern von Kommentaren, Umbenennen von Klassen, Methoden und Attributen oder das Aufteilen größerer Klassen in kleinere. Refactoring ist eine logische Konsequenz des Dazulernens während eines Entwicklungsprozesses. Man muss erst einmal etwas Programmtext geschrieben haben um zu erkennen, dass es auch besser geht. 3.8 Dokumentation des Entwicklungsprozesses Big Visible Charts im Computerlabor Zum XP gehört die Beobachtung und Dokumentation des Software- Entwicklungsprozesses auf der Big Visible Chart (BVC). Das ist ein großes handgezeichnetes Plakat mit Diagrammen, die verschiedene Facetten des Prozesses visualisieren. Die waagrechte Achse ist die Zeitachse; Zeiteinheit ist meist ein Tag oder eine Iteration. So kann man z.b. festgehalten, wie viele erfolgreiche und nicht erfolgreiche Tests während einer Iteration durchgeführt worden sind. Die Lehrperson kann einige Dinge vorgeben, die jede Gruppe protokollieren muss. Die Schüler sollten aber außerdem ermuntert werden, sich selbst weitere Diagramme auszudenken. Abbildung 3 zeigt ein Beispiel. Die erhobenen Daten betreffen nicht allein das Softwareprodukt, sondern auch Rahmenbedingungen, die auf den Entwicklungsprozess Einfluss haben. Dies lässt die Lehrperson rechtzeitig Probleme erkennen. Ein Team kann über ihre BVC zum Ausdruck bringen, was seine Arbeit behindert und was sie fördert.

10 Anzahl Tests pro Iteration erfolgreich nicht erfolgreich insgesamt implementierte Stories Ziel Anzahl der Tipps der Lehrerin hilfreich nicht hilfreich/ irreführend 2 fehlende Teammitglieder Abbildung. 3 Diagramme der Big Visible Chart Das Geheimnis des Erfolges der BVC liegt offenbar darin, dass sie öffentlich ist und jedermann, der den Raum betritt, ins Auge springt. Digitale Dokumentationen, die nur über das Netz erreichbar sind und erst aufgerufen werden müssen, ersetzen nicht die BVC [Je04]. 4 Fazit Development is Learning sagt Kent Beck, der Hauptprotagonist des Extreme Programming [Be03]. Eine Softwareentwicklungsmethodologie, die Dazulernen unterstützt, sollte eigentlich ein gutes Vorbild für die Gestaltung von Informatikprojekten in der Schule sein. Freilich müssen die Methoden der Profis an die besonderen Bedingungen der Schule (Zeitknappheit, Korsett des 45-Minuten-Takts, Räumlichkeiten) angepasst werden. Oder umgekehrt. Literaturverzeichnis [KP93] Koerber, Bernhard; Peters, Ingo-Rüdiger: Planungsstrukturen bei größeren Unterrichtsvorhaben - Theorie und Praxis der Planung informatischer Bildungsprozesse bei komplexen Problemlösungen. In: Login 13 (1993) Heft 6. [Be03] Beck, Kent: Extreme Programming Explained, Addison-Wesley [JAH00] Jeffries, Ron; Anderson, Ann; Hendrickson, Chet: Extreme Programming Installed. Addison-Wesley [Je04] Jeffries, Ron: Big Visible Charts. XP Magazine (XProgramming.com) [vcp03] Van Cauwenberghe, Pascal; Peeters, Vera: The XP Game [Wa02] Wake, William C.: Extreme Programming Explored. Addison-Wesley [We05] Weigend, Michael: Python gepackt. 2. Aufl. Bonn (mitp) [We05a] Weigend, Michael: Objektorientierte Programmierung mit Python. 2. Aufl. Bonn (mitp) 2005.