Was bisher geschah

Vorstellung

In einem dreieinhalbstündigen Vortrag wurden die Idee, Werte und Techniken von ExtremeProgramming vorgestellt. Ursprünglich auf eineinhalb Stunden angesetzt, wurde durch viel Diskussionsbedarf der zeitliche Rahmen etwas gesprengt.

Diskussion

In der dem Vortrag folgenden Zeit wurde sehr viel diskutiert ob des Für und Widers dieser Softwareentwicklungsprozesses, oft in kleineren Gruppen, aber auch in unserem wöchentlichen Plenum.

Abstimmung

Nach der Diskussion haben wir abgestimmt, ExtremeProgramming etwa ein halbes Jahr lang zu betreiben und uns dann umzuschauen, was dabei herausgekommen ist.

Vorträge

Um die einzelnen Techniken zu lernen, haben wir weitere, vertiefende Vorträge gehalten. Dies sind folgende Techniken, wobei die Reihenfolge der Aufzählung mit der zeitlichen Reihenfolge der Vorträge übereinstimmt und von uns als wichtig erachtet wird):

PlanungsSpiel

Nach dem Vortrag haben wir hier noch eine Übung gemacht, in der wir Gruppen zu vier Leuten (je zwei waren in der Rolle als Entwickler und Kunde) mit vier nacheinander gestellten Aufgaben konfrontierten. Es waren Anforderungen, die die Kunden zu vertreten und mit den Entwicklern zu diskutieren hatten. Die Aufgaben umfassten Anforderungen, eine Art Parser für die Wiki-Notation zu schreiben. Sie bauten aufeinander auf und waren miteinander in Bezug zu bringen (Beispiel: eine Anforderung in Aufgabe 3 war es, eine Sache zu machen, die eine Anforderung in Aufgabe 2 nicht mehr erforderlich machen sollte. Die Spieler konnten davon ausgehen, daß diese Anforderung von Aufgabe 2 noch nicht implementiert wurde -> StoryCard zerreissen wäre die Lösung!). Vortrag und Übung gingen nahtlos ineinander über und dauerten etwas 4 Stunden (Pausen inklusive).

Das ganze ich sehr gut angekommen. Einige meinten sogar, daß sie eben damit die Philosophie von XP viel besser verstanden hätten. Es hat (fast) allen Beteiligten viel Spaß gemacht.

(Den Vortragenden ist dabei aufgefallen, daß, obwohl sie sich die Anforderungen gut durchdacht hatten, es doch einige ungeklärte Ungereimtheiten ergaben, die sie ganz schön ins Schwitzen brachten, als sie damit Konfrontiert wurden :-) )

ProgrammierStandards

Dieser Vortrag hatte den Sun's Java Coding Standard als Grundlage. Anhand von vielen dort beschriebenen Beispielen haben wir aufgezeigt, was es bedeuten könnte, eine Konvention bzgl. des Codes zu vereinbahren. Es war für viele eher langweilig, diesem Vortrag zu folgen, da es für sie augenscheinlich nur Kleinig- und Nebensächlichkeiten waren, die dort angesprochen wurden, trotz dem Bemühen der Vortragenden, darauf hinzuweisen, daß es eben keine Kleinigkeit ist, sich z.B. über die richtige Klammersetzung zu einigen und daß es keine EinzigWahreArtGeschweifteKlammernZuSetzen gibt.

UnitTests

Hier sind wir weniger auf die Art und Weise, wie genau man nun einen Test schreibt (Wie sieht die API von JUnit aus? Wie genau würde ich xyz testen?) eingegangen, sondern haben uns an dem Leitfaden von JohannesLinks Buch UnitTestsMitJava orientiert und das klassische Testen gegenüber dem TestFirst-Ansatz abgegrenzt. Wir haben es aber, auch aus Zeitmangel, nicht mehr geschafft, Codebeispiele zu geben, und man konnte merken, daß dies vermisst wurde. Allerdings haben wir als kleine Übung im Anschluss daran die Zuhörer gebeten, Tests für zwei Methoden zu schreiben, welche wir ans Whiteboard geschrieben haben. Dies war eine Fakultäts- und eine equals-Funktion (letztere bzgl. des in der Java-API benutzten Equals-Kontraktes) und bei beiden waren die Vortragenden überrascht, ab welcher Stufe bereits das Testen für viele als abgeschlossen galt. Umgekehrt waren die Zuhörer überrascht, wieviel man da doch testen kann. Der Vortrag dauerte etwa 2,5h.

