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