• Agile Softwareentwicklung - Mit Scrum zum Erfolg!

  Page 1

• Inhaltsübersicht

  Page 8

• + Inhaltsverzeichnis

  Page 10

  • Danksagungen

    Page 10

  • Vorwort

    Page 10

  • Einleitung

    Page 10

  • + Teil I Erste Schritte

    Page 10

    • 1 Agil werden ist nicht einfach (aber die Mühe wert)

      Page 10

    • 2 Sich an Scrum anpassen (ADAPT)

      Page 10

    • 3 Modelle zur Scrum-Einführung

      Page 11

    • 4 Iterativer Wechsel zur Agilität

      Page 11

    • 5 Die ersten Projekte

      Page 11

  • + Teil II Einzelpersonen

    Page 12

    • 6 Widerstände überwinden

      Page 12

    • 7 Neue Rollen

      Page 12

    • 8 Veränderte Rollen

      Page 12

    • 9 Entwicklungspraktiken

      Page 13

  • + Teil III Teams

    Page 13

    • 10 Teamstruktur

      Page 13

    • 11 Teamwork

      Page 14

    • 12 Ein selbst organisiertes Team leiten

      Page 14

    • 13 Das Product Backlog

      Page 14

    • 14 Sprints

      Page 14

    • 15 Planung

      Page 15

    • 16 Qualität

      Page 15

  • + Teil IV Die Organisation

    Page 16

    • 17 Skalierung

      Page 16

    • 18 Verteilte Teams

      Page 16

    • 19 Parallele Anwendung anderer Verfahren

      Page 17

  • + Teil V Die nächsten Schritte

    Page 17

    • 20 Personal, Infrastruktur und das PMB

      Page 17

    • 21 Wie weit sind Sie gekommen?

      Page 18

    • 22 Sie sind noch nicht fertig

      Page 18

  • Literatur

    Page 18

  • Stichwortverzeichnis

    Page 18

• Danksagungen

  Page 20

• Vorwort

  Page 24

• + Einleitung

  Page 26

  • Weitere Annahmen über Sie

    Page 27

  • Der Aufbau dieses Buchs

    Page 27

  • Hinweise zu einigen Begriffen

    Page 28

  • Wie Sie dieses Buch verwenden sollten

    Page 28

