ReFit: Refaktorisieren von Akzeptanztests

Johannes Link hat einen Werkzeugsatz geschrieben, mit dem man größere Mengen an FitNesse-Seiten umstellen und Refaktorisieren kann. Derzeit präsentiert sich ReFit, wie er das Werkzeug nennt, recht spartanisch als Groovy-Konsole, Johannes hat mir aber versichert, dass er jeden unterstützt, der Lust hat, dazu eine schicke grafische Oberfläche zu schreiben. Im Projekt verwendbar ist ReFit jetzt schon, zumindest wenn die Entwickler sich noch nicht auf die Maus beschränken, sondern noch mit der Tastatur umzugehen wissen…

Weitere Informationen und Links finden Sie auf Johannes Links Blog unter dem Titel Refactoring FitNesse Tests.

Verbreitung agiler Entwicklung

Nach einer aktuellen Umfrage des Web-Magazins Methods&Tools haben nur noch 13% der befragten Orgnisationen nichts von agiler Entwicklung gehört. 17% der Unternehmen setzen mindstens eine agile Methode in allen neuen Projekten ein, während 56% der Organisationen in verschiedenem Umfang zumindest mit agilen Praktiken experimentieren. Verglichen mit dem Jahr 2005 bedeutet das, dass fast doppelt so viele Unternehmen Agilität vollständig einsetzen, die „Exprimentierquote“ ist von 41% auf 56% gestiegen.

Das korrelliert gut mit Zahlen der TU München, die ebenfalls herausgefunden hat, dass in 16% der deutschen Unternehmen Agilität eingesetzt wird.

Ich denke, hier kann man die zunehmende Bedeutung des Themas für die Industrie erkennen. Noch ist das Fenster offen, in dem sich Unternehmen über den Einsatz agiler Praktiken am Markt differenzieren können, weil sie schneller und billiger bessere Software ausliefern, als die Mitbewerber. Ich bin davon überzeugt, dass jene Firmen, die diese Möglichkeit in den nächsten Jahren verstreichen lassen, in wenigen Jahren so unter Druck geraten, dass sie entweder ohne weiteren Marktvorteil gezwungener Maßen umstellen müssen, oder vom Markt verschwinden.

Veröffentlicht unter Agilit

Die Planung in der Tasche haben

Ein immer wiederkehrendes Problem bei agiler Planung ist die Menge an Karten, mit denen man jonglieren muss. In einem Monat sind vielleicht zehn, fünfzehn oder mehr Stories geplant, zu einer Story können leicht fünf oder sechs Aufgaben entstehen und der Platz auf einer Pinwand ist beschränkt.

Eine nette Lösung für das Problem hat Johannes Stark entwickelt, der in einem von mir betreuten Team mitarbeitet:

Tasche für die Planung Aus transparenten Hüllen und ein wenig Klebeband werden Taschen gebastelt, in welche die Karten für die User Story und alle noch ungeplanten Aufgaben gesteckt werden. Die Taschen hängen in der Reihenfolge ihrer Priorität an der Pinwand. Zur Wochenplanung werden dann die Aufgaben nach der Reihenfolge ihrer Priorität aus den Taschen genommen und auf eine zweite Pinwand gehängt, bis die Wasserlinie erreicht ist. Überzählige Aufgaben wandern wieder zurück in die Taschen.

Fallen unter der Woche neue Aufgaben an, so werden sie in die Taschen der zugehörigen User Story gesteckt und bei der nächsten Wochenplanung berücksichtigt. Ist eine Tasche leer und die Aufgaben abgearbeitet, so ist die User Story erledigt – vorausgesetzt natürlich, die Tests laufen.

Sieben Jahre Agiles Manifest

Diese Woche hat sich die Formulierung des agilen Manifests zum siebten Mal gejährt: Zwischen dem 11. und 13.2.2001 trafen sich 17 Protagonisten der nordamerikanischen agilen Szene – damals noch unter dem Schlagwort „Lightweight Processes“ bekannt – um sich über Gemeinsamkeiten und Konflikte auszutauschen. Unter Ihnen Kent Beck, Ward Cunningham, Martin Fowler, Ken Schwaber, Dave Thomas, Jim Highsmith und Brian Marick.

Was als private Veranstaltung geplant war, entpuppte sich zum Startschuss einer Bewegung, deren Einfluss auf unsere Branche bis heute nicht abschätzbar ist. Nach aktuellen Untersuchung arbeiten heute bis zu 50% der amerikanischen Unternehmen ganz oder teilweise mit agilen Verfahren, in Deutschland lag die Quote im letzten Jahr bei 16% – Tendenz zunehmend. Wenige andere Ideen haben unsere Branche so tiefgreifend verändert.

