Auf zum San Francisco Marathon!

Golden Gate Bridge, aufgenommen von Rodefeld

Was ist das: Es ist etwa 2,7 km lang und ich laufe da in 67 m Höhe einmal aus San Francisco raus und dann wieder zurück? Jap, genau, in etwas mehr als sieben Tagen ist's soweit.

Am Start unseres Urlaubs hat mir Jorina erlaubt, einen Marathon zu laufen. Natürlich aus reinem Eigennutz, denn dann muss/kann ich ja nicht direkt danach so viel laufen und sie hat mehr von mir ihm Urlaub :-)

Der RunSFM, wie der San Francisco Marathon kurz genannt wird, findet am 3. August statt. Am 2. fliegen wir von Frankfurt über Seattle nach San Francisco. Mein Kollege Martin, der Business-Kasper schlechthin und vielfacher Atlantiküberquerer, der meinte, der Jetlag wird mein Freund und ich schon nachts um 3 Uhr wieder wach sein - pünktlich zum Marathonstart um 5:30 Uhr. Brrr, was für Zeiten!

20000 Teilnehmer werden dieses Jahr erwartet, wobei davon etwa 5000 den Marathon laufen werden und der Rest von 5k bis Halbmarathon. Der Start wird in Wellen erfolgen, also ein Block nach dem anderen separat gestartet werden. Ich bin im zweiten Block und werde um 5:31 h Ortszeit loslaufen können. Ganz interessant finde ich deren Zeitmess-System mit dem D-Tag. Dieses Video zeigt, wie's gehen soll:



Na, hoffentlich flattert mir das Ding nicht davon. Oder nervt beim Laufen (flap flap flap)... oh nö, das muss nicht sein.

Um 14:30 h nachmittags Mitteleuropäischer Sommerzeit, also hier in Deutschland, oder 5:30 h nachts nach Pacific Standard Time, beide Male Sonntag, 3. August, startet der RunSFM. Dann wäre ich so ab 17:30 h respektive 8:30 h mehr oder weniger nah vor oder nach der Ziellinie anzutreffen. Getrackt werden soll das Dank der D-Tags relativ zeitnah hier.

Die Strecke geht 5 Meilen (8 km) am Wasser entlang, dann über die Golden Gate Bridge (Cooles Google Maps: Ganz San Francisco ist abfotografiert, man kann quasi am Notebook durch Fort Point auf die Golden Gate Bridge "laufen"), dreht eine kleine Schleife und läuft die Brücke wieder zurück. Ab Meile 12,5 (km 20) laufe ich eine Schleife im Golden Gate Park (Schleife ist gut: immerhin mehr als 10 km), und dann geht's die restlichen 12 Kilometer quer durch die Stadt wieder zurück ans Wasser. Es gibt die komplette Route als pdf.

Persönliche Bestzeiten wird's wohl von mir nicht geben: Die Siegerzeit vom RunSFM 2007 ist nur 2:25'57 h, und es sind lediglich 35 Läufer unter drei Stunden geblieben. Die Höhenmeter sind schuld.

Ich habe endlich das Höhenprofil ausfindig machen können (auf engl. Elevation Chart oder von RunSFM auch als Altimeter, also Höhenmesser, bezeichnet, und nicht, wie ich immer gesucht habe, Topography, Altitude, Difference of Altitude oder Altitude Profile - aber das war doch klar, oder?!), und das sieht nicht bestzeitentauglich aus. Vom Start bei knapp über NN geht's bis Meile 5 (die Brücke) ganz flach. Die Brücke selbst soll 67 m hoch sein, auf dem pdf mit dem Höhenprofil kann man aber erkennen, dass es auf 260 Fuß hoch geht, also etwa 78 m. Später im Golden Gate Park, dort, wo die 10-km-Schleife gedreht wird von km 20 bis 30, da geht's über 2,25 Meilen von 60 auf 300 Fuß hoch, also 3,6 km lang von 18 auf etwa 100 m. Nicht leicht, wenn man schon einen Halbmarathon in den Beinen hat. Danach geht's aber wieder runter auf Meereslevel, d.h. die letzten 10 km sind flach. Das ist doch auch ganz nett.

Ich berichte mit Sicherheit, wie es/ich gelaufen ist/bin. Das wird allerdings wohl nicht zeitnah sein - Urlaub, ihr versteht :-)

10k im Bühlertal: Höhenschnuppern

Heute war ich beim 41.Internationalen Volkslauf-Bühlertal gestartet, und zwar beim 10-km-Lauf. Der ist gar nicht direkt im Ort Bühlertal, sondern gestartet wird bei 886 m ü. M. beim Luftkurort Hundseck, direkt an der Schwarzwaldhochstraße. Das ist für einen Wahl-Karlsruher mit nur 115 m ü. M. schon ganz schön hoch.