• + Teil I Erste Schritte

  Page 30

  • + 1 Agil werden ist nicht einfach (aber die Mühe wert)

    Page 32

    • + 1.1 Was den Übergang zur Agilität so schwer macht

      Page 34

      • 1.1.1 Der erfolgreiche Wechsel erfolgt nicht ausschließlich von oben nach unten oder von unten nach oben

        Page 34

      • 1.1.2 Der Endzustand ist unvorhersehbar

        Page 35

      • 1.1.3 Scrum greift weit um sich

        Page 36

      • 1.1.4 Scrum ist deutlich anders

        Page 37

      • 1.1.5 Die Änderung erfolgt schneller als jemals zuvor

        Page 38

      • 1.1.6 Best Practices sind gefährlich

        Page 39

    • + 1.2 Warum es die Mühe wert ist

      Page 39

      • 1.2.1 Höhere Produktivität bei geringeren Kosten

        Page 41

      • 1.2.2 Gesteigertes Engagement und höhere Zufriedenheit der Mitarbeiter

        Page 43

      • 1.2.3 Kürzere Time-to-Market

        Page 43

      • 1.2.4 Höhere Qualität

        Page 45

      • 1.2.5 Höhere Zufriedenheit der Stakeholder

        Page 45

      • 1.2.6 Die bisherigen Methoden funktionieren nicht mehr

        Page 46

    • 1.3 Ein Blick nach vorn

      Page 47

    • 1.4 Literatur

      Page 47

  • + 2 Sich an Scrum anpassen (ADAPT)

    Page 50

    • + 2.1 Situationsbewusstsein

      Page 52

      • 2.1.1 Mittel zur Entwicklung von Situationsbewusstsein

        Page 53

    • + 2.2 Wille

      Page 55

      • 2.2.1 Werkzeuge, um den Willen zu stärken

        Page 56

    • + 2.3 Befähigung

      Page 60

      • 2.3.1 Werkzeuge zur Entwicklung einer Befähigung

        Page 61

    • + 2.4 Bekanntmachung

      Page 63

      • 2.4.1 Werkzeuge zur Bekanntmachung von Scrum

        Page 64

    • + 2.5 Ausweitung

      Page 66

      • 2.5.1 Quellen der Schwerkraft in der Organisation

        Page 67

    • 2.6 Das Gesamtbild

      Page 70

    • 2.7 Literatur

      Page 71

  • + 3 Modelle zur Scrum-Einführung

    Page 72

    • + 3.1 Klein anfangen oder alles auf einmal

      Page 72

      • 3.1.1 Was spricht für einen kleinen Anfang?

        Page 73

      • 3.1.2 Was spricht für einen Wechsel im Ganzen?

        Page 74

      • 3.1.3 Zwischen den Modellen wählen

        Page 75

    • + 3.2 Offizielle Bekanntmachung oder heimlich, still und leise

      Page 76

      • 3.2.1 Was spricht für eine offizielle Bekanntmachung?

        Page 77

      • 3.2.2 Was spricht für einen heimlichen Übergang?

        Page 78

      • 3.2.3 Zwischen den Modellen wählen

        Page 79

    • + 3.3 Modelle für die Verbreitung von Scrum

      Page 79

      • 3.3.1 Aufteilen und Keimen

        Page 79

      • 3.3.2 Wachsen und Aufteilen

        Page 80

      • 3.3.3 Internes Coaching

        Page 81

      • 3.3.4 Was spricht für Aufteilen und Keimen?

        Page 81

      • 3.3.5 Was spricht für Wachsen und Aufteilen?

        Page 82

      • 3.3.6 Was spricht für internes Coaching?

        Page 82

      • 3.3.7 Eine Vorgehensweise wählen

        Page 83

    • + 3.4 Neue Entwicklungspraktiken einführen

      Page 84

      • 3.4.1 Was spricht für einen baldigen Beginn?

        Page 85

      • 3.4.2 Was spricht für einen Aufschub?

        Page 85

    • 3.5 Schlussbetrachtung

      Page 86

    • 3.6 Literatur

      Page 87

  • + 4 Iterativer Wechsel zur Agilität

    Page 90

    • 4.1 Das Verbesserungs-Backlog

      Page 91

    • + 4.2 Die Enterprise Transition Community

      Page 92

      • 4.2.1 ETC-Sprints

        Page 94

      • 4.2.2 Aufgaben der ETC

        Page 97

    • + 4.3 Verbesserungs-Communitys

      Page 99

      • 4.3.1 Katalysatoren für Verbesserungen

        Page 101

      • 4.3.2 Sprints in Verbesserungs-Communitys

        Page 102

      • 4.3.3 Fokus auf Ziele mit Praxisrelevanz

        Page 104

      • 4.3.4 Die Mitglieder der Verbesserungs-Communitys

        Page 105

      • 4.3.5 Communitys auflösen

        Page 106

    • 4.4 Es gibt keine Patentlösung

      Page 107

    • 4.5 Ein Blick nach vorn

      Page 108

    • 4.6 Literatur

      Page 108

  • + 5 Die ersten Projekte

    Page 110

    • + 5.1 Ein Pilotprojekt auswählen

      Page 110

      • 5.1.1 Vier Eigenschaften eines idealen Pilotprojekts

        Page 111

    • + 5.2 Den richtigen Zeitpunkt zum Anfangen finden

      Page 113

      • 5.2.1 Drohender Fehlschlag

        Page 114

    • + 5.3 Das Pilotteam zusammenstellen

      Page 115

      • 5.3.1 Was tun, wenn das Pilotprojekt keinen Erfolg hat?

        Page 116

    • + 5.4 Erwartungen abstecken

      Page 117

      • 5.4.1 Erwartungen an den Fortschritt

        Page 118

      • 5.4.2 Erwartungen an die Vorhersagbarkeit

        Page 119

      • 5.4.3 Erwartungen an die Einstellung zu Scrum

        Page 120

      • 5.4.4 Erwartungen an die Beteiligung

        Page 121

    • 5.5 Es ist doch nur ein Pilotprojekt

      Page 121

    • 5.6 Literatur

      Page 122

