Extreme Programming: Überblick

Größe: px

Ab Seite anzeigen:

Download "Extreme Programming: Überblick"

Mathias Baum
vor 8 Jahren
Abrufe

1 Extreme Programming: Überblick Stefan Diener / Apr 18, 2007 / Page 1

2 Prinzipien Rollen Planung Implementierung Praktiken weitere Vorgehensweisen Grenzen Inhalt Stefan Diener / Apr 18, 2007 / Page 2

3 Prinzipien (Auswahl) strukturiertes Vorgehen kein Chaos! Teamarbeit Offenheit stetige Kommunikation gleichmäßige Auslastung, keine Überstunden gelebtes Risikomanagement Stefan Diener / Apr 18, 2007 / Page 3

4 Rollen Product Owner: z.b. Produktmanagement, Marketing, Kunde hat Verantwortung für das Produkt Kunde: kann identisch mit Product Owner sein Auftraggeber Entwickler: Architekt, Designer, Programmierer, Tester, etc. Projektmanager: z.b. Product Owner oder Entwickler Teamleitung User: Nutzer des Produkts Stefan Diener / Apr 18, 2007 / Page 4

identisch mit Product Owner sein Auftraggeber Entwickler: Architekt, Designer,

5 Release-Planung Planung (1) Anzahl und Dauer (1-4 Wochen) der Iterationen definieren Story Cards erstellen (Kunde) daraus Anforderungen Alternative zu Story Cards: CRC-Cards CRC = Class Responsibility Collaboration beschreibt Akteur und dessen Verantwortlichkeiten und Interaktionen mit anderen Akteuren Stefan Diener / Apr 18, 2007 / Page 5

CRC-Cards CRC = Class Responsibility Collaboration beschreibt Akteur und dessen

6 Planung (2) Nutzen- und Risikoabschätzung der Story Cards Priorisierung: Prio 1: hohes Risiko, hoher Wert Prio 2: niedriges Risiko, hoher Wert Prio 3: niedriges Risiko, niedriger Wert Prio 4: hohes Risiko, niedriger Wert Implementierung der Prio 4 vermeiden Stefan Diener / Apr 18, 2007 / Page 6

Prio 3: niedriges Risiko, niedriger Wert Prio 4: hohes Risiko, niedriger

7 Planung (3) Analyse der Kundenwünsche Must-haves lineare Kundenzufriedenheit Exciters (es geht auch ohne, aber mit erzeut Begeisterung) Aufwandsabschätzung: Story Points relativer Aufwand der Stories (Entwickler) Ergebnis der Planung: Zuweisung von Story Cards zu Iterationen Stefan Diener / Apr 18, 2007 / Page 7

Aufwandsabschätzung: Story Points relativer Aufwand der Stories (Entwickler)

8 Implementierung einer Iteration (1) Iterations-Planung: Zerlegung der User Stories in Tasks Task: techn. Arbeitspaket (Stundenbereich) Verteilung der ersten Tasks im Team Implementierung der Tasks Task beendet: neuen Task zuweisen und implementieren Stefan Diener / Apr 18, 2007 / Page 8

Arbeitspaket (Stundenbereich) Verteilung der ersten Tasks im Team

9 Implementierung einer Iteration (2) Story Card ist beendet, wenn alle zugehörigen Tasks beendet sind Story Card nicht beendet zum Release-Termin: in nächste Iteration verschieben Stefan Diener / Apr 18, 2007 / Page 9

Story Card nicht beendet zum Release-Termin: in

10 Praktiken (1) Pair Programming Kollektives Eigentum (Code und Wissen) Permanente Integration erfordert automatisches Build-System Test Driven Development Einbeziehung des Kunden, On-Site Customer Ständige Refactorings Keep the software soft! Stefan Diener / Apr 18, 2007 / Page 10

Driven Development Einbeziehung des Kunden, On-Site Customer Ständige

11 Keine Überstunden Praktiken (2) kurze Iterationen (1-4 Wochen), ständige Transparenz Coding Standards Einfaches Design, KISS It's easy to have a complicated idea. It's very very hard to have a simple idea. -- Carver Mead Planing Game Planungsphase mit Entwicklern und Kunde Stefan Diener / Apr 18, 2007 / Page 11

complicated idea. It's very very hard to have a simple idea.

12 Stand-up Meetings Weitere Vorgehensweisen tägliche, kurze Besprechung Was wurde erreicht? Was kommt heute? Wo gibt es Probleme? neue Paar-Bildung für Pair Programming (nach Bedarf) nach Release: Feedback von Management und Usern Akzeptanztests, häufiges Feedback Einfluss auf aktuelle Iteration und ggf. Priorisierung/Planung Stefan Diener / Apr 18, 2007 / Page 12

neue Paar-Bildung für Pair Programming (nach Bedarf) nach Release: Feedback von Management

13 Grenzen schwierig einsetzbar in verteilten Umgebungen verschiedene, konkurrierende Kunden verteilte Entwicklungsteams anonymer Kunde, Massenmarkt Teamgröße max. 10 Personen Probleme durch Beweislast, dass Pair Programming die Produktivität steigert Mißtrauen Einbettung in Unternehmenskultur, die XP nicht unterstützt starre Strukturen, starre Vorgehensweisen, Ignoranz Stefan Diener / Apr 18, 2007 / Page 13

10 Personen Probleme durch Beweislast, dass Pair Programming die Produktivität steigert Mißtrauen

Ähnliche Dokumente

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management