Eigentlich wollte ich morgens um 5:30 h aufstehen, um 6 h zu Markus fahren, Laufkollege von mir und Arbeitskollege von Jorina, dann zusammen mit ihm um 6:20 h in Ruhe in den Schwarzwald fahren, bei der Wettkampf-Organisation anmelden, umziehen, warmlaufen und um Punkt 8 h starten. Um 6:39 h bin ich aufgewacht, weil es mir verdächtig hell draußen zu sein schien...

Panik! Ursachenforschung: Handywecker hat geweckt, Handy war aber auf lautlos geschaltet. Scheiße! Pulsuhrwecker hat geweckt, habe den Arm aber unter der Decke gehabt und das Piepen nicht gehört. Scheiße! Muss Markus Bescheid telefonieren. "Kein Anschluss unter dieser Nummer!" Wah? Markus hat mir die falsche neue Handy-Nummer gegeben. Rufnummernspeicher durchwühlen, richtige Nummer finden, Markus anrufen. Markus ist noch bei sich Zuhause, wartet auf mich. Mist! Wir verabreden, getrennt zu fahren und uns am Start zu treffen. Katzenwäsche, Klamotten anziehen (gestern Abend schon bereit gelegt), Sachen schnappen (gestern Abend schon gepackt), waghalsige Manöver Richtung Autobahn einlegen. Polizeikontrolle. Neiiin! "Ich habe nichts getrunken, bin auf dem Weg zu einem Wettkampf!" Wedele mit dem Ausdruck der Google-Maps-Karte. Als ob das überzeugen könnte. Kann es, ich darf sofort weiterfahren. Komme gegen 7:40 h in Hundseck an. Wetze zur Anmeldung, bezahle EUR 6, bekomme Startnummer, wetze zurück zum Auto. Dreimal die Sicherheitsnadeln korrekt benutzt (Startnummer mit Shirt verbinden), einmal nicht (Startnummer mit Fleisch verbinden). Fluche wie ein Feldspatz. Vaseline schmieren, Autan sprühen, Tape kleben - fertig. Noch sechs Minuten, laufe mich warm auf dem Sprint zum Start...

Markus stand schon an der Startlinie und winkte mir zu. Wir hatten noch zwei Minuten, unter anderem, um das Profil abzuklären: Die 10 km wurden in einer einzigen Schleife gelaufen. Wir waren im Schwarzwald, und es wurde hügelig: Die ersten 2 km waren relativ steil bergauf, danach ging's stetig bergab, und die kleine Anhöhe vorm Ziel fiel dann schon gar nicht mehr auf. Meine Pulsuhr vermeldete allerdings nach dem Lauf nur schlappe 70 Höhenmeter - kam mir deutlich mehr vor.

Der Startschuss erfolgte und beendete abrupt meine Überlegungen, ob ich mich noch ein wenig mental auf diesen Lauf würde vorbereiten können. Ich war etwas verwirrt, stand in der zweiten Reihe, lief los wie immer - und hatte nach 500 m nur noch fünf Läufer vor und schon eine ordentliche Lücke hinter mir. Ich erinnerte mich, dass der Sprecher vor dem Start irgendetwas von zuwenig Läufern erzählt hatte, weil am Vortag eine Konkurrenzveranstaltung stattgefunden hatte. Aha, deswegen war ich also so weit vorne. (Später erfuhr ich, dass es sich um den Hardtseelauf mit den Badischen Volkslauf-Mannschafts-Meisterschaften handelte.)

Egal, ich wollte mein Rennen laufen, meinen Status überprüfen. Vor einem Jahr bin ich hier meine persönliche Bestzeit von 38'09 min gelaufen, und ich wollte mindestens unter 39 min und bestenfalls eine neue persönliche Bestzeit laufen. Immerhin möchte ich dieses Jahr noch unter 36 min kommen, nicht wahr, Matthias?!

Ab km 2 lief die Spitzengruppe, bestehend aus drei Läufern, der Verfolgergruppe, auch drei Läufer, davon. In der Verfolgergruppe war ich. Wer hier an Tour de France denkt, der liegt da gar nicht so verkehrt: Die drei da vorne setzten sich ab, wir setzten ihnen nach. Naja, also eigentlich setzten wir da gar nichts nach, noch nicht einmal etwas dagegen. Wir, Erich Feist (M50), Manfred Haas (M35) und ich, wir hatten genug mit uns selbst zu schaffen.

