Xebia Scrum Techrally

Am 4. April 2008 haben wir wieder eine unserer vierteljährlichen Tech Rallies abgehalten. Eine Tech Rally ist, wie der Name schon sagt, eine ganztägige technische Schulung für die gesamte Softwareentwicklungsabteilung. Das Thema einer ITR kann fast alles sein, solange es technisch ausgerichtet ist oder einen Bezug zu unserer Arbeit hat. Bei früheren Tech Rallies ging es zum Beispiel um Ruby, Grails, CSS/Javascript/Ajax und Oracle-Datenbanken, um nur einige zu nennen. Dieses Mal ging es bei unserer Tech Rally um die Entwicklung des besten SCRUM-Tools aller Zeiten. Eine ziemliche Herausforderung, wenn man nur 8 Stunden Zeit hat, aber um ein kurzes Fazit zu ziehen: Die Ergebnisse waren sehr beeindruckend. Es ist eine ziemliche Herausforderung, eine Veranstaltung wie diese zu organisieren. Um den Spaß und den Teamaspekt in den Vordergrund zu stellen, wurde die Gruppe in kleinere Gruppen (von ca. 4 Personen) aufgeteilt und konnte sich die Technologien aussuchen, die ihnen gefielen.

Tagesordnung

Um die Struktur zu verbessern, wurde die folgende Tagesordnung erstellt: 9.00-9.15: Einführung 9.15-10.30: Codierung 10.30-10.45: Kleine Pause 10.45-12.00: Kodierung 12.00-13.00: Pause 13.00-15.00: Weitere Kodierung 15.00-15.15: Kleine Pause 15.15-16.00: Endgültige Programmierung! 16.00-17.30: +-15-minütige Präsentationen mit Bier, um das 'endgültige' Produkt zu präsentieren. 17.30-17.40: Rückblick Wenn sich das nach einem ziemlich engen Zeitplan anhört, haben Sie Recht: Das war es auch! Aber wenn Sie nur 8 Stunden zur Verfügung haben, brauchen Sie einen straffen Zeitplan, denn Sie werden alle Minuten brauchen, die Sie bekommen können.

Mannschaften

Die folgenden Teams wurden (im Voraus) gebildet, zusammen mit ihrem bevorzugten Technologie-Stack:

Nach einer kleinen Einführung beanspruchte jede Gruppe einen Büroraum, der als Teambasis diente, und wir begannen mit der Programmierung. Da wir alle bereits mit verschiedenen Scrum-Tools gearbeitet haben, hatten wir alle ein gutes Gefühl dafür, was wir erstellen sollten, was das Programmieren etwas einfacher und die Domäne viel leichter zu verstehen machte. Es gab keine Vorgaben für das zu erstellende Tool, was die Kreativität der Teilnehmer anregte und zu einigen interessanten Ideen führte. Nach einem ganzen Tag fanatischen Programmierens und gestärkt durch ein großartiges Sandwiches-und-Suppe-Mittagessen (Danke!) haben die Teams die folgenden Ergebnisse erzielt:

Holy Scrum Das Holy Scrum-Team hat ein Flex-basiertes Frontend entwickelt, das von einem Grails-Backend mit JMS-Kommunikation unterstützt wird und eine DSL-gestützte XMPP-Schnittstelle für die Verwaltung von User Stories enthält. Okay, wir geben zu, dass nicht alles so reibungslos funktionierte, wie wir es uns erhofft hatten (was natürlich an der knappen Zeit und einigen Problemen mit der Hibernate Proxy Serialisierung lag), aber am Ende hatten wir ein funktionierendes Flex CRUD Frontend, Datenbankpersistenz und XMPP-Empfang und -Sendung von Nachrichten. Insgesamt eine recht vollständige Anwendung, die mit etwas mehr Zeit in ein brauchbares Produkt verwandelt werden könnte. NoCRUD Das NoCRUD-Team hatte einen ganz anderen Ansatz. Während alle anderen Teams unsere normale 80%ige Abdeckungsregel ausließen, produzierte das NoCRUD-Team sogar mehr Testcode als bei einem normalen Projekt. Mit Fitnesse und rSpec erstellte das Team eine Testsuite auf der Grundlage von BDD (Behavior Driven Development). Dies führte zu einer sehr lesbaren DSL in Fitnesse sowie zu einem lesbaren rSpec Funktionstestsatz. Auf die Frage, welches Tool sie bevorzugen, lautete die Antwort natürlich: Es kommt darauf an. Allerdings mit dem Nebenvermerk, dass rSpec-Tests viel näher am zu testenden Code sind und daher leichter zu pflegen und einfacher auszuführen sind, ohne dass zusätzliche Fixtures erstellt werden müssen, auch wenn Fitnesse für Nicht-Programmierer besser geeignet sein könnte.

