Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D Braunschweig

Größe: px

Ab Seite anzeigen:

Download "Extreme Programming. Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D-38122 Braunschweig"

Sara Becker
vor 8 Jahren
Abrufe

1 Extreme Programming Frank Gerberding LINEAS Informationstechnik GmbH Theodor-Heuss-Straße 2 D Braunschweig Stand:

2 LINEAS Gruppe - Zahlen und Fakten LINEAS Gruppe Branche Software- und Beratungshaus Gegründet 1987 Dienstleistung Beratung und Konzepte Entwicklung kundenspezifischer Software Systemintegration und -administration Umsatz in 2006 ca. 18,5 Mio. EUR (Gesamtleistung) Mitarbeiter ca. 200 Mitarbeiter/innen Standorte Braunschweig, Dortmund, Wolfsburg, Nürnberg, München, Stuttgart Zertifizierung DIN EN ISO 9001:

-administration Umsatz in 2006 ca. 18,5 Mio. EUR (Gesamtleistung) Mitarbeiter ca.

3 LINEAS Gruppe LINEAS Systeme LINEAS GmbH Systeme Braunschweig AG Braunschweig LINEAS Informationstechnik GmbH LINEAS Project Services GmbH LINEAS LINEAS Automotive GmbH GmbH LINEAS Healthcare GmbH LINEAS LINEAS International Business GmbH GmbH AIRPAS Aviation AG

GmbH LINEAS LINEAS Automotive GmbH GmbH LINEAS Healthcare GmbH

4 Überblick Geschichte Extreme Programming im Kontext anderer Entwicklungsmethoden Praktiken, Werte, Grundsätze Warum ist Extreme Programming so wie es ist? Werte Grundsätze Praktiken Primäre Praktiken Folge-Praktiken Zusammenfassung

5 Geschichte XP expl. 2nd Ed. V-Modell XT AUP RUP Agile Manifesto EUP DSDM FDD XP explained XP V-Modell Spiralmodell Scrum V-Modell Wasserfallmodell (1970)

Manifesto EUP DSDM FDD XP explained XP V-Modell 97 1990

6 Praktiken, Werte, Grundsätze Praktiken Praktiken, Techniken, die jeder beherrschen sollte Handwerkszeug Wie wird etwas gemacht Werte Bilden Grundlage für jede Tätigkeit auch in der Software-Entwicklung Warum wird etwas gemacht Grundsätze Bilden Brücke zwischen Werten und Praktiken Machen aus dem "Warum" das "Wie"

für jede Tätigkeit auch in der Software-Entwicklung Warum wird etwas gemacht

7 Werte Kommunikation Voraussetzung für Teamarbeit, häufig Problem in IT-Projekten Einfachheit Wichtigster Wert bei XP Feedback Je früher man Feedback bekommt, desto eher kann man reagieren Mut Wird oft für unbequeme Handlungen benötigt Respekt Grundlage für alle anderen Werte Jedes Teammitglied hat gleichen Wert, jede Meinung ist wichtig

kann man reagieren Mut Wird oft für unbequeme Handlungen benötigt Respekt Grundlage für

8 Grundsätze (I) Menschlichkeit Software wird von Menschen entwickelt Wirtschaftlichkeit Jemand muss alles bezahlen Prioritäten setzen Gegenseitiger Nutzen Wichtigster XP-Grundsatz Jeder akzeptiert etwas leicht wenn er Nutzen für sich sieht Selbstähnlichkeit Wenn etwas im Kleinen funktioniert, funktioniert es oft auch im Großen Verbesserung»In software development, "perfect" is a verb, not an adjective«vielfalt Verschiedene Teammitglieder sind von Vorteil Unterschiedliche Erfahrungen und Kenntnisse Reflektion Gute Teams analysieren Erfolge und Misserfolge "Reflection comes after action"

funktioniert es oft auch im Großen Verbesserung»In software development, "perfect" is a verb, not an adjective«vielfalt Verschiedene Teammitglieder

9 Grundsätze (II) Fluss Kleine Releases verbessern Feedback Gelegenheiten Probleme sind Gelegenheiten für Veränderungen Redundanz Probleme auf mehrere Arten lösen Kosten der Redundanz sind geringer als die eines Desasters Misserfolge Aus ihnen kann man viel lernen Anstatt lange zu diskutieren: ausprobieren Qualität Qualität ist keine Kontrollvariable Kleine Schritte Viele kleine Schritte anstatt weniger großer Akzeptierte Verantwortung Verantwortung kann nicht zugewiesen sondern nur akzeptiert werden

