[OOP 2009] Vortrag Agile Planung – Vom Schätzpoker zum Geschäftsmodell

Vortrag Agiles Schätzen und Planen (Photo: Oliver Wihler)„Zu agilen Planverfahren ist eigentlich schon alles gesagt“ meinte Stefan Roock kürzlich auf der Eröffnung der XP Days und nur wer in den vorderen Reihen saß, konnte das ironische Blitzen in seinen Augen sehen. In der Tat stelle ich in Workshops und Diskussionen immer wieder fest, dass den wenigsten die volle Bandbreite agiler Planung bewusst ist. Viele wissen noch, wie man Planungen robust macht gegen Schätzfehler und unvorhergesehene Ereignisse und manch einer beherrscht auch noch selbst-adaptierende Schätzverfahren. Aber Techniken zur langfristigen Vorhersage oder Aussagen zur Wahrscheinlichkeit, dass bestimmte Planungspunkte auch wirklich abgeschlossen werden, sind weithin unbekannt. Dabei erlaubt der Werkzeugkasten agiler Planung nicht nur recht zuverlässige kurzfristige Vorhersagen, sondern bietet bis hin zur Entwicklung neuer Geschäftsmodelle vielfältige Möglichkeiten.

Dieses Spektrum werde ich in meinem Vortrag „Agile Planung – Vom Schätzpoker zum Geschäftsmodell“ auf der OOP in München am 29.1. ab 17:00 Uhr beleuchten. Ich werde zunächst die Basis agiler Schätz- und Planungsverfahren vorstellen und mich dann über mögliche Erweiterungen bis zu Geschäftsmodellen vorarbeiten. Leider kann man das Thema in 60 Minuten nicht erschöpfend behandeln. Ein paar Anregungen und neue Ideen können Sie aber sicher mit nach Hause nehmen, egal ob Sie Projektleiter(in), Scrum Master(in), Fachverantwortlich(e), Product Owner, oder ganz normales Teammitglied sind. Nur über Agilität sollten Sie schon ein wenig gehört haben.

Falls nicht, empfehle ich Ihnen eher den ganztägigen Workshop „Agile Praxis erleben„, den Henning Wolf, Bernd Schiffer und ich gemeinsam am Freitag auf der OOP abhalten werden.

Nachtrag: Mittlerweile sind auch die Feedbackbögen der XPDays in Hamburg ausgewertet (an dieser Stelle noch mal Danke an Arne Roock für die super Organisationsarbeit!). Der Vortrag wurde dort auf einer Skala von +2 bis -2 mit 1,9 bewertet und errang damit Platz 1 von allen Bewertungen. Danke an alle, die mitgeholfen haben, das möglich zu machen, insbesondere Bernd Schiffer! Zitate aus den Feebackbögen:

  • sehr konkret und konzentriert, guter Inhalt
  • regt zum Nachdenken an
  • gute Vortragsweise, super, sehr beeindruckend, viele neue anregungen

Das Photo stellte freundlicherweise Oliver Wihler zur Verfügung

Teamdynamik und Psychologie

Auf den XPDays in Hamburg stellte die Pychologin Maud Winkler das Tuckman-Modell der Teamentwicklung vor (genau genommen, das erweiterte Tuckman-Modell von Eberhard Stahl, das dieser in seinem Buch „Dynamik in Gruppen“ vorstellt):

  • Forming
  • Storming
  • Norming
  • Performing
  • Reforming

Die vierte Phase ist die produktivste Phase (wobei man hier vorsichtig sein muss, diese Phase nicht als konfliktfrei zu verstehen, nur werden hier Konflikte produktiv genutzt). Das Durchleben der anderen Phasen ist jedoch notwendige Voraussetzung dafür, dass das Team bei Performing gut arbeitet. Nicht erledigte Aufgaben aus den vorigen Phasen bleiben als Störfaktoren liegen und behindern das Team in der Arbeit. Um das Modell halbwegs realistisch zu gestalten, hat Eberhard Stahl das ursprüngliche Modell um eine iterative Komponente erweitert, die von Frau Winkler sehr betont wurde.

