| Grußwort | 6 |
| Vorwort | 9 |
| Zielgruppe dieses Buchs | 9 |
| Aufbau dieses Buchs – Agiles Manifest und agile Prozessmodelle | 10 |
| Das studentische Software-Engineering-Labor | 10 |
| Danksagung | 10 |
| Inhaltsverzeichnis | 12 |
| Software-Prozessmodelle | 15 |
| 1.1 Ein Prozessmodell – was ist das? | 15 |
| 1.1.1 Einteilung in Projekttypen | 16 |
| 1.1.2 Schwergewichtige und leichtgewichtige Prozessmodelle | 16 |
| 1.1.3 Prozessmodell vs. Vorgehensmodell | 17 |
| 1.2 Das Phasenmodell | 17 |
| 1.3 Das Spiralmodell | 18 |
| 1.4 Moderne iterativ-inkrementelle Prozessmodelle | 20 |
| 1.4.1 V-Modell | 20 |
| 1.4.2 Unified Software Development Process (UP) | 20 |
| 1.4.3 Agile Prozessmodelle | 21 |
| Literatur | 21 |
| Das Agile Manifest | 22 |
| Literatur | 24 |
| Extreme Programming (XP) | 25 |
| 3.1 Die fünf Werte | 26 |
| 3.1.1 Kommunikation | 26 |
| 3.1.2 Einfachheit | 26 |
| 3.1.3 Feedback | 27 |
| 3.1.4 Mut | 28 |
| 3.1.5 Respekt | 28 |
| 3.2 Die 14 Prinzipien | 29 |
| 3.2.1 Menschlichkeit | 29 |
| 3.2.2 Wirtschaftlichkeit | 29 |
| 3.2.3 Wechselseitiger Vorteil | 30 |
| 3.2.4 Selbstähnlichkeit | 30 |
| 3.2.5 Verbesserung | 30 |
| 3.2.6 Vielfältigkeit | 30 |
| 3.2.7 Reflexion | 31 |
| 3.2.8 Fluss | 31 |
| 3.2.9 Gelegenheit | 31 |
| 3.2.10 Redundanz | 31 |
| 3.2.11 Fehlschlag | 32 |
| 3.2.12 Qualität | 32 |
| 3.2.13 Kleine Schritte | 32 |
| 3.2.14 Akzeptierte Verantwortung | 32 |
| 3.3 Prozessschritte und traditionelle XP-Praktiken | 32 |
| 3.3.1 Planung | 33 |
| 3.3.2 Design der Software | 39 |
| 3.3.3 Kodieren | 42 |
| 3.3.4 Testen der Software | 48 |
| 3.4 Erweiterte XP-Praktiken | 49 |
| 3.4.1 Primärpraktiken | 50 |
| 3.4.2 Folgepraktiken | 52 |
| 3.4.3 Unterschiede zwischen erweiterten und traditionellen XP- Praktiken | 54 |
| 3.5 Berühmte XP-Praktiken | 55 |
| 3.5.1 Erstellen von User Stories | 56 |
| 3.5.2 Paarweises Programmieren | 56 |
| 3.5.3 Collective Code Ownership, Shared Code | 56 |
| 3.5.4 Kontinuierliche Code-Integration, eine Codebasis | 57 |
| 3.5.5 Kunde im Team, Einbeziehung des Kunden | 57 |
| Literatur | 57 |
| Crystal und Crystal Clear | 58 |
| 4.1 Teamgröße und Risiko – die Crystal-Familie | 58 |
| 4.2 Die sieben Crystal-Eigenschaften | 60 |
| 4.2.1 Regelmäßige Lieferung | 60 |
| 4.2.2 Reflektierte Verbesserung | 60 |
| 4.2.3 Verdichtete oder osmotische Kommunikation | 61 |
| 4.2.4 Persönliche Sicherheit | 62 |
| 4.2.5 Schwerpunkte bilden | 62 |
| 4.2.6 Einfache Kontaktaufnahme mit Endanwendern | 63 |
| 4.2.7 Technische Umgebung mit automatisierten Tests, Konfigurationsmanagement und regelmäßige Integrationen | 63 |
| 4.3 Crystal Clear | 64 |
| 4.3.1 Eigenschaften und Praktiken | 64 |
| 4.3.2 Rollen im Projektteam | 67 |
| Literatur | 70 |
| Scrum | 71 |
| 5.1 Scrum – die Projektrollen | 71 |
| 5.1.1 Product Owner | 72 |
| 5.1.2 Team | 73 |
| 5.1.3 ScrumMaster | 75 |
| 5.1.4 Weitere Scrum-Rollen | 77 |
| 5.1.5 Gefahr durch Rollenmissbrauch | 77 |
| 5.2 Scrum – der Prozess | 78 |
| 5.2.1 Scrum-Flow - Überblick | 78 |
| 5.2.2 Sprint - Details | 79 |
| 5.3 Scrum-Artefakte | 83 |
| 5.3.1 Product Backlog | 83 |
| 5.3.2 Sprint Backlog | 85 |
| 5.3.3 Releaseplan und Burndown Chart | 85 |
| Literatur | 87 |
| Experimentelles Software-Engineering im studentischen Labor | 88 |
| 6.1 Die Projekte im studentischen Labor | 89 |
| 6.2 Randbedingungen der studentischen Sessions | 91 |
| 6.3 Veränderung der klassischen Projektrollen in agilen Projekten | 93 |
| 6.3.1 Der Projektmanager im agilen Projekt | 93 |
| 6.3.2 Der Qualitätsmanager im agilen Projekt | 97 |
| 6.4 Neue Teamrolle – der Integrationsingenieur | 101 |
| 6.5 Veränderung agiler Praktiken und Prozesse in der Praxis | 102 |
| 6.5.1 Design von User Stories | 102 |
| 6.5.2 Collective Code Ownership | 103 |
| 6.5.3 Mini-Team-Größe: Sind XP-Paare erfolgreich? | 103 |
| 6.5.4 Der Weg zur erfolgreichen Software-Integration | 109 |
| 6.5.5 Crystal und die reflektierte Verbesserung | 112 |
| 6.5.6 Scrum im studentischen Labor | 116 |
| 6.5.7 Hierarchische Prozesse unter dem agilen Deckmantel | 124 |
| Literatur | 126 |
| MAP – Meta Agile Process Model | 127 |
| 7.1 Team-Psychologie – Landkarte der Verhaltensweisen im Team | 127 |
| 7.2 Das Super-Team | 130 |
| 7.3 Was ist MAP? | 131 |
| 7.4 MAP – die Projektrollen im Team | 132 |
| 7.4.1 Kunde | 133 |
| 7.4.2 Kommunikationsmanager | 133 |
| 7.4.3 Integrationsingenieur | 135 |
| 7.4.4 Team | 136 |
| 7.4.5 Prozessverantwortlicher - der MAP-Beobachter | 137 |
| 7.4.6 Projektrollen in der Landkarte der Verhaltensweisen | 138 |
| 7.5 MAP Cycle – der Referenzprozess | 139 |
| 7.6 MAP und Scrum | 141 |
| 7.6.1 Vergleich der Rollen | 141 |
| 7.6.2 Bestimmung des Product Owners | 144 |
| 7.6.3 Prozess | 147 |
| 7.6.4 Artefakte | 149 |
| 7.6.5 MAP und Scrum - geht das? | 150 |
| 7.6.6 Vorteile für Scrum-Anwender | 151 |
| 7.7 MAP im regulierten Umfeld | 151 |
| 7.8 MAP-Projekt in der Industrie | 154 |
| Literatur | 155 |
