Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 Schlank oder untergewichtig? Erfahrungen beim Einsatz von eXtreme Programming (XP) Kerstin Dittert © Copyright Kerstin Dittert.

Ähnliche Präsentationen


Präsentation zum Thema: "1 Schlank oder untergewichtig? Erfahrungen beim Einsatz von eXtreme Programming (XP) Kerstin Dittert © Copyright Kerstin Dittert."—  Präsentation transkript:

1 1 Schlank oder untergewichtig? Erfahrungen beim Einsatz von eXtreme Programming (XP) Kerstin Dittert © Copyright Kerstin Dittert

2 2 Was ist XP? ein leichter Softwareentwicklungsprozess entwickelt von Kent Beck erstmalig eingesetzt im Chrysler-Projekt C3 (1997) C3 war zuvor mit einem anderen Vorgehen aufgesetzt worden von Chrysler als gescheitert erklärt Kent Beck übernahm das Projekt alle bisherigen Ergebnisse wurden weggeworfen XP-Methodik wurde eingesetzt das Projekt wurde erfolgreich abgeschlossen (time & budget) damaliges Einsatzgebiet: Projekte, bei denen es nichts mehr zu retten gab © Copyright Kerstin Dittert

3 3 Zeit XP und andere Vorgehensmodelle Analyse Design Realisierung Test Wasserfallmodelliterative Prozesse (z.B. RUP, OEP)XP © Copyright Kerstin Dittert

4 4 Elemente der XP-Methodik Planspiel Priorisierung der Anforderungen "Business value first" Projektmetapher starke Einbeziehung der Fachabteilung "On-Site-Customer" Einfaches Design kurze Iterationen Permanente Integration Automatisches Testen Programmieren in Paaren Code-Kollektiv © Copyright Kerstin Dittert

5 5 Planspiel und Projektmetapher Gemeinsame Planung durch Entwicklungsteam Fachabteilung Planspiel grobe Festlegung des Funktionsumfang des Gesamtsystem Granularität: grob beschriebene Anwendungsfälle Projektmetapher beschreibt die Fachlichkeit des Systems erleichtert die Kommunikation Priorisierung: "Business value first" Fachabteilung legt fest, was am wichtigsten ist Wirtschaftlicher Mehrwert zählt Wichtiges  zuerst implementieren! © Copyright Kerstin Dittert

6 6 On-Site-Customer Mitarbeiter der Fachabteilung stehen dem Projekt permanent zur Verfügung aktive Mitarbeit bei der... Klärung fachlicher Fragen Priorisierung von Anforderungen Planung Testfallerarbeitung © Copyright Kerstin Dittert

7 7 Mit welcher Wahrscheinlichkeit schlägt das Projekt fehl, wenn ein Mitarbeiter das Projekt verlässt? (m.a.W.: vom Truck überfahren wird) hoher Truck-Faktor das Team besteht aus Spezialisten jeder kennt "seinen" Teil perfekt jeder kennt ausschliesslich seinen Teil niedriger Truck-Faktor jeder hat Einblick in alle Bereiche der Anwendung  Collective Code-Ownership Truck-Faktor © Copyright Kerstin Dittert

8 8 Programmierer arbeiten stets zu zweit an einem Arbeitsplatz ein Teammitglied programmiert der Partner steht für Fragen und Diskussionen zur Verfügung er übernimmt implizit Review-Aufgaben (Code und Design) Die Paar-Konstellationen wechseln regelmäßig Niemand besitzt Rechte an "seinem" Code Das Wissen über die verschiedenen Anwendungsteile wird im Team verteilt Truck-Faktor gering Ausgeprägter Coaching-Effekt Pair Programming und Code-Kollektiv © Copyright Kerstin Dittert

9 9 Testen und Integration "Test before coding" Testfall wird vor der Implementierung der Logik geschrieben Zu jeder neuen Klasse gehört auch ein Testfall Permanente Integration Code-Integration: wenn alle Testfälle erfolgreich verlaufen Minimiert die Gefahr von Seiteneffekten Stabilität und Erweiterbarkeit nehmen deutlich zu Automatische Testdurchführung zwingend notwendig manuelle Test sind bei sehr kurzen Iterationen unwirtschaftlich Testwerkzeuge (z.B. JUnit) JUnit  Geschäftslogik, Applikationslogik für GUI: kommerzielle Testwerkzeuge einsetzen © Copyright Kerstin Dittert

10 10 Refactoring Verbesserung der bisherigen Implementierung Design Code Häufige Anwendungen Generalisierung Einführung von Schnittstellen Bereinigung von "fast-hacks" Entfernen von debug-Ausgaben und-und-und... Wichtig für Stabilität der Anwendung Motivation im Team (Anspruch an die Qualität der eigenen Arbeit) © Copyright Kerstin Dittert

11 11 Architektur und Design grundlegende Architektur wird am Anfang festgelegt, z.B. Schichtenmodell grobe Komponentenaufteilung Design wird von den Paaren entwickelt keine umfangreiche Dokumentation Bei Bedarf Diskussion und Entwurf in größerer Gruppe Handskizzen, Whiteboard-Entwürfe etc. reichen aus Klassendiagramme, Sequenzdiagramme etc. werden nur erstellt, wenn sie für das Verständnis im Team benötigt werden! © Copyright Kerstin Dittert

12 12 Iterationsplanung Gemeinsame Planung Fachabteilung (FA) und Entwicklungsteam (ET) fördert das gegenseitige Verständnis bezüglich  Technik  Fachlichkeit Feinplanung FA: Welche Anwendungsfälle werden als nächstes implementiert? ET: Wie hoch ist der Realisierungsaufwand dafür? Aufwand pro Iteration zu gross  Fachabteilung reduziert den Funktionsumfang zu klein  Fachabteilung fügt Funktionalität hinzu © Copyright Kerstin Dittert