• + Teil II Einzelpersonen

  Page 124

  • + 6 Widerstände überwinden

    Page 126

    • + 6.1 Widerstände vorhersehen

      Page 126

      • 6.1.1 Wer leistet Widerstand?

        Page 127

      • 6.1.2 Trugschlüsse aus dem Wasserfallmodell und Agilophobien

        Page 129

    • + 6.2 Die Änderungen vermitteln

      Page 130

      • 6.2.1 Informationen von Vorgesetzten

        Page 130

      • 6.2.2 Informationen von Gleichgestellten

        Page 131

    • + 6.3 Gründe und Formen des Widerstands

      Page 132

      • 6.3.1 Skeptiker

        Page 135

      • 6.3.2 Saboteure

        Page 137

      • 6.3.3 Betonköpfe

        Page 139

      • 6.3.4 Mitläufer

        Page 141

    • 6.4 Widerstände als Warnhinweise sehen

      Page 143

    • 6.5 Literatur

      Page 143

  • + 7 Neue Rollen

    Page 146

    • + 7.1 ScrumMaster

      Page 146

      • 7.1.1 Eigenschaften eines guten ScrumMasters

        Page 147

      • 7.1.2 Leitende Entwickler als ScrumMaster

        Page 150

      • 7.1.3 Interne und externe ScrumMaster

        Page 151

      • 7.1.4 Rotationsverfahren

        Page 151

      • 7.1.5 Übliche Probleme lösen

        Page 152

    • + 7.2 Product Owner

      Page 154

      • 7.2.1 Aufgaben des Product Owners

        Page 154

      • 7.2.2 Ein Product Owner pro Team

        Page 157

      • 7.2.3 Eigenschaften eines guten Product Owners

        Page 159

      • 7.2.4 Der ScrumMaster als Product Owner

        Page 160

      • 7.2.5 Übliche Probleme lösen

        Page 161

    • 7.3 Neue Rollen, alte Aufgaben

      Page 163

    • 7.4 Literatur

      Page 164

  • + 8 Veränderte Rollen

    Page 166

    • 8.1 Analyst

      Page 166

    • + 8.2 Projektmanager

      Page 169

      • 8.2.1 Warum den Titel ändern?

        Page 171

    • + 8.3 Architekten

      Page 171

      • 8.3.1 Nicht selbst programmierende Architekten

        Page 172

    • + 8.4 Fachmanager

      Page 173

      • 8.4.1 Die Führungsrolle des Fachmanagers

        Page 174

      • 8.4.2 Personalentscheidungen

        Page 175

    • 8.5 Programmierer

      Page 175

    • 8.6 Datenbankadministratoren

      Page 177

    • 8.7 Tester

      Page 178

    • 8.8 User Experience Designer

      Page 180

    • 8.9 Drei gemeinsame Prinzipien

      Page 182

    • 8.10 Literatur

      Page 183

  • + 9 Entwicklungspraktiken

    Page 186

    • + 9.1 Technische Exzellenz anstreben

      Page 186

      • 9.1.1 Testgetriebene Entwicklung

        Page 187

      • 9.1.2 Refactoring

        Page 190

      • 9.1.3 Gemeinsame Verantwortung

        Page 191

      • 9.1.4 Kontinuierliche Integration

        Page 193

      • 9.1.5 Pair Programming

        Page 195

    • + 9.2 Design: bewusst und doch emergent

      Page 197

      • 9.2.1 Lernen, ohne umfassendes Design auszukommen

        Page 198

      • 9.2.2 Das Design lenken

        Page 200

    • 9.3 Die Verbesserung der Entwicklungspraktiken ist ein Muss

      Page 202

    • 9.4 Literatur

      Page 203

