Sie sind hier
E-Book

Essential Scrum

Umfassendes Scrum-Wissen aus der Praxis

AutorKenneth S. Rubin
Verlagmitp Verlags GmbH & Co. KG
Erscheinungsjahr2014
Seitenanzahl480 Seiten
ISBN9783826684739
FormatePUB/PDF
Kopierschutzkein Kopierschutz/DRM
GerätePC/MAC/eReader/Tablet
Preis34,99 EUR
  • Umfassendes Scrum-Wissen auf Team-, Produkt- und Portfolio-Ebene
  • Kernkonzepte, Rollen, Planung und Sprints ausführlich erläutert
  • Auch geeignet zur Vorbereitung auf die Scrum-Zertifizierung

Dieses Buch beschreibt das Wesen von Scrum - die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen zu entwickeln.Es ist entstanden, weil der Autor Kenneth S. Rubin als Agile- und Scrum-Berater oft nach einem Referenzbuch für Scrum gefragt worden ist - einem Buch, das einen umfassenden Überblick über das Scrum-Framework bietet und darüber hinaus die beliebtesten Ansätze für die Anwendung von Scrum präsentiert.
Dieses Buch ist der Versuch, die eine entscheidende Quelle für alles Wesentliche über Scrum bereitzustellen.Rubin beleuchtet die Werte, Prinzipien und Praktiken von Scrum und beschreibt bewährte, flexible Ansätze, die Ihnen helfen werden, sie viel effektiver umzusetzen. Dabei liefert er mehr als nur die Grundlagen und weist zudem auf wichtige Probleme hin, die Ihnen auf Ihrem Weg begegnen können.Ob Sie sich nun zum ersten Mal an Scrum versuchen oder es schon seit Jahren benutzen: Dieses Buch weiht Sie in die Geheimnisse des Scrum-Entwicklungsverfahrens ein und vermittelt Ihnen ein umfangreiches Scrum-Wissen auf Team-, Produkt- und Portfolio-Ebene. Für diejenigen, die bereits mit Scrum vertraut sind, eignet es sich als Scrum-Referenz.Rubin hat das Buch nicht für eine bestimmte Scrum-Rolle geschrieben. Stattdessen soll es allen, die direkt oder indirekt mit Scrum zu tun haben, ein gemeinsames Verständnis von Scrum und den Prinzipien, auf denen es beruht, vermitteln.

Aus dem Inhalt:
1. Teil: Kernkonzepte
  • Scrum-Framework
  • Agile Prinzipien
  • Sprints
  • Anforderungen und User Stories
  • Das Product Backlog
  • Schätzungen und Velocity
  • Technische Schulden

2. Teil: Rollen
  • Product Owner
  • Scrum
  • Master
  • Entwicklungsteam
  • Strukturen des Scrum-Teams
  • Manager

3. Teil: Planung
  • Scrum-Planungsprinzipien
  • Mehrstufige Planung
  • Portfolio-Planung
  • Visionsfindung/Produktplanung
  • Release-Planung

4. Teil: Sprints
  • Sprint-Planung
  • Sprint-Ausführung
  • Sprint Review
  • Sprint-Retrospektive


Kenneth S. Rubin bietet Scrum- und Agile-Training und Beratung an und hilft Unternehmen, Produkte effektiver und wirtschaftlicher zu entwickeln. Als zertifizierter Scrum-Trainer hat er mehr als 18.000 Menschen zu den Themen Agile und Scrum, Smalltalk-Entwicklung, Organisieren objektorientierter Projekte und Übergangsmanagement unterrichtet. Er hat Hunderte von Unternehmen beraten, von Startups bis Fortune-10-Firmen. Rubin war der erste Managing Director der weltweit agierenden Scrum Alliance, einer nichtkommerziellen Organisation, die sich auf die erfolgreiche Scrum-Übernahme konzentriert. Er war bereits erfolgreich als Scrum-Product-Owner, ScrumMaster und Entwickler unterwegs und hat auch als CEO, COO, VP of Engineering, VP of Product Management und VP of Professional Services gearbeitet.

Kaufen Sie hier:

Horizontale Tabs

Leseprobe

Einleitung


Dieses Buch beschreibt das Wesen von Scrum – die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen.

Was ist das Wesen von Scrum?


Scrum beruht auf einer kleinen Menge an Kernwerten, -prinzipien und -praktiken (zusammenfassend als Scrum-Framework bezeichnet). Organisationen, die Scrum einsetzen, müssen das Scrum-Framework in seiner Gänze annehmen. Das muss sicher nicht in der ganzen Organisation auf einmal geschehen, aber zumindest in den ersten Teams, die Scrum benutzen werden. Scrum komplett anzunehmen, bedeutet jedoch nicht, dass die Organisationen dieses Entwicklungsverfahren entsprechend einer vorgefertigten Einheitsformel umsetzen müssen. Es bedeutet vielmehr, dass sie sich immer an das Scrum-Framework halten müssen, während sie ihre eigene passende Mischung aus den Vorgehensweisen für ihre individuelle Scrum-Umsetzung entwickeln.