MudCrud Der MudCrud verfolgte einen völlig anderen Ansatz. Kein ausgefallenes Frontend, keine leistungsstarken Backends, sondern ein reines Texteingabe- und -ausgabesystem. Mit einer (für sie) völlig neuen Programmiersprache (mOO) (Zitat: "Wie schreibt man etwas in eine Liste?!?!?!? Aarghh!!") gelang es dem Team, ein Multi User Dungeon (MUD) zu erstellen, das die Navigation zwischen verschiedenen Ebenen (Projekten), die Bearbeitung von User Stories und sogar die Planung von Poker ermöglichte! Das Ergebnis war wirklich beeindruckend und es machte wirklich Spaß, es sich anzusehen, als das Team eine Demo vorführte. Scrumclipse Obwohl Scrumclipse einige Schwierigkeiten hatte, seine Mitglieder im Team zu halten, und am Ende nur zwei Entwickler hatte, gelang es ihnen dennoch, mit Eclipse RCP eine funktionierende Anwendung zu erstellen. Das RCP-Framework gibt Ihnen einen kleinen Vorsprung, indem es Ihnen eine grundlegende Benutzeroberfläche zur Verfügung stellt. Scrumclipse nutzte diesen Beispielcode zu seinem Vorteil und erweiterte die Anwendung, um die Scrum-Domäne zu behandeln. Das Ergebnis ist eine Multiview-Benutzeroberfläche mit andockbaren Panels, einem Eigenschaftseditor für die Bearbeitung von Aufgaben und einem erstaunlich grafisch gestalteten Startbildschirm der Anwendung. Wicket Scrum Das Wicket Scrum bestand hauptsächlich aus Entwicklern mit einer Leidenschaft für Wicket. Überraschenderweise bestand die gesamte Wicket-Anwendung aus einer einzigen Benutzeroberfläche mit einer Schaltfläche, die absolut nichts tat (die Schaltfläche war übrigens so konzipiert, dass sie nichts tat). Was lief hier schief? Nun, eigentlich nicht viel, aber das Scrum-Team von Wicket konzentrierte sich hauptsächlich auf die Verwendung einer OO-Datenbank (in diesem Fall db4o) und die Verwendung des SpringBuilder von Grails, um die Spring-Konfiguration zu starten. Spring Modules bietet ein Modul für die Integration von db4o und Spring, das die Integration von db4o in Ihr Projekt extrem einfach macht. Die Integration des Grails SpringBuilders in ein Java-Webprojekt erwies sich als sehr schwierig, vor allem weil der SpringBuilder keine Unterstützung für das Hinzufügen von Transaktionen in Ihrer Spring-Konfiguration bot. TechnoCrud Das TechnoCrud-Team hat sich auf Technology Driven Architecture (TDA, ein neues Paradigma?) gestürzt. Alles, was ein bisschen unternehmerisch, skalierbar oder spaßig erschien, wurde hineingesteckt. Das Team war so sehr in die Entwicklung der Anwendung vertieft, dass es keine Zeit hatte, eine PowerPoint-Präsentation vorzubereiten, aber das wurde durch eine sequenzielle Präsentation aller Teammitglieder vor Ort problemlos bewältigt! Kurz gesagt, die Anwendung basierte auf Mule, war mit Terracotta geclustert, hatte einige RMI- und (wieder!) XMPP-Schnittstellen und verfügte sogar über Exportfunktionen nach Excel. Es gab ein paar kleinere Fehler in der Implementierung, wie z.B. die Tatsache, dass man nichts einfügen konnte, aber die Demo war so überwältigend, dass wir das alle vergessen haben.

Fazit

Alles in allem hat die Art und Weise, wie wir die Tech Rallye durchgeführt haben, wirklich gut funktioniert und wir hatten eine Menge Spaß beim Hacken und Lernen, während wir an einem gemeinsamen Ziel arbeiteten. Jeder hat einige interessante Implementierungen und Ideen hervorgebracht, und sogar einige der Teammitglieder waren von den Ergebnissen überrascht! Ich bin mir sicher, dass künftige Tech Rallies noch besser sein werden als diese, aber das war eine unvergessliche Veranstaltung! Erik Pragt Die Fotos wurden von Jeroen van Erp aufgenommen. Auf seiner Flickr-Seite finden Sie weitere Fotos!