Posts tagged ‘eXtremeProgramming’

Buchtipp “Clean Code”

Das Buch “Clean Code” von Robert Martin stand schon eine Weile in meinem Bücherregal. Ich habe es solange aufgeschobene, weil ich für mich wenig Neues erwartete. Jetzt bin ich dann endlich dazu gekommen, das Buch zu lesen. Ich hatte vor, es zu überfliegen, weil der Inhalt für mich mit 10 Jahren agiler Programmiererfahrung nicht wirklich neu sein kann.

Wirklich neu war der Inhalt auch nicht, aber aus dem Überfliegen ist auch nichts geworden. Zum einen ist das Buch so kurzweilig geschrieben, dass das Lesen Spaß macht. Zum anderen waren doch einige Abschnitte drin, die mich überrascht und zum Nachdenken angeregt haben.

Die grundsätzliche Argumentation des Buches ist, dass man sich auch um die Kleinigkeiten kümmern muss. Das ist erstmal konträr zu dem, was ich im Studium gelernt habe. Dort war eine Hauptmotivation für Module, dass man in denen das Chaos einsperren kann. Demnach müsste man die Makrostruktur sauber halten und muss sich um die Interna der Module nicht so sehr kümmern. Klang logisch. Aber sowas habe ich in 18 jahren kommerzieller Softwareentwicklung nicht erlebt. Entweder war das System auf jeder Ebene gut strukturiert oder auf jeder Ebene vergurkt. Ich denke, das hängt mit der Einstellung der Entwickler zusammen. Entweder sie interessieren sich für Qualität. Dann tun sie das auf jeder Ebene. Oder sie interessieren sich nicht für Qualität. Dann kümmern sie sich auch nicht um eine vernünftige Makro-Struktur. Robert Martin hat also Recht: Wir müssen uns um sauberen Code auch auf Mikro-Ebene kümmern.

Nur ein Beispiel für die Überraschungen, die das Buch für mich bereit hielt Robert Martin vertritt die Ansicht, dass eine Methode mit einem Parameter schon komplex ist und wenn möglich vermieden werden sollte. Mit 2 oder 3 Parametern wird es demnach noch viel schlimmer. Zuerst habe ich gedacht “naja…”. Aber seine Argumente sind gut und er hat Recht. Viele Parameter sind in sich komplex und deuten häufig darauf hin, dass wir zusätzliche Klassen benötigen oder Methoden in andere Klassen verschoben werden sollten.

Fazit: Aus meiner Sicht ist “Clean Code” ein Must-Have für jeden professionellen Softwareentwickler – egal ob agil oder nicht. Auch alte Hasen werden Nutzen daraus ziehen können.

January 26, 2010 at 8:43 am 2 comments

Flow, Pair Programming, Teams und das Unerwartete

Ich bin jetzt endlich dazu gekommen, einen Artikel zu lesen, der schon eine Weile bei mir rumlag: “Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience” (PDF).

Auch wenn der Artikel nicht mehr ganz frisch ist, ist er dennoch sehr erfrischend. Er untersucht die Auswirkungen verschiedener Team-Organisationsformen in agilen Projekten. Zuerst belegt er die Annahme, dass Teams, die sich selbst Tasks nehmen, die effektivste Form der Arbeitsorganisation ist. Gefolgt von Teams, denen die Aufgaben zugewiesen werden, gefolgt von Individuen, die sich die Arbeit selbst nehmen, gefolgt von Individuen, die Arbeit zugewiesen bekommen. Damit ist die klassische Form der Arbeitszuweisung am wenigsten effektiv. Interessanterweise geht FDD mit seinem Class-Ownership-Konzept aber auch in diese (ineffektive) Richtung.

Richtig interessant wird der Artikel aber bei der Frage des Pair-Programming. Die Autoren haben bei sich festgestellt, dass die Enwicklung dann mit Abstand am Effektivsten war, wenn alle 90 (!) Minuten die Pair-Partner getauscht wurden. Bei wachsender Teamgröße (11 Personen) war 120 Minuten die ideale Zeitspanne, bis die Paare wieder wechseln sollten.
Das ist wirklich erstaunlich. Normalerweise geht man davon aus, dass man für hochproduktives Arbeiten im Flow arbeiten muss. Der Flow-Zustand hat aber auch Nachteile: Man braucht lange, um in den Flow-Zustand zu gelangen und wenn man drin ist, ist der Zustand fragil. Durch Unterbrechungen kann er schnell zerstört werden. Nun sagen die Ergebnisse des Papers, dass man auch ohne Flow-Zustand extrem produktiv sein kann – schließlich institutionalisiert das extrem häufige Wechseln des Pair-Partners ja gerade die Unterbrechungen. Dadurch geht man immer wieder mit einer neuen Perspektive an die Aufgabe heran (“Beginners Mind”) und kommt so auf die besten Ideen. Und das ist offenbar sehr produktiv.