• + Teil III Teams

  Page 206

  • + 10 Teamstruktur

    Page 208

    • + 10.1 Zwei Pizzas pro Team

      Page 208

      • 10.1.1 Warum zwei Pizzas genügen

        Page 209

      • 10.1.2 Die Produktivität kleiner Teams

        Page 211

    • + 10.2 Featureteams bevorzugen

      Page 214

      • 10.2.1 Sparsamer Einsatz von Komponententeams

        Page 216

      • 10.2.2 Wer trifft die Entscheidungen?

        Page 219

      • 10.2.3 Was heute richtig ist, kann morgen schon falsch sein

        Page 220

    • + 10.3 Selbst organisiert heißt nicht zusammengewürfelt

      Page 220

      • 10.3.1 Das Team aus den richtigen Personen zusammenstellen

        Page 221

    • + 10.4 Jeder nur ein Projekt

      Page 223

      • 10.4.1 Je mehr Aufgaben, umso weniger Zeit dafür

        Page 224

      • 10.4.2 Wann ist Multitasking angebracht?

        Page 225

      • 10.4.3 Multitasking von Unternehmen

        Page 226

      • 10.4.4 Die Tretmühle anhalten

        Page 227

    • 10.5 Richtlinien für eine gute Teamzusammenstellung

      Page 228

    • 10.6 Vorwärts

      Page 230

    • 10.7 Literatur

      Page 231

  • + 11 Teamwork

    Page 232

    • + 11.1 Das Team als Ganzes ist verantwortlich

      Page 232

      • 11.1.1 Das Engagement des gesamten Teams fördern

        Page 234

    • 11.2 Spezialisten nur sparsam einsetzen

      Page 235

    • + 11.3 Immer ein kleines bisschen von allem tun

      Page 237

      • 11.3.1 Nicht alles auf das Ende des Sprints verschieben

        Page 238

      • 11.3.2 Auf unterschiedliche Größen der Backlog-Einträge achten, die Sie zusagen

        Page 239

    • + 11.4 Lernen als Team fördern

      Page 240

      • 11.4.1 Voraussetzungen zum Lernen schaffen

        Page 240

      • 11.4.2 Verschwendung von Wissen unterbinden

        Page 245

    • 11.5 Zusammenarbeit durch Engagement fördern

      Page 247

    • 11.6 Und jetzt alle zusammen

      Page 249

    • 11.7 Literatur

      Page 250

  • + 12 Ein selbst organisiertes Team leiten

    Page 252

    • + 12.1 Die Selbstorganisation beeinflussen

      Page 253

      • 12.1.1 Container, Unterschiede und Austauschvorgänge

        Page 254

    • + 12.2 Die Evolution beeinflussen

      Page 260

      • 12.2.1 Das externe Umfeld auswählen

        Page 261

      • 12.2.2 Leistung definieren

        Page 262

      • 12.2.3 Botschaften vermitteln

        Page 262

      • 12.2.4 Stellvertretende Selektionskriterien einführen

        Page 263

      • 12.2.5 Das System mit Energie erfüllen

        Page 264

    • 12.3 Führen heißt nicht nur Pizza bestellen

      Page 265

    • 12.4 Literatur

      Page 266

  • + 13 Das Product Backlog

    Page 268

    • + 13.1 Von Dokumentation zu Diskussion

      Page 268

      • 13.1.1 Das Baby nicht mit der Dokumentation ausschütten

        Page 271

      • 13.1.2 User Storys für das Product Backlog verwenden

        Page 271

    • + 13.2 Anforderungen schrittweise verfeinern

      Page 274

      • 13.2.1 Nachträglich auftretende Anforderungen

        Page 274

      • 13.2.2 Das Product Backlog als Eisberg

        Page 275

      • 13.2.3 Schrittweise Verfeinerung von Anforderungen – warum?

        Page 277

      • 13.2.4 Schrittweise Verfeinerung von User Storys

        Page 278

    • 13.3 Ohne Spezifikation anfangen

      Page 282

    • 13.4 DEEP: Wie ein gutes Product Backlog aussieht

      Page 286

    • 13.5 Reden Sie miteinander

      Page 287

    • 13.6 Literatur

      Page 287

  • + 14 Sprints

    Page 288

    • + 14.1 Bei jedem Sprint funktionierende Software ausliefern

      Page 288

      • 14.1.1 Was bedeutet »potenziell auslieferbar«?

        Page 289

      • 14.1.2 Richtlinien für potenzielle Auslieferbarkeit

        Page 291

    • 14.2 In jedem Sprint etwas Wertvolles liefern

      Page 293

    • + 14.3 In einem Sprint den nächsten vorbereiten

      Page 297

      • 14.3.1 Billardkugel-Sprints

        Page 297

      • 14.3.2 Nur das aufnehmen, was erledigt werden kann

        Page 297

    • + 14.4 Zusammenarbeit während des gesamten Sprints

      Page 299

      • 14.4.1 Tätigkeitsspezifische Sprints vermeiden

        Page 301

      • 14.4.2 Ende/Ende- statt Ende/Anfang-Beziehungen

        Page 302

      • 14.4.3 Überlappendes User Experience Design

        Page 303

      • 14.4.4 Ganzheitlich denken, inkrementell arbeiten

        Page 304

      • 14.4.5 Architektur und Datenbankdesign

        Page 305

    • + 14.5 Timeboxes immer gleich lang gestalten und genau einhalten

      Page 307

      • 14.5.1 Sprints niemals verlängern

        Page 309

    • + 14.6 Ändern Sie nicht das Ziel!

      Page 311

      • 14.6.1 Brechen Sie mit der Gewohnheit, Teams umzudirigieren!

        Page 313

    • 14.7 Feedback einholen, lernen und anpassen

      Page 314

    • 14.8 Literatur

      Page 315

  • + 15 Planung

    Page 316

    • 15.1 Pläne schrittweise verfeinern

      Page 316

    • + 15.2 Pläne nicht durch Überstunden retten

      Page 318

      • 15.2.1 Auf schmerzhafte Weise lernen

        Page 319

      • 15.2.2 Wie man das schafft

        Page 320

      • 15.2.3 Wenn keine Überstunden, was dann?

        Page 322

    • + 15.3 Änderungen des Umfangs bevorzugen

      Page 323

      • 15.3.1 Die Alternativen unter der Lupe

        Page 324

      • 15.3.2 Es kommt auf das Projekt an

        Page 327

    • + 15.4 Schätzungen und Commitments trennen

      Page 328

      • 15.4.1 Die richtigen Daten verwenden

        Page 328

      • 15.4.2 Von der Schätzung zum Commitment

        Page 332

      • 15.4.3 Erfahrungswerte der Entwicklungsgeschwindigkeit als Grundlage für Commitments

        Page 333

    • 15.5 Zusammenfassung

      Page 337

    • 15.6 Literatur

      Page 337

  • + 16 Qualität

    Page 338

    • + 16.1 Tests in den Prozess integrieren

      Page 338

      • 16.1.1 Tests am Projektende – keine gute Idee

        Page 339

      • 16.1.2 Qualität einbauen

        Page 341

    • + 16.2 Automatisierung auf verschiedenen Ebenen

      Page 342

      • 16.2.1 Welche Rolle spielen UI-Tests noch?

        Page 345

      • 16.2.2 Manuelle Tests

        Page 345

      • 16.2.3 Automatisierung innerhalb des Sprints

        Page 345

      • 16.2.4 Beispiele für die Vorteile

        Page 347

    • + 16.3 Akzeptanztestgetriebene Entwicklung

      Page 348

      • 16.3.1 Der angemessene Grad an Detaillierung

        Page 350

    • + 16.4 Technische Schulden zurückzahlen

      Page 352

      • 16.4.1 Testschulden in drei Schritten zurückzahlen

        Page 353

    • 16.5 Qualität ist Sache des gesamten Teams

      Page 354

    • 16.6 Literatur

      Page 355

