Planungshorizonte

In den Frühzeiten agiler Entwicklung wurde mir einmal während einer Podiumsdiskussion über Entwicklungsprozesse aus dem Publikum die folgende Frage gestellt: „Sie propagieren die schnelle Reaktionsfähigkeit und die Anpassungsfähigkeit an den Markt. Das klingt sehr schön, aber wir müssen Produktplanungen über die nächsten fünf Jahre vorlegen. Wie können Sie das mit agiler Entwicklung tun?“ Ich war neugierig geworden, welche Branche so lange Zukunftsperspektiven nicht nur ermöglicht, sondern offensichtlich einzufordern scheint und so fragte ich erst nach, aus welcher Branche der Fragesteller denn käme. Die Antwort erregte allgemeine Heiterkeit: „Wir bauen Handys.“

Ich empfahl dem Fragesteller, die derzeitigen Prozesse unbedingt beizubehalten, sollte es ihnen tatsächlich gelungen sein, vor fünf Jahren vorherzusehen, dass der SMS-Versand von Jugendlichen die wichtigste Einnahmequelle der Mobilfunkbetreiber werden würde – zu dieser Zeit war der SMS-Service noch keine fünf Jahre alt.

Der Handyhersteller ist übrigens mittlerweile insolvent, unter anderem, weil er sich am Markt nicht schnell genug bewegt hatte.

Designwissen ist wichtiger, als Plattformwissen

Martin Fowler hat mal wieder einen sehr lesenswerten Eintrag geschrieben zum Thema „Welche Art von Wissen ist Wichtiger“. Seine Schlussfolgerung: Im Zweifelsfall ist es deutlich effizienter, einem guten Designer eine neue Plattform beizubringen, als einem Plattformspezialisten gutes Design. Ideal wäre natürlich beides, in der Realität steht man aber häufig vor der Wahl. Ich würde jedes seiner Worte unterschreiben.

Den vollständigen Eintrag finden Sie unter Prefer Design Skills

Umfrage von it-agile: Wie agil wollen Sie sein?

Ein wenig Werbung in „fremder Sache“: it-agile veranstaltet gemeinsam mit dem OBJEKTspektrum eine Umfrage über den derzeitigen Stand der Agilität. Die Ergebnisse werden im OBJEKTspektrum veröffentlicht. Da ich die Zusammenarbeit mit den Kollegen von it-agile immer sehr genossen habe (und auch selbst an den Ergebnissen der Umfrage interessiert bin), möchte ich diese Aktion unterstützen.

Wenn an der Umfrage teilnehmen wollen (auch wenn Sie [noch] nichts mit Agilität zu tun haben!), gehen Sie einfach bis zum 27.1.2008 auf folgenden Link: http://news.sigs-datacom.de/ff/srv2_output.php?s=25ddc0f8c9d3e22e03d3076f98d83cb2&xqnotr=1. Das Ausfüllen des Formulars dauert ca. 8 min.

Wie so häufig bei solchen Aktionen können Sie Ihre Kontaktdaten gegen die Teilnahme an einer Verlosung tauschen, Sie können aber auch anonym antworten.

Veröffentlicht unter Agilit

Jazz ist nun doch frei verfügbar

[Hinweis: Ich habe diesen Eintrag nach einer Richtigstellung von Marko Schulz (s.u.) überarbeitet – 18.1.08]