Und an dieser Stelle finde ich den Artikel auf einer Meta-Ebene sehr interessant: Die Autoren haben ein “Naturgesetz” in Frage gestellt – nämlich dass hochproduktives Arbeiten nur im Flow möglich ist. Und so konnten sie etwas wirklich Neues entdecken. Respekt!

January 18, 2010 at 9:42 pm 4 comments

Artikel zu Low-Tech-Tools in JAXenter

Auf JAXenter ist ein Artikel von mir zu Low-Tech-Tools erschienen: http://it-republik.de/jaxenter/artikel/Low-Tech-Tools-2747.html

December 14, 2009 at 8:24 am Leave a comment

Buch: x-teams

Ich habe gerade das Buch “x-teams” von Deborah Ancona und Henrik Bresman gelesen.

Es geht im Buch um eine besondere Art von Teams, die sogenannten x-teams, die besonders gut in hochkomplexen Umgebungen funktionieren:

  1. x-teams sind innovativ.
  2. x-teams haben in ihrem Lebenszyklus unterschiedliche Schwerpunktsetzungen: Explore, Exploit, Export. Zunächst wird das Umfeld exploriert, um die Situation zu verstehen. Anschließend wird eine Idee oder ein Produkt ausgearbeitet und umgesetzt. Und zuletzt werden die Ergebnisse in den Markt und das eigene Unternehmen exportiert.
  3. x-teams beschäftigen sich nicht primär mit sich selbst, sondern managen stets auch die Beziehungen zu ihrem Umfeld, den Stakeholdern etc.
  4. x-teams haben wechselnde Mitglieder, abhängig von den Lebenszyklus-Phasen.

Diese Eigenschaften basieren auf Untersuchungen erfolgreicher Teams bei Microsoft, BP, P&G, etc. Bei diesen Teams handelte es sich nicht nur um IT-Teams.

Es gibt hier offensichtliche Parallelen zu Scrum oder anderen agilen Ansätzen:

  1. Scrum dient der Entwicklung innovativer Produkte.
  2. Meistens werden bei agilen Ansätzen zwei “Phasen” unterschieden: Envisioning (=Explore) und Entwicklung (=Exploit). Der Export-Teil fehlt hingegen als explizites Element. Ich habe nur sehr fragmentarisches Wissen über die Ursachen, warum eXtreme Programming bei Crysler letztlich beendet wurde. Möglicherweise hat der Export gefehlt?
  3. Scrum sieht den Product Owner als primäre Schnittstelle zur Außenwelt vor, in XP war es der On-Site-Customer. x-teams deuten darauf hin, dass wir diese Schnittstelle nicht zu strikt begreifen sollten. Alle Teammitglieder sollen und dürfen Kontakt zu Anwendern und anderen Stakeholdern haben. Es muss halt nur klar sein, wer letztlich den Geschäftswert einschätzt und die Priorisierung vornimmt.
  4. Wir weisen immer gerne darauf hin, dass Teambildung erhebliche Kosten verursachen kann und man daher nicht jeden Sprint das halbe Team austauschen sollte. Wir sollten es damit aber auch nicht übertreiben und gar keinen personellen Wechsel mehr erlauben.

Aus meiner Sicht liefert das Buch ein paar neue Erkenntnisse und Denkmodelle, aber nichts gravierend Neues. Dadurch hat es sich für mich dann auch nicht so interessant gelesen.

December 4, 2009 at 7:01 pm 1 comment

Vortrag zum inkrementellen Entwurf auf XP-Days und Scrum-Gathering

Die Präsentation zum inkrementellen Entwurf, die ich auf den XP-Days Germany in Karlsruhe gehalte habe, findet sich hier als Prezi-Flash-Präsentation.

Einen fast identischen Vortrag habe ich auch auf dem Scrum-Gathering in München gehalten. Hier ist die Prezi-Präsentation dazu.

Die Präsentationen habe ich mit Prezi erstellt. Die Vorteile von Prezi aus meiner Sicht, habe ich bereits in einem anderen Blogeintrag beschrieben.