• + Teil IV Die Organisation

  Page 356

  • + 17 Skalierung

    Page 358

    • + 17.1 Die Rolle des Product Owners anpassen

      Page 358

      • 17.1.1 Gemeinsame Verantwortung, geteilte Aufgaben

        Page 359

    • + 17.2 Ein umfangreiches Product Backlog handhaben

      Page 361

      • 17.2.1 Ein Produkt, ein Product Backlog

        Page 361

      • 17.2.2 Das Product Backlog in einer sinnvollen Größe halten

        Page 362

    • + 17.3 Proaktiver Umgang mit Abhängigkeiten

      Page 364

      • 17.3.1 Laufende Vorausplanung

        Page 365

      • 17.3.2 Ein Release-Kickoff abhalten

        Page 367

      • 17.3.3 Ein Mitglied in mehreren Teams

        Page 368

      • 17.3.4 Integrationsteams

        Page 369

    • + 17.4 Die Arbeit der einzelnen Teams koordinieren

      Page 371

      • 17.4.1 Meta-Scrums

        Page 371

      • 17.4.2 Sprints synchronisieren

        Page 375

    • + 17.5 Sprintplanung im großen Maßstab

      Page 376

      • 17.5.1 Verzögerung um einen Tag

        Page 377

      • 17.5.2 Das Großraumverfahren

        Page 377

    • + 17.6 Praxiscommunitys fördern

      Page 379

      • 17.6.1 Offizielle und inoffizielle Communitys

        Page 380

      • 17.6.2 Ein Umfeld zur Förderung von Communitys bilden

        Page 381

      • 17.6.3 Teilnahme

        Page 383

    • 17.7 Scrum skaliert

      Page 383

    • 17.8 Literatur

      Page 384

  • + 18 Verteilte Teams

    Page 386

    • 18.1 Die Art und Weise der Verteilung festlegen

      Page 387

    • + 18.2 Für Zusammenhalt sorgen

      Page 389

      • 18.2.1 Entscheidende kulturelle Unterschiede berücksichtigen

        Page 389

      • 18.2.2 Kleine kulturelle Unterschiede berücksichtigen

        Page 392

      • 18.2.3 Fachgebiets- und Teamsubkulturen stärken

        Page 393

      • 18.2.4 Frühe Erfolge betonen und dadurch Vertrauen wecken

        Page 395

    • + 18.3 Sich von Angesicht zu Angesicht treffen

      Page 398

      • 18.3.1 Antrittsbesuche

        Page 398

      • 18.3.2 Kontaktbesuche

        Page 400

      • 18.3.3 Reisende Botschafter

        Page 400

    • + 18.4 Veränderte Kommunikation

      Page 402

      • 18.4.1 Wieder etwas Dokumentation hinzufügen

        Page 403

      • 18.4.2 Das Product Backlog um Einzelheiten erweitern

        Page 403

      • 18.4.3 Laterale Kommunikation fördern

        Page 404

    • + 18.5 Besprechungen

      Page 405

      • 18.5.1 Allgemeine Ratschläge

        Page 406

      • 18.5.2 Sprintplanung

        Page 408

      • 18.5.3 Daily Scrum

        Page 411

      • 18.5.4 Meta-Scrum

        Page 414

      • 18.5.5 Sprint-Review und -Retrospektive

        Page 415

    • 18.6 Vorsichtig vorgehen

      Page 417

    • 18.7 Literatur

      Page 417

  • + 19 Parallele Anwendung anderer Verfahren

    Page 420

    • + 19.1 Scrum und sequenzielle Entwicklung

      Page 420

      • 19.1.1 Drei mögliche Wechselbeziehungen

        Page 421

      • 19.1.2 Drei Konfliktbereiche

        Page 422

      • 19.1.3 Können Scrum und sequenzielle Entwicklung auf Dauer nebeneinander bestehen?

        Page 424

    • + 19.2 Steuerung

      Page 424

      • 19.2.1 Scrum-Projekte mit nichtagiler Steuerung

        Page 426

    • + 19.3 Konformität

      Page 427

      • 19.3.1 ISO 9001

        Page 427

      • 19.3.2 CMMI (Capability Maturity Model Integration)

        Page 429

      • 19.3.3 Konformität erreichen

        Page 431

    • 19.4 Vorwärts

      Page 432

    • 19.5 Literatur

      Page 432