CodeRefactoring

Anhand des RefactoringBeispiels haben wir erklärt, wie kleine Refactorings durchgeführt werden. Eine praktische Vorführung haben wir auf den geplanten Workshop verlegt. Es war eine positive Einstellung gegenüber dieser Technik vorhanden. Weiterhin gab es nur sehr wenig Diskussion, was aber auch damit zusammenhängen mag, daß wir uns vorher 4 Stunden mit der Zielfindung beschäftig haben und alle daher etwas geschlaucht waren.

Was wir gedenken, geschehen zu lassen

Workshop

Wir möchten einen Workshop machen, in dem die Projektteilnehmer lernen, testgetrieben zu entwickeln. Die Leiter dieses Workshops sind ebenfalls Teilnehmer des Projektes. TestgetriebeneEntwicklung soll hier UnitTests, CodeRefactoring, PairProgramming und EinfachesDesign umfassen. Zu UnitTests und CodeRefactoring haben die Teilnehmer bereits Vorträge gehört, während zu EinfachesDesign und PairProgramming lediglich vage Vorstellungen bestehen, welche wir aber glauben, anhand konkreter Dinge (Code!) besser erklären zu können als anhand von Argumenten.

Der Workshop ist erstmal auf 4h angesetzt, wir gehen allerdings jetzt schon davon aus, einen Workshop II aufzusetzen. Da wir über viel zu wenig Projektrechner verfügen, werden wir auf private Notebooks ausweichen, möglichst mit separater Tastatur zwecks besserem PairProgramming. Wir gehen davon aus, keine einheitliche Entwicklungsumgebung vorzufinden. Ein Notebook samt Beamer steht den Leitern des Workshops zur Verfügung, an dem alles vorgeführt werden kann.

Der gedachte Ablauf:

Teilnehmer zu Paaren sich finden lassen

Die Workshopteilnehmer sollen sich zu Paaren zusammenfinden. Es wird dabei angemerkt, daß die nun entstehenden Paare des öfteren während des Workshops getauscht werden sollen. Letztere Erwähnung erfolgt auch deswegen, damit weniger akzeptierte Projektteilnehmer mit akzeptierteren und schlechtere Programmierer mit besseren sich zusammenfinden (im Hinterkopf behaltend, daß dies ja nie von Dauer sein wird!).

IDE und Sprache in Betrieb nehmen

Wir haben uns im Projekt noch auf keine Sprache geeinigt, da wir erst unsere Zielfindung abwarten möchten. Anhand mehrerer Umfragen hat sich aber zweifelsohne die SpracheJava und die SpracheCpp als die Favoriten herausgestellt. Alle Teilnehmer dieses Projektes verfügen über mehr oder minder ausgeprägte Erfahrungen in beiden Sprachen, da diese im Grundstudium gelehrt wurden. Einen entsprechenden Auffrischungskurs zu veranstalten ist in Diskussion (vielleicht sogar noch vor diesem Workshop).

Die IDE richtet sich nach der Sprache und wird an diesem Tag den meisten der Teilnehmer das erste Mal vorgestellt werden. Wir möchten eine einheitliche Arbeitsumgebung schaffen, um keine Reibung beim ständigen Wechsel der Arbeitsumgebung zu schaffen (die entsteht schon genug dank uneinheitlicher Hardware). Bei der SpracheJava möchten wir die IntelliJ IDEAEntwicklungsUmgebung einsetzen, bei der SpracheCpp die EclipseEntwicklungsUmgebung. "möchten einsetzen" meint, daß wir Entwicklungsumgebung und Sprache gemeinsam installieren und konfigurieren wollen.

CodingStandard einstellen

Wegen des ProgrammierStandards wollen wir eine vorläufige Einstellung in den IDEs gemeinsam vornehmen.

Projekt für eine Aufgabe aufsetzen

In der IDE wollen wir gemeinsam einstellen, was notwendig ist, um eine Aufgabe bearbeiten zu können. Damit erhoffen wir uns auch, die Entwicklungsumgebung besser kennen zu lernen.

Aufgaben bearbeiten

