6 Jahre extreme Programming Eine Retrospektive

Größe: px

Ab Seite anzeigen:

Download "6 Jahre extreme Programming Eine Retrospektive"

Carsten Sauer
vor 8 Jahren
Abrufe

1 6 Jahre extreme Programming Eine Retrospektive Dipl.-Informatiker Martin Lippert Senior IT-Berater

2 Hintergrund Senior IT-Berater bei it-agile GmbH extreme Programming seit Anfang 1999 Kommerzielle Projekte 2 bis 30 Entwickler 11 Wochen bis 3 Jahre Große Erfolge... sehr kurze Projektlaufzeiten Software mit hohem Nutzen für Anwender und Unternehmen engagierte Entwickler exzellente Planbarkeit und Controlling... und herbe Rückschläge degenerierter Code, Strukturverlust der Architektur Umfeld nicht bereit Risikobereitschaft als Bumerang

.. sehr kurze Projektlaufzeiten Software mit hohem Nutzen für Anwender und Unternehmen engagierte Entwickler

3 Inhalt Die grundlegenden Ideen Wie alles anfing Was seitdem passierte Wo XP heute steht Wohin es weitergeht Danksagung: Jens Coldewey Jutta Eckstein Torsten Fink Christoph Kemp Johannes Link Henning Wolf Stefan Roock

Jens Coldewey Jutta Eckstein Torsten Fink Christoph Kemp

4 Money, Money, Money Der Nutzen der Software muss ihre Kosten übersteigen

5 Der Prozessansatz Kunde Entwickler 1. Anforderungen 2. Aufwandsschätzung 3. Priorisierung 4. Funktionalitäten

6 Die Verantwortlichkeiten Kunde Entwickler 1. Anforderungen 2. Aufwandsschätzung 3. Priorisierung 4. Funktionalitäten Verantwortlich für Geschäftswert Verantwortlich für Technologie

Funktionalitäten Verantwortlich für Geschäftswert

7 Nichts entwickeln, was nur rumliegt! Systemeinsatz Saldo in EUR später realisieren jetzt realisieren Heute Heute + 1 Jahr Zeit

8 Deliver Early, Deliver Often Software-Funktionalitäten möglichst früh einsetzen

9 Typischer zeitlicher Projektverlauf Release- Planung (Release <6 Monate) Erstes Release häufig Exploration Iterationsreview Release- Review. I.d.R. Auslieferung Release Release Iteration Aufgabe Aufgabe Aufgabe Iteration Aufgabe Aufgabe Aufgabe Iteration Aufgabe Aufgabe Aufgabe Iteration Aufgabe Aufgabe Aufgabe Iteration Aufgabe Aufgabe Aufgabe Iteration Aufgabe Aufgabe Aufgabe Iterationsplanung (Iteration <1 Monat) Aufgaben sind i.d.r. so geschnitten, dass der Kunde die Erledigung feststellen kann

Aufgabe Aufgabe Iteration Aufgabe Aufgabe Aufgabe Iteration Aufgabe Aufgabe Aufgabe Iteration Aufgabe Aufgabe Aufgabe

10 Nomenklatur Release heißt auch Milestone oder Inkrement. Es gibt innerhalb einer Iteration keine Meilensteine. Es kann aber innerhalb einer Iteration Auslieferungen geben (Bsp.: Daily Deployment). Aufgabe heißt auch Task, Story, Feature oder Episode. Mitunter gilt: Feature besteht aus Stories. Story besteht aus Tasks

Es kann aber innerhalb einer Iteration Auslieferungen geben (Bsp.: Daily Deployment).

11 XP-Techniken

12 Eine Retrospektive Was ist passiert? Was haben wir gelernt?

13 1999: Das XP-Manifest 1/2 Kent Beck provoziert und stellt vieles von dem in Frage, was als Stand der Kunst und Common Sense gilt. 80% XP bringt nur 20% des Nutzens? Wem XP nicht passt, der fliegt aus dem Team? Wie soll das denn funktionieren?