• + Teil V Die nächsten Schritte

  Page 434

  • + 20 Personal, Infrastruktur und das PMB

    Page 436

    • + 20.1 Die Personalabteilung

      Page 437

      • 20.1.1 Hierarchien

        Page 437

      • 20.1.2 Regelmäßige Leistungsbeurteilungen

        Page 439

      • 20.1.3 Teammitglieder entfernen

        Page 440

      • 20.1.4 Aufstiegsmöglichkeiten

        Page 441

      • 20.1.5 Wo Menschen zusammenarbeiten, verursachen sie Probleme

        Page 442

    • + 20.2 Infrastruktur

      Page 443

      • 20.2.1 Die Räumlichkeiten

        Page 443

      • 20.2.2 Der gesamte Arbeitsraum wird zum Projektbüro

        Page 444

      • 20.2.3 Das Mobiliar

        Page 446

      • 20.2.4 Was im Arbeitsbereich sichtbar sein sollte

        Page 447

    • + 20.3 Das Projektmanagementbüro

      Page 450

      • 20.3.1 Menschen

        Page 451

      • 20.3.2 Projekte

        Page 451

      • 20.3.3 Prozesse

        Page 452

      • 20.3.4 Das PMB umbenennen

        Page 453

    • 20.4 Fazit

      Page 454

    • 20.5 Literatur

      Page 455

  • + 21 Wie weit sind Sie gekommen?

    Page 456

    • 21.1 Der Sinn von Messungen

      Page 456

    • + 21.2 Allgemeine Methoden zur Messung von Agilität

      Page 457

      • 21.2.1 Die Shodan-Konformitätsstudie

        Page 458

      • 21.2.2 Agile:EF

        Page 459

      • 21.2.3 Die Comparative-Agility-Bewertung

        Page 461

    • 21.3 Eigene Bewertungsverfahren aufstellen

      Page 464

    • + 21.4 Balanced Scorecard für Scrum-Teams

      Page 466

      • 21.4.1 Die Balanced Scorecard aufstellen

        Page 467

      • 21.4.2 Einfache Metriken bevorzugen

        Page 469

    • 21.5 Müssen wir diese Mühen wirklich auf uns nehmen?

      Page 471

    • 21.6 Literatur

      Page 472

  • 22 Sie sind noch nicht fertig

    Page 474