Dieses Modell erlaubt einen interessanten Blick auf agil geführte Teams. In diesen Teams werden regelmäßig Retrospektiven abgehalten, in denen sich das Team in eine Reflexionsphase begibt. Im Sinne des erweiterten Tuckman-Modells wird das Team also in regelmäßigen Abständen wieder in die Reformingphase „gestürzt“, die im Rahmen der Retrospektive bis zum Norming geführt wird. So werden sachliche und zwischenmenschliche Probleme auf einen klaren Zeitpunkt konzentriert, statt ständig im Untergrund zu rumoren.

Das bedeutet aber auch besondere Anforderungen an die Kompetenz des Moderators einer Retrospektive: Wer hier die Teamsituation falsch einschätzt oder angezeigte Interventionen unterlässt oder überspitzt, bewirkt bestenfalls, dass die „unproduktiven“ Phasen während der Retrospektive nicht abgeschlossen werden und das Team weiter behindern. Schlimmstenfalls wird das Team gesprengt. Hier hilft ein erfahrener externer Moderator, der auch über den dafür notwendigen psychologischen Werkzeugkasten verfügt.

(Um einer Kritik an dem Modell zuvorzukommen, die Joseph Pelrine auf der Konferenz geäußert hat: Das Modell versucht weder einen Prozess zu beschreiben, noch erhebt es den Anspruch auf einzige Wahrheit. Es dient lediglich dazu, Anhaltspunkte für geeignete Intervention eines Leiters oder Moderators zu geben. Es ist also kein „RUP der Teamdynamik“, sondern eben „nur“ ein psychologisches Modell, das ähnlich wie die einschlägigen Kommunikationsmodelle in bestimmten Situationen helfen kann, die aktuelle Situation zu verstehen. Zudem scheint mir das erweiterte Tuckman Modell wesentlich realistischer, als das recht lineare Original, auf das sich Joseph bezog).

Notizen von der OOPSLA – Refactoring Werkzeuge

Einmal im Jahr gönne ich mir den Besuch der OOPSLA. Zum einen, um Bekanntschaften und Freundschaften zu pflegen, aber auch, um einen Überblick zu bekommen, was derzeit an (wirklich) neuen Dingen aufkommt, abseits der aufgeregten Marketing-Hypes. Ich möchte hier über für mich interessante Erkenntnisse berichten.

Am ersten Tag entschloss ich mich kurzfristig, als Zuhörer am zweiten Workshop über Refactoringwerkzeuge teilzunehmen. Eine Entscheidung, die sich gelohnt hat, obwohl ich normalerweise „Präsentationsworkshops“ meide. Der Workshop hat einen guten Überblick über den aktuellen Stand der Forschung zum Thema Refactoring gegeben — und deutlich gemacht, dass wir hier erst am Beginn einer Entwicklung stehen, die unsere Arbeit über die nächsten Jahre wesentlich beeinflussen wird.

Zu den Vorträgen:

Refactoring bei IntelliJ

Dimitri Jemerov von JetBrains (IntelliJ, Resharper) stellte die Mechanismen hinter den Refactoring Browser von IntelliJ IDEA vor. Er basiert auf einem gemeinsamen „Refactoring Workflow Framework“, mit dem sich die einzelnen Operationen relativ einfach implementieren lassen. Jemerov sprach von einer „Refactoring DSL“, die bei IntelliJ dafür entwickelt wurde.

Während die Grundlagen relativ gut standardisierbar sind (und die vorgestellten Ideen auch entsprechend wenig überraschend), liegt der Teufel und damit auch der Aufwand im Detail. Hier diktiert die Sprachkomplexität auch die Komplexität des Refactorings. Gerade bei Java mit seinen Einschränkungen was wo erlaubt ist, führt das beim Refactoring gelegentlich auch zu Ergebnissen, die nicht gerade schön sind. Die Begründung war pragmatisch: Normalerweise wird refaktorisierter Code nicht mehr überprüft. Daher muss er zu 100% korrekt sein, auch wenn das Ergebnis nicht gerade elegant ist.