13 13 Iterationen im Projektverlauf Ergebnis einer Iteration lauffähige Programm-Version viele kurze Iterationen Konfigurations- und Testmanagement sind wichtig! Länge einer Iteration steht fest keine Verlängerung einer Iteration bei drohenden Zeitüberschreitungen: Reduktion des Funktionsumfangs (Time-Boxing) © Copyright Kerstin Dittert

14 14 Eigene Erfahrungen Neuentwicklung, d.h. fachliche Analyse Architektur- und Design-Entwurf Implementierung, Test und Einführung Anwendung zur Finanzierungsplanung ca. 30 Fachmasken geplante Einführung: 4 Monate nach Projektstart Teamgrösse: 7 Mitarbeiter Rollen im Team: 2 Mitarbeiter DB 2 Mitarbeiter OOA/OOD 4 Mitarbeiter OOP 1 Mitarbeiter Projektleitung Projektumfeld © Copyright Kerstin Dittert

15 15 Licht... Hohe Qualität  durch Pair-Programming und Refactoring permanente Reviews "Krummes Design" wird vom Partner sofort bemängelt Regelmäßige Redesign-Phasen (Refactoring) Maß für den Erfolg ist das lauffähige Programm (anstelle der Seitenzahl von Spezifikationen oder Dokumentationen)  robuster und wartungsfreundlicher Code Konzentration auf das Wesentliche  durch "Business value first" und kurze Iterationen Vermeidung "goldener Wasserhähne" implementiert wird das, was konkret benötigt wird  pünktliche Auslieferung des ersten Release © Copyright Kerstin Dittert

16 16... noch mehr Positives Hohe Motivation im Team  durch Collective-Code-Ownership Gleichstellung im Team Möglichkeit, über den eigenen Horizont hinaus zu gucken Einhaltung der Qualitätsanforderungen  durch Refactoring Leichte Integration von "Anfängern"  durch Pair-Programming Coach ist ständig verfügbar Coach wechselt kaum Zusatzaufwand  hohe Produktivität !!! © Copyright Kerstin Dittert

17 17 Schwierigkeiten "On-Site-Customer" liess sich kaum verwirklichen Starke Einbindung der Fachabteilung in das Tagesgeschäft Planspiel konnte nicht mit der Fachabteilung durchgeführt werden Planspiel wurde als "Spielerei" betrachtet Nicht alle Testszenarien können durch automatische Test abgedeckt werden Viele kommerzielle Systeme  sind datenzentriert  bilden Prozesse in der GUI-Ablaufsteuerung ab  besitzen nur wenig Fachlogik GUI-Steuerung ist schwierig zu testen © Copyright Kerstin Dittert

18 18 Fazit Einbindung der FA schwierig hohe Motivatio n "Anfänger" : leichte Integration Blick über den Tellerrand wartungs- freundlich läuft ! hohe Qualität Termi ntreue hohe Zufriede n-heit automatische Testabdeckun g < 100% Kräfte zehrend © Copyright Kerstin Dittert

19 19 Für welche Art von Projekten ist XP geeignet Team klein (< ca. 15 ) Profis und Anfänger können leicht gemischt werden!!! Verteilung alle Mitarbeiter sollten sich am gleichen Standort befinden  direkte Kommunikation  Wechsel beim Pair-Programming  permanente Integration Fachabteilung aktive Mitarbeit nötig © Copyright Kerstin Dittert

20 20 Einsatz der Methode Je mehr, desto besser möglichst alle Elemente gemeinsam einsetzen manche Methoden erzwingen den Einsatz einer weiteren Beispiel: Permanente Integration ohne automatische Tests  unmöglich! Auch solo einsetzbar Pair-Programming Refactoring Automatische Tests Kurze Iterationen © Copyright Kerstin Dittert

21 21 Pair Programming Arbeitsumfeld Schreibtisch und Monitor für zwei Personen geeignet Rückzug in "Privatspähre" möglich  z.B. um s zu bearbeiten  Falls möglich: Einrichtung spezieller Paar-Arbeitsplätze, zusätzlich zu den Arbeitsplätzen der einzelnen Mitarbeiter Arbeitsorganisation alle Mitarbeiter in räumlicher Nähe gemeinsame Arbeit im Paar max. 6 Stunden pro Tag Team-Mitarbeiter dürfen nicht auf "ihrem" Code beharren können 90%-Lösungen akzeptieren "Detaillisten" und "Sammler" sprengen das Team © Copyright Kerstin Dittert

22 Hier besser nicht... Kritische fachliche Aufgaben möglicher Verlust oder Gefährdung von Menschenleben,  z.B. Medizintechnik,  Flugtechnik,  etc. potentieller hoher materieller Verlust, z. B.  Zahlungsverkehr  Billing-Systeme  Maschinensteuerung  etc. Diese Systeme stellen erhöhte Anforderungen an Fehlerfreiheit Stabilität Robustheit Testszenarios und Qualitätssicherung können nicht allein dem Entwicklungsteam überlassen werden 22 Stopp © Copyright Kerstin Dittert

23 23 Mehr Infos Kerstin Dittert Ich freue mich auf gemeinsame Projekte mit Ihnen! © Copyright Kerstin Dittert


Herunterladen ppt "1 Schlank oder untergewichtig? Erfahrungen beim Einsatz von eXtreme Programming (XP) Kerstin Dittert © Copyright Kerstin Dittert."

Ähnliche Präsentationen


Google-Anzeigen