Projektmanagement SS 02 e Xtreme Programming Part II

Projektmanagement SS 02 e. Xtreme Programming Part II Referenten: Robert Cajer Marcus Stegner Steve Moser 14. Juni 2002

Themen n Was ist XP? n Der Umgang mit Risiken (das Grundproblem der Softwareentwicklung) n Gegenüberstellung herkömmlicher Verfahren (Zeit/Kosten Faktor) n Grundwerte XP im Beispiel n Rollenverteilung n Der Weg zu einer Lösung n Wann ist XP nicht sinnvoll?

Warum e. Xtreme Programming? Extreme programming takes common principles and practices to extreme levels Common principles and practices n „Code reviews“ sind gut Taken to extreme levels ► ständige „code reviews“ ► n Testen ist gut n Integrationstests sind wichtig n Design ist wichtig ► n Einfachheit ist gut ► Architektur ist wichtig n Kurze Iterationen sind gut n ► ► ► „pair programming“ ständiges testen Programmierer: Modultests Kunden: Funktionstests mehrmals am Tag „continuous integration“ ständiges (re)design „refactoring“ alles so einfach wie möglich bzw. so komplex wie nötig Ständige Architektur-Weiterentwicklung extrem kurz: „Minuten bis Stunden“ „planning game“

Was verspricht e. Xtreme Programming? Programmierern: Ø Konzentration auf relevante Dinge Ø Nicht allein sein in schwierigen Situationen Ø Das zu tun, was Mensch am besten kann Kunden und Managern Ø Maximalen Output aus jeder Projektwoche Ø Konkrete Ergebnisse in kurzen Intervallen Ø Kurze Reaktionszeiten bei Änderungen Ø Vertretbarer Aufwand bei Änderungen

Was ist e. Xtreme Programming? Kennzeichen: Ø Kurze Zyklen Ø Ø Ø >sofortiges Feedback Inkrementelles planen >einfacher Anfangsplan wird laufend weiterentwickelt Evolutionärer Entwurf >solange das System im Einsatz ist Automatisches Testen >frühe Fehlererkennung Enge Zusammenarbeit von „normalen“ Programmierern Einklang zwischen >persönlichen, kurzfristigen „Instinkten“ der Programmierer >übergeordneten, langfristigen Projektzielen

Der Umgang mit Risiken - Das Grundproblem der Softwareentwicklung-

Risiko: Termin nicht einhaltbar Am Auslieferungstag verkünden, dass es noch 6 Monate dauert…. . XP Ansatz: Kurze Zyklen § Produkt Releases -> Wochen, höchstens Monate § Iteration innerhalb eines Release -> ein bis vier Wochen § Programmieraufgaben innerhalb einer Iteration -> ein bis drei Tage Zyklen-Definition prioritäts- und risiko-orientiert § Funktionen mit hoher Priorität für Kunden Termine werden eingehalten § evtl. mit weniger implementierter Funktionalität Vorteile: ü Geringere Verzögerungen bzw. weniger weggelassene Features ü Schnelles Kundenfeedback ü Frühe Entdeckung von Problemen ü Weggelassenes versteckt keine unangenehmen Überaschungen ü Weggelassenes hat geringere Priorität

Risiko : Projekt-Abbruch Nach mehrfachen Verzögerungen wird das Projekt abgebrochen…. . XP Ansatz: Fokussierung auf bestes Aufwands-/Nutzen-Verhältnis o Kunde muss kleinstes Release wählen, dass ihm einen signifikanten Mehrwert darstellt. Vorteile ü Vor Inbetriebnahme kann weniger schief gehen ü Bestes Kosten-/Nutzen-Verhältnis

Risiko: Unwartbarkeit Effektive Nutzung, aber frühe Ablösung wegen zu hoher Wartungskosten XP Ansatz: Tests: o Durch Programmierer und Kunden o Laufend wiederholt Vorteile ü System ist jederzeit in „Bestform“ ü Keine Ansammlung von Fehlern

Risiko: Unbenutzbarkeit durch Programmierfehler Inbetriebnahme, aber fehlende Akzeptanz wegen zu vieler Programmierfehler…. . XP Ansatz: Tests: o Durch Programmierer und Kunden o Laufend wiederholt Vorteile ü System ist jederzeit in „Bestform“ ü Keine Ansammlung von Fehlern

