Refactoring mit PHP

Veröffentlicht am von

Dass Refactoring in Java mit Eclipse so richtig Spaß macht und auch die Kombination von Visual Studio mit Resharper oder DevExpress ganz brauchbar ist, dürfte zumindest unter Agilisten hinreichend bekannt sein. PHP-Entwickler haben es da deutlich schwerer, wie Roy Ganor in seinem Blog-Eintrag „Refactoring PHP Code“ beschreibt. Zend scheint zumindest ein paar Basisfunktionen anzubieten, aber selbst der Beitrag (auf dem Firmenblog!) klingt nicht wirklich enthusiastisch. Dennoch kann es sich für PHP-Entwickler lohnen, hineinzuschauen und zumindest zu beobachten, was dort die nächste Zeit passiert.

Achtung: Ich selbst habe keinerlei Erfahrung mit Refactoring unter PHP! Wer da mehr weiß, ist herzlich eingeladen, hier Kommentare zu ergänzen.

[OOP 2009] Workshop Agile Praxis erleben

Veröffentlicht am von

Haben Sie mittlerweile alles über Agilität gelesen, was Ihnen über den Schreibtisch kam? Klingt das für Sie alles „irgendwie logisch“, aber so ganz können Sie sich noch nicht vorstellen, wie das in der Praxis funktionieren soll? Würden Sie das alles gerne einmal in der Praxis ausprobieren? Aber am besten, ohne dabei Ihr Projekt, Ihre Karriere und Ihren Job zu riskieren? Dann möchten wir Sie herzlich einladen zu unserem eintägigen Workshop „Agile Praxis erleben“ am Freitag, 30. Januar auf der OOP in München.

„Wir“, das sind Henning Wolf und Bernd Schiffer von it-agile sowie ich und möglicherweise wird uns auch noch Johannes Link unterstützen. Wir werden mit Ihnen ein agiles Projekt durchführen, mit (fast) allem, was dazu gehört: Planungstechniken, Produktverantwortliche, Entwickler, Tester, Backlog, Retrospektiven und so weiter. Nur auf eine Demo zur testgetriebenen Entwicklung werden wir aus Zeitgründen verzichten müssen. Sie werden in die gleichen Probleme laufen, die Sie auch in Ihren eigenen Projekten anfangs hätten, Sie werden lernen, wie Sie diese Probleme in den Retrospektiven anpacken können und Schritt für Schritt besser werden können. Und zu guter letzt stehen Ihnen noch drei oder vier der erfahrensten „Agilisten“ Deutschlands Rede und Antwort auf Ihre Fragen. Das Ganze garantiert ohne Powerpoint, Beamer, oder Computer in einer Entwicklungsumgebung, die Sie nicht nur mit Sicherheit beherrschen, sondern die auch noch allen Beteiligten eine Menge Spaß bringt.

Wir haben den Workshop bereits auf den XPDays 2008 in Hamburg durchgeführt und die Erwartungen aller Teilnehmer erfüllen können. Allerdings sollten Sie sich beeilen, der Workshop ist auf 25 Teilnehmer begrenzt.

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

Veröffentlicht am von

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

Veröffentlicht am von

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).

Einsatz testgetriebener Entwicklung nimmt langsam zu

Veröffentlicht am von

Nach einer Umfrage von Martinig & Associates ist der Einsatz testgetriebener Entwicklung zwischen 2006 und 2008 von 14% auf 20% der befragten Organisationen gestiegen. Das ist auf der einen Seite erfreulich, auf der anderen Seite zeigt es aber, dass wir noch immer bei den „Early Adoptern“ sind. Daran gemessen, dass TDD im Gegensatz zu informellem „Nachtesten“ bei gleichem oder sogar verringertem Aufwand fast die doppelte Testabdeckung erreicht (persönliche Erfahungen sowohl von mir als auch von Johannes Link), dürfte die geringe Nutzung weder an wirtschaftlichen noch an methodischen Gründen liegen. Ich vermute eher, dass viele Entwickler sich zunächst subjektiv langsamer fühlen, wenn sie testgetrieben arbeiten — und nicht das Durchhaltevermögen haben, sich einmal zwei oder drei Monate auf das Verfahren einzulassen, bevor sie aufgeben. Dann würden Sie nämlich feststellen, dass sie deutlich weniger Fehler beheben müssen und damit wesentlich schneller sind, als vorher. Vielleicht nicht bis zu ersten „hingerotzten“ Version, aber sicher bis zum produktionsfähigen Code. Nur wenige Teams schaffen dieen Schritt denn auch aus eigener Kraft ohne Coaching.

Crystal in einem Satz

Veröffentlicht am von

Alistair Cockburn fasst die Essenz der Crystal Methoden in seinem Blog-Eintrag „Crystal is about Self-Awareness“ sehr schön zusammen:

  • Scrum is about self-organization
  • XP is about self-discipline
  • Crystal is about self-awareness

Vielleicht kommt es daher, dass sich viele Anfänger zunächst auf Rezeptverfahren wie Scrum und XP (Version 1.0) stürzen: Konzepte der Selbst-Erkenntnis sind sperrig und benötigen mehr Erfahrung, als klare Kochrezepte. „Crystal ist für Fortgeschrittene“ sagt Alistair auch deutlich.

Die Rezepte sind ein guter Start. Über kurz oder lang fällt aber eine Entscheidung: Bleibt man auf Rezeptniveau, indem man über Prozesse und Praktiken streitet, dann kann man die Einführung agiler Verfahren irgendwann als gescheitert betrachten. Oder übernimmt das Team irgendwann über Retrospektiven die Kontrolle und beginnt, den Prozess als Arbeitsmittel selbst zu gestalten. Dann ist man im wesentlichen bei Crystal gelandet bzw. hat den Schritt nachvollzogen, den XP beim Übergang auf Version 2.0 gemacht hat.

Wie Unternehmen die Krise überleben

Veröffentlicht am von

Roland Berger hat in der Studie „Be flexible – How engineered products companies prepare for the downturn“ 500 Maschinen- und Anlagenbauer untersucht, wie sie mit wirtschaftlichem Abschwung umgehen und Krisen überleben. Als zyklische Branche ist gerade die Investitionsgüterindustrie besonders anfällig für konjunkturelle Schwankungen. Das Resümee: Die besten Unternehmen können so flexibel auf die Krise reagieren, dass sie Konjunktureinbrüche sogar als Chance nutzen können, ihre eigene Marktposition zu stärken.

Wie die meisten anderen Sparten steigt der Anteil der IT an der Wertschöpfung auch im Maschinen- und Anlagenbau stetig. Die von Berger postulierte Flexibilität setzt unter anderem auch entsprechende Flexibilität in Forschung und Entwicklung voraus, nicht nur, aber auch bei der IT. Verfahren und Vorgehensmodelle, die zu Laufzeiten von vielen Jahren führen, können da schnell zum Ballast werden.

Agile Verfahren erlauben hier viel größere Flexibilität. Agile Planungstechniken fügen sich elegant und nahtlos in eine szenariobasierte Unternehmensplanung ein, wie sie Berger bei den erfolgreichen Unternehmen beobachtet. Zu Beginn der Rezession könnte noch ausreichend Zeit bleiben, flexibler zu werden.

„Machen Sie Flexibilität zur Sache des Top-Managements“ zählt Roland Berger als einen der fünf strategischen Bausteine auf, um die Krise zu überleben. Diese Forderung dürfte nicht nur für den Maschinenbau gelten.

PS: Mehr über agile Planungstechniken erzähle ich u.a. auf den XPDays 2008 in Hamburg oder auf der OOP 2009 in München