Schlagwort

agileentwicklung

29.3.2008

Tonabnehmer #15: Jutta Eckstein, Johannes Link, Jens Coldewey, Henning Wolf -
7 Jahre Agiles Manifest

Jutta EcksteinJohannes LinkJens ColdeweyHenning Wolf

Im Februar 2001 war das Agile Manifest geboren. In dieser Roundtable-Diskussion machen wir eine Bestandsaufnahme, Reflektion, Analyse: Was haben sieben Jahre Agile Entwicklung gebracht?

Mit dabei: Jutta Eckstein (Blog, Profil), Johannes Link (Blog, Profil), Jens Coldewey (Blog, Profil), Henning Wolf (Blog, Profil)

25.2.2001

Agile Softwareentwicklung

Die Autoren von Scrum, XP, DSDM, ASD und Crystal sowie einige vergleichbar erfahrene Leute einigten sich auf das Manifest für agile Softwareentwicklung:

Wir zeigen bessere Wege zur Softwareentwicklung auf, indem wir Software entwickeln und anderen dabei helfen. Wir bevorzugen:

  • Menschen und Zusammenarbeit vor Prozessen und Werkzeugen
  • Funktionierende Software vor umfassender Dokumentation
  • Zusammenarbeit mit dem Kunden vor vertraglicher Verhandlung
  • Reaktion auf Veränderung vor Einhaltung eines Plans

Das heißt, während die Punkte auf der Rechten wertvoll sind, wertschätzen wir die Punkte auf der Linken mehr.

Weitere Links

5.5.2005

Extreme Programming:
Auf ein Neues

InfoWeek 9/2005

von Frank Westphal und Tammo Freese
erschienen in der InfoWeek 09/2005

Vor noch fünf Jahren galten seine Ideen zur Softwareentwicklung als unglaublich extrem. Heute sind viele der Extreme Programming (XP) Praktiken akzeptiert. Mit einer von Grund auf neu geschriebenen, zweiten Auflage seines Bestsellers "Extreme Programming Explained" zeichnet Kent Beck ein aktuelles Bild: Die vielleicht effektivste und zugleich menschlichste Softwareentwicklungsmethodik ist gerade noch effektiver und menschlicher geworden.

Das neue Extreme Programming schlägt leisere Töne an. Die Kinderkrankheiten hat es hinter sich gebracht, es ist erwachsen geworden. Im Kern finden sich nach wie vor die vier groß geschriebenen Werte: Einfachheit, Kommunikation, Feedback und Mut. Schon seit frühesten Tagen lag XP als fünfter Wert Respekt zu Grunde, der in der neuen Fassung nun explizit seinen Einzug ins Wertesystem feiert.

Mehr pragmatisch und weniger dogmatisch

Die wohlbekannten XP-Praktiken sind aus den gesammelten Erfahrungen der vergangenen Jahre sowohl verbessert, vereinfacht und konkretisiert als auch verallgemeinert worden. Fanden sich im ursprünglichen XP nur ein Dutzend Praktiken, hat sich die Anzahl mit der Überarbeitung verdoppelt. Der Grund zur scheinbaren Zunahme der schlanken Methode ist, dass die Menge der Praktiken jetzt in Pflicht und Kür aufgeteilt ist: Während die primären Praktiken meist isoliert anwendbar sind und deshalb in jedem Prozess zu einer sofortigen Verbesserung führen können, setzen die weiterführenden Praktiken auf den Grundstock auf und führen den agilen Prozess schließlich an seine Leistungsgrenzen. Nichtzuletzt durch diese Abschwächung gelingt es dem runderneuerten XP, einerseits die Eingangsschwelle für jedermann zu senken und andererseits in Anwendungsbereiche vorzudringen, für die es initial nicht geeignet schien. Als Beispiele seien hier nur große und verteilte Projekte genannt.

Bei Programmierern beliebt