Nun also doch: IBM hat am 14. Januar bekannt gegeben, dass Jazz ab sofort frei verfügbar ist. Damit steht das neueste „Baby“ der beiden Eclipse-Väter Erich Gamma und Andre Weinand wie auch schon Eclipse zumindest zur Evaluierung kostenlos zur Verfügung: Man muss IBM noch mit der Preisgabe seiner E-Mail Adresse bezahlen (http://www.jazz.net).

Selbst habe ich noch mit Jazz gespielt, geschweige denn es im Projekt eingesetzt. Dieser Bericht hier ist daher nur eine Zusammenfassung der White Papers und einer Vorführung auf der OOPSLA.

Was ist Jazz? Ähnlich wie Eclipse ist Jazz vor allem eine Plattform, also ein System, das zur Erweiterung mit Plug-Ins einlädt. Während Eclipse aber für den Arbeitsplatz eines einzelnen Entwicklers konzipiert ist, soll Jazz das ganze Team unterstützen. Es fordert damit also Micorsofts Team Foundation Server heraus.
Weiterlesen

Methodik: Use Cases, User Stories und Akzeptanztests

Was ist eigentlich der methodische Unterschied zwischen Use Cases und User Stories? Ich habe mich selbst nicht sonderlich intensiv mit Use Cases beschäftigt, kann hier also nur wiedergeben, was ich von Alistair Cockburns Erklärung verstanden habe: Eine User Story ist letztlich die Überschrift eines Szenarios, möglicherweise zusammen mit einem Beispiel. Mehrere Szenarien ergeben gemeinsam einen Use Case.

Darf man als Agilist nun Use Cases verwenden, oder nicht? Die Frage ist in dieser Form natürlich Unsinn, weil es bei agiler Entwicklung nicht darum geht, was man „darf“ und was nicht, sondern wie man ein Ziel erreicht. Das Ziel ist in diesem Fall ein adäquates Verständnis der Art und Weise, wie das System eingesetzt wird.
Weiterlesen

Veröffentlicht unter Agilit

Use Cases oder User Stories?

In Alistair Cockburns Wiki erzählt ein Teilnehmer namens „Remick“ unter dem Titel „Why I still use use cases„, wie er ein Problem recht erfolgreich mit Use Cases analysieren konnte, bis ein „Agile Coach“ kam und das Team auf User Stories zwang – was letztlich zum Scheitern des Projekts führte, wenn man „Remick“ folgt.

Ich halte das für einen der häufigsten Fehler wenig- oder unerfahrener „Agiler Coaches“: Sie glauben, es müsse immer alles genau so ablaufen, wie in ihrem jeweiligen Lieblingsbuch beschrieben. Ich erinnere mich an eine Diskussion, ob man bei XP nur Karteikarten im amerikanischen Format verwenden könne, oder auch DIN A5 Karten verwendet werden dürfen…

Nach zehn Jahren Erfahrung mit der Einführung agiler Entwicklung sehe ich da manches entspannter: Ob jemand Use Cases oder User Stories verwendet, ist nicht projektentscheidend, solange man darauf achtet, sich nicht zu verkünsteln (Alistair hat fast eine halbe Stunde gebraucht, um mir überhaupt den Unterschied zu erklären…). Und die Entscheidung, was man ändern sollte und was man getrost übernehmen kann, und in welcher Reihenfolge, ist eben von Organisation zu Organisation unterschiedlich. Das braucht Erfahrung und Fingerspitzengefühl. Allerdings bekommt man diese Erfahrung nicht in einem 2-tägigen Kurs, auch wenn man anschließend ein Zertifikat in der Hand hält.

Veröffentlicht unter Agilit

Bestandteile eines Projektplans – wirklich nötig?

Stefan Hagen hat in seinem „Projektmanagement Blog“ eine Folie bereitgestellt mit den „Bestandteilen eines Projektplans„. Die Folie enthält unter anderem 18 Teilpläne, einschließlich „Arbeitspaketdefinitionen“ und „Terminplan (GANTT)“.

Aus agiler Sicht erscheint das eher schwergewichtig. Anstatt festzulegen, welche Pläne gebraucht werden, diskutiere ich lieber die Ziele einer Planung:

  • Das Team auf die wichtigen Aufgaben fokussieren
  • Zusammenarbeit koordinieren
  • Vorhersagen über Fertigstellungstermine ermöglichen
  • Transparenz über den Projektstatus schaffen

Im agilen Bereich hat sich das aus der Toyota-Produktion stammende Kanban-Prinzip bewährt: Weiterlesen

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.

Langfristige Produktplanung und Agilität

Ein wichtiges Argument für agile Entwicklung ist, dass man flexibel auf Änderungen der Umstände reagieren kann. Viele Manager befürchten allerdings, dass sie diesen Vorteil auf Kosten der Planbarkeit erkaufen müssten. Gerade bei Produkthäusern verlangen Kunden und Investoren möglichst zuverlässige Aussagen, wann welche neuen Produktmerkmale oder Marktstrategien zur Verfügung stehen. Stört hier agile Entwicklung?

Ich meine, dass agile Planungspraktiken ganz im Gegenteil sogar helfen, solche langfristigen Planungsaussagen nicht nur zu treffen, sondern dann auch noch einzuhalten. Allerdings muss man dafür eine zusätzliche Planungsebene einführen, nennen wir sie strategische Planung (oder Roadmap, falls Ihnen Anglizismen besser gefallen). Anders als alle anderen Planungsebenen in einem agilen Vorhaben, geht der Horizont der strategischen Planung nicht nur über die anstehende Iteration, sondern über die nächsten 18 oder 24 Monate – mehr ist in der Regel nicht mehr seriös planbar.
Weiterlesen

Refactoring von Spaghetticode

Refactoring von Spaghetticode ist grundsätzlich anders, als Refactoring im Rahmen testgetriebener Entwicklung: Letzteres ist gut verstanden und bedarf keiner besonderen Beachtung während der Planung, die einzelnen Refactoringschritte dauern immer nur ein paar Minuten und sind in der Gesamtschätzung enthalten.

Wenn man aber versucht, alten Spaghetticode durch Refactoring wieder in einen wartbaren Zustand zu bringen, sieht die Sache ganz anders aus. Dies ist ein kaum planbares Unterfangen mit hohem Zeit- und Aufwandsrisiko. Der Nutzen kommt dabei häufig erst, wenn die Arbeiten deutlich voran geschritten sind; oft wird also Monate lang ohne greifbaren Nutzen entwickelt, bis sich der „Knoten“ plötzlich auflöst und ein deutlich besser wartbares Design entsteht, das exakt der alten Funktionalität entspricht – modulo der Fehler, die man üblicherweise während dieser Arbeit noch entdeckt und behebt.

Um die Situation etwas zu entschärfen, gehen wir bei solchen Vorhaben oft in mehreren Phasen vor, die sich bisher ganz gut bewährt haben (ich spreche hier von „wir“, weil ein solcher Umbau immer im Team oder mindestens von einem Paar durchgeführt werden muss, niemals von einem „Einzelkämpfer“):
Weiterlesen