Das agile Manifest ist vereinfachend und polarisierend und zieht daraus seine Macht. „Wenn Du Werte beschreiben willst, geht das nur, wenn Du sagst, was Du im Konfliktfall statt ihrer opfern würdest,“ hat mir Martin Fowler einmal vor ein paar Jahren erklärt. „Sonst bieten die Werte keine Handlungshilfe und Du landest dabei, dass es schön wäre, wenn wir uns alle lieb hätten.“ Das Manifest polarisiert also, weil es eine Entscheidungshilfe im Konfliktfall sein soll. Aber die Polarisierung schützt auch vor Mitläufern, die sich um die Gedanken hinter agiler Entwicklung nicht scheren, sondern nur mit dem nächsten Hype schnelles Geld machen wollen. Es ist ein wichtiger Verdienst der agilen Bewegung, solche Tendenzen bisher weitgehend marginalisiert zu haben.

Heute haben sich manche der damaligen Protagonisten zurück gezogen. Das Erbe des agilen Manifests wird von der Agile Alliance Non-Profit Organization (AANPO) „verwaltet“, die sich nach wie vor bemüht, unterschiedliche Bestrebungen konstruktiv zusammen zu halten. Ich erinnere mich noch gut an die vielen zum Teil sehr emotionalen Telefonate während meiner Zeit im Vorstand der AANPO, als ich dazu auserkoren worden war, den Tendenzen zur Zersplitterung der Konferenzlandschaft entgegen zu arbeiten; ein Vorhaben, das schließlich zur Gründung der Agile Konferenzen geführt hat. Auch der heutige Vorstand leistet viel unbezahlte Hintergrundarbeit, um die agile Bewegung trotz aller fruchtbaren Unterschiede zusammen zu halten.

Ich persönlich glaube, dass wir in zwanzig Jahren agile Entwicklung betrachten werden, wie heute strukturierte Programmierung: Man redet nicht darüber, man macht es einfach, weil es Stand der Kunst ist.

Wir werden sehen…

Veröffentlicht unter Agilit

Seminar Refaktorisieren in München

Am 5. und 6. März gebe ich in Zusammenarbeit mit SIGS Datacom ein zweitägiges Seminar zu Refaktorisieren in München. Nach einer wirklich kurzen Einführung können Sie in dem Seminar erleben, wie Sie mit Hilfe kleinster, sicherer Schritte zunächst völlig unverständlichem Code in eine lesbare Variante umformen, um sie dann in Richtung einer neuen Architektur weiter zu entwickeln. Natürlich werden wir auch mögliche Rollen von Refaktorisieren im Projekt diskutieren, emergente Archtiekturen ansprechen und bei Bedarf ein wenig Richtung testgetriebene Entwicklung schauen.

Im Gegensatz zu manchen anderen Seminaren zum Refaktorisieren werde ich keine drögen Transformationskapitel abarbeiten, sondern lege Wert darauf, dass die Teilnehmer Strategien des Refaktorisierens verstehen und eintrainieren. Das macht nicht nur mehr Spaß, sondern bildet vor allem das Rüstzeug für die eigene Weiterbildung.

Zielgruppe sind Entwickler, Architekten und Projektleiter. Ein paar Grundkenntnisse mit Java und Eclipse sind hilfreich und Sie sollten keine Angst vor dem Programmieren haben. Sie brauchen Sie einen Laptop mit Windows XP (oder einer Windows XP VM), die restliche Software erhalten Sie während des Seminars. Anmelden können Sie sich auf der Semniarseite von SIGS Datacom.

Video über Standup Meetings

Thomas Lieder hat ein schönes Video ausgegraben, in dem Stacia Broderick, Boris Gloger, Denise Vielehr, Hubert Smits, Jens Ostsergaard und Tamara Sulaiman vormachen, wie man ein Standup keinesfalls durchführen darf. Freundlicherweise haben sie die Regeln, nach denen es ablaufen sollte auch gleich mitgeliefert. Das sind 8 1/2 Minuten, die sich durchaus lohnen. Viel Spaß:

(Falls der Link bei Ihnen nicht funktioniert, gehen Sie bitte direkt auf http://www.youtube.com/watch?v=B3htbxIkzzM).

Statistiken zu agilen Projekten

In seinem jüngsten Eintrag im Cutter-BlogIf Agile Were to Go Mainstream“ fasst der Cutter Metrikexperte Michael Mah seine Auswertungen über agile Projekte zusammen, die er aus seiner über 7400 Projekte umfassenden Projektdatenbank erstellt hat. Zu den interessantesten Schlussfolgerungen zählen meines Erachtens:

  • Die meisten agilen Projekte waren überdurchschnittlich schnell: Etwa 80% lagen über dem Industriedurchschnitt, einige sogar doppelt so schnell, wie traditionelle Projekte. Umgekehrt heißt dass natürlich auch, dass 20% langsamer waren, als der Durchschnitt.
  • Agile Teams waren überdurchschnittlich groß, allerdings stieg die Fehlerquote nicht, wie bei traditionellen Projekten, mit der Teamgröße. Die Neigung zu größeren Teams überrascht mich und steht im Gegensatz zu meiner persönlichen Erfahrung. Ob das kulturelle Unterschiede sind, also der deutschsprachige Raum insgesamt eher zu großen Projekten neigt, ob meine Erfahrung da nicht repräsentativ ist, oder ein Missverständnis vorliegt, ist eine spannende Frage.
  • Agile Projekte haben niedrigere Fehlerraten. Am besten schneiden gut eingespielte XP Teams ab, deren Fehlerraten zum Teil um 30-50% unter dem Industriedurchschnitt lagen. Damit wird die Behauptung gestützt, testgetriebene Entwicklung trage wesentlich zur technischen Qualität eines Produkts bei.

Den vollständigen Artikel – mitsamt einem launigen Aufmacher zum Ursprung agiler Verfahren – finden Sie hier.

Praktiken I: Retrospektiven

Zu den – neuen – Kerngedanken agiler Entwicklung gehört die Idee, den Prozess in die Verantwortung des Teams zu geben. Das entspricht zum einen dem agilen Manifest, das ja fordert, dass „Individuen und Interaktion wichtiger sind, als Prozesse und Werkzeuge“. Zum anderen wird hier einmal wieder ein Konzept aus dem „Lean Management“ umgesetzt: Bei Toyota haben die Arbeiter in der Produktion erheblichen Einfluss auf die Produktionsprozesse. Schließlich wissen sie am besten, was gut funktioniert und was nicht.

Die Verantwortung für den Prozess zu bekommen bedeutet freilich nicht, dass jeder tun und lassen kann, was er will. Das Team muss vielmehr definieren, wie es arbeitet und diesen Prozess ständig verbessern. In seinen Crystal Methoden hat Alistair Cockburn die „Methodology Shaping Workshops“ nach jeder Auslieferung als eine der wenigen bindenden Praktiken definiert. Seitdem vor sieben Jahren Norm Kerths Buch „Retrospectives“ erschienen ist (siehe unten), haben sich Retrospektiven in allen agilen Verfahren als zentrale Praktik entwickelt: Regelmäßig stattfindende Workshops, auf denen alle Beteiligten reflektieren, wie das letzte Release gelaufen ist und beschließen, was in Zukunft anders gemacht werden soll. Es handelt sich dabei um eine Reflexion der gelebten Projektpraxis, also nicht um ein Review eines Prozessdokuments und auch nicht um einen Audit.
Weiterlesen

Neue Serie: Agile Praktiken

Agilität scheint nun auch in Deutschland Schwung zu bekommen. Als Folge davon treffe ich immer wieder auf ein gesteigertes Interesse an Informationen über die grundlegenden agilen Praktiken. Ich werde deshalb in loser Folge einige zentrale agile Praktiken vorstellen mit Links zu weiteren Informationen. Diese Artikel werden allerdings etwas ausführlicher, als gewohnt.

Den Anfang dieser Serie machen Retrospektiven.

Agile Zertifizierung basisdemokratisch: WeVouchFor

Das Thema „Zertifizierung“ wurde in den letzten Jahren in der agilen Gemeinschaft sehr kontrovers diskutiert. Die Scrum Gemeinschaft hat sich mit einem eigenen Zertifizierungsprogramm „selbständig“ gemacht, das nicht zuletzt wegen der zum Teil sehr niedrigen Zertifizierungsschwelle vielfach sehr kritisch diskutiert wurde – nicht nur von mir (der „Certified Scrum Master“ ist im wesentlichen die Teilnahmebescheinung an einem zweitägigen Kurs).

Brian Marick, einer der innovativsten Querdenker unter den Agilisten und Laurent Bossavit haben nun einen radikal anderen, basisdemokratischen Ansatz in der Alpha-Version gestartet: We Vouch For… Die Idee ist so einfach wie bestechend: Jeder kann sich als Mitglied einschreiben und Mitglieder zertifizieren sich gegenseitig. Um den einzelnen Zertifikaten Substanz zu geben, muss man genau angeben, wofür man den Kollegen zertifiziert und vor allem, auf welcher Basis. So lautet mein Zertifikat für Johannes Link zum Beispiel:
Weiterlesen

Veröffentlicht unter Agilit