Essential Scrum kombiniert die Werte, Prinzipien und Praktiken von Scrum mit einer Reihe bewährter Ansätze, die mit dem Scrum-Framework konsistent sind, aber nicht von ihm vorgegeben werden. Einige dieser Ansätze werden sich für Ihre Situation eignen, andere wiederum nicht. Jeder Ansatz muss untersucht und an Ihre jeweiligen Umstände angepasst werden.

Die Ursprünge dieses Buches


Als Agile/Scrum-Berater und -Trainer werde ich oft nach einem Referenzbuch für Scrum gefragt – einem, das einen umfassenden Überblick über das Scrum-Framework bietet und darüber hinaus die beliebtesten Ansätze für die Anwendung von Scrum präsentiert. Da es mir nicht gelungen ist, ein einziges Buch zu finden, das diese Themen auf einem Niveau behandelt, das für heutige Anwender sinnvoll wäre, habe ich immer gleich eine ganze Sammlung an Büchern empfohlen: einige, die das Scrum-Framework diskutieren, aber nicht mehr aktuell oder in gewisser Weise unvollständig sind, einige hoch angesehene Agile-Bücher, die sich nicht ausschließlich auf Scrum beschränken, und eine Handvoll Bücher, die sich auf einen speziellen Aspekt von Scrum oder einen bestimmten Ansatz konzentrieren, aber nicht das komplette Scrum-Framework in aller Tiefe behandeln. Das sind viele Bücher für jemanden, der nur eine einzige Ressource sucht, die das Wesen von Scrum abdeckt!

Die Begründer von Scrum (Jeff Sutherland und Ken Schwaber) bieten eine Scrum-spezifische Publikation namens The Scrum Guide. Dieses kurze Dokument (ca. 15 Seiten) wird von seinen Autoren als das »definitive Regelbuch zu Scrum und die Dokumentation von Scrum selbst« beschrieben (Schwaber und Sutherland 2011). Sie vergleichen ihr Werk mit den Regeln des Schachspiels, die »beschreiben, wie die Figuren gesetzt werden, wie gewechselt wird, was ein Gewinn ist usw.«. Obwohl The Scrum Guide als Überblick oder Regelwerk zu Scrum ganz nützlich ist, ist es von seiner Anlage her nicht als umfassende Quelle für alle wesentlichen Scrum-Kenntnisse gedacht. Stellen Sie sich zur Verdeutlichung einfach vor, Sie würden einem Schachanfänger eine 15-seitige Beschreibung der Regeln des Schachspiels geben und dann von ihm erwarten, dass er anschließend ein anständiger Spieler ist. Das funktioniert nicht. Genauso wenig können Sie erwarten, dass jemand The Scrum Guide liest und sofort gute Ergebnisse abliefert.

Dieses Buch, Essential Scrum, ist der Versuch, die eine entscheidende, bisher fehlende Quelle für alles wesentliche Wissen über Scrum bereitzustellen. Es enthält eine tiefgreifende Diskussion der Scrum-Prinzipien, -werte und -praktiken – eine, die in den meisten Fällen mit führenden Köpfen aus der Agile-Szene sowie dem The Scrum Guide konform geht. (Ich weise darauf hin und erkläre, wo von den allgemein bekanntesten Ansichten abgewichen wird.) Dieses Buch beschreibt außerdem Ansätze, die mit dem Scrum-Framework konsistent sind und erfolgreich von mir und den von mir trainierten Teams eingesetzt wurden. Es soll keine anderen Bücher ersetzen, die eine tiefgreifende vertikale Behandlung einer vorhandenen Scrum-Praxis oder -Vorgehensweise liefern. Solche Bücher ergänzen vielmehr dieses Buch und gehen teilweise sogar darüber hinaus. Stellen Sie sich Essential Scrum lieber als einen Ausgangspunkt Ihrer Reise vor, auf der Sie Scrum einsetzen, um Ihre Kunden zu erfreuen.

Zielgruppe


Für die vielen Tausend Leute, die meine Kurse »Working on a Scrum Team«, »Certified ScrumMaster« und »Certified Scrum Product Owner« besucht haben, und die vielen Teams, die ich trainiert habe, wird dieses Buch Themen, die wir bereits diskutiert haben, wieder auffrischen und vielleicht auch näher erläutern. Und für die noch viel größere Anzahl an Leuten, mit denen ich noch nicht das Vergnügen hatte zusammenzuarbeiten, wird es entweder eine erste Einführung in Scrum und agile Praktiken sein oder eine Chance, Scrum in einem anderen Licht zu sehen und die eigene Anwendung von Scrum zu verbessern.

Ich habe dieses Buch nicht für eine bestimmte Rolle geschrieben – es ist nicht speziell für Product Owner oder ScrumMaster oder Mitglieder des Entwicklungsteams gedacht. Stattdessen soll es allen, die direkt oder indirekt mit Scrum zu tun haben, ein gemeinsames Verständnis von Scrum und den Prinzipien, auf denen es beruht, vermitteln. Ich hoffe, dass Ihre Organisation mit dieser gemeinsamen Grundlage in eine bessere Lage versetzt wird, Scrum erfolgreich einzusetzen.