Vieles hat sich durch XP verändert: Einige XP-Praktiken werden mittlerweile im Studium vermittelt. Automatisiertes Testen ist zum festen Bestandteil der Entwicklungskultur geworden. Zur inkrementellen Verbesserung des Softwaredesigns stehen Entwicklungsumgebungen mit automatisierter Refactoringunterstützung zur Verfügung. Und Pair Programming wird heute viel einfacher akzeptiert. Während sich das leichtgewichtige XP bislang nicht gegen schwergewichtige Prozesse durchsetzen konnte, scheint es vor allem in kleineren Unternehmen Erfolg zu haben. Der Grund dafür ist sicherlich, dass dem vorherrschenden chaotischen "Code und Fix" Vorgehen vieler Softwareunternehmen mit XP's gesundem Menschenverstand schnell zu einem massiven Produktivitätsgewinn verholfen werden kann.

Im Management wenig Durchdringung

War XP auch die erste agile Methode, die von einer breiten Masse wahrgenommen wurde, steht ihr Bekanntheitsgrad in keinem Verhältnis zu ihrem Verbreitungsgrad. Ganz anders sah dies aus, als das erste Buch erschien. Zu Zeiten der Dotcom-Ära gedieh XP überaus prächtig, schließlich passte seine Philosophie hervorragend in die damalige Projektlandschaft von kleinen schnellen Teams in einer Welt mit sich rapide verändernden Anforderungen. Mit dieser Ära ging teils auch der für innovative, sich selbst organisierende Projektteams nötige kulturelle Nährboden verloren. Die Verbreitung von XP fand darin ihre organisatorischen Grenzen. Und während der Name gerade in Programmiererkreisen große Aufmerksamkeit erzeugte, stieß er im Management übel auf. Zudem war XP aus Sicht der Programmierer beschrieben, so dass die Änderungen in der Projektabwicklung aus Management- und Kundensicht nicht als Chancen, sondern lediglich als Risiken wahrgenommen wurden. Dieses Bild will mit dem neuen XP korrigiert werden. Denn mit seinem erweiterten Rollenmodell werden auch Nicht-Programmierer in das XP-Team eingebunden.

Lean Thinking

Auffällig ist, wie viele Anleihen aus dem Lean Manufacturing herausgearbeitet wurden. Gerade die Parallelen zum Toyota Produktionssystem, der Just in Time Fertigungsstrategie des führenden japanischen Autobauers, können ein Weg sein, den XP-Ideen im Management zu einer höheren Akzeptanz zu verhelfen. Über viele Jahre standen nur solche Fragen wie die Effizienz von Pair Programming, Testgetriebener Entwicklung oder eines Kunden vor Ort im Zentrum der Diskussion. Dabei bekäme es der weiteren Akzeptanz besser, würde sich die Aufmerksamkeit in heutigen Zeiten des Kostendrucks mehr auf übergeordnete Themen wie Wertschöpfungsketten, Return on Investment, Zero Defects und Time to Market verlagern. Denn durch die Einführung neuer Praktiken wie der Ursachenforschung zur Fehlerprävention sowie der Anwendung der Theory of Constraints zur Vermeidung von Flaschenhälsen gelingt es XP, die nötige, am japanischen Kaizen orientierte Philosophie der kontinuierlichen Prozessverbesserung zu etablieren. Wie weit man jedoch mit dem extremen Programmieren gehen will, bleibt insbesondere nach Aufweichung der Praktiken jedermann selbst überlassen. XP stellt in sich eh kein Ziel dar, sondern ist und bleibt ein Weg zur Verbesserung der Softwareentwicklung.

16.3.2005

Tonabnehmer #2: Jutta Eckstein -
Agilität im Großen

Interview mit Jutta Eckstein

Für den zweiten Tonabnehmer habe ich Jutta Eckstein in Braunschweig besucht. Bei leckerem Husten- und Bronchialtee haben wir über agile Softwareentwicklung in großen Projekten geschwätzt.

Das Interview können Sie als MP3 herunterladen oder direkt als Podcast empfangen. (Was ist Podcasting?)

Hören Sie u.a., warum Feedback im Zentrum von Agilität steht: "Wenn man sich überlegt, agile Entwicklung zu verfolgen, dann ist es nicht damit getan, dass man sich einen Prozess ausschaut wie Extreme Programming oder Scrum oder Feature-Driven Development oder was auch immer und dann diesen umsetzt, sondern was eben das Wichtigste ist: Dass man immer wieder Feedback einholen muss, inwiefern der Prozess dem Team und dem Projekt auch wirklich gerade nützt. Oder ob es vielleicht irgendwelche Ecken gibt, wo der Prozess mehr hindert oder vielleicht auch das Team Probleme hat, genau diesen Prozess umzusetzen. Man muss dann eben gemeinsam herausfinden, was man stattdessen tun kann, um zum Erfolg zu kommen."

