Schlagwort
agileentwicklung
29.3.2008
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
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
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
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
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 (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 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:
- Softwareentwicklung soll Spaß machen. Tut sie das nicht, ist der
Prozess defekt.
- Jedes Projekt und jedes Team ist einzigartig und benötigt damit
seinen eigenen maßgeschneiderten Prozess.
- 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.
- Ihr Entwicklungsprozess ist ein wanderndes Ziel. Sie sollten ihn
ständig verbessern und ihn an Ihre örtlichen Begegebenheiten
anpassen.
- Es muß nicht unbedingt XP sein. Leichtgewichtigkeit an sich kann
schon ein wertvolles Ziel sein.
Weitere Links
15.3.2007
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.
30.11.2006
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
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
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
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
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
- Sind diese Risiken zu hoch, um das Projekt weiterzuführen? Falls nein, wie lassen sich diese Risiken mindern?
- Diese Risiken fortlaufend nach Auslösern überwachen, die sie zum größeren Risiko werden lassen.
- Nur angehen, wenn nichts besseres zu tun.
Project Chartering
- Lohnt sich die Projektidee überhaupt?
- Wie wird die Vision/Mission der Organisation durch das Projekt unterstützt?
- Woran erkennen wir einen Projekterfolg?
- Wer zählt zur Project Community?
Charter
- Vision und Mission-Statement
- Project Community
- Werte
- verpflichtete Resourcen
- Erfolgsmaßstäbe
- 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
- Was lief gut, was nicht vergessen werden sollte?
- Was haben wir gelernt?
- Was sollten wir nächstes Mal anders machen?
- Was stört uns immer noch?
- Was müssen wir noch näher diskutieren?
Iterationsretrospektiven
Links
20.1.2001
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.