Bei Kilometer 3 hatte sich die Spitzengruppe so viel Abstand verschafft, dass ich nicht mehr an sie dachte und mich nur noch um meine eigene Gruppe kümmerte. Die 4. Kilometermarkierung nutzte der M50 für eine Tempoverschärfung - und ich konnte nicht mit, weil ich da gerade Seitenstechen bekam. "Na toll", dachte ich, "wieder meine Magen-Darm-Verschwörung!" Nee, war sie nicht, war wirklich nur ein paar hundert Meter Seitenstechen, die dann wieder verschwanden. Muss noch vom "Aufstieg" gewesen sein, also von den ersten zwei Kilometern.

Irgendwo zwischen Kilometer 4 und 5 gab ich dann wieder Gas. Der M50 hatte inzwischen den M35 stehenlassen, und den habe ich mir dann geschnappt. Das Überholen ging reibungslos, also visierte ich den M50 an und brauchte etwa anderthalb Kilometer zum Auf- und Überholen.

Bestandsaufnahme: Mir geht's saugut. Die Geschwindigkeit ist berauschend, es geht die ganze Zeit leicht bergab. Ob das eine neue persönliche Bestzeit wird? Fühlt sich so an. Genau sagen kann ich's nicht, hab' keinen einzigen Kilometer mitgestoppt, weil auf die anderen Läufer geachtet. Wie auf den M50 von gerade eben. Der ist jetzt schon weit hinter mir. Was nun? Mist, bin alleine, kein Ziel mehr vor Augen. Doch! Da vorne, ist das...? Ja! Das ist einer von der Spitzengruppe! Der ist ja gar nicht so weit weg, hat wohl das Tempo der anderen nicht mitgehen können. Na, dann mal hinterher, was hab' ich zu verlieren? 4. Platz ist doch blöde... Das flutscht aber heute auch wie geölt, ich komme immer näher. Kilometer 7 ist gerade vorbei, gleich bin ich bei ihm. Und dann? Argh, Taktik! Ich darf nicht hinter ihm verschnaufen, dann komme ich nie an dem vorbei und vorm Ziel überspurtet der mich. Also dran vorbeilaufen und so tun, als ob das ganz leicht wäre. Meine Beine sind schon total schwer. Jetzt bin ich dran - und vorbei. Er schaut rüber, ich nicht, gebe direkt neben ihm noch etwas Gas, jetzt bin ich an ihm vorbei. Unglaublich, aber der Abstand wird größer, fünf Meter, zehn Meter. Der ist platt, der kann nicht mehr mithalten! Da ist Kilometer 8, und der Abstand wächst. Hier ist's sehr kurvig, so dass ich mich nicht umzudrehen brauche, sondern in den Kurven zur Seite lugen kann. Und der Abstand wird immer noch größer! Aber ich freu mich noch nicht zu früh, noch ist das Ziel fern. Aber he, da ist schon das Schild für km 9. Das gibt es doch nicht, der kommt nicht mehr ran, und ich kann sogar noch drauflegen, gebe Alles auf den letzten Metern...

Ich hatte noch nie so einen leeren Zielbereich beim Einlaufen gesehen. Alles applaudierte, ich war fix und alle, und stehe zwei anderen Läufern gegenüber - den einzigen anderen im Ziel! Ob ich M35 sei, fragten sie sofort. Nein, M30, sagte ich. Da waren sie froh. Welche Plätze sie gemacht hätten, fragte ich. Den ersten und zweiten, sagten sie. Und wo sind die anderen, fragte ich. Und als sie den Kopf schüttelten raffte ich endlich, dass ich gerade den dritten Platz in der Gesamtplatzierung gemacht hatte!

Boah, was für ein Gefühl! Ich stand noch nie bei der Gesamtplatzierung auf dem Treppchen! Auf den ersten Platz lief Bernd Schillinger (M35), auf den zweiten Alexander Leuchtner (M35). Den Bruder von Bernd, Martin Schillinger, auch M35, hatte ich als letztes überholt, und da ich kein M35, sondern noch ein M30 bin, teilten sich die drei zwar nicht die Gesamtplatzierung, aber immerhin die Altersklassenplatzierung der M35. Glückwunsch an alle drei!

Zweite Freude an diesem Tag: Ich hatte meine alte persönliche Bestzeit regelrecht terminiert! Um 53 Sekunden habe ich mich von 38'09 min auf 37'16 min steigern können. 53 Sekunden! Wahnsinn! Dabei habe ich dem Gesamt-Viertplatzierten noch 14 Sekunden abnehmen können. Bin total begeistert, wie das gelaufen ist!