Ohne Retrospektiven ist ein agiler Prozess dann auch kein agiler Prozess, erklärt Jutta: "Weil ich nur durch die Retrospektiven in der Lage bin, den Prozess wirklich anzupassen: an die Bedürfnisse des Projekts, an die Bedürfnisse des gesamten Teams, des Kunden usw."

Zu ihrer Rolle als Kommunikationsmanagerin: "Manche Dinge, die [in kleinen Projekten] automatisch laufen, wie dass man sich an der Kaffeetheke trifft, dass man nebenbei mitkriegt, wie jemand ein Problem hat, oder grundsätzlich was Kommunikation angeht: Das funktioniert [in größeren Projekten] einfach nicht mehr automatisch, sondern man muss es institutionalisieren. Also: Man muss sicherstellen/gewährleisten, dass die Kommunikation existiert."

27.1.2005

Timeboxing

Eine Teilnehmerfrage, die während meines OOP-Vortrags aufkam:

"Sollten Iterationen immer die gleiche Länge besitzen oder darf die Timebox variieren?"

Meine Meinung:

Beim iterativen Vorgehen geht es darum, ein Projekt in einen erkennbaren Rhythmus zu zwingen. Iterationen bringen ein Entwicklungsteam in den Zustand, regelmäßig funktionsfähige Software mit neuer wertvoller Funktionalität auszuliefern. Sie sind der natürliche Herzschlag eines gesunden Projekts.

Um den Fortschritt vergleichbar messen zu können, ist eine feste Iterationslänge unbestreitbar von Vorteil. Schließlich geht es beim erfolgreichen Projektmanagement darum, die vier Variablen Zeit, Umfang, Qualität und Mittel geschickt miteinander in Einklang zu bringen. Und die Idee des Timeboxings ist gerade, interessante Kompromisse zu erzielen.

26.8.2001

Extreme Programming

Extreme Programming (XP) ist ein agiler Softwareentwicklungsprozess für kleine Teams. Der Prozess ermöglicht, langlebige Software zu erstellen und während der Entwicklung auf vage und sich rasch ändernde Anforderungen zu reagieren. XP-Projekte schaffen ab Tag eins Geschäftswert für den Kunden und lassen sich fortlaufend und außergewöhnlich stark durch den Kunden steuern.

Im Kern beruht XP auf den Werten Kommunikation, Einfachheit, Feedback, Mut, Lernen, Qualität und Respekt. XP erfordert Disziplin und Prinzipientreue. Die beschriebenen XP-Techniken sind jedoch wirklich nur die Startlinie. Das Ziel ist es, den Entwicklungsprozess an die örtlichen Begebenheiten anzupassen und fortlaufend zu verbessern.

Techniken für ein XP-Team

Ein XP-Team besteht aus zwei bis etwa zwölf Programmierern, einem Kunden oder mehreren direkten Anprechpartnern auf Kundenseite und dem Management. Ferner erfordert der Prozess die Rollen des Trainers und Verfolgers. Der Trainer bespricht mit dem Team die diszipliniert einzuhaltenden Techniken und erinnert das Team, wenn es die selbstgewählten Regeln verletzt. Der Verfolger nimmt regelmässig den aktuellen Status und die geleisteten Programmieraufwände auf, um so zuverlässige Geschichtsdaten über das Projekt zu erhalten. Zu beachten ist, daß der Kunde in der Regel weder den Geldgeber noch den wirklichen Endanwender darstellt.

Offene Arbeitsumgebung

Das Team arbeitet zusammen in einem größeren Raum oder eng aneinander grenzenden Räumen. Typischerweise ist der "Kriegsraum" mit Wandtafeln und unzähligen Flipcharts ausgestattet. Die Arbeitstische stehen meist dicht beieinander im Kreis mit den Monitoren nach außen gerichtet und sind so gestaltet, daß zwei Programmierer zusammen bequem an einem Computer arbeiten können.