Risiko: Unbenutzbarkeit durch Fehlentwicklung Inbetriebnahme, aber das System tut was anderes als die Kunden wollten. . XP Ansatz: Kunden im Team integrieren Kundenvertreter spielt aktive Rolle im Team -> Anforderungsspezifikation -> Funktionstests Vorteile ü Laufendes Feedback ü Schnelle Beseitigung von Kommunikationsproblemen

Risiko: Änderung der Anforderung Inbetriebnahme, aber der Kunde braucht es nicht mehr … XP Ansatz: Kurze Zyklen weitreichende Anforderungsänderungen weniger wahrscheinlich Grundeinstellung „Änderung ist die einzige Konstante“ kein Unterschied zwischen Anforderungsänderungen und sonstigen Änderungen schnelle Reaktionsmöglichkeit auf Anforderungsänderungen Kunden sind gehalten ihre Anforderungsdefinitionen jederzeit anzupassen

Risiko: „ Featuritis „ System voller „interesting features“, die aber niemand wirklich braucht… XP Ansatz: Nur Tasks höchster Priorität realisieren Grundsätzlich!

Zeit/Kosten-Faktor in XP

Wie teuer sind Änderungen? § Traditionelle Sichtweise / Erfahrung

Wie teuer sind Änderungen? n XP Sichtweise/Erfahrung (? )

Grundwerte XP im Beispiel

XP in Beispielen n Kunde: Jedes Projekt beginnt mit einem Auftrag § Bisher: Erstellung eines Pflichtenhefts mit den abzuliefernden Features § XP: Keine Anforderungen, sondern Problemschilderung = User Stories

User Story: Parkhaus n Vielzahl von Aufgaben n Kunde beschreibt alle Vorfälle (User Stories): n Einfahren eines Fahrzeugs in das Parkhaus: Fahrer bleibt an geschlossener Schranke stehen, fordert per Knopfdruck Parkschein an Entnimmt Parkschein -> Schranke öffnet sich Fahrer passiert die Schranke schließt wieder

Vollständigkeit User Story? n Was ist wenn etwas fehlt? z. B. : - Parkhaus ist voll - Vorrat an Parkscheinen erschöpft Kerngedanke der User Story: Neue Gedanken werden einfach hinzugefügt. Ø Erst die Sammlung aller Stories ergibt den kompletten Ablauf.

Besonderheit von XP n Mitarbeit des Kunden während der gesamten Entwicklung: n geht weit über Pflichtenheft und Abnahmetest hinaus n Idealfall: n Mitarbeiter des Kunden sitzt beim Entwicklungsteam und sorgt somit für kurze Kommunikationswege

Umsetzung der User Stories n Kunde/Management und Entwickler legen fest: n n n Umsetzungsreihenfolge der Stories Zeitplan für die einzelnen Komponenten Abschätzung des Gesamtaufwands Ø Release-Plan

Release-Plan n beinhaltet für jedes einzelne Projektziel - wie lange es dauert, dieses Ziel zu erarbeiten - wie dessen erfolgreiche Umsetzung vom Gelingen anderer Stories abhängt - was die Umsetzung kostet

Codierung n Aufteilung der User Stories in kleine Teile (z. B. : zwei Bearbeitungstage) n Module werden dabei einfach gehalten n Als erstes programmiert man immer den Test eines Modules n Programmieren der eigentlichen Module n Sofortige sequentielle Integration dieser Ø Fehler wird sofort gefunden

Pair-Programming n Zwei Programmierer teilen sich einen Arbeitsplatz und arbeiten an einer Story n Ist die Story vollendet sucht sich jeder einen neuen Partner Ø Vorteil: Jeder kennt das Projekt Ideenaustausch Gegenseitige Ergänzung

Schrittweise Näherung n XP-Regel: Tu nie mehr, als du tun musst Ø Änderungen ruinieren nicht gleich die ganze Planung n Regelmäßiges Update des Iterationsplans Ø Stimmen die Schätzungen noch? Ø greifbare Zahlen

Entwicklungs-Fortschritt n Häufige Integration -> viele Versionen = Neue Release Ø Dieses Verfahren vermittelt dem Auftraggeber einen Eindruck vom Fortschritt. Ø Kunde kann Release-Version ausgiebig testen. -> Fehler können sofort beseitigt werden