• Literatur

  Page 476

• + Stichwortverzeichnis

  Page 490

  • A

    Page 490

  • B

    Page 490

  • C

    Page 491

  • D

    Page 491

  • E

    Page 491

  • F

    Page 492

  • G

    Page 492

  • H

    Page 492

  • I

    Page 492

  • J

    Page 492

  • K

    Page 493

  • L

    Page 493

  • M

    Page 493

  • N

    Page 494

  • O

    Page 494

  • P

    Page 494

  • Q

    Page 495

  • R

    Page 495

  • S

    Page 495

  • T

    Page 496

  • U

    Page 497

  • V

    Page 498

  • W

    Page 498

  • X

    Page 498

  • Y

    Page 498

  • Z

    Page 499

• Copyright

  Page 508

"Agile Softwareentwicklung" ist das praxisbezogene und leicht umsetzbare Standardwerk fur den schnellen Einstieg in Scrum und agile Softwareentwicklung - und wie sie langfristig genutzt wird. Mike Cohn, fuhrender Berater und Anwender agiler Softwareentwicklung gibt detaillierte Ratschlage, wertvolle Tipps und Fallbeispiele aus der Praxis, basierend auf seinen profunden Erfahrungen bei der Einfuhrung von Scrum und agiler Entwicklung, die er bei hunderten von Unternehmen gesammelt hat. Dieses Buch richtet sich an pragmatische Softwareentwickler, die effektive Antworten auf die schwierigen Fragestellungen bei der Implementierung von Scrum suchen. Cohn erlautert jede Facette des Vorgangs: Erste Schritte, Hilfe fur den Einzelnen in seiner neuen Rolle, Teambildung, Hochskalierung, Arbeit ein einem verteilten Team sowie Einfuhrung effizienter Metriken und kontinuierliche Verbesserung.