Kurze Iterationen

Die Entwicklung erfolgt in Perioden von ein bis drei Wochen. Am Ende jeder Iteration steht ein funktionsfähiges, getestetes System mit neuer, für den Kunden wertvoller Funktionalität.

Gemeinsame Sprache

Das Team entwickelt in seiner Arbeit ein gemeinsames Vokabular, um über die Arbeitsweisen und das zu erstellende System diskutieren zu können. Die Kommunikation im Team erfolgt stets offen und ehrlich.

Retrospektiven

Jede Iteration endet damit, in einem Rückblick über die eigenen Arbeitsweisen kritisch zu reflektieren und im Team zu diskutieren, was gut lief und was in Zukunft anders angegangen werden muß. Typischerweise werden aus den Dingen, die während dieser Team-Reviews zur Oberfläche kommen, Regeln generiert, vom Team akzeptiert, auf Poster geschrieben und im Projektraum zur Erinnerung an die Wand geheftet. Ein- oder zweimal jährlich macht das Team für zwei Tage einen gemeinsamen Ausflug, um in einem Offsite-Meeting formal vor- und zurückzublicken.

Tägliches Standup-Meeting

Der Tag beginnt mit einem Meeting, das im Stehen gehalten wird, damit es kurz und lebendig bleibt. Jedes Teammitglied berichtet reihum, an welcher Aufgabe er gestern gearbeitet hat und was er heute machen wird. Probleme werden genannt aber nicht gelöst. Die meisten Teams treffen sich vor der Wandtafel ihrer Iterationsplanung.

Techniken für die Kunden

Benutzergeschichten

Die Kunden halten ihre Anforderungen in Form einfacher Geschichten auf gewöhnlichen Karteikarten fest. Jeder geschriebenen Story-Karte kommt das Versprechen nach, den genauen Funktionsumfang zum rechten Zeitpunkt im Dialog mit den Programmierern zu verfeinern und zu verhandeln.

Iterationsplanung

Jede Iteration beginnt mit einem Planungsmeeting, in dem das Kundenteam seine Geschichten erzählt und mit dem Programmierteam diskutiert. Die Programmierer schätzen den Aufwand grob ab, den sie zur Entwicklung jeder einzelnen Geschichte benötigen werden. Die Kunden wählen in Abhängigkeit der Aufwandsschätzungen den Kartenumfang für die Iteration aus, der ihren Geschäftsgegenwert maximieren würde. Die Programmierer zerlegen die geplanten Geschichten am Flipchart in technische Aufgaben, übernehmen Verantwortung für einzelne Aufgaben und schätzen deren Aufwände vergleichend zu früher erledigten Aufgaben. Aufgrund der genaueren Schätzung der kleinen Aufgaben verpflichten sich die Programmierer auf genau soviele Geschichten, wie sie in der vorhergehenden Iteration entwickeln konnten. Diese Planungsspiele schaffen eine sichere Umgebung, in welcher geschäftliche und technische Verantwortung zuverlässig voneinander getrennt werden.

Anforderungsdefinition im Dialog

Das für die anstehenden Programmieraufgaben nötige Verständnis der Anforderungen wird fortlaufend in der Konversation mit den Kunden geprüft und vertieft. In kurzen Designsessions wird unter Umständen auf eine der Wandtafeln ein wenig UML gemalt oder es werden Szenarien mit Hilfe von CRC-Karten durchgespielt. Während der gesamten Entwicklung dienen die Kunden als direkte Ansprechpartner zur Bewältigung fachlicher Fragen. Die verbleibende Zeit verbringen die Kunden mit dem Schreiben und Ergründen neuer Benutzergeschichten und Akzeptanztests.

Akzeptanztests

Die Kunden spezifizieren während der Iteration funktionale Abnahmekriterien. Typischerweise entwickeln die Programmierer ein kleines Werkzeug, um diese Tests zu kodieren und automatisch auszuführen. Spätestens zum Ende der Iteration müssen die Tests erfüllt sein, um die gewünschte Funktion des Systems zu sichern.

Kurze Releasezyklen