14 1999: Das XP-Manifest 2/2 Umfeldfragen bleiben offen. Festpreisverträge Planung, Schätzung und Controlling großer Projekte Kein Kunde vor Ort Inhomogene Entwicklerteams Testen bei Multithreading, Datenbanken, GUI, etc. Embedded Systems, Echtzeitsysteme Technologien mit langen Turn-Around-Zeiten (C, C++) Kosten-Nutzen-Analyse (Pair-Programming, Unit-Tests)

Entwicklerteams Testen bei Multithreading, Datenbanken, GUI, etc.

15 2005: V-Modell XT XT = extreme Tailoring

16 2005: Standish-Group: Chaos-Report

17 The-Eclipse-Way

18 Timeline 1/4 C3- Projekt beginnt XP Begriff XP zum ersten Mal in der Öffentlichkeit (OOPSLA) Ward Cunningham: EPISODES Smalltalk- Refactoring- Browser

1997 1998 Ward Cunningham: EPISODES Smalltalk-

19 Timeline 2/4 Kent Beck beim Arbeitskreis Objekttechnologie XP- Conference in Sardinien Kerth: Project Retrospectives Agiles Manifest SCRUM- Buch extreme Programming explained ASD-Buch C3-Projekt beendet Cockburn: Agile Software Development

SCRUM- Buch 1999 2000 2001 extreme Programming explained ASD-Buch

20 Timeline 3/4 Bücher, Bücher, Bücher Lean Software Development Zweite Auflage extreme Programming explained FDD- Buch XP-Gurus treten in den Hintergrund

explained 2002 2003 2004 FDD- Buch XP-Gurus treten

21 Timeline 4/4 V-Modell XT Standish Group empfiehlt agile Methoden

22 Buch-Neuerscheinungen bei Amazon 1/2 Agile Methoden XP SCRUM FDD Agil Summe Agil

23 Buch-Neuerscheinungen bei Amazon 2/2 XP vs. UP XP UP & RUP

24 Die Wissenschaft JUnit Pair-Programming Mehrere eigene regelmäßige Konferenzen zu agilen Themen (XP-Conference, Agile, etc.). Agile Themen sind ständige Vertreter auf allgemeinen großen Konferenzen (OOPSLA, etc.)

25 Die IT-Wirtschaft Agile Alliance hat über Mitglieder Eigene regelmäßige wirtschaftsnahe Konferenzen zu agilen Themen (XP- Days). Agile Themen auf wirtschaftsnahen Konferenzen ständig vertreten (OOP, JAX, JFS, etc.)

26 XP Success Stories C3 Sabre Airline Solutions (42% produktiver, nur noch 20% der Fehler) Die Agile Alliance hat 79 Case Studies gesammelt, von denen viele Success Stories sind. Im C2-Wiki sind über 100 Unternehmen aufgelistet, die angeben, XP zu machen

27 The-Eclipse-Way: Ein Agiler Prozess

28 Relevanz für die Praxis 1/2 Agile Elemente finden sich in vielen kommerziellen Projekten Einführbar ohne Zustimmung des Kunden und des eigenen Managements. Mechanistische Beschreibung vorhanden. Anordnung nach Ron Jeffries

29 Relevanz für die Praxis 2/2 ABER Sehr wenige Projekte können XP nach erster Auflage XP-Manifest Noch viel weniger können XP nach zweiter Auflage XP-Manifest Erkenntnis für viele Entwickler: XP hörte sich nach dem Paradies an. Beim Ausprobieren stellt sich heraus, dass es sehr harte und verantwortungsvolle Arbeit erfordert. Dann lieber doch nicht? Unit-Tests werden nur unvollständig eingesetzt. Kaum jemand macht durchgängig Test-First