Meine Befürchtung nach der ersten Freude: Das ist nur ein Trost-Dritter-Platz, denn das Startfeld war nicht so pralle dieses Jahr, lediglich 114 Teilnehmer. Aber wenn man sich mal die Ergebnisse von vor zwei Jahren anschaut (die gibt's noch online bei Google): Platz 1 und 2 sind keine unbeschriebenen Bühlertal-Blätter: Vor zwei Jahren kam Alexander auf den 5. Platz, Bernd auf den 2. Platz. Und mit meiner Zeit von heute wäre ich vor zwei Jahren immerhin noch auf den 5., Alexanders, Platz gekommen. Für mich eine absolute Traumzeit!

Apropos Traumzeit: Markus kam in für ihn guten 49'55 min ins Ziel, seine, wie es gleich nach dem Lauf aus ihm herausprustete, Traumzeit. An dieser Stelle herzliche Glückwünsche an Markus!

Die dritte Freude an diesem Tage kam dann beim Warten bei Kaffee und Kuchen auf die Siegerehrung, als Markus sich in der Ergebnisliste fand und mich fragte, ob denn die 2 hinter seinem Namen tatsächlich bedeute, dass er in der Altersklasse M30 auf den zweiten Platz gelaufen sei! Ja, bedeutete sie, er war Zweitplatzierter in der AK M30 - direkt hinter mir, dem Erstplatzierten in der AK M30! Und so standen Markus und ich denn gemeinsam mit dem Drittplatzierten der AK M30, Sebastian Walter, auf dem Podest.

Ist das ein geiler Tag, oder was? Gesamt-Dritter, Alterklassen-Erster, Persönliche Bestzeit, gesund, Markus glücklich und ich erst recht. Das sind ungewohnte Höhen für mich, muss mich erstmal dran gewöhnen. Sub-36, ich komme!

P.S.: Ich bin immer noch ohne orthopädische Einlagen unterwegs! Drei Wochen nach dem 80er in Karlsruhe, bei dem ich das erste Mal seit Jahren ohne Einlagen gelaufen bin, bin ich immer noch nicht wieder rückfällig geworden. Und anscheinend tut es mir gut (siehe neue persönliche Bestzeit über 10 km :-) ). Zumindest konnte ich die letzten drei Wochen Bahntraining absolvieren, ohne Fuß- oder Hüftprobleme zu bekommen.

P.P.S.: Das war der erste Lauf für einen Verein in meinem Leben. Vor vier Wochen habe ich mich nach Vereinen in Karlsruhe umgeschaut und bin beim LSG Karlsruhe hängengeblieben. Nette Leute, von Hobbyläufern bis Elite ist alles dabei. Ich glaube, da werde ich glücklich.

Update 23.07.2008: Die von der LSG haben sich so über diesen Post gefreut, dass sie angefragt haben, ob sie ihn auf ihre Homepage übernehmen dürfen. Durften sie, und haben sie dann auch.

3. Deutschsprachiges Scrum-Meeting

Am 11.07.2008 trafen sich gut 40 Scrummer zum 3. Deutschsprachigen Scrum-Meeting in Unterföhring bei München. Dort sitzt die Allianz Shared Infrastructure Services, der IT-Dienstleister des bekannten deutschen Versicherungsunternehmens. Die versorgen momentan unter der Leitung von Simon Roberts ihre Projekte mit Scrum und waren Sponsor des Scrum-Meetings.

Das Meeting wurde im Open-Space-Format durchgeführt: Zu Anfang sammelte Krishan Matthis, der zusammen mit Simon den Tag organisiert hat, die Themen. Verteilt auf drei Räume und Säle wurde dann mit den Füßen abgestimmt, welche Themen in welchem Ausmaß gehört und diskutiert werden wollten.

Gleich zu Anfang war ich zusammen mit Hans-Peter Korn Session-Owner eines Timeslots zum Thema Teamdynamik. Hans-Peter ließ mir den Vortritt uns so trug ich zum erweiterten Tuckman-Model vor. Das Tuckman-Model zeigt Erklärungen für die Dynamik und bestimmte Phänomene innerhalb einer Gruppe auf und kann zur Kommunikation über und der Analyse von Gruppen herangezogen werden. Über die Namen der Phasen (Norming, Storming, Forming, Performing und Reforming) ist das erweiterte Tuckman-Model nach Eberhard Stahl zu großem Bekanntheitsgrad gelangt. Dazu sind die Folien online oder können gleich hier angeschaut werden:

| View | Upload your own

Nachdem ich also ein Model zur Gruppendynamik vorgestellt habe, begann Hans-Peter seinen Session-Teil mit dem George-Box-Zitat "All models are wrong; some models are useful." Das versprach nach dieser Einleitung, mindestens interessant zu werden.