Nach ein bis drei Monaten wird das System an die wirklichen Endanwender ausgeliefert, damit das Kundenteam wichtiges Feedback für die Weiterentwicklung erhält.

Techniken für die Entwicklung

Programmieren in Paaren

Die Programmierer arbeiten stets zu zweit am Code und diskutieren während der Entwicklung intensiv über Entwurfsalternativen. Sie wechseln sich minütlich an der Tastatur ab und rotieren stündlich ihre Programmierpartner. Das Ergebnis ist eine höhere Codequalität, grössere Produktivität und bessere Wissensverbreitung.

Gemeinsame Verantwortlichkeit

Der gesamte Code gehört dem Team. Jedes Paar soll jede Möglichkeit zur Codeverbesserung jederzeit wahrnehmen. Das ist kein Recht sondern eine Pflicht.

Erst Testen

Gewöhnlich wird jede Zeile Code durch einen Testfall motiviert, der zunächst fehlschlägt. Die Unit Tests werden gesammelt, gepflegt und nach jedem Kompilieren ausgeführt.

Design für heute

Jeder Testfall wird auf die einfachst denkbare Weise erfüllt. Es wird keine unnötig komplexe Funktionalität programmiert, die momentan nicht gefordert ist.

Refactoring

Das Design des Systems wird fortlaufend in kleinen, funktionserhaltenden Schritten verbessert. Finden zwei Programmierer Codeteile, die schwer verständlich sind oder unnötig kompliziert erscheinen, verbessern und vereinfachen sie den Code. Sie tun dies in disziplinierter Weise und führen nach jedem Schritt die Unit Tests aus, um keine bestehende Funktion zu zerstören.

Fortlaufende Integration

Das System wird mehrmals täglich durch einen automatisierten Build-Prozess neu gebaut. Der entwickelte Code wird in kleinen Inkrementen und spätestens am Ende des Tages in die Versionsverwaltung eingecheckt und ins bestehende System integriert. Die Unit Tests müssen zur erfolgreichen Integration zu 100% laufen.

Techniken für das Management

Akzeptierte Verantwortung

Das Management schreibt einem XP-Team niemals vor, was es zu tun hat. Stattdessen zeigt der Manager lediglich Probleme auf und läßt die Kunden und Programmierer selbst entscheiden, was zu tun gilt. Dies ist eine große, neue Herausforderung für das Management.

Information durch Metriken

Eine der Hauptaufgaben des Managements ist es, dem Team den Spiegel vorzuhalten und zu zeigen, wo es steht. Dazu gehört unter anderem das Erstellen einfacher Metriken, die den Fortschritt des Teams oder zu lösende Probleme aufzeigen. Es gehört auch dazu, den Teammitgliedern regelmässig in die Augen zu schauen und herauszufinden, wo Hilfe von Nöten ist.

Ausdauerndes Tempo

Softwareprojekte gleichen mehr einem Marathon als einem Sprint. Viele Teams werden immer langsamer bei dem Versuch, schneller zu entwickeln. Überstunden sind keine Lösung für zuviel Arbeit. Wenn Refactorings und Akzeptanztests aufgeschoben werden, muß der Manager dem Team stärker den Rücken freihalten. Wenn Teammitglieder müde und zerschlagen sind, muß der Manager sie nach Hause schicken.

Links

Bücher

Mailinglisten

User's Groups

8.1.2001

Agile Prozesse

Agile Softwareentwicklungsprozesse sind zweifellos en vogue. Sie unternehmen den Versuch, die Anzahl der im Prozess zu erstellenden Artefakte weitestgehend zu reduzieren. Das bedeutet, daß sich das Gewicht eines jeden Artefakts rechtfertigen muß und auf die Erstellung und Pflege von Nebenprodukten jenseits vom Programmcode verzichtet wird, wenn das Risiko dafür gering genug ist.

Momentan dominiert Extreme Programming die Diskussion um die leichtgewichtigen Methoden. Vielleicht nicht ohne Grund, denn XP kommt mit seinen zwölf Techniken vergleichsweise konkret daher. Andererseits erfordert der Prozess jedoch hohe Disziplin im Team.

Weitere Vertreter der leichtgewichtigen Familie für Agile Softwareentwicklung sind z.B.:

Vergessen Sie bitte nicht:

  1. Softwareentwicklung soll Spaß machen. Tut sie das nicht, ist der Prozess defekt.
  2. Jedes Projekt und jedes Team ist einzigartig und benötigt damit seinen eigenen maßgeschneiderten Prozess.
  3. Der Prozess gehört dem Team. Jedes Team entscheidet selbst (akzeptiert), welche Regeln es befolgen will (und welche nicht). Mit einem aufgezwungenen Prozess kommt es oft zur Schieflage, weil Autorität und Verantwortlichkeit für den Prozess nicht einer Hand liegen.
  4. Ihr Entwicklungsprozess ist ein wanderndes Ziel. Sie sollten ihn ständig verbessern und ihn an Ihre örtlichen Begegebenheiten anpassen.
  5. Es muß nicht unbedingt XP sein. Leichtgewichtigkeit an sich kann schon ein wertvolles Ziel sein.

Weitere Links

15.3.2007

5 Minutes Interview
with Martin Wisniowski

Für die 5 Minutes Interviews auf Digital Tools hat mir Martin Wisniowski kurz und bündig einige Fragen gestellt. Als kleine, feine State of the Art Bestandsaufnahmen beschreibt Martin das Konzept der Reihe. Heute: zum Agilen, zum Extremen und zum Dinge-geregelt-kriegen mit GTD. Zum Lesen hier entlang bitte.

5 Minutes Interview mit Martin Wisniowski

30.11.2006

Extreme Hour
vs. XP-Game

Nachdem ich am vergangenen Freitag auf dem XPday schon darauf angesprochen wurde und auch Johannes und ich heute noch mal auf das Thema kamen, dachte ich mir, ich poste einfach schnell mehr dazu … vielleicht interessiert's ja noch wen.

Die kürzesten XP-Projekte der Welt

Einen neuen Prozess zu erlernen und gleichzeitig seine Arbeit zu machen, geht häufig nicht so gut zusammen. Zum Lernen gehört Experimentieren und zum Experiment gehört das erlaubte (und irgendwo auch explizit gewünschte) Fehler-machen-dürfen. Ohne das, kein Lerneffekt.

Im XP haben wir schon recht früh auf Simulation und Prozessminiatur gesetzt. Ganz nach dem XP-Prinzip der kleinen Anfangsinvestition kann man so XP spielerisch erfahrbar machen. Um ein ganzes Projekt in einer guten Stunde zu simulieren, gibt es zwei Spielarten. Beide machen sie einen Heidenspaß, fokussieren jedoch auf unterschiedliche Aspekte:

Extreme Hour

Die Extreme Hour (von Peter Merel) dreht 6-7 Iterationen à 10 Minuten. Das Team besteht aus Entwicklern, Kunden, QA, Tracker und Coach. Ihre Aufgabe ist es, z. B. eine bessere Mausefalle zu entwickeln oder einen modernen Haushaltsroboter. Die Arbeitsergebnisse werden typischerweise in Story-Form skizziert, programmiert wird nicht.

Vorteile

  • explizite Teamrollen und -verantwortlichkeiten
  • realistische (wenn auch extreme) Timebox
  • setzt viel Kommunikation voraus
  • produziert natürliche Integrationsaufwände

Nachteile

  • Abnahmekriterien nur relativ vage (man muss sich einigen :-)
  • Iterationen neigen in der XH dazu, den Fokus auf bestimmte Aktivitäten zu lenken, dadurch ein wenig zu wasserfallartig
  • wenig bis gar kein vergleichendes Aufwandsschätzen möglich

XP-Game

Im XP-Spiel (von Vera Peeters und Pascal Van Cauwenberghe) sind die Iterationen noch kürzer: exakt 120 Sekunden. Das Team teilt sich im wesentlichen auf Entwickler und Kunden auf, plus Tracker (mit Stoppuhr). Zu erledigen sind echte, physikalische Aufgaben, wie Kartenhäuser bauen, Luftballons aufpusten oder Rätsel lösen.

Vorteile

  • Aufgaben haben harte Abnahmekriterien
  • trainiert Aufwandsschätzung über mehrere Iterationen