30 Diskussionsschwerpunkte Technik (Unit-Testen, Refactoring ) Management (Tracking, Schätzen ) Kundenrolle (Nutzenorientierung, Planung)

31 Bewertung des aktuellen Zustandes XP ist erwachsen. Umfeldfragen sind geklärt. 2. Generation XP: IXP, 2. Auflage XP-Manifest Die Risiken bei der Verwendung von XP sind bekannt und beherrschbar. Aber: Auch korrekt durchgeführte XP-Projekte können scheitern. Aber: Es gibt Vorbedingungen für agile Methoden. Organisationsstrukturen, Unternehmenskultur, Qualifikation der Entwickler Viele Unternehmen erfüllen diese Voraussetzungen noch nicht und sind daher nicht fit für agil. Die Einführung agiler Methoden bedeutet in diesen Fällen Anpassung des Unternehmens. klare Verantwortlichkeiten, Entscheidungsfreudigkeit änderungsfreundliches Klima lernförderliches Klima

32 Wie geht es weiter mit XP? Was zählt, ist was hinten rauskommt. Welche Teams können Ihren Kunden einen höheren Nutzen versprechen? Z.B.: Niedrigere Entwicklungskosten Niedrigere Betriebs- und Wartungskosten Höhere Entwicklungsgeschwindigkeit Bessere Termintreue Wie hoch können die Verbesserungen sein? Optimierungen oder Quantensprünge?

33 Die Verantwortlichkeiten Kunde Entwickler 1. Anforderungen 2. Aufwandsschätzung 3. Priorisierung 4. Funktionalitäten Verantwortlich für Geschäftswert Verantwortlich für Technologie

34 überfordern viele Kunden Kunde Mit XP können kurze Releasezyklen realisiert werden. Damit kann der Kunde schnell Nutzen aus seinen Investitionen ziehen. Welcher Kunde kann Nutzen seriös berechnen und dann noch vorher? Welche Kunde schafft eine fachlich sinnvolle Projektplanung, die Einzelreleases sinnvoll ordnet? Verantwortlich für Geschäftswert These: XP-Projekte bieten den Kunden Möglichkeiten, mit denen die Kunden gar nichts anfangen können

35 überfordern viele Teams Teams sollen den Entwicklungsprozess selbst anpassen. Dazu ist ständige selbstkritische Reflektion über die eigene Arbeit notwendig. Arbeit wird ständig (minimal) reorganisiert. Entwickler These: Viele Entwicklungsteams nehmen den Entwicklungsprozess nicht in Verantwortung. Verantwortlich für Technologie

36 Was wir wirklich brauchen! Der Kunde braucht professionelle Unterstützung, um seine Rolle in agilen Projekten wahrzunehmen. Einen Quantensprung schaffen wir nur, wenn wir dem Kunden dort methodische Unterstützung bieten können. Entwicklungsteam müssen lernen, ihren Entwicklungsprozess selbst anzupassen

37 Diskussionsschwerpunkte Technik (Unit-Testen, Refactoring ) Management (Tracking, Schätzen ) Kundenrolle (Nutzenorientierung, Planung) Organisation von Unternehmen XX

38 Fazit Gut, dass es XP gibt. Positive Einflüsse von XP auf viele andere Methoden. XP entwickelt sich weiter, wird aber auch unschärfer. XP bedeutet immer noch harte Arbeit und umdenken. Die Potenziale von XP werden kaum ausgenutzt. XP betrifft neben Entwicklern auch Manager, Kunden und Anwender

39 Schluss-Satz In zwanzig Jahren wird man über Wasserfall-Integration und Arbeiten ohne Refactoring lächeln, wie wir heute über Compiler lächeln, die Nachts im Batch laufen. (Vermutung Jens Coldewey)

40 Fragen

Ähnliche Dokumente

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden?

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? Stefan Roock stefan.roock@akquinet.de Hintergrund 1/2 Senior IT-Berater bei der akquinet AG extreme Programming seit Anfang 1999, dann