Konkret stellte Hans-Peter das Cynefin-Model vor. Er zeigte daran, dass die meisten Projektsituationen statt kompliziert oder einfach und damit analysierbar, eher komplex oder chaotisch und damit gar nicht oder nur sehr schwer analysier- und regelbar sind. Soweit ich es verstanden habe, argumentierte dann Hans-Peter über den Radikalen Konstruktivismus (Wahrnehmung ungleich Realität), dass teamdynamische Modelle (wie etwa auch das Tuckman-Model) als eine Art selbst erfüllende Prophezeiung durch ihre bloße Kenntnis den Betrachter zu falschen Schlüssen leitet, so nach dem Motto "Wenn ich einen Hammer habe, dann ist alles ein Nagel." Für Hans-Peter scheint es mir so, als ob statt Regeln von umfangreichen Modellen lediglich ganz grundlegende Eigenschaften für ein Team gelten, etwa "die grundsätzliche Übereinstimmung des Teams mit dem 'Sinn' des Teams als Ganzes" (Zitat aus seinem Skript zur Session). Umfangreiches Material hat Hans-Peter online zur Verfügung gestellt.

Das ist eine für mich ungeheuer spannende Sache, und ich bin ein wenig unglücklich, dass unsere gemeinsame Session nach 90 Minuten bereits vorbei war, ohne dass wir in eine tiefere Diskussion hätten einsteigen können. So sehe ich bislang noch einen Widerspruch in Hans-Peters Argumentation, denn einerseits rät er, Abstand von Modellen im Allgemeinen zu nehmen, andererseits basiert seine Argumentation ebenfalls auf zwei Modellen, dem Cynefin-Model und den allgemeinen Eigenschaften eines Teams. Leider konnten wir auch im weiteren Verlauf des Meetings uns nicht darüber austauschen. Muss ich unbedingt noch nachholen.

Nach dem Mittag bin ich zuerst bei Simon und Krishan in einer Session gewesen, in der sie die Frage nach wichtigen Skills für einen Scrum-Master stellten und damit eine rege Diskussion in Gang brachten. Ich habe nichts mitgeschrieben aus dieser Session, kann hier keine Liste aller Skills präsentieren, und erinnere mich an Skills wie das Verstehen der Abhängigkeiten von Werte, Prinzipien, Techniken. Authentizität war ein anderer genannter Skill. Nach 45 Minuten bin ich da dann raus und in eine andere Session.

Simon Roberts wechselte auch, wollte er doch zusammen mit Boris Gloger eine Session über die Rollen in Scrum halten. Über seine neuen Rollen in Scrum hat Boris bereits vor Wochen auf der Mailingliste der Deutschsprachigen Scrum-Community geschrieben, und da habe ich ihn nicht verstanden, aber auch keine Zeit zum Nachfragen gehabt. Auf dem Meeting in Unterföhring nun hoffte ich, ein wenig Licht ins Rollendunkel zu bekommen - war aber dann höchstens ein leichtes Flackern.

Boris präsentierte zunächst seine neuen Scrum-Rollen (Model: 3+3 Rollen): Neben den ursprünglichen Rollen Product-Owner, Scrum-Master und dem Team gibt es die glogerschen Rollen End-User, Kunde und Management. Rollen, so habe ich Boris verstanden, sind für ihn Container für Verantwortung, die im Prozess, nicht in der Firma, definiert sind. Die Verantwortung für den Product-Owner ist dabei der Return-On-Investment (ROI), die des Scrum-Masters die Prozesseinhaltung, die des Teams die Produktentwicklung. Die Verantwortung des End-Users ist die Benutzbarkeit des Produktes, die des Kunden das Budget und die des Managements der Einsatz des Prozesses (Scrum eben). Zwecks Unterscheidung erklärte Boris, dass Product-Owner, Scrum-Master und das Team zusammen das Scrum-Team genannt werden (laut Ken Schwaber so auf der englischsprachigen Mailingliste vor ein paar Wochen definiert).

Boris hatte mit einigem Gegenwind aus der Zuhörerschaft zu schaffen. So wurde nicht deutlich, warum es gerade diese drei neuen Rollen sein sollten, denn es wäre stark situationsabhängig, welche zusätzlichen Rollen für einen speziellen Scrum-Anwendungsfall definiert werden müßten. Außerdem, so wurde gegen das 3+3-Rollen-Model argumentiert, würde es die Einfachheit des ursprünglichen Scrum-Rollen-Models opfern, was nach Meinung einiger überhaupt erst Scrum so populär hat werden lassen.

Mich irritierte auch der Begriff "Scrum-Team" im Gegensatz zum Team. Stelle ich mir sehr schwer in der Referenzierung bei gesprochener Rede vor: "Reden wir vom Team..." - "Welches Team meinst Du? Das Scrum-Team oder das Team-Team?" - "Das Team eben, die Entwickler." - "Ah, okay, das Team-Team also." - "Nein, nur das Team." - "Ok, aber nicht das Scrum-Team." - "Nein, nicht dieses Team." - "Sondern das andere Team?!" - "..."
Fast wie ein Monty-Python-Sketch ("Spam Spam Spam Spam...").