Ich stelle mir vor, dass jedes Mitglied des Scrum-Teams dieses Buch auf seinem Schreibtisch hat, aufgeschlagen in einem Kapitel, das für die gerade ausgeführte Arbeit relevant ist. Ich stelle mir außerdem Manager auf allen Ebenen der Organisation vor, die das Buch lesen, weil sie verstehen wollen, wie sich Scrum effektiv zum Organisieren der Arbeit einsetzen lässt und welche organisatorischen Änderungen erforderlich sind, um Scrum erfolgreich umzusetzen. Organisationen, die einen anderen agilen Ansatz als Scrum benutzen oder benutzen wollen, werden die hier enthaltenen Informationen nichtsdestotrotz für ihre spezielle Version des agilen Denkens hilfreich finden.

Der Aufbau dieses Buches


Dieses Buch beginnt mit einer kurzen Einführung in Scrum (Kapitel 2) und schließt mit einer Diskussion des vorwärtsweisenden Weges (Kapitel 23). Die restlichen Kapitel sind in vier Teile gegliedert:

  • Teil I – Kernkonzepte (Kapitel 28): Scrum-Framework, agile Prinzipien, Sprints, Anforderungen und User Stories, Product Backlog, Schätzungen und Velocity sowie technische Schulden

  • Teil II – Rollen (Kapitel 913): Product Owner, ScrumMaster, Entwicklungsteam, Scrum-Team-Strukturen und -Manager

  • Teil III – Planung (Kapitel 1418): Scrum-Planungsprinzipien, mehrstufige Planung, Portfolio-Planung, Visionsbildung/Produktplanung und Release-Planung

  • Teil IV – Sprints (Kapitel 1922): Sprint-Planung, Sprint-Ausführung, Sprint Review und Sprint-Retrospektive

Wie Sie dieses Buch benutzen


Wie man es erwarten würde, schrieb ich dieses Buch in der Annahme, dass die meisten Leute es strikt von vorn nach hinten lesen würden. Wenn Sie mit Scrum noch nicht so vertraut sind, dann sollten Sie auch tatsächlich so vorgehen, weil die Kapitel normalerweise aufeinander aufbauen. Sollten Sie sich zunächst einmal einen Komplettüberblick über das Scrum-Framework verschaffen wollen, dann lesen Sie Kapitel 2.

Für diejenigen, die bereits mit Scrum vertraut sind, eignet sich dieses Buch als Scrum-Referenz. Falls Sie sich für Sprint-Retrospektiven interessieren, dann gehen Sie direkt zu Kapitel 22. Wollen Sie die Feinheiten des Product Backlogs untersuchen, lesen Sie Kapitel 6. Ich empfehle jedoch allen – auch denen, die Scrum schon kennen – dringend, Kapitel 3 komplett zu lesen. Die Prinzipien, die dort dargestellt werden, bilden die Grundlage für das Scrum-Framework und den Rest des Buches – und dabei handelt es sich nicht einfach um eine Wiederholung der Werte und Prinzipien des Agile Manifesto (Beck et al. 2001), die Sie in vielen anderen Beschreibungen von Scrum finden.

Visual AGILExicon


Ich bin stolz, in diesem Buch eine neue visuelle Sprache zur Beschreibung von Scrum präsentieren zu dürfen – Visual AGILExicon. Mithilfe dieser Sprache wurden die mehr als 200 Grafiken in diesem Buch erstellt. Visual AGILExicon besteht aus einem Vokabular aus Icons, die speziell zur Darstellung der wesentlichen Scrum-Rollen, -Artefakte und -Aktivitäten entworfen wurde, und stellt somit eine effektive Methode dar, um Konzepte zu vermitteln und das allgemeine Verständnis von Scrum zu verbessern. Wenn Sie Visual AGILExicon in ihrer ganzen Farbenpracht genießen wollen, finden Sie unter www.innolution.com weiterführende Informationen. Diese Website enthält auch eine Vielzahl an Ressourcen und Diskussionen im Zusammenhang mit diesem...

