Schlagwort

retrospektiven

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

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

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)

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