Simon stellte daraufhin sein Model 3+1-Rollen vor. Seine These: Ja, es gäbe weitere Rollen neben den drei ursprünglichen Scrum-Rollen, aber welche das genau seien, das wäre abhängig vom genauen Kontext. Simon war das Minimieren der sozialen Komplexität sehr wichtig. Daher bezeichnete er diese zusätzlichen Rollen insgesamt als +1 oder "others", reduziert eben auf eine einzige Rolle, die mehrere Personen umfassen kann. Damit lässt er bewußt offen, welche Rollen das sind und auch, wie viele. Er stellt lediglich fest, dass es diese zusätzlichen Rollen gibt.

Meiner Ansicht nach adressiert das 3+1-Model nicht nur die vom Publikum vorgetragenen Bedenken, sondern belässt das Scrum-Rollen-Model hinreichend einfach; daß es noch andere Rollen geben kann neben den drei ursprünglichen, ist eigentlich logisch aus Sicht eines anpassbaren Prozesses, wie es Scrum zu sein behauptet. Simon hat es lediglich einmal explizit festgestellt: 3+1.

Weg von den Rollen: Neben der Teilnahme an und der Interaktion in den Sessions gab's noch ausreichend Gelegenheit, alte Bekannte wiederzusehen, neue Mitglieder der Scrum-Community kennen zu lernen und viel Flurfunk zu lauschen. Die Organisation war wieder vom Feinsten: Danke an Krishan und Simon! Kost und Logis des Sponsors Allianz waren sehr angenehm. Insgesamt gab's sehr viel positives Feedback in der Abschlussrunde der Veranstaltung für diesen Tag.

Eine Diskussion möchte ich nicht unerwähnt lassen: Über die Scrum-Community im Deutschsprachigen Raum und die restliche deutschsprachige Agile Szene, insbesondere, aber nicht nur, die XPler. Es gibt von beiden Seiten Stimmen, die jeweils eine zurückhaltende bis ablehnende Einstellung bei der jeweils anderen Community zu sehen glauben.

Einerseits sehen einige XPler kein Entgegenkommen auf Scrummer-Seite: Da wurde ein Sessionvorschlag abgelehnt, der weitere agile Praktiken diskutieren wollte, wenn denn Scrum erstmal in einer Firma/einem Projekt/einem Team etabliert ist. Oder es wird die Zurückhaltung im Sinne von Nichtbesuch bis Nichtteilnahme von Scrummern auf bzw. an den XpDays im November diesen Jahres bemängelt.

Andererseits sehen einige Scrummer kein Entgegenkommen auf XPler-Seite: Da wird sich gefragt, warum sich keine XPler in der deutschsprachigen Scrum-Community blicken lassen. Oder warum auf den XpDays Scrum scheinbar nur eine untergeordnete Rolle spielen soll.

Einige dieser Ansichten scheinen für mich dabei auf Missverständnissen zu beruhen. So sind einige XPler bereits Teil der deutschsprachigen Scrum-Community, etwa Joseph Pelrine, der Scrummer in Europa schlechthin, und derjenige, der seine Wurzeln in XP hat und immerhin zum Gründungsmeeting der Deutschsprachigen Scrum-Community damals in Frankfurt einlud. Jens Coldewey, Urgestein der Agilen Szene, war auf dem diesjährigen Treffen dabei, und es hörte sich stark danach an, als ob es nicht sein letztes Mal sein sollte. Andreas Thiel und Fahd Al-Fatish fallen mir noch als scrummende XPler ein. Auch ich habe meine Wurzeln in XP und bin von Anfang an bei der deutschsprachigen Scrum-Community dabei gewesen.

Die XpDays sind tatsächlich von jeher scrumaffin: Vor dem Hauptkonferenztag werden z.B. CSM-Kurse angeboten, viele Scrummer nehmen an der Veranstaltung teil und es gab in der Vergangenheit auch einige Scrum-Sessions auf den XpDays. Interessant an dieser Stelle: Im Programm der XpDays des letzten Jahres gab es zwei Sessions, die explizit Scrum thematisierten - gegenüber auch zwei Sessions, die explizit XP thematisierten. Ausgeglichener kann es wohl kaum zugehen.