Die 4 Grundwerte des XP 1. 2. 3. 4. Kommunikation Einfachheit Feedback Mut

Beziehung der Grundwerte zueinander Kommunikation Einfachheit Je einfacher das System, desto besser die Kommunikation

Beziehung der Grundwerte zueinander Kommunikation Einfachheit Mut Feedback

Beziehung der Grundwerte zueinander Feedback Kommunikation Einfachheit Je mehr Feedbacks man erhält, desto einfacher ist es, zu kommunizieren.

Zusammenfassung

Schlussfolgerung n Sie programmieren, weil Sie nichts leisten wenn Sie nicht programmieren. n Sie testen, weil Sie sonst nicht wissen, wann Sie mit dem Programmieren fertig sind. n Sie hören zu, weil Sie sonst nicht wissen, was Sie programmieren und testen sollen. n Und Sie entwerfen ein Design, damit Sie unendlich lange programmieren, testen und zuhören können.

Rollenverteilung Die Spieler in XP

Der „Truck-Faktor“ v Der Truck-Faktor gibt an, mit welcher Wahrscheinlichkeit das Projekt scheitern wird, wenn ein Teammitglied von einem Truck überfahren wird. n Der höchste Truck-Faktor (1. 0) wird erreicht, wenn das Team aus Spezialisten besteht, von denen jeder seinen Teil des Systems perfekt kennt. n Der niedrigste Truck-Faktor (0. 0) wird erreicht, wenn „Collective Code Ownership“ praktiziert wird.

Rollen Ø Auftraggeber (Client) Ø Kunde (Customer) ========= o Programmierer o Tester o Verfolger (Tracker) ========= Ø Trainer (Coach) TEAM

Auftraggeber (Client) Ø Für zentrale Entscheidungen zuständig Ø Definiert die Ziele (Umfang) Ø Stellt finanzielle Mittel bereit Ø Stellt die Zielerreichung fest Ø Damit hängt der Erfolg eine Projektes wesentlich vom Auftraggeber ab Ø Nimmt am Planungsspiel für Projektetappen (Releases) teil

Kunde (Customer) Ø Der Kunde legt fest was zu tun ist (Prioritäten) Ø Dazu schreibt er die User Stories Ø Diese müssen verständlich, umsetzbar, testbar sein Ø Schreibt zusätzlich die funktionalen Abnahmetests und führt diese –mit Hilfe des Testers- durch Ø Diese funktionalen Testssagen ihm, ob das System das tut was er erwartet

Kunde (Customer) (2) Ø Als Mitglied des Teams nimmt er an den Planungsmeetings (Release und Iteration) und den täglichen Stand-up Meetings teil Ø Er ist für aufkommende Fragen bezüglich der Stories immer ansprechbar Ø Der Kunde beeinflusst die Entwickler durch permanentes Feedback Ø Dazu muss er während der Entwicklung immer vor Ort sein

Programmierer (Programmer) Ø Die tägliche Arbeit besteht aus Zuhören, Testen, Implementieren und Design Ø Die Programmierer haben einen großen Anteil bei der Planung, da nicht das Management die Pläne vorgibt, sondern das Team diese ausarbeitet Ø Ehrlichkeit ist wichtig Man muss sich über seine Stärken und Schwächen im klaren sein und um Hilfe bitten können Außerdem funktioniert die Aufwandsabschätzung nur mit Ehrlichkeit (und Erfahrung)

Programmierer (Programmer) (2) Ø Programmierer sollen gut sein, aber „Super- Coder“ sind unnötig (können sogar behindern) Ø Teamfähigkeit ist wichtig, denn es wird ständig mit wechselnden Paaren gearbeitet und der Quelltext gehört dem Team Ø Andere Skills wie die Fähigkeit zum „Refactoring“ und zum „Unit Testing“ werden (zwangsläufig) in XP gelernt werden

Tester o Der „Tester“ hilft dem Kunden bei der Erstellung und Durchführung der funktionalen Tests o Außerdem sammelt er die Ergebnisse und macht sie für alle sichtbar (Qualität) o Die Rolle wird normalerweise von den Entwicklern oder vom Coach übernommen