December 2, 2009 at 11:54 am Leave a comment

Programmierkatas

Auf den XP-Days Germany 2009 fand ein Format namens “TDD mit den Profis” statt. Die Idee ist, dass Paare bestehend aus einem TDD-Profi und einem nicht so erfahrenen TDDler gegeneinander antreten. Die Paare führen in kurzer Zeit TDD und Pair-Programming vor. Bei den XP-Days hatten die Paare in der Vorrunde 5 Minuten Zeit und im Finale 8 Minuten.
Ich bin mit meiner Pair-Partnerin ins Finale gekommen, musste mich dort aber mit dem zweiten Platz zufrieden geben.

In der Vorrunde konnten sich die Paare sehr frei aussuchen, was sie vorführen. Im Finale gab es vorgegebene Code-Katas (siehe Konzept der Code-Katas siehe Wikipedia). Für die Vorrunde hatten wir mehrere Tage für die Vorbereitung Zeit, für das Finale 2 Stunden.

Code-Katas hatte ich vorher bereits programmiert. Allerdings nicht so, wie es für die XP-Days-Sessions notwendig war. In der Kürze der Zeit lässt sich nur dann sinnvoll etwas zeigen, wenn man die Übung auswendig und flüssig vorführen kann. Und dafür muss man sie einüben. Und das bedeutet, die Kata in der Vorbereitung mehrfach zu programmieren und immer wieder zu variieren, um den besten Ablauf zu finden.

Und dieses mehrfache Programmieren derselben Aufgabe war entgegen meinen Erwartungen nicht langweilig, sondern sehr interessant und lehrreich. So haben wir auf der Konferenz meine Finalaufgabe (Primfaktorzerlegung) nochmal während des Community-Day programmiert (im Rahmen eines Coding Dojos) und auf der Rückfahrt von Karlsruhe mit der Bahn nach Hamburg haben Bernd Schiffer und ich die Code-Kata nochmal programmiert.

Robert Martin hat die Code-Kata sogar zu Musik vorgeführt und damit Programmierung in die Nähe einer Kunstform gebracht.

November 29, 2009 at 9:36 pm 2 comments

Überstunden: Go oder No-Go?

Insbesondere mit dem Scrum-Commitment gibt es immer wieder Diskussionen über die ungeliebten Überstunden. Muss das Team Überstunden schieben, um sein Commitment zu halten? Diese Diskussion will ich hier aber gar nicht führen – vielleicht später. Bei der Diskussion um Überstunden habe ich häufig das Gefühl, dass es sich in der agilen Welt um eine heilige Kuh handelt. Überstunden sind ein No-Go und fertig. Tatsächlich glaube ich, dass wir uns mit dieser Haltung einer Option berauben, die man in der passenden Situation durchaus in Betracht ziehen sollte.

Und genau zu so einer Situation habe ich ein Praxisbeispiel. Wir haben vor einiger Zeit ein Projekt angenommen, in dem wir eine Webanwendung für eine Versicherung entwickeln sollten. Für das Projekt hatten wir 2,5 Monate Zeit und die Deadline war ebenso hart wie sportlich. Und da der Termin so eng war, haben wir gemeinsam im Team beschlossen, dass jeder von Beginn an soviele Überstunden macht, wie er selbst verantworten kann. Wir haben alle eine ganze Weile Überstunden geschoben. Die Menge hat aber über die Zeit abgenommen, weil wir immer sicherer wurden, dass wir den Termin halten können. Letztlich haben wir den Termin auch gehalten und es wurde eines der produktivsten und befriedigsten Projekte, an dem ich bisher beteiligt war – und das bei wirklich konsequentem TDD, sehr hoher Testabdeckung und sehr gut strukturiertem Code.
Bei der Retrospektive haben alle Teammitglieder die Überstunden-Maßnahme begrüßt. Sie wurde in einer “Jo, wir schaffen das”-Atmosphäre geboren (im Gegensatz zur sonst üblichen “Wir arbeiten soviel wir können, damit wir hinterher keinen Anschiss kriegen”-Atmosphäre). Es war also “Play to win”.

Zur Klarstellung: Ich rede hier nicht von Überstunden, die irgend jemand anordnet. Ich rede davon, dass das Team Überstunden bewusst und gewollt über einen kurzen und verantwortbaren Zeitraum einsetzt.

September 21, 2009 at 6:40 pm 1 comment

Older Posts Newer Posts