Blick ins Buch
Inhaltsverzeichnis
Cover1
Titel5
Impressum6
Inhaltsverzeichnis7
Vorwort von Mike Cohn21
Vorwort von Ron Jeffries23
Einleitung25
Danksagungen29
Über den Autor33
Kapitel 1: Einführung35
1.1 Was ist Scrum?35
1.2 Die Ursprünge von Scrum37
1.3 Wieso Scrum?38
1.4 Ergebnisse bei Genomica39
1.5 Kann Scrum Ihnen helfen?39
1.5.1 Die Complex-Domäne42
1.5.2 Die Complicated-Domäne42
1.5.3 Die Simple-Domäne43
1.5.4 Die Chaotic-Domäne43
1.5.5 Disorder (Nicht-Wissen, Regellosigkeit)43
1.5.6 Unterbrechungsgesteuerte Arbeit44
1.6 Abschließende Bemerkungen45
Teil I: Kernkonzepte47
Kapitel 2: Das Scrum-Framework49
2.1 Überblick49
2.2 Scrum-Rollen50
2.2.1 Product Owner51
2.2.2 ScrumMaster51
2.2.3 Das Entwicklungsteam52
2.3 Scrum-Aktivitäten und Artefakte52
2.3.1 Product Backlog54
2.3.2 Sprints56
2.3.3 Sprint-Planung57
2.3.4 Sprint-Ausführung58
2.3.5 Daily Scrum59
2.3.6 Fertig (Done)60
2.3.7 Sprint Review62
2.3.8 Sprint-Retrospektive63
2.4 Abschließende Bemerkungen63
Kapitel 3: Agile Prinzipien65
3.1 Überblick65
3.2 Veränderlichkeit und Unsicherheit68
3.2.1 Hilfreiche Veränderlichkeit bereitwillig annehmen68
3.2.2 Iterative und inkrementelle Entwicklung nutzen69
3.2.3 Ausnutzen der Veränderlichkeit durch Inspektion, Anpassung und Transparenz71
3.2.4 Gleichzeitiges Reduzieren aller Formen der Unsicherheit72
3.3 Vorhersage und Anpassung73
3.3.1 Optionen offen halten73
3.3.2 Akzeptieren, dass man es nicht gleich von Anfang an richtig machen kann74
3.3.3 Einen adaptiven, untersuchenden Ansatz bevorzugen76
3.3.4 Änderung auf eine ökonomisch sinnvolle Weise annehmen77
3.3.5 Vorhersagende, im Voraus erfolgende Arbeit mit adaptiver, bedarfsgerechter Arbeit abwägen80
3.4 Validiertes Wissen81
3.4.1 Schnelles Validieren wichtiger Annahmen81
3.4.2 Abwägen mehrerer gleichzeitiger Lernschleifen81
3.4.3 Organisieren des Workflows für schnelle Feedbacks82
3.5 Work in Process (WIP)84
3.5.1 Wirtschaftlich sinnvolle Batch-Größen benutzen84
3.5.2 Lagerbestände erkennen und sinnvoll verwalten86
3.5.3 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Arbeiter87
3.5.4 Verzögerungskosten betrachten89
3.6 Fortschritt90
3.6.1 An Echtzeitinformationen anpassen und umplanen90
3.6.2 Fortschritt messen, indem man funktionierende Güter validiert91
3.6.3 Auf eine wertzentrierte Auslieferung konzentrieren91
3.7 Leistung92
3.7.1 Gehe schnell, aber hetze nicht92
3.7.2 Baue Qualität ein93
3.7.3 Mache alles ohne großes Zeremoniell93
3.8 Abschließende Bemerkungen94
Kapitel 4: Sprints97
4.1 Überblick97
4.2 Timeboxing98
4.2.1 Legt ein WIP-Limit fest98
4.2.2 Erzwingt eine Priorisierung98
4.2.3 Demonstriert Fortschritt99
4.2.4 Verhindert unnötigen Perfektionismus99
4.2.5 Motiviert die Fertigstellung99
4.2.6 Verbessert die Vorhersagbarkeit100
4.3 Kurze Zeitdauer100
4.3.1 Erleichterte Planung100
4.3.2 Schnelles Feedback101
4.3.3 Verbesserter Return on Investment101
4.3.4 Begrenzte Fehler101
4.3.5 Wiedererweckte Begeisterung101
4.3.6 Häufige Checkpoints102
4.4 Konsistente Dauer103
4.4.1 Vorteile der Kadenz104
4.4.2 Vereinfacht die Planung104
4.5 Keine das Ziel beeinflussenden Änderungen105
4.5.1 Was ist ein Sprint-Ziel?105
4.5.2 Gegenseitige Verpflichtung105
4.5.3 Änderungen versus Klärung106
4.5.4 Konsequenzen einer Änderung106
4.5.5 Pragmatisch sein108
4.5.6 Abnormaler Abbruch109
4.6 Definition von Fertig (Done)110
4.6.1 Wie lautet die Definition von Fertig?110
4.6.2 Die Definition von Fertig kann sich im Laufe der Zeit weiterentwickeln112
4.6.3 Definition von Fertig versus Akzeptanzkriterien114
4.6.4 Fertig versus Fertig-Fertig114
4.7 Abschließende Bemerkungen115
Kapitel 5: Anforderungen und User Stories117
5.1 Überblick117
5.2 Gespräche119
5.3 Progressive Verfeinerung120
5.4 Was sind User Stories?121
5.4.1 Card (Karte)121
5.4.2 Conversation (Gespräch)122
5.4.3 Confirmation (Bestätigung)123
5.5 Der Detaillierungsgrad124
5.6 In gute Stories INVESTieren127
5.6.1 Independent (unabhängig)127
5.6.2 Negotiable (verhandelbar)128
5.6.3 Valuable (werthaltig)128
5.6.4 Estimatable (schätzbar)130
5.6.5 Passende Größe (klein)130
5.6.6 Testable (prüfbar)131
5.7 Nichtfunktionale Anforderungen131
5.8 Stories zum Wissenserwerb132
5.9 Stories sammeln134
5.9.1 Workshop zum Schreiben von User Stories134
5.9.2 Story Mapping135
5.10 Abschließende Bemerkungen136
Kapitel 6: Das Product Backlog139
6.1 Überblick139
6.2 Product-Backlog-Elemente140
6.3 Merkmale guter Product Backlogs141
6.3.1 Detailed appropriately (ausreichend detailliert)141
6.3.2 Emergent142
6.3.3 Estimated (geschätzt)142
6.3.4 Prioritized (priorisiert)143
6.4 Pflege144
6.4.1 Was bedeutet Pflege?144
6.4.2 Wer führt die Pflege durch?145
6.4.3 Wann findet die Pflege statt?146
6.5 Die Definition von Bereit148
6.6 Flow Management150
6.6.1 Release Flow Management150
6.6.2 Sprint Flow Management151
6.7 Welche und wie viele Product Backlogs?152
6.7.1 Was ist ein Produkt?152
6.7.2 Große Produkte – hierarchische Backlogs154
6.7.3 Mehrere Teams – ein Product Backlog155
6.7.4 Ein Team – mehrere Produkte156
6.8 Abschließende Bemerkungen157
Kapitel 7: Schätzung und Velocity159
7.1 Überblick159
7.2 Was und wann wir schätzen160
7.2.1 Schätzungen für Portfolio-Backlog-Elemente161
7.2.2 Product-Backlog-Schätzungen161
7.2.3 Aufgabenschätzungen162
7.3 Schätzkonzepte für Product-Backlog-Elemente163
7.3.1 Als Team schätzen163
7.3.2 Schätzungen sind keine Verpflichtungen164
7.3.3 Exaktheit versus Präzision165
7.3.4 Relative Größenschätzung165
7.4 Schätzeinheiten für Product-Backlog-Elemente168
7.4.1 Story-Punkte168
7.4.2 Idealtage168
7.5 Planungspoker169
7.5.1 Schätzskala170
7.5.2 Wie man spielt171
7.5.3 Vorteile173
7.6 Was ist Velocity?173
7.7 Einen Velocity-Bereich berechnen174
7.8 Die Velocity vorhersagen175
7.9 Die Velocity beeinflussen176
7.10 Missbrauch der Velocity177
7.11 Abschließende Bemerkungen178
Kapitel 8: Technische Schulden179
8.1 Überblick179
8.2 Die Folgen technischer Schulden181
8.2.1 Unvorhersehbarer Wendepunkt182
8.2.2 Zunehmend verzögerte Auslieferung182
8.2.3 Beträchtliche Anzahl an Defekten182
8.2.4 Steigende Entwicklungs- und Support-Kosten182
8.2.5 Das Produkt verkümmert183
8.2.6 Schwindende Vorhersehbarkeit183
8.2.7 Leistungseinbruch183
8.2.8 Allgemeiner Frust184
8.2.9 Sinkende Kundenzufriedenheit184
8.3 Ursachen der technischen Schulden184
8.3.1 Druck hinsichtlich des Erreichens einer Deadline184
8.3.2 Erfolglose Versuche der Velocity-Beschleunigung185
8.3.3 Gerücht: Weniger Testen kann die Velocity beschleunigen186
8.3.4 Schulden bauen auf Schulden auf187
8.4 Technische Schulden müssen organisiert werden188
8.5 Die Zunahme technischer Schulden überwachen189
8.5.1 Bewährte technische Praktiken anwenden189
8.5.2 Eine starke Definition von Fertig benutzen190
8.5.3 Die wirtschaftlichen Aspekte technischer Schulden richtig verstehen190
8.6 Technische Schulden sichtbar machen193
8.6.1 Technische Schulden auf geschäftlicher Ebene sichtbar machen193
8.6.2 Technische Schulden auf der technischen Ebene sichtbar machen194
8.7 Technische Schulden abbauen196
8.7.1 Nicht alle technischen Schulden sollten abgebaut werden197
8.7.2 Wenden Sie die Pfadfinderregel an (Bauen Sie die Schulden ab, sobald sie Ihnen begegnen)199
8.7.3 Bauen Sie technische Schulden schrittweise ab199
8.7.4 Bauen Sie die technischen Schulden mit den höchsten Zinsen zuerst ab200
8.7.5 Technische Schulden abbauen, während man für den Kunden werthaltige Arbeit erledigt201
8.8 Abschließende Bemerkungen202
Teil II: Rollen203
Kapitel 9: Der Product Owner205
9.1 Überblick205
9.2 Hauptaufgaben206
9.2.1 Organisation der wirtschaftlichen Belange207
9.2.2 Mitwirkung an der Planung209
9.2.3 Pflege des Product Backlogs209
9.2.4 Definition und Verifikation der Akzeptanzkriterien209
9.2.5 Zusammenarbeit mit dem Entwicklungsteam210
9.2.6 Zusammenarbeit mit den Stakeholdern211
9.3 Eigenschaften/Fähigkeiten212
9.3.1 Fachwissen212
9.3.2 Soziale Kompetenz213
9.3.3 Entscheidungsfindung213
9.3.4 Verantwortung213
9.4 Der Alltag eines Product Owners214
9.5 Wer sollte Product Owner sein?216
9.5.1 Interne Entwicklung217
9.5.2 Gewerbliche Entwicklung218
9.5.3 Ausgelagerte Entwicklung220
9.5.4 Komponentenentwicklung221
9.6 Product Owner kombiniert mit anderen Rollen222
9.7 Das Product-Owner-Team222
9.7.1 Product-Owner-Stellvertreter223
9.7.2 Chief Product Owner224
9.8 Abschließende Bemerkungen225
Kapitel 10: ScrumMaster227
10.1 Überblick227
10.2 Wichtigste Aufgaben227
10.2.1 Coach227
10.2.2 »Dienende Führungskraft«228
10.2.3 Prozessautorität229
10.2.4 Schutz vor störenden Einflüssen229
10.2.5 Beseitigung von Hindernissen229
10.2.6 Berater in der Organisationsentwicklung229
10.3 Eigenschaften/Fähigkeiten230
10.3.1 Sachkundig230
10.3.2 Neugierig230
10.3.3 Geduldig231
10.3.4 Teamfähig231
10.3.5 Schützend231
10.3.6 Transparent232
10.4 Alltag232
10.5 Die Rolle ausfüllen233
10.5.1 Wer sollte ScrumMaster sein?233
10.5.2 Ist die Rolle des ScrumMasters eine Vollzeitbeschäftigung?234
10.5.3 ScrumMaster in Kombination mit anderen Rollen234
10.6 Abschließende Bemerkungen235
Kapitel 11: Das Entwicklungsteam237
11.1 Überblick237
11.2 Rollenspezifische Teams237
11.3 Wichtigste Aufgaben238
11.3.1 Durchführung des Sprints238
11.3.2 Tägliches Untersuchen und Anpassen (»Inspect and Adapt«)239
11.3.3 Pflege des Product Backlogs239
11.3.4 Den Sprint planen239
11.3.5 Produkt und Prozess untersuchen und anpassen239
11.4 Eigenschaften/Fertigkeiten240
11.4.1 Selbstorganisierend240
11.4.2 Funktionsübergreifend vielseitig242
11.4.3 T-förmige Fertigkeiten243
11.4.4 Die Musketier-Einstellung245
11.4.5 Kommunikation mit hoher Bandbreite247
11.4.6 Transparente Kommunikation248
11.4.7 Die richtige Größe248
11.4.8 Fokussiert und verpflichtet249
11.4.9 In einer nachhaltigen Geschwindigkeit arbeiten251
11.4.10 Langlebig252
11.5 Abschließende Bemerkungen254
Kapitel 12: Die Strukturen des Scrum-Teams255
12.1 Überblick255
12.2 Funktionsteams versus Komponententeams255
12.3 Koordination mehrerer Teams260
12.3.1 Scrum of Scrums260
12.3.2 Der Release-Train262
12.4 Abschließende Bemerkungen265
Kapitel 13: Manager267
13.1 Überblick267
13.2 Teams koordinieren268
13.2.1 Grenzen definieren269
13.2.2 Ein klares Ziel vorgeben269
13.2.3 Teams bilden270
13.2.4 Die Teamzusammensetzung ändern271
13.2.5 Teams bevollmächtigen271
13.3 Teams fördern273
13.3.1 Die Mitarbeiter anspornen273
13.3.2 Kompetenz entwickeln273
13.3.3 Fachliche Anleitung bieten274
13.3.4 Die Integrität des Teams bewahren275
13.4 Die Umgebung ausrichten und anpassen275
13.4.1 Agile Werte fördern275
13.4.2 Organisatorische Hindernisse entfernen276
13.4.3 Die internen Abteilungen ausrichten276
13.4.4 Die Partner ausrichten277
13.5 Den Wertschöpfungsfluss organisieren277
13.5.1 Die Sichtweise des Systems annehmen277
13.5.2 Die wirtschaftlichen Aspekte organisieren278
13.5.3 Messungen und Berichte überwachen278
13.6 Projektmanager279
13.6.1 Projektmanagementaufgaben in einem Scrum-Team279
13.6.2 Eine getrennte Projektmanager-Rolle bewahren281
13.7 Abschließende Bemerkungen285
Teil III: Planen287
Kapitel 14: Scrum-Planungsprinzipien289
14.1 Überblick289
14.2 Gehen Sie nicht davon aus, dass im Voraus erstellte Pläne korrekt sind290
14.3 Die Vorabplanung sollte hilfreich, aber nicht exzessiv sein290
14.4 Halten Sie sich die Planungsoptionen bis zum letzten verantwortbaren Augenblick offen291
14.5 Konzentrieren Sie sich stärker auf das Anpassen und Neuplanen als darauf, einem Plan zu genügen291
14.6 Den Planungsbestand richtig organisieren294
14.7 Bevorzugen Sie kleinere und häufigere Releases295
14.8 Lernen Sie schnell dazu und weichen Sie vom Plan ab, wenn es nötig sein sollte297
14.9 Abschließende Bemerkungen297
Kapitel 15: Planung auf mehreren Ebenen299
15.1 Überblick299
15.2 Portfolio-Planung301
15.3 Produktplanung (Visionsbildung)301
15.3.1 Die Vision301
15.3.2 Allgemeines Product Backlog302
15.3.3 Produkt-Roadmap302
15.4 Release-Planung304
15.5 Sprint-Planung306
15.6 Tägliche Planung306
15.7 Abschließende Bemerkungen307
Kapitel 16: Portfolio-Planung309
16.1 Überblick309
16.1.1 Das Timing309
16.1.2 Teilnehmer310
16.1.3 Der Prozess310
16.2 Zeitplanungsstrategien312
16.2.1 Optimierung der Rendite über die Lebensdauer313
16.2.2 Kalkulation der Verzögerungskosten314
16.2.3 Schätzungen mit Genauigkeit statt Präzision317
16.3 Zuflussstrategien318
16.3.1 Den wirtschaftlichen Filter anwenden318
16.3.2 Zufluss- und Abflussrate ausbalancieren319
16.3.3 Sich bietende Gelegenheiten schnell ergreifen321
16.3.4 Planen Sie kleinere, häufigere Releases322
16.4 Abflussstrategien324
16.4.1 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Mitarbeiter324
16.4.2 Einrichten eines WIP-Limits324
16.4.3 Auf ein komplettes Team warten325
16.5 Strategien zur Überprüfung der in Bearbeitung befindlichen Produkte326
16.5.1 Die Grenznutzenrechnung verwenden327
16.6 Abschließende Bemerkungen328
Kapitel 17: Visionsfindung (Produktplanung)331
17.1 Überblick331
17.1.1 Das Timing332
17.1.2 Teilnehmer332
17.1.3 Der Prozess334
17.2 SR4U-Beispiel334
17.3 Die Entwicklung der Vision336
17.4 Erstellen eines allgemeinen Product Backlogs338
17.5 Die Definition der Produkt-Roadmap339
17.6 Andere Aktivitäten342
17.7 Wirtschaftlich vernünftige Visionsfindung344
17.7.1 Eine realistische Vertrauensschwelle anstreben345
17.7.2 Konzentrieren Sie sich auf einen kurzfristigen Planungshorizont346
17.7.3 Handeln Sie schnell347
17.7.4 Erwerben Sie validiertes Wissen347
17.7.5 Nutzen Sie eine inkrementelle Finanzierung348
17.7.6 Lernen Sie schnell dazu und weichen Sie ggf. vom Plan ab (aka Schnelles Scheitern)350
17.8 Abschließende Bemerkungen350
Kapitel 18: Release-Planung (längerfristige Planung)351
18.1 Überblick351
18.1.1 Das Timing352
18.1.2 Teilnehmer352
18.1.3 Der Prozess353
18.2 Release-Einschränkungen355
18.2.1 Alles fest355
18.2.2 Umfang und Termin fest356
18.2.3 Fester Umfang357
18.2.4 Fester Termin358
18.2.5 Variable Qualität358
18.2.6 Einschränkungen aktualisieren358
18.3 Das Product Backlog pflegen359
18.4 Die minimal freigebbaren Funktionen (Minimum Releasable Features, MRFs) verfeinern360
18.5 Sprint Mapping (Einordnung der Product-Backlog-Elemente)361
18.6 Release-Planung mit festem Termin363
18.7 Release-Planung mit festem Umfang368
18.8 Die Kosten berechnen370
18.9 Kommunizieren371
18.9.1 Den Fortschritt in einem Release mit festem Umfang kommunizieren371
18.9.2 Den Fortschritt in einem Release mit festem Termin kommunizieren374
18.10 Abschließende Bemerkungen375
Teil IV: Sprints377
Kapitel 19: Die Sprint-Planung379
19.1 Überblick379
19.1.1 Das Timing379
19.1.2 Teilnehmer379
19.1.3 Der Prozess380
19.2 Ansätze für die Sprint-Planung382
19.2.1 Zweiteilige Sprint-Planung382
19.2.2 Einteilige Sprint-Planung383
19.3 Die Kapazität ermitteln384
19.3.1 Was ist die Kapazität?384
19.3.2 Kapazität in Story-Punkten386
19.3.3 Die Kapazität in Aufwandsstunden386
19.4 Product-Backlog-Elemente auswählen387
19.5 Zuversicht erwerben388
19.6 Das Sprint-Ziel verfeinern390
19.7 Die Verpflichtung finalisieren390
19.8 Abschließende Bemerkungen390
Kapitel 20: Die Sprint-Ausführung391
20.1 Überblick391
20.1.1 Das Timing391
20.1.2 Teilnehmer392
20.1.3 Der Prozess392
20.2 Die Planung der Sprint-Ausführung393
20.3 Flow-Management393
20.3.1 Parallele Arbeit und Ausschwärmen394
20.3.2 Welche Arbeit begonnen werden soll396
20.3.3 Wie man die Arbeit an den Aufgaben organisiert397
20.3.4 Welche Arbeit muss erledigt werden?397
20.3.5 Wer erledigt die Arbeit?398
20.4 Daily Scrum398
20.5 Die Durchführung der Aufgaben – Technische Praktiken399
20.6 Kommunizieren400
20.6.1 Task Board400
20.6.2 Das Sprint-Burndown-Chart401
20.6.3 Das Sprint-Burnup-Chart404
20.7 Abschließende Bemerkungen405
Kapitel 21: Sprint Review407
21.1 Überblick407
21.2 Teilnehmer408
21.3 Vorarbeiten409
21.3.1 Entscheiden, wen man einlädt410
21.3.2 Die Aktivität zeitlich planen410
21.3.3 Bestätigen, dass die Sprint-Arbeit erledigt ist411
21.3.4 Auf die Demonstration vorbereiten412
21.3.5 Festlegen, wer was macht412
21.4 Das Vorgehen412
21.4.1 Zusammenfassen413
21.4.2 Demonstrieren414
21.4.3 Diskutieren415
21.4.4 Ändern415
21.5 Sprint-Review-Probleme416
21.5.1 Abnahmen der PBIs416
21.5.2 Sporadische Teilnahme416
21.5.3 Umfangreiche Entwicklungsprojekte417
21.6 Abschließende Bemerkungen417
Kapitel 22: Die Sprint-Retrospektive419
22.1 Überblick419
22.2 Teilnehmer421
22.3 Die Vorarbeit422
22.3.1 Den Fokus der Retrospektive definieren422
22.3.2 Die Übungen auswählen423
22.3.3 Objektive Daten sammeln423
22.3.4 Die Retrospektive strukturieren424
22.4 Das Vorgehen425
22.4.1 Die Atmosphäre gestalten426
22.4.2 Gemeinsamer Kontext427
22.4.3 Einsichten identifizieren429
22.4.4 Aktionen festlegen432
22.4.5 Die Retrospektive schließen435
22.5 Dranbleiben435
22.6 Probleme der Sprint-Retrospektive436
22.7 Abschließende Bemerkungen438
Kapitel 23: Der Weg nach vorn439
23.1 Es gibt keinen Endzustand439
23.2 Finden Sie Ihren eigenen Weg440
23.3 Best Practices mit anderen teilen440
23.4 Mit Scrum den Weg nach vorn finden441
23.5 Immer weiter!443
Anhang A: Referenzen445
Anhang B: Glossar449
Stichwortverzeichnis471