Tatsächlich sehe ich ein großes Problem in der Namensgebung dieser Veranstaltung, die da mit vollem Namen lautet "XP-Days - Konferenz für Entwickler und Projektmanager über eXtreme Programming und agile Softwareentwicklung". Da steckt Agile SE nur noch als Appendix im Untertitel der Veranstaltung und klammert damit - bestimmt nicht mit Absicht, aber immerhin - potentiell Scrummer aus oder stellt sie scheinbar in die zweite Reihe. Die Veranstaltung wird quasi überall nur mit "XpDays" referenziert, und da geht auch noch das letzte bisschen "agil" im Titel flöten. Es wird aus meiner Sicht Zeit für die AgileDays, damit Scrum gleichberechtigt neben XP und Chrystal und FDD und Wiesiealleheißen auftreten kann, für "Ideen, die vor allem der gemeinsamen Sache helfen."

Über das 3. Deutschesprachige Scrum-Meeting schrieben auch

• Jens Coldewey: Scrum-Gathering in München
• Boris Gloger: 3. Deutschsprachige Scrum Gathering

Weitere Infos gibt's auf dem Wiki der Deutschsprachigen Scrum-Community.

Groovy und JavaScript und die Kunst, geschweifte Klammern zu setzen

Vor ein paar Jahren bin ich in ein Projekt gekommen, in dem darüber abgestimmt werden sollte, wie die Klammern in Java zu setzen seien. Es gab zwei Alternativen: den K&R-Stil und den Allman-Stil. Das Ergebnis damals war deutlich knapp. Nach einigen Wochen Gemurre programmierte aber jeder so, wie abgestimmt wurde. Es blieb der Eindruck zurück, dass sehr viel heiße Luft erzeugt und viel produktive Arbeitszeit sprichwörtlich verbrannt worden ist.

Nach hitzigen Diskussion vor der Abstimmung (vielen war "absolut klar", was denn die einzig wahre Art geschweifte Klammern zu setzen sein müsse) wurde mir damals klar, dass es eine Frage von Geschmack und Ästethik sein müsse und nicht objektiv beantwortbar sein könne, welcher Stil besser wäre als der andere. Es gab damals einfach kein rationales Argument für den einen oder den anderen Stil. Die Argumente beruhten auf Spekulation oder subjektivem Empfinden der Beteiligten.

Die Diskussion und die Entscheidung wären vermutlich anders verlaufen, wenn wir damals in Groovy oder JavaScript programmiert hätten. Dort gibt es jeweils ein Beispiel dafür, dass der Allman-Stil nicht immer durchgängig angewendet werden kann. Da der Klammersetzungs-Stil aber gerade eine einheitliche Formatierung des Quelltextes ermöglichen soll, würde eine inkonsistente Anwendung des Stils - mal soll er eingehalten werden, mal nicht - das Aus für diesen Stil bedeuten. Schon rein praktisch stelle ich es mir sehr kompliziert vor: IDEs bieten eine automatische Quelltext-Formatierung, die bei den folgenden Beispielen entsprechende Fehler einbauen würden. Keine schöne Vorstellung.

Zu den Beispielen: Das JavaScript-Beispiel steht in Douglas Crockfords "JavaScript: The Good Parts", das Groovy-Beispiel war dann nicht schwer davon abzuleiten. Hier das von mir adaptierte Beispiel in JavaScript im K&R-Stil:

var assertEquals = function(expected, actual) {
    if(expected === actual) return;
    alert('AssertionError! Expected: <' + expected + '>, but was <' + actual + '>');
}

var foo = function() {
    return {
        key: 'value'
    };
}

assertEquals('value', foo().key);

Die erste Methode assertEquals ist ein Ersatz für JavaScripts Assertions-Losigkeit. assertEquals hier ist das, was man von JUnits assertEquals als Java-Entwickler kennt. Die Methode vergleicht einen erwarteten mit einem tatsächlichen Wert: Sind sie gleich, passiert nichts (ergo: Alles okay), andernfalls wird eine entsprechende Fehlermeldung als modaler Dialog ausgegeben. Dies ist noch nicht das eigentliche Beispiel, erleichtert aber die Lesbarkeit im Folgenden.

Die Methode foo gibt ein Objekt zurück. In JavaScript können Objekte literal durch geschweifte Klammern dargestellt werden. Das Objekt hat eine Instanzvariable key mit dem Wert value.

Die letzte Zeile ist die Zusicherung: Wenn foo aufgerufen wird, dann kann ich auf die Variable key zugreifen und erhalte den Wert value. So weit, so alles gut.

Nun formatiere ich die Methode foo nach dem Allman-Stil:

var foo = function()
{
    return
    {
        key: 'value'
    };
}

Es gibt eine Fehlermeldung in der Zeile mit dem Aufruf der Zusicherung: foo() has no properties, foo() hat keine Variable key. Warum?