Nachteile

  • weniger Teamarbeit, keine Integration, wenig Kommunikation
  • Iterationen fast zu spielerisch (Aufgaben werden einzeln gestoppt)
  • Aufgaben relativ isoliert voneinander

XP-Programmierpraktiken vermitteln sie beide nicht. Die Extreme Hour konzentriert sich mehr auf Teamrollen, Kommunikation und Integration. Das XP-Game veranschaulicht dagegen besser den Planungsprozess, das vergleichende Schätzen und das "Wetter von gestern". Je nach dem, was im Mittelpunkt stehen soll, wähle man die eine oder andere Simulation. Für alle, die's selbst ausprobieren wollen, viel Spaß:

Materialien

20.11.2006

Breaking News:
Extreme Programmierer zetteln Aufstand an

Einen weiteren kleinen Schatz möchte ich ebenfalls nicht für mich behalten. Im Frühjahr 2001 zettelten Tammo und ich in unseren ersten XP-Vorträgen die große Revolution an. Die ersonnenen Aufstände blieben jedoch aus. Bis heute. Wir waren jünger und naiver. Damals:

XP, der Aufstand der Programmierer?

Wir wollen Qualität abliefern.

Wir wollen wissen, was der Kunde in welcher Reihenfolge entwickelt haben möchte.

Wir wollen Unterstützung von Kollegen und Kunden bekommen, wenn wir sie brauchen.

Wir wollen unsere eigenen Abschätzungen machen und sie aktualisieren dürfen.

Wir wollen Verantwortlichkeit übernehmen und sie nicht zugewiesen bekommen.

XP, der Aufstand der Kunden?

Kunden wollen wissen, was bis wann und zu welchen Kosten erreicht werden kann.

Kunden wollen aus jedem Personentag den maximalen Wert ziehen.

Kunden wollen den Projektfortschritt sehen.

Kunden wollen ihre Meinung ändern können.

Kunden wollen Planänderungen so früh wie möglich erfahren; Kunden sollten jederzeit aussteigen können.

Kunden wollen nicht belogen werden.

20.11.2006

Generative Regeln
schaffen reiches Verhalten

Vor ein paar Tagen habe ich ein paar alte Vortragsfolien wieder entdeckt … die ich überraschend gut finde. Für eine Konferenz im Herbst 2002 in Helsinki hatte ich mich von Dee Hock (Gründer von VISA) anstecken lassen und XP in Form einfacher, generativer Regeln vorgestellt. Hock hat die Chaostheorie auf Organisationen angewandt; heraus kamen chaordische Organisationen (Wortkreuzung aus Chaos und Ordnung) und ein tolles Buch: Birth of the Chaordic Age. Seine Schlussfolgerung war:

Einfache, klare Ziele und Prinzipien führen zu komplexem, intelligenten Verhalten. Komplexe Regeln und Vorschriften führen zu einfachem, dummen Verhalten.

Daraus motiviert habe ich meine damaligen XP-Regeln aufgestellt. Einige klingen aus heutiger Sicht schon gar nicht mehr extrem. Und zu viele sinds. Wobei ich allerdings auch nicht wüsste, was ich weglassen sollte:

program in pairs

motivate each change of program behavior with an automated unit test

refactor the code into its simplest form

integrate your code as often as necessary

check every requirement with an automated acceptance test

ship a working system with new valuable functionality at least every 2 weeks

release the system at least every few weeks to users outside the team

customer is always available to answer questions

whole team works together in an open space area

have a standup meeting every day at the same time

align authority and responsibility

always work on the most important business problem

plan a little bit every day, for the iteration every 2 weeks, for the release every 3 months

design for today

periodically reflect on your process and tune it

always have enough time to complete your job

27.1.2005

Industrial XP

Diese Woche habe ich die OOP-Konferenz in München besucht. Mein Vortrag dort drehte sich um die Fragen:

  • Was hat Extreme Programming (XP) über die bekannten Programmierpraktiken hinaus für Planung und Management von Softwareprojekten zu bieten?
  • Wie hat sich XP aus den Erfahrungen der vergangenen fünf Jahre weiterentwickelt?
  • Was muss man beachten, damit sich Agilität nicht nur im Entwicklungsbereich, sondern im Geschäft selbst niederschlägt?
  • Wie funktioniert XP in größeren Teams und Organisationen?