Weitere E-Books zum Thema: Programmiersprachen - Softwareentwicklung

ASP.NET Shortcut

E-Book ASP.NET Shortcut
Format: PDF

Shortcut-Tipps für ASP.NET-Profis Die neue .NET-Version der Active Server Pages stellt eine Umgebung zur Entwicklung von Web-Applikationen im .NET-Framework bereit. Viele aus der Desktop-…

ASP.NET Shortcut

E-Book ASP.NET Shortcut
Format: PDF

Shortcut-Tipps für ASP.NET-Profis Die neue .NET-Version der Active Server Pages stellt eine Umgebung zur Entwicklung von Web-Applikationen im .NET-Framework bereit. Viele aus der Desktop-…

ASP.NET Shortcut

E-Book ASP.NET Shortcut
Format: PDF

Shortcut-Tipps für ASP.NET-Profis Die neue .NET-Version der Active Server Pages stellt eine Umgebung zur Entwicklung von Web-Applikationen im .NET-Framework bereit. Viele aus der Desktop-…

Programmieren lernen in PHP 5

E-Book Programmieren lernen in PHP 5
Format: PDF

Mit der Version 5 erreicht PHP einen bemerkenswerten Reifegrad, der PHP zu einer festen Größe in der Welt der Webprogrammierung macht. Gerade die leichte Erlernbarkeit macht PHP zur idealen…