lernen Anstatt lange zu diskutieren: ausprobieren Qualität Qualität ist keine Kontrollvariable Kleine Schritte Viele kleine

10 Primäre Praktiken (I) Sit Together Räumliche Nähe unterstützt Kommunikation Whole Team Für jede Aufabe gibt es mindestens ein Teammitglied Team-Mitglieder wechseln, gehören aber immer zu 100% zum Team Informative Workspace z.b. Wand mit Story-Cards In 15 Sekunden aktuellen Projektstatus erkennen können Energized Work keine Überstunden Erholt und gesund arbeiten können Pair Programming Einige Stunden pro Tag Alle paar Stunden Partner wechseln Stories Jede Aufgabe ist Story Stories werden sofort abgeschätzt Stories können auf Wand geheftet werden (z.b. zur Status-Anzeige) Stories bestehen aus Tasks

r immer zu 100% zum Team Informative Workspace z.b.

11 Primäre Praktiken (II) Weekly Cycle Planung der Woche Schreiben der Tests, Implementierung bis Tests laufen Quarterly Cycle Vierteljährliche Grobplanung Slack Immer etwas "Luft" mit einplanen Evtl. Zusatz-Tasks einplanen Continuous Integration Mindestens alle paar Stunden komplettes System bauen Ten-Minute-Build System bauen und testen: nicht länger als 10 Minuten Dauer Nur automatische Tests Test-First-Programming Zuerst Test schreiben Dann solange implementieren bis Test erfolgreich ist Incremental Design Ständige Verbesserung des Designs Erfahrungen fließen durch Refactoring in Design ein

Zusatz-Tasks einplanen Continuous Integration Mindestens alle paar Stunden komplettes System bauen Ten-Minute-Build System bauen und testen: nicht

12 Folge-Praktiken (I) Real Customer Involvement Kunde ist Teil des Teams, kann realitätsnahe Tests definieren, kennt Anforderungen, kann Planung mitgestalten Incremental Deployment Änderungen an bestehenden Systemen in kleinen Schritten Team Continuity Beziehungen und Vertrauen zwischen Menschen sind wichtig Teams sollten nur mit Bedacht geändert werden Shrinking Teams Team sollte immer nur so groß sein wie nötig Root-Cause Analysis Fehler werden zunächst behoben Anschließend wird analysiert warum es zu einem Fehler kam Shared Code Viele Entwickler kennen viele Teile des Codes Viele Entwickler können viele Teile des Code ändern

sollten nur mit Bedacht geändert werden Shrinking Teams Team sollte immer nur so groß sein wie nötig Root-Cause Analysis Fehler werden zunächst behoben

13 Folge-Praktiken (II) Code and Tests Code und Tests sind wichtigste Ergebnisse Möglichst alles andere daraus generieren Single Code Base Mehrere Versionen sind aufwändig zu pflegen Daily Deployment Die Lücke zwischen Implementierung und Deployment von Features sollte so klein wie möglich sein Viele Voraussetzungen sind nötig um dies zu erreichen Negotiated Scope Contract Kosten, Zeit und Qualität sollten vertraglich fix sein, der Umfang sollte Spielraum haben Lieber viele kleine Verträge als einen großen Pay-Per-Use Bezahlung z.b. pro Transaktion oder Quartal Liefert hilfreiche Informationen zur Verbesserung des Systems Unterstützt viele andere Praktiken (z.b. iteratives Vorgehen, Weekly Cycle)

Negotiated Scope Contract Kosten, Zeit und Qualität sollten vertraglich fix sein, der Umfang sollte Spielraum haben Lieber viele kleine Verträge als einen großen Pay-Per-Use

14 Zusammenfassung Extreme Programming ist Agile Software- Entwicklung Leichtgewichtiger Prozess Wenig Bürokratie Praktiken sind teilweise schwierig umsetzbar Weil Kunde nicht mitspielt Weil Praktiken sich nach und nach etablieren müssen XP muss nicht vollständig umgesetzt werden Praktiken können einzeln eingeführt werden Viele Praktiken profitieren aber voneinander Kosten Anforderungen Analyse Konventionelle Annahme Extreme Programming Design Implementierung Test Produktion Zeit

nicht vollständig umgesetzt werden Praktiken können einzeln eingeführt werden Viele Praktiken profitieren aber voneinander

15 Stand: Vielen Dank für Ihre Aufmerksamkeit

Ähnliche Dokumente

extreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?