Interessante Features von IntelliJ, die er vorstellte, waren:

  • Extract Method bei mehreren Ergebniswerten: Hier werden komplette Klassen erzuegt und extrahiert.
  • Refactorings über mehrere Sprachen: Während der aktuelle Stand (Rename, Move) noch nicht so aufregend ist, wird derzeit daran gearbeitet, die interne Darstellung sprachübergreifend zu gestalten, um auch komplexe Refactorings sprachübergreifend zu ermöglich. Geplant ist Unterstützung von Java, Ruby, Groovy, Python und XML (wenn ich keinen vergessen habe…)
  • Veränderung von Typen: Als Beispiel ersetzte Dimitri ein Array durch eine Liste, ein Beispiel für ein ziemlich komplexes Refactoring, das auch nur teilautomatisiert möglich ist. Leider reichte die Zeit nicht aus, das im Detail darzustellen.

Die anschließende Diskussion kreiste vor allem um den Konflikt zwischen 100% korrektem Umbau des Codes, eleganten Ergebnissen und Unterstützung des Entwicklers. Es dürfte hier kaum möglich sein, den richtigen Weg zu finden.

Oberflächen für Refactoring Werkzeuge

Dustin Campbell, der vor wenigen Monaten von DevExpress (Refactor!) zu Microsoft wechselte, demonstrierte aktuelle Entwicklungen in der Oberfläche von Refactoring Werkzeugen am Beispiel von Refactor!. Der Trend geht dahin, den Browser nahtlos in den Editor zu integrieren: Keine Dialogboxen mehr, keine Sammlungen von Shortcuts, statt dessen kontext-sensitive Erweiterungen des Editors. Wer mit Eclipse arbeitet, kennt ähnliche Ansätze bereits vom Umbenennen eines Identifikators: Drückt man vor dem Editieren eines Identifikators eine bestimmte Tastenkombination, werden auch alle anderen Vorkommen umbenannt. Refactor! treibt diesen Ansatz wesentlich weiter: Das Werkzeug ist darauf optimiert, mit einem einzigen Shortcut kontextsensitiv zu arbeiten.