Mathematik für Informatiker

E-Book Mathematik für Informatiker
Format: PDF

Die Informatik entwickelt sich in einer unglaublichen Geschwindigkeit. Häufig ist die Mathematik Grundlage von Neuerungen. Deshalb ist sie unverzichtbares Werkzeug jedes Informatikers und Pflichtfach…

Mathematik für Informatiker

E-Book Mathematik für Informatiker
Format: PDF

Die Informatik entwickelt sich in einer unglaublichen Geschwindigkeit. Häufig ist die Mathematik Grundlage von Neuerungen. Deshalb ist sie unverzichtbares Werkzeug jedes Informatikers und Pflichtfach…

Mathematik für Informatiker

E-Book Mathematik für Informatiker
Format: PDF

Die Informatik entwickelt sich in einer unglaublichen Geschwindigkeit. Häufig ist die Mathematik Grundlage von Neuerungen. Deshalb ist sie unverzichtbares Werkzeug jedes Informatikers und Pflichtfach…

Weitere Zeitschriften

AUTOCAD Magazin

AUTOCAD Magazin

Die herstellerunabhängige Fachzeitschrift wendet sich an alle Anwender und Entscheider, die mit Softwarelösungen von Autodesk arbeiten. Das Magazin gibt praktische ...

caritas

caritas

mitteilungen für die Erzdiözese FreiburgUm Kindern aus armen Familien gute Perspektiven für eine eigenständige Lebensführung zu ermöglichen, muss die Kinderarmut in Deutschland nachhaltig ...

DGIP-intern

DGIP-intern

Mitteilungen der Deutschen Gesellschaft für Individualpsychologie e.V. (DGIP) für ihre Mitglieder Die Mitglieder der DGIP erhalten viermal jährlich das Mitteilungsblatt „DGIP-intern“ ...