Darüber hinaus habe ich diskutiert, wie wir Softwareentwicklung als Wertschöpfungsprozess verstehen sollten, was die zweite Auflage von XP an Neuerungen zu bieten hat und was Lean Development bedeutet.

Nachfolgend präsentiere ich einen Abriss der nicht-technischen Praktiken von Industrial XP: Assessments, Business Stories, Charters und mehr.

Was ist Industrial XP?

  • XP für große Teams und Organisationen
    • verfeinert die vorhandenen Praktiken
    • erweitert das Repertoire um neue Praktiken für alle Projektbeteiligten
  • macht implizites XP-Wissen explizit
    • betont immer die Aspekte, die in der Praxis am sträflichsten vernachlässigt werden

Werte und Praktiken

Werte und Praktiken von Industrial XP

 

Readiness Assessment

  • Ist die Project Community und Organisation bereit zur Veränderung?
  • Kann die Project Community mit XP erfolgreich sein?
    • initiale Bewertung
    • ständige Neubewertung

Assessments

  • offene Arbeitsumgebung?
  • Pairingmöglichkeiten? Möbel? Kernzeit?
  • Domänenexperten verfügbar?
  • untestbarer Legacy Code? Refactoringtools?
  • Codeeigentümer?
  • Datenbank zugreifbar? Schema änderbar?

Risk Management

  • Welche Projektrisiken bestehen?
  • Was können wir gegen sie unternehmen?
    • Top 10 technische Risiken
    • Top 10 organisatorische Risiken

Projektrisiken

Risikomatrix
  1. Sind diese Risiken zu hoch, um das Projekt weiterzuführen? Falls nein, wie lassen sich diese Risiken mindern?
  2. Diese Risiken fortlaufend nach Auslösern überwachen, die sie zum größeren Risiko werden lassen.
  3. Nur angehen, wenn nichts besseres zu tun.

Project Chartering

  1. Lohnt sich die Projektidee überhaupt?
  2. Wie wird die Vision/Mission der Organisation durch das Projekt unterstützt?
  3. Woran erkennen wir einen Projekterfolg?
  4. Wer zählt zur Project Community?

Charter

  1. Vision und Mission-Statement
  2. Project Community
  3. Werte
  4. verpflichtete Resourcen
  5. Erfolgsmaßstäbe
  6. Kontextdiagramm

Project Community

  • Wer hat Einfluss auf den Projekterfolg?
  • Wen betrifft das Projekt?
    • häufig ein wesentlich größerer Personenkreis als zunächst angenommen

Werte

  • Welche Werte teilt die Project Community?
  • Sind die Werte mit den XP-Praktiken zu vereinbaren?
    • wenn ja, lassen wir uns in unserem Handeln durch die Werte leiten
    • wenn nein, müssen wir eine andere (agile) Methode in Betracht ziehen

Test-Driven Management

  • Welche Erwartungen an das Projekt bestehen aus Managementsicht?
    • interne Tests: auf Ebene der IT-Abteilung
    • externe Tests: auf Organisationsebene

Business Stories

Apple's Managementtest für den iTunes Music Store:

"Our new service will register at least 1 million song downloads during its first month in production."

SMART: Specific, Measurable, Achievable, Relevant, Time-Based

Retrospectives

  1. Was lief gut, was nicht vergessen werden sollte?
  2. Was haben wir gelernt?
  3. Was sollten wir nächstes Mal anders machen?
  4. Was stört uns immer noch?
  5. Was müssen wir noch näher diskutieren?

Iterationsretrospektiven

Retrospektiveergebnisse

Links

20.1.2001

Software-Expedition

Julian Mack hat eine sehr interessante Dissertation vorgelegt und in seiner Arbeit untersucht, in wie weit das Leitbild einer Expedition zu einem besseren Verständnis für Softwareentwicklungsvorhaben führen kann.

Die Software-Expedition ist insbesondere in der Kombination mit XP sehr spannend, da viele Parallelen bestehen.

Nachtrag 12.07: Bislang habe ich hier für Julian einige PDFs gehostet … nun widmet Julian seiner Software-Expedition eine eigene Website.