JavaScript kennt das Konzept des Semicolon Insertion: Fehlt am Ende einer Zeile ein Semikolon, dann wird es dort von JavaScript automatisch hinzugefügt. Das ist vielfach praktisch, aber ungünstig beim Allman-Stil und dem return-Statement. Was da nun eigentlich steht, ist dies:

var foo = function()
{
    return;
    {
        key: 'value'
    };
}

JavaScript kümmert sich nicht um das, was nach dem return-Statement kommt, es wird ignoriert, ohne Fehlermeldung. Wenn wir foo() ausgeben, dann sehen wir den wahren Rückgabewert: undefined. Klar, dass undefined keine Variablen kennt.

In Groovy sieht's ähnlich aus. Dieses Beispiel ist im K&R-Stil formatiert:

def foo() {
    return { ->
        return 42
    }
}

assert 42 == foo().call()

Die Methode foo() gibt eine Closure zurück, die, wenn aufgerufen, 42 zurückgibt. In Groovy ist das return-Statement optional: Die letzte Anweisung einer Methode wird automatisch als return-Statement benutzt. Viele Entwickler schreiben aber gerne noch das return-Keyword hin, um explizit zu machen, dass hier etwas zurückgegeben wird.

Die Zusicherung (im Gegensatz zu JavaScript hat Groovy die schon eingebaut) erwartet 42, wenn die Closure, die foo() zurück gibt, ausgeführt wird. So weit, so alles gut.

Nun formatiere ich die Methode foo nach dem Allman-Stil:

def foo()
{
    return
    { ->
        return 42
    }
}

Es gibt eine Fehlermeldung in der Zeile mit dem Aufruf der Zusicherung: java.lang.NullPointerException: Cannot invoke method call() on null object, auf foo() kann kein .call() aufgerufen werden. Warum?

Auch in Groovy darf man die Semikolons weglassen. Und auch in Groovy wird alles nach dem ersten return-Statement ignoriert. Folglich liefert foo() den Wert null zurück, was die NullPointerException erklärt; die folgende Closure wird ohne Fehlermeldung ignoriert.

Fazit: Ich möchte hier keinen Religionskrieg um den Klammersetzungs-Stil ausrufen oder Öl ins Feuer derer gießen, die sich da bekriegen. Ich fand es nur interessant, dass der Klammersetzungs-Stil in einigen Sprachen Konsequenzen außerhalb von subjektiv empfundener Ästethik oder Benutzungsfreundlichkeit haben kann. Ich sehe diese Beispiele nicht als Argument gegen Semicolon Insertion oder (optionalen und) mehrfachen return-Statements von Groovy und JavaScript; die Vorteile dieser Eigenschaften der beiden Sprachen überwiegen die Nachteile meiner Ansicht nach deutlich.

Meine Lehre, die ich aus den Beispielen ziehe: In Groovy oder JavaScript würde ich Abstand vom Allman-Stil nehmen, weil er nicht konsistent durchgehalten werden kann.

Übrigens I: Python- und Haskell-Entwickler können wirklich froh sein, dass sie durch derartige Religionskriege nicht durch müssen; Python und Haskell ordnen Blöcke durch tiefere Einrückung unter. Eingebaute Schönheit - meinem subjektiven Empfinden nach, versteht sich ;-)

Übrigens II: Bei den Sourcen von werkannwann.de und bei denen vom Grails-Buch formatieren wir Groovy und JavaScript nach K&R mit zwei Ausnahmen:

1. Geschweifte Klammern einzeiliger Closures oder Methoden schreiben wir mit einem Leerzeichen Abstand zwischen den geschweiften Klammern und dem Inhalt in die gleiche Zeile wie den Closure-/Methoden-Inhalt. Beispiel:
   [1, 2, 3].each{ println it }
   Im oberen Beispiel würde foo() so aussehen:
   

   def foo() { return { return 42 } }

   
   Wobei wir das return-Keyword immer dort weglassen, wo es möglich ist. Dann wird daraus:
   

   def foo() { { 42 } }

2. if-, do-, while- und for-Statements schreiben wir ohne geschweifte Klammern, wenn es sich beim folgenden Block um einen Einzeiler handelt. Wenn diese Statements einen einzeiligen Block haben, dann schreiben wir ihn in die gleiche Zeile direkt nach dem Statement. Beispiel:
   

   if(guardCondition) return

Von beiden Ausnahmen machen wir recht häufig Gebrauch, da sowohl Groovy als auch JavaScript einen wesentlich kompakteren Code erzeugt als beispielsweise Java, und wir so auf relativ viele Einzeiler kommen.

[JFS 2008] Grails-Vortrag

Vorhin habe ich auf dem Java Forum Stuttgart einen Vortrag über Grails gehalten. Ich habe die Folien online zur Verfügung gestellt:

| View | Upload your own