Die Demonstration war beeindruckend, hier wurde ziemlich sicher die derzeit beste Lösung für die Oberfläche des Werkzeugs präsentiert. Ob die dahinter liegenden Mechanismen mit den Anforderungen großer Systeme mithalten können, weiß ich nicht. Ebenso wenig ist mir klar, ob diese Art der Oberfläche für Umbauten an großen Systemen noch adäquat ist, insbesondere in Situationen, in denen bewusst nicht-vollständige Refactorings eingesetzt werden sollen. Das lässt sich sicherlich nur durch praktischen Einsatz herausfinden (Bekannt ist, dass Refactor! für C++ erhebliche Stabilitätsprobleme hat. Die Versionen für C# (und andere .NET Sprachen) scheinen nicht so extrem unter diesem Problem zu leiden). Unabhängig davon ist die enge Integration von Editor und Refactoring sehr interessant (sie war genau genommen bereits in John Grants und Don Roberts „Ur-Refactoring-Browser“ angelegt) und ich hoffe, dass sie sich auf breiter Basis durchsetzen.

Werkzeuge zur Entwicklung von Refactoring Werkzeugen

Dieser Teil des Workshops richtete sich naturgemäß eher an jene, die selbst Refactoring bauen, als an deren Anwender. Ich fand die Vorträge dennoch interessant, weil sie einen guten Eindruck liefern, mit welchen Problemen derzeit gekämpft wird und was uns die Zukunft hier bringen kann.

Verbesserung der Analyse

Max Schäfer von der Oxford University stellte eine Refactoring Engine vor, die sich vor allem um Namensprobleme kümmert, um sicher zu stellen, dass die verbreiteten Probleme, die Refactoringwerkzeuge mit Verschattung von Namen haben. Aus Anwendersicht war die Nachricht interessant, dass keines der marktüblichen Werkzeuge hier wirklich sauber arbeitet. Es lohnt sich also weiterhin, darauf zu achten, dass man die Verschattungsregeln der Sprachen nicht zu sehr ausreizt — eine Regel, die schon im Interesse der Lesbarkeit von Programmen sinnvoll ist.

Framework für den Bau von Refactoring Werkzeugen

Jeffery Overbey, ein Diplomand von Ralph Johnson an der Univerity of Illinois, Urbana Champaign, demonstrierte einen Ansatz, die für brauchbares Refactoring notwendigen Syntaxbäume aus speziellen Grammatiken zu erzeugen. Sein Demonstrationsobjekt war ein Transformationswerkzeug für Fortran-Programme. Hier ging es eher im Detailprobleme, die eher für Werkzeugbauer von Interesse sind, wie zum Beispiel der Umgang mit Kommentaren und Einrückungen, Themen die im klassischen Compilerbau kaum eine Rolle spielen, für die Akzeptanz von Refactoring Werkzeugen aber entscheidend ist. Der Vortrag hat schön gezeigt, dass Refactoringwerkzeuge derzeit eine ähnliche Entwicklung durchmachen, wie Compiler in den 70er Jahren. Das halte ich durchaus für einen Grund, sich auf die Werkzeuge der nächsten zwanzig Jahre zu freuen 🙂

Refactoring auf höherer Ebene

Macneil Shonle von der University of San Diego stellte ein Plug-in für Eclipse vor, das versucht, Java Refactorings auf höherer Ebene umzusetzen (Arcum). Auch wenn sich der Vortrag eher um Grundlagenforschung drehte, zeigte er doch, dass zumindest die angelsächsischen Universitäten mittlerweile den Ball aufgenommen haben und an den komplexen Problemen wie Migrationen von Bibliotheken forschen. Sollten diese Arbeiten für den professionellen Einsatz reif werden — womit ich nicht in den nächsten zehn Jahren rechne —, könnte das den Umgang mit Architektur und Bibliotheken ähnlich revolutionieren, wie die derzeitigen Werkzeuge den Umgang mit Code und Design verändert haben.

Analyse des Refactoring von Entwicklern

Emerson Murphy-Hill von der Portland State University berichtete über Strategien, um herauszufinden, welche Refactorings an einer Codebasis durchgeführt wurden. Auch er stellte noch mehr Fragen vor, als Antworten. Ziel ist die Verbesserungen von Refactoringwerkzeugen, das Thema kann aber auch relevant werden, um Dokumentations- und Revisionsanforderungen zu erfüllen, oder in Wartungssituationen den Code zu verstehen. Zweifel sind aber angebracht: Murphy-Hill stellte fest, dass nur ca. 10% der Refactorings mit Werkzeugen durchgeführt werden und nur etwa ein Drittel sich überhaupt im Versionsmanagement niederschlagen. Sein Resümee: Wir kennen (noch) keine zuverlässige Methode, durchgeführte Refactorings zu ermitteln.

Zum Nachdenken hat auch eine Erkenntnis am Rande angeregt: Deutete ein Check-in in das Versionsmanagement einen Kommentar, der auf Refactoring hindeutet, war die Anzahl der darin enthaltenen Umbauten halb so groß [sic!], wie bei Check-ins ohne solche Kommentare. Es wäre interessant, ob sich das auf die Zuverlässigkeit von Check-in-Kommentaren verallgemeinern lässt.

Refactoring Lab

Josh Kerievsky, Autor des Buchs „Refactoring to Patterns“ und Gründer von „Industrial Logic„, zeigte den Einsatz seines „Refactoring Labs“, eines Trainingswerkzeugs für Refactoring. Die Studenten werden vor eine Refactoringaufgabe gestellt und das Lab analysiert den gewählten Lösungsweg und macht Verbesserungsvorschläge, z.B. dass bestimmte Schritte, die manuell gemacht wurden, einfacher im Refactoringbrowser durchgeführt werden können. Die Regeln sind als JUnit-Tests hinterlegt und überprüfen z.B. wie oft die Tests gestartet wurden und welche Optionen beim Umbau eingesetzt wurden. Ein sehr nettes Werkzeug für die Schulung.

Refactoring für Nebenläufigkeit

Der Organisator Danny Dig berichtete über seine Arbeiten am MIT, in denen er versuchte, sequenziell geschriebenen Code in Code umzustellen, der die Java 5 Unterstützung für Nebenläufigkeit nutzt. Das Werkzeug heißt Concurrencer und ist als Eclipse-Plugin verfügbar. Die Wirksamkeit des Tools wurde mit 6 Open Source Projekten überprüft. Die Ergebnisse waren zwar nicht perfekt, aber deutlich besser, als die manuellen Umstellungen der Entwickler, die die entsprechenden Werkzeuge betreuen. Immerhin machte das Werkzeug keine Fehler, die zu Fehlfunktionen der Software führen können — im Gegensatz zu vier solchen Fehlern im offiziellen, manuell umgestellten Code. Als wichtige Richtung für die zukünftige Entwicklung wurde die Integration mit Analysewerkzeugen angesprochen: Deren Ergebnisse sollten die Entwickler durch die notwendigen Schritte leiten.

Wer vor dem Problem steht, Java Code threadsafe zu machen, sollte sich das Tool genauer ansehen.

Refactoring von Programmen zur Matrixmanipulation

Beverly Sanders von der University of Florida erzählte über den Einsatz von Refactoring in der algebraischen Chemie. Dabei werden chemische Reaktionen simuliert, was im Wesentlichen darauf hinausläuft, Lösungen für die Schrödingergleichungen zu finden. Die Programme laufen auf hoch-parallelen Supercomputern mit speziellen DSLs für Matrizenumformungen. Hier wird Refactoring nicht zur Verbesserung des Designs eingesetzt, sondern um die Performance und Ausführungskomplexität zu verbessern. Das geht oft nicht durch pures Ansehen, sondern auf der Basis von Messungen. Für mich war die Einsicht spannend, dass man Refactoring auch in zunächst anderen Domänen mit ganz anderen Zielen betreiben kann. Der Schluss liegt nahe, dass wir hier erst ganz am Anfang stehen.

Resümee

Refactoring steht erst am Anfang. Sowohl für die Werkzeuge im breiten Einsatz, als auch in Randthemen besteht noch erheblicher Forschungsbedarf, der zunehmend von den Universitäten auch angegangen wird. Aus Sicht des Praktikers kann man nur hoffen, dass sich diese Forschung so bald wie möglich in breit einsetzbaren Produkten niederschlägt. Das könnte die Art, wie wir programmieren weg vom Programme schreiben hin zu Software entwickeln revolutionieren — vorausgesetzt, die Ausbildung wird auch entsprechend angepasst.

XPDays in Hamburg: Eintägiger Workshop „Agilität erleben“

Ich freue mich, im November gemeinsam mit Bernd Schiffer und Henning Wolf von it-agile im Rahmen der XP Days in Hamburg einen eintägigen Workshop „Agilität erleben“ anbieten zu können. Der Workshop ist vor allem für jene gedacht, die sich Agilität bisher eher vorsichtig genährt haben, oder sich nur aus Büchern, Zeitschriften und Blogs informiert haben und nun „gefahrlose Praxis“ suchen; und für jene, die bisher nur agile Entwicklungspraktiken einsetzen und jetzt ihre Leistung auch „auf die Straße“ bringen wollen.

Einen Tag lang haben Sie die Gelegenheit, die wichtigsten Praktiken agiler Teamarbeit und agilen Projektmanagements am eigenen Leib zu erleben – in einer „Entwicklungsumgebung“, die Sie unter Garantie beherrschen. Wir haben den Tag vollständig powerpointfrei gestaltet, schließlich sollen Sie Agilität erleben und nicht von uns überredet werden.

Was werden Sie erleben?

  • Agile Planung
  • Agiles Anforderungsmanagement
  • Querschnittsteams vom Fachexperten bis zum Tester
  • Entwicklung nach Nutzen
  • Agiles Controlling
  • Retrospektiven

Innerhalb eines Tages kann man natürlich nicht nach den Sternen greifen, aber wir versprechen Ihnen ein paar bleibende Eindrücke — und dass wir garantiert innerhalb unseres Sonnensystems bleiben…

Der Workshop findet am Donnerstag, 27.November 2008 in Hamburg statt. Weitere Informationen und die Anmeldung finden Sie auf den Webseiten der XP Days 2008: http://www.xpdays.de/2008/sessions/praxis_erleben.html. Frühzeitige Anmeldung lohnt sich: Die Teilnehmerzahl ist begrenzt!

PS: Wer Ende November keine Zeit hat, nach Hamburg zu kommen, oder keinen Platz mehr bekommet, hat im Januar auf der OOP 2009 in München noch eine zweite Gelegenheit. Ich werde den Workshop separat ankündigen, sobald das OOP-Programm veröffentlicht ist.

Videocast zu Einführung agiler Entwicklung

Am Rande der OOP 2008 hat mich Damir Tomicic für die Microsoft Architects Connection zur Einführung agiler Entwicklung interviewt. Das Interview ist jetzt als 30-minütiges Videocast verfügbar:

Einführung agiler Entwicklung – Ein Resümee aus 10 Jahren Erfahrung.

Weitere Interviews mit anderen Referenten finden Sie in der OOP 2008 Nachlese der MAC.

Workshop „Einführung in agile Entwicklung“ in Bern

Vielleicht gehören Sie zu denen, die einiges zu agiler Entwicklung gelesen haben, die manches interessant finden, anderes eher skeptisch sehen und die im Großen und Ganzen noch nicht so recht wissen, was Sie davon halten sollen. Wenn Sie Lust haben, einen Tag dafür zu investieren, agile Entwicklung zu erleben, sollten Sie darüber nachdenken, am 28. April zur SEE 2008 in Bern zu kommen.

Sie haben dort Gelegenheit, agile Techniken zu erleben und zum Teil auch auszuprobieren. Gemeinsam mit Bernd Schiffer von it-agile werde ich die Grundlagen agiler Entwicklung vorstellen, Sie werden ein „Mini-Projekt“ selbst mit agilen Managementtechniken durchführen und können am praktischen Beispiel verfolgen, wie testgetriebene Entwicklung und Refaktorisieren in der täglichen Arbeit ablaufen.

Nähere Informationen finden Sie unter http://www.see-conf.de/workshop_agile.html

CfP für EuroPLoP Pattern-Konferenz

Bis zum 18. Februar ist noch Zeit, seine persönlichen Pattern-Versuche für die EuroPLoP 2008 in Irsee einzureichen. Ziel der Konferenz ist die Unterstützung von Pattern-Autoren und solchen, die es werden wollen. Jeder Autor erhält zunächst einen erfahrenen Patter-Autoren, einen „Shepherd“, beseite gestellt, der Hinweise und Tipps gibt, wo das Papier verbessert werden kann. Bis zum 18.4. hat man Zeit für einige Iterationen, dann wird entschieden, ob das Papier in einen „Writer’s Workshop“ kommt, also in einer Gruppe auf der Konferenz noch einmal gereviewt wird, oder ob der Autor auf dem Konferenz selbst weiteres Shepherding erhält.

Die EuroPLoP ist eine einzigartige Konferenz, die vollständig darauf ausgerichtet ist, Kontakte zwischen den Autoren zu knüpfen. Die Teilnehmerzahl ist auf 60 Personen begrenzt. Die meisten (guten) europäischen und ein Teil der amerikanischen Patternbücher der letzten zehn Jahre haben zumindest eine ihrer Wurzeln auf der EuroPLoP, viele zukünftige Bücher werden dort ihre Wurzeln haben. Und viele erste Anfänge dieser Bücher, die auf der EuroPLoP eingereicht wurden, waren möglicherweise schlechter, als das, was gerade in Ihrem Kopf oder Schreibtisch brütet. Zudem ist es eine einmalige Gelegenheit, Reviewkultur und Schreibkultur zu lernen.

Den vollständigen Call for Papers gibt es unter http://www.hillside.net/europlop/.

Vortrag „Einführung agiler Entwicklung“ am 29.1.2008 in Frankfurt

Auf Einladung der XP User Group Frankfurt werde ich den Vortrag „Einführung agiler Entwicklung – ein Erfahrungsbericht aus zehn Jahren Praxis“ auch am 29. Januar ab 19:30 Uhr in Frankfurt. Eine Beschreibung des Vortrags finden Sie im Blog-Eintrag vom 12.12.2007, nähere Informationen zur Veranstaltung auf dem „AgileWiki“ der XP User Group Frankfurt.