In verschiedenen Aufgaben wollen wir TestgetriebeneEntwicklung lernen (endlich :-) ). Die Aufgabe wird von den Leitern des Workshops vorgestellt und Fragen dazu beantwortet. Da sich bekanntlich XP-Neulinge schwer tun, erst den Test zu schreiben, werden wir gemeinsam am Beamer die ersten Schritte mit UnitTests machen, welche dann jedes PairProgramming-Team für sich nacharbeiten kann. Wenn die Teilnehmer die erste Dosis Tests verkraftet haben, wollen wir bereits stetig CodeRefactoring praktizieren, das Design vereinfachen und darauf achten, das die ProgrammierStandards eingehalten bzw., falls notwendig, angepaßt werden. Wir wollen viel darüber reden, was wir gerade tun.

Nach der Aufgabe, die mehr oder minder als erstes reibungslos über die Bühne gegangen sein wird (dies ist dann der Fall, wenn nur noch vereinzelt Teams Probleme und/oder Fragen haben), werden wir die folgenden Aufgaben stellen und erwarten, daß die Teilnehmer sie selbstständig versuchen zu lösen. Die Leiter des Workshops werden die Zeit nutzen, in der Rolle des Coachs einzelnen Teams direkte Hilfestellung zu geben. Anschließend vergleichen wir die Ergebnisse und Erfahrungen.

Die Aufgaben im einzelnen sollen sein:

• Fakultät berechnen
• equals für ein Objekt mit einem Attribut laut Java-Kontrakt implementieren
• Wiki-Parser schreiben? (wenn ja, dann unterteilt in mehrere Teilaufgaben)
• ...

Die Aufgaben wurden unter anderem im Hinblick darauf ausgewählt, daß es Aufgaben sind, die in den Vorträgen zum PlanungsSpiel und den UnitTests als Beispiele benutzt wurden und somit den Teilnehmern bereits bekannt sein sollten, was wiederum die Hemmschwelle etwas herabsetzen könnte. Allerdings tun wir uns mit der Auswahl von Aufgaben relativ schwer (siehe Fragen).

Fragen

Bzgl. dem geplanten Workshop:

• Wie könnte das Vorgehen beim Workshop verbessert werden? Wie wird im allgemeinen ein Workshop aufgebaut? Hat jemand grundlegend andere Erfahrung bzgl. Workshops gemacht?
• Welche Aufgaben könnten wir beim geplanten Workshop stellen? Hat da jemand konkrete Erfahrung, welche sich da gut eignen würden und wäre bereit, sie uns hier mitzuteilen?
• Prinzipiell eignen sich insbesondere Aufgaben mittlerer Komplexität, bei denen man sofort eine grobe Vorstellung hat, wie man das machen könnte, mit der sich aber wahrscheinlich noch niemand ausführlich auseinandergesetzt hat. Konkrete Beispiele die ich kenne:
• Römische Zahlen Parser: Haben wir selber einmal als Einführung in TestgetriebeneEntwicklung benutzt. Hier zeigt sich sehr schön, wie Testfall für Testfall durch das geschickte Erkennen und Entfernen von Duplikation sich aus der Behandlung von Einzelfällen ein eleganter, tabellenbasierter Algorithmus entwickelt. Nachteil ist, dass es kein Zusammenspiel mehrerer Klassen zu untersuchen gibt.
• Bowling Game Score Card: Ein Beispiel aus AgileSoftwareDevelopment PrinciplesPatternsAndPractices (auch einzeln herunterladbar von http://www.objectmentor.com/resources/listArticles?key=topic&topic=Test Driven Development). Hier ist sehr schön zu sehen, dass ein EinfachesDesign vollkommen anders ausfallen kann, als man sich das anfangs vielleicht vorgestellt hat.
• Money Bag: Das klassische Beispiel aus dem JUnit Cookbook, ganz ausführlich in TestDrivenDevelopmentByExample behandelt. Zeigt schön das Entstehen der API aus Client-Sicht und das Entstehen von neuen Klassen. Als Thema aber vielleicht ein bisschen trocken.

• Auch interessant finde ich die TestFirstChallenge? von BillWake? ( http://www.xp123.com/xplor/xp0201/index.shtml) - er gibt hier die Tests vor und stellt die Aufgabe, sie entsprechend Schritt für Schritt zu erfüllen. Vielleicht könnte man die Idee für den Workshop aufgreifen, indem man anfangs noch den gesamten Zyklus gemeinsam durchgeht, bald nur noch die Tests gemeinsam bespricht und das Implementieren den einzelnen Gruppen überlässt, bis man schließlich ganz auf Eigenarbeit übergeht? -- IljaPreuß

Diskussion

wurde durch viel Diskussionsbedarf der zeitliche Rahmen etwas gesprengt.

 --> XPVortragenDiskussion