Verfolger (Tracker) Ø Der „Tracker“ ist das Team Gewissen Ø Gibt dem Team feedback wie gut die Wirklichkeit mit der Abschätzung übereinstimmt und weist das Team auf mögliche Probleme hin Ø Er ermittelt regelmäßig (z. B. nach Abschluß einer Aufgabe) die Zeit die für die Aufgabe nötig war und aktualisiert den „Load Faktor“ Ø Er beobachtet den Entwicklungsprozess und überwacht ob die Pläne eingehalten werden können Ø Die Rolle wird normalerweise von den Entwicklern oder vom Coach übernommen

Trainer (Coach) Ø Der Coach ist für das Funktionieren des Prozesses verantwortlich. Dazu benötigt er einen guten Überblick über das System Ø Wenn etwas schief läuft, muss der Coach wieder in die richtige Richtung lenken, möglichst aber indirekt (Selbstverantwortung der Entwickler) Ø Außerdem sollte er technische Fähigkeiten haben, um z. B. als Programmierpartner besonders für neue Teammitglieder verfügbar zu sein Ø Schließlich nimmt der Coach an Management Meetings die das Projekt betreffen teil (Bindefunktion)

Das Team Persönlicher Kontakt und Kommunikation im Team wird gefördert ØKeine Vereinsamung ØKein Einzelkämpfertum ØKeine unausräumbaren Missverständnisse Unterstützung für neue Mitglieder ØVon jedem anderen ØBei Frage nach Hilfe muss man „Ja“ sagen Ermutigung neuer Mitglieder schrittweise mehr Verantwortung zu übernehmen ØMehr Erfolgserlebnisse und ØMehr Zufriedenheit

Der Weg zu einer Lösung

Der Weg zu einer Lösung n Einflußfaktoren n n Kostenrahmen Zeitrahmen Qualität Funktions-Umfang n Umgang mit Veränderung

Einfluss des Kostenrahmens n zu wenig Geld n keine effektive Entwicklung n mehr Geld n bessere Umgebung, Ausstattung, Ausbildung, . . . n aber Geld allein macht kein erfolgreiches Projekt n „ 40 Programmierer“-Anekdote n besser n Projektgröße schrittweise anpassen n Problem n Status-/ Prestige-Denken von Projektleitern

Einfluss des Zeitrahmens n zu wenig Zeit n n n schlechter Qualität geringer Umfang hohe Kosten n mehr Zeit n n bessere Qualität mehr Funktionalität n aber zu viel Zeit bis Inbetriebnahme schadet n Kein Feedback aus laufendem Betrieb n wenig Einflussmöglichkeiten durch Programmier-Team n Zeitrahmen ist meist vom Kunden bestimmt

Einfluss der Qualität 1. externe Qualität n was der Kunde sieht 2. interne Qualität n was der Programmierer sieht n geringere interne Qualität n n n was der Programmierer sieht kurzfristige Zeitersparnis langfristige Wartbarkeitskatastrophe langfristig schlechte externe Qualität demoralisierender Effekt im. Team n hohe interne Qualität

Einfluss der Qualität n n n langfristig schnellere Entwicklung bessere Motivation/ Zufriedenheit des Teams Kundenzufriedenheit

Einfluss des Funktions-Umfangs n Wichtigste Einflussmöglichkeit (laut Kent Beck) n Idee n n Kosten, Zeit und Qualität festlegen realisierbaren Funktionsumfang n Vorteile n Leichte Anpassbarkeit an Änderungsanforderungen n Risiko n Zu viele/ zu wichtige Funktionen werden gestrichen n XP-Ansatz n n wichtigste Kundenanforderungen zuerst realisieren Aufwandschätzungen mit Feedback

Einflussfaktoren: Fazit/Empfehlungen n Kosten: Resourcen bedarfsgerecht einsetzen! n Zeit : keine Einflussmöglichkeit , da extern bestimmt ! n Qualität : hohe interne Qualität anstreben! (Bestimmt durch Kunden) n Umfang : minimalen Funktions-Umfang anstreben! (Bestimmt durch Projektleiter)

Wann ist XP nicht sinnvoll?

Wann ist XP nicht sinnvoll? n Kultureller Hintergrund n z. B. Rollenverteilung n Inhomogenes Team n Unternehmensführung n z. B. Richtung wird vorgegeben § Kunde/Manager besteht auf komplette Spezifikation oder Design n „Freaks“ im Team n Teamgröße n Ca. 10 Programmierer n Projektgröße n XP Umgebung n z. B. örtliche Gegebenheit