Scrum mit User Stories

 
 
Hanser, Carl (Verlag)
  • 3. Auflage
  • |
  • erschienen am 16. Januar 2017
  • |
  • 287 Seiten
 
E-Book | PDF mit Wasserzeichen-DRM | Systemvoraussetzungen
978-3-446-45077-6 (ISBN)
 
Scrum als Framework für die Agile Softwareentwicklung kombiniert mit User Stories als ein unschlagbares Doppel:

Scrum definiert mit Hilfe einfacher Regeln und klarer Verantwortlichkeiten einen Rahmen für agile Softwareprojekte. User Stories beschreiben Anforderungen aus Sicht des Benutzers und liefern einen greifbaren Mehrwert.

- Dieses Buch erklärt die Grundlagen beider Konzepte und beschreibt, wie Sie User Stories in die Elemente und Abläufe von Scrum einbinden. Angefangen vom Schreiben und Priorisieren eines User-Story-basierten Product Backlog bis hin zur User-Story-getriebenen Sprint- und Releaseplanung lernen Sie alles, was für den erfolgreichen Einsatz von User Stories in Ihrem Scrum-Projekt wichtig ist.
- Erfahren Sie, wie Sie Anforderungen im Sinne des Kunden mit Hilfe von User Stories beschreiben und im Product Backlog verwalten.
- Erfahren Sie, wie User Stories den Flow eines Scrum-Projekts steuern und das Team bei der Entwicklung werthaltiger Software leiten.
- Lernen Sie, wie Sie die Geschäftsregeln einer User Story als Akzeptanztests beschreiben und so die Basis für Akzeptanztest-getriebene Entwicklung schaffen.
- Erlernen Sie die Anwendung von Story Maps als neue Methode zur ganzheitlichen Anforderungsanalyse.
- Erfahren Sie in einem Praxisbericht von Dr. Mainusch, wie Scrum in großen, aus mehreren Teams bestehenden Projektenbei Bosch funktioniert.


Egal ob man Scrum und User-Stories einsetzt oder nicht: Mit diesem Buch lernt wohl jeder noch etwas dazu.
3., erweiterte Auflage
  • Deutsch
  • München
  • |
  • Deutschland
  • 19,24 MB
978-3-446-45077-6 (9783446450776)
3446450777 (3446450777)
http://dx.doi.org/10.3139/9783446450776
weitere Ausgaben werden ermittelt
Ralf Wirdemann ist erfahrener Software-Coach mit dem Schwerpunkt agile Softwareentwicklung. Er hat Scrum bereits in einer Reihe von Projekten eingeführt. Er ist Autor zahlreicher Fachartikel und gefragter Sprecher auf Konferenzen.
1 - Inhalt [Seite 6]
2 - Vorwort zur 3. Auflage [Seite 16]
3 - 1 Einführung [Seite 18]
3.1 - 1.1 Warum dieses Buch? [Seite 19]
3.2 - 1.2 Struktur und Aufbau [Seite 20]
3.3 - 1.3 Dankeschön [Seite 22]
3.4 - 1.4 Feedback [Seite 23]
4 - 2 Beispiel: Scrumcoaches.com [Seite 24]
4.1 - 2.1 Das Projekt [Seite 25]
4.2 - 2.2 Der Entwicklungsprozess [Seite 26]
4.3 - 2.3 Die Beteiligten [Seite 26]
4.4 - 2.4 Die Anforderungen [Seite 27]
4.5 - 2.5 Priorisieren und Schätzen des Product Backlog [Seite 28]
4.5.1 - 2.5.1 Priorisieren [Seite 29]
4.5.2 - 2.5.2 Schätzen [Seite 30]
4.6 - 2.6 Sprint-Planung [Seite 31]
4.6.1 - 2.6.1 Sprint-Ziel [Seite 31]
4.6.2 - 2.6.2 Entwicklungsgeschwindigkeit [Seite 32]
4.6.3 - 2.6.3 Analyse der User Stories [Seite 32]
4.6.4 - 2.6.4 Design der User Stories [Seite 32]
4.7 - 2.7 Sprint-Durchführung [Seite 34]
4.8 - 2.8 Messen des Sprint-Fortschritts [Seite 36]
4.9 - 2.9 Am Ende des Sprint [Seite 37]
4.9.1 - 2.9.1 Sprint-Review [Seite 37]
4.9.2 - 2.9.2 Sprint-Retrospektive [Seite 37]
4.10 - 2.10 Die Arbeit geht weiter [Seite 39]
4.11 - 2.11 Zusammenfassung [Seite 40]
4.12 - 2.12 Wie geht es weiter? [Seite 40]
5 - 3 Die Grundlagen von Scrum [Seite 42]
5.1 - 3.1 Was ist Scrum? [Seite 42]
5.2 - 3.2 Scrum, ein Framework? [Seite 44]
5.3 - 3.3 Überblick [Seite 45]
5.3.1 - 3.3.1 Scrum-Team [Seite 45]
5.3.2 - 3.3.2 Vision und Product Backlog [Seite 45]
5.3.3 - 3.3.3 Sprint Planning Meeting [Seite 46]
5.3.4 - 3.3.4 Sprints [Seite 47]
5.3.5 - 3.3.5 Daily Scrums [Seite 47]
5.3.6 - 3.3.6 Sprint-Review [Seite 48]
5.3.7 - 3.3.7 Sprint-Retrospektive [Seite 48]
5.4 - 3.4 Prinzipien [Seite 48]
5.4.1 - 3.4.1 Transparenz [Seite 48]
5.4.2 - 3.4.2 Beobachten und Anpassen [Seite 49]
5.4.3 - 3.4.3 Timeboxing [Seite 50]
5.4.4 - 3.4.4 Dinge abschließen [Seite 50]
5.4.5 - 3.4.5 Maximierung von Geschäftswert [Seite 51]
5.4.6 - 3.4.6 Teams scheitern nicht [Seite 52]
5.4.7 - 3.4.7 Ergebnisorientierung [Seite 52]
5.5 - 3.5 Die Rollen [Seite 53]
5.5.1 - 3.5.1 Das Team [Seite 54]
5.5.2 - 3.5.2 Der ScrumMaster [Seite 55]
5.5.2.1 - 3.5.2.1 Dienstleistender Anführer und Problembeseitiger [Seite 55]
5.5.2.2 - 3.5.2.2 Scrum implementieren [Seite 56]
5.5.2.3 - 3.5.2.3 Entscheider [Seite 56]
5.5.2.4 - 3.5.2.4 Müssen ScrumMaster programmieren können? [Seite 57]
5.5.2.5 - 3.5.2.5 Product Owner-Coaching [Seite 57]
5.5.2.6 - 3.5.2.6 Belastbare Persönlichkeit [Seite 57]
5.5.2.7 - 3.5.2.7 Scrum in der Organisation verbreiten [Seite 58]
5.5.3 - 3.5.3 Der Product Owner [Seite 58]
5.5.3.1 - 3.5.3.1 Den Kunden repräsentieren [Seite 59]
5.5.3.2 - 3.5.3.2 User Stories und Product Backlog [Seite 59]
5.5.3.3 - 3.5.3.3 Mit dem Team durch den Sprint [Seite 60]
5.5.3.4 - 3.5.3.4 Bestimmen, wann was fertig ist [Seite 60]
5.5.4 - 3.5.4 Nebenrolle Kunde [Seite 60]
5.6 - 3.6 Die ideale Arbeitsumgebung [Seite 62]
5.7 - 3.7 Empirisches Management [Seite 63]
5.8 - 3.8 Zusammenfassung [Seite 65]
5.9 - 3.9 Wie geht es weiter? [Seite 65]
6 - 4 User Stories [Seite 66]
6.1 - 4.1 Was sind User Stories? [Seite 67]
6.1.1 - 4.1.1 Story-Karte [Seite 68]
6.1.2 - 4.1.2 Konversation [Seite 69]
6.1.3 - 4.1.3 Akzeptanzkriterien [Seite 69]
6.2 - 4.2 Warum User Stories? [Seite 70]
6.3 - 4.3 User Stories schreiben [Seite 71]
6.3.1 - 4.3.1 Die Sprache des Kunden [Seite 72]
6.3.2 - 4.3.2 Benutzerrollen [Seite 72]
6.3.3 - 4.3.3 User-Story-Muster [Seite 74]
6.3.4 - 4.3.4 Epics [Seite 74]
6.3.5 - 4.3.5 Themen [Seite 76]
6.3.6 - 4.3.6 Wie viel Detail? [Seite 77]
6.3.7 - 4.3.7 Keine Technik [Seite 78]
6.3.8 - 4.3.8 Keine Benutzeroberfläche [Seite 78]
6.4 - 4.4 Eigenschaften guter User Stories [Seite 78]
6.4.1 - 4.4.1 Independent - Unabhängige User Stories [Seite 78]
6.4.2 - 4.4.2 Negotiable - Verhandelbare User Stories [Seite 79]
6.4.3 - 4.4.3 Valuable - Wertvolle User Stories [Seite 79]
6.4.4 - 4.4.4 Estimatable - Schätzbare User Stories [Seite 80]
6.4.5 - 4.4.5 Small - Kleine User Stories [Seite 80]
6.4.6 - 4.4.6 Testable - Testbare User Stories [Seite 81]
6.5 - 4.5 Zusammenfassung [Seite 82]
6.6 - 4.6 Wie geht es weiter? [Seite 82]
7 - 5 Agiles Schätzen [Seite 84]
7.1 - 5.1 Was ist agiles Schätzen? [Seite 85]
7.1.1 - 5.1.1 Relative Größe statt Dauer [Seite 85]
7.1.2 - 5.1.2 Schätzen in Story Points [Seite 86]
7.1.3 - 5.1.3 Wo bleibt die Dauer? [Seite 87]
7.1.4 - 5.1.4 Argumentationshilfe für Story Points [Seite 87]
7.2 - 5.2 Schätzen von User Stories [Seite 88]
7.2.1 - 5.2.1 Größenordnungen und Punktesequenzen [Seite 89]
7.2.2 - 5.2.2 Planungspoker [Seite 91]
7.2.2.1 - 5.2.2.1 Schätzen im Team [Seite 93]
7.2.2.2 - 5.2.2.2 Referenz-Story und Triangularisierung [Seite 93]
7.2.2.3 - 5.2.2.3 Planungspoker funktioniert [Seite 95]
7.2.3 - 5.2.3 Wann schätzen? [Seite 95]
7.3 - 5.3 Zusammenfassung [Seite 96]
7.4 - 5.4 Wie geht es weiter? [Seite 96]
8 - 6 Agiles Planen [Seite 98]
8.1 - 6.1 Was macht Planung agil? [Seite 98]
8.2 - 6.2 Velocity [Seite 100]
8.2.1 - 6.2.1 Tatsächliche Velocity [Seite 100]
8.2.2 - 6.2.2 Angenommene Velocity [Seite 101]
8.2.2.1 - 6.2.2.1 Angenommene Velocity = Tatsächliche Velocity [Seite 102]
8.2.2.2 - 6.2.2.2 Mittlere Velocity [Seite 103]
8.2.3 - 6.2.3 Velocity-basierte Planung [Seite 104]
8.2.4 - 6.2.4 Nachhaltige Velocity [Seite 105]
8.3 - 6.3 Agile Planung funktioniert [Seite 107]
8.3.1 - 6.3.1 Velocity korrigiert Schätzfehler [Seite 107]
8.3.2 - 6.3.2 Neubewertung von User Stories [Seite 108]
8.3.3 - 6.3.3 Urlaub, Krankheit und ähnliche Ereignisse [Seite 109]
8.3.4 - 6.3.4 Der Plan entsteht [Seite 109]
8.4 - 6.4 Zusammenfassung [Seite 110]
8.5 - 6.5 Wie geht es weiter? [Seite 110]
9 - 7 User Stories fürs Product Backlog [Seite 112]
9.1 - 7.1 Das Product Backlog [Seite 112]
9.2 - 7.2 Das Product Backlog füllen [Seite 115]
9.2.1 - 7.2.1 Anforderungsworkshops [Seite 116]
9.2.2 - 7.2.2 Interviews, Markt-Feedback und Abstimmungsrunden [Seite 117]
9.2.3 - 7.2.3 Überarbeitung und Pflege des Product Backlog [Seite 118]
9.3 - 7.3 User Stories priorisieren [Seite 119]
9.3.1 - 7.3.1 Finanzieller Wert [Seite 119]
9.3.2 - 7.3.2 Kosten [Seite 120]
9.3.3 - 7.3.3 Kundenzufriedenheit nach Kano [Seite 121]
9.3.4 - 7.3.4 Risiko [Seite 122]
9.3.5 - 7.3.5 Abhängigkeiten [Seite 123]
9.3.6 - 7.3.6 Priorisierende Faktoren abwägen [Seite 123]
9.3.7 - 7.3.7 MuSCoW-Priorisierung [Seite 124]
9.4 - 7.4 User Stories schneiden [Seite 125]
9.4.1 - 7.4.1 Vertikales Schneiden [Seite 126]
9.4.2 - 7.4.2 Schneiden nach Daten [Seite 127]
9.4.3 - 7.4.3 Schneiden nach Aufwand [Seite 128]
9.4.4 - 7.4.4 Schneiden nach Forschungsanteilen [Seite 128]
9.4.5 - 7.4.5 Schneiden nach Qualität [Seite 129]
9.4.6 - 7.4.6 Schneiden nach Benutzerrolle [Seite 130]
9.4.7 - 7.4.7 Schneiden nach Akzeptanzkriterien [Seite 130]
9.4.8 - 7.4.8 Schneiden nach technischer Voraussetzung [Seite 131]
9.5 - 7.5 Andere Anforderungen [Seite 132]
9.5.1 - 7.5.1 Anforderungen umformulieren [Seite 132]
9.5.2 - 7.5.2 Constraints [Seite 133]
9.5.3 - 7.5.3 Fehler [Seite 134]
9.5.4 - 7.5.4 Technisches Backlog [Seite 134]
9.6 - 7.6 Zusammenfassung [Seite 135]
9.7 - 7.7 Wie geht es weiter? [Seite 136]
10 - 8 User Story Mapping [Seite 138]
10.1 - 8.1 User Story Maps [Seite 139]
10.2 - 8.2 Eine Story Map erstellen [Seite 140]
10.2.1 - 8.2.1 Schritt 1: User Tasks ermitteln [Seite 141]
10.2.2 - 8.2.2 Schritt 2: Gruppen bilden - User Activities [Seite 142]
10.2.3 - 8.2.3 Schritt 3: Ordnung schaffen [Seite 143]
10.2.4 - 8.2.4 Schritt 4: User Tasks durchlaufen = Geschichten erzählen [Seite 143]
10.2.5 - 8.2.5 Schritt 5: User Stories schreiben [Seite 144]
10.3 - 8.3 Warum Story Mapping? [Seite 145]
10.3.1 - 8.3.1 Basis für gute Product Backlogs [Seite 145]
10.3.2 - 8.3.2 Kleinstmögliche Releases [Seite 146]
10.3.3 - 8.3.3 Motivation und Einsicht für alle Stakeholder [Seite 146]
10.3.4 - 8.3.4 Lückenlosigkeit [Seite 146]
10.3.5 - 8.3.5 Softwarearchitektur [Seite 147]
10.3.6 - 8.3.6 Multi-Team-Setups [Seite 147]
10.4 - 8.4 Von der Story Map zum Product Backlog [Seite 147]
10.4.1 - 8.4.1 User Stories schreiben [Seite 150]
10.4.2 - 8.4.2 Die Story Map ersetzt das Product Backlog [Seite 150]
10.5 - 8.5 Zusammenfassung [Seite 150]
10.6 - 8.6 Wie geht es weiter? [Seite 151]
11 - 9 Sprint-Planung [Seite 152]
11.1 - 9.1 Überblick und Ablauf [Seite 152]
11.2 - 9.2 Beteiligte [Seite 153]
11.3 - 9.3 Ergebnisse [Seite 153]
11.4 - 9.4 Vorbereitung [Seite 156]
11.4.1 - 9.4.1 Sprint Velocity [Seite 156]
11.4.1.1 - 9.4.1.1 Anpassen der Velocity [Seite 156]
11.4.1.2 - 9.4.1.2 Bugfixing, Refactoring und andere Aufgaben [Seite 157]
11.4.2 - 9.4.2 Story-Auswahl [Seite 158]
11.4.3 - 9.4.3 Sprint-Länge [Seite 159]
11.5 - 9.5 Sprint Planning 1 [Seite 160]
11.5.1 - 9.5.1 Ablauf [Seite 160]
11.5.2 - 9.5.2 Sprint-Ziel - Warum führen wir den Sprint durch? [Seite 161]
11.5.3 - 9.5.3 Vorstellung, Analyse und Commitment [Seite 161]
11.5.4 - 9.5.4 Fehler und andere technische Aufgaben [Seite 163]
11.6 - 9.6 Sprint Planning 2 [Seite 164]
11.6.1 - 9.6.1 Ablauf [Seite 165]
11.6.2 - 9.6.2 Story-Design [Seite 166]
11.6.3 - 9.6.3 Tasks schneiden [Seite 167]
11.6.3.1 - 9.6.3.1 Taskgröße [Seite 168]
11.6.3.2 - 9.6.3.2 Schneidetechniken [Seite 168]
11.6.3.3 - 9.6.3.3 Ungeplante Tasks [Seite 169]
11.6.4 - 9.6.4 Tasks schätzen? [Seite 169]
11.6.4.1 - 9.6.4.1 Taskschätzungen sind sinnvoll [Seite 170]
11.6.4.2 - 9.6.4.2 Taskschätzungen sind unsinnig [Seite 170]
11.6.4.3 - 9.6.4.3 Keine Empfehlung [Seite 171]
11.6.5 - 9.6.5 Das Sprint Backlog [Seite 172]
11.6.6 - 9.6.6 Fehler und andere technischen Aufgaben verteilen [Seite 173]
11.6.7 - 9.6.7 Was tun, wenn es länger wird? [Seite 173]
11.7 - 9.7 Abschluss [Seite 174]
11.8 - 9.8 Zusammenfassung [Seite 175]
11.9 - 9.9 Wie geht es weiter? [Seite 175]
12 - 10 Sprint-Durchführung [Seite 176]
12.1 - 10.1 Die eigentliche Arbeit beginnt [Seite 176]
12.2 - 10.2 Wer macht was? [Seite 178]
12.2.1 - 10.2.1 Das Team [Seite 178]
12.2.2 - 10.2.2 Der Product Owner [Seite 179]
12.2.3 - 10.2.3 Der ScrumMaster [Seite 179]
12.3 - 10.3 Story für Story Richtung Sprint-Ziel [Seite 180]
12.3.1 - 10.3.1 Wie viele User Stories zurzeit? [Seite 181]
12.3.2 - 10.3.2 Arbeit an einer User Story [Seite 181]
12.3.3 - 10.3.3 Definition of Done [Seite 181]
12.3.4 - 10.3.4 Abnahme fertiger User Stories [Seite 182]
12.3.4.1 - 10.3.4.1 Entwicklertest [Seite 182]
12.3.4.2 - 10.3.4.2 Akzeptanztest [Seite 183]
12.3.4.3 - 10.3.4.3 QA-Abnahme [Seite 183]
12.3.4.4 - 10.3.4.4 Frühestmögliche Fehlerbehebung [Seite 184]
12.4 - 10.4 Daily Scrum [Seite 184]
12.4.1 - 10.4.1 Aktualisierung des Taskboard [Seite 185]
12.4.2 - 10.4.2 Ein guter Zeitpunkt [Seite 186]
12.4.3 - 10.4.3 Ein guter Ort [Seite 187]
12.4.4 - 10.4.4 Wer ist noch dabei? [Seite 187]
12.4.5 - 10.4.5 Was macht der ScrumMaster? [Seite 188]
12.5 - 10.5 Unterbrechungen [Seite 189]
12.6 - 10.6 Messen und Anpassen [Seite 190]
12.6.1 - 10.6.1 Bug- und technische Burndown-Charts [Seite 191]
12.6.2 - 10.6.2 Was tun, wenn es eng wird? [Seite 192]
12.7 - 10.7 Reguläres Sprint-Ende [Seite 193]
12.8 - 10.8 Sprint-Review [Seite 194]
12.8.1 - 10.8.1 Vorbereitung [Seite 194]
12.8.2 - 10.8.2 Ort, Zeitpunkt und Teilnehmer [Seite 194]
12.8.3 - 10.8.3 Ziel [Seite 195]
12.8.4 - 10.8.4 Ablauf [Seite 195]
12.9 - 10.9 Das Team organisiert sich [Seite 196]
12.9.1 - 10.9.1 Verantwortung übernehmen [Seite 196]
12.9.2 - 10.9.2 Das Team machen lassen und aus Fehlern lernen [Seite 197]
12.9.3 - 10.9.3 Den Product Owner einbeziehen [Seite 197]
12.9.4 - 10.9.4 Software-Pull-Systeme [Seite 198]
12.9.5 - 10.9.5 Das Team bei der Arbeit mit Tasks coachen [Seite 199]
12.9.6 - 10.9.6 Einzelgespräche [Seite 199]
12.10 - 10.10 Sprint Best Practices [Seite 200]
12.10.1 - 10.10.1 Source Code Management und Story-Branches [Seite 200]
12.10.2 - 10.10.2 Kontinuierliches Integrieren [Seite 201]
12.10.3 - 10.10.3 Automatisierung [Seite 201]
12.10.4 - 10.10.4 Verständlicher Quellcode [Seite 202]
12.10.5 - 10.10.5 Elektronische Sprint Backlogs und Burndown-Charts [Seite 202]
12.11 - 10.11 Zusammenfassung [Seite 203]
12.12 - 10.12 Wie geht es weiter? [Seite 203]
13 - 11 User Stories Akzeptanztesten [Seite 204]
13.1 - 11.1 Was ist Akzeptanztesten? [Seite 204]
13.1.1 - 11.1.1 Akzeptanzkriterien [Seite 205]
13.1.1.1 - 11.1.1.1 Akzeptanzkriterien sind Erwartungen [Seite 205]
13.1.1.2 - 11.1.1.2 Akzeptanzkriterien sind Geschäftsregeln [Seite 206]
13.1.2 - 11.1.2 Akzeptanztests [Seite 206]
13.1.3 - 11.1.3 Akzeptanztesten [Seite 207]
13.2 - 11.2 Akzeptanzkriterien schreiben [Seite 208]
13.2.1 - 11.2.1 Vom Akzeptanzkriterium zum Akzeptanztest [Seite 208]
13.2.2 - 11.2.2 Merkmale guter Akzeptanzkriterien [Seite 209]
13.2.3 - 11.2.3 Akzeptanzkriterien auch für Epics? [Seite 211]
13.3 - 11.3 Beispiel: Suche nach Coaches [Seite 211]
13.4 - 11.4 Kleine Bausteine: Auf dem Weg zur DSL [Seite 212]
13.5 - 11.5 Akzeptanztesten während des Sprint [Seite 213]
13.6 - 11.6 Die hohe Schule: Akzeptanztest-getriebene Entwicklung [Seite 215]
13.6.1 - 11.6.1 ATDD-Beispiel: Suche nach Coaches [Seite 216]
13.6.2 - 11.6.2 Product Owner love writing Tests? [Seite 218]
13.6.2.1 - 11.6.2.1 Alternative JCriteria [Seite 218]
13.7 - 11.7 Lohnt sich das Ganze? [Seite 219]
13.8 - 11.8 Zusammenfassung [Seite 219]
13.9 - 11.9 Wie geht es weiter? [Seite 220]
14 - 12 Sprint-Retrospektive [Seite 222]
14.1 - 12.1 Nach dem Sprint ist vor dem Sprint [Seite 223]
14.2 - 12.2 Ablauf von Retrospektiven [Seite 223]
14.3 - 12.3 Retrospektiven vorbereiten [Seite 225]
14.4 - 12.4 Retrospektiven leiten [Seite 225]
14.5 - 12.5 Agenda und Check-in [Seite 226]
14.6 - 12.6 Phase 1: Daten sammeln [Seite 227]
14.6.1 - 12.6.1 Erstellung einer Timeline [Seite 228]
14.6.2 - 12.6.2 Erweiterung der Timeline um Energiepunkte [Seite 229]
14.7 - 12.7 Phase 2: Einsichten generieren [Seite 230]
14.7.1 - 12.7.1 Positiv- / Delta-Liste [Seite 230]
14.7.2 - 12.7.2 Warum-Fragen [Seite 231]
14.8 - 12.8 Phase 3: Entscheiden, was zu tun ist [Seite 231]
14.9 - 12.9 Phase 4: Ziele formulieren und Aktionen planen [Seite 232]
14.10 - 12.10 Abschluss [Seite 233]
14.11 - 12.11 Themenorientierte Retrospektiven [Seite 234]
14.12 - 12.12 Zusammenfassung [Seite 235]
14.13 - 12.13 Wie geht es weiter? [Seite 236]
15 - 13 Agile Releaseplanung [Seite 238]
15.1 - 13.1 Releaseplanung [Seite 238]
15.1.1 - 13.1.1 Themen-Releases [Seite 238]
15.1.2 - 13.1.2 Datum-Releases [Seite 239]
15.1.3 - 13.1.3 Releaseplanungs-Workshop [Seite 240]
15.1.4 - 13.1.4 Was macht die Planung agil? [Seite 240]
15.2 - 13.2 Planungs-Velocity [Seite 241]
15.2.1 - 13.2.1 Durchführung von Test-Sprints [Seite 241]
15.2.2 - 13.2.2 Historische Daten [Seite 242]
15.2.3 - 13.2.3 Das Team bestimmen lassen [Seite 242]
15.2.4 - 13.2.4 Auswahl eines Verfahrens [Seite 242]
15.3 - 13.3 Der Releaseplan [Seite 243]
15.4 - 13.4 Sichere Planung [Seite 244]
15.4.1 - 13.4.1 Sichere Velocity [Seite 244]
15.4.2 - 13.4.2 Sicherheit durch weniger wichtige User Stories [Seite 245]
15.5 - 13.5 Monitoring und Aktualisierung [Seite 246]
15.6 - 13.6 Zusammenfassung [Seite 247]
15.7 - 13.7 Wie geht es weiter? [Seite 247]
16 - 14 Verticals - SCRUM@OTTO [Seite 248]
16.1 - 14.1 Warum ich über diese Geschichte schreibe [Seite 248]
16.2 - 14.2 Die Vorgeschichte [Seite 250]
16.3 - 14.3 Das Lhotse-Projekt - Zahlen, Daten, Fakten [Seite 251]
16.4 - 14.4 Das Team - Menschen im Mittelpunkt [Seite 252]
16.5 - 14.5 Triaden - die Führung eines Teams [Seite 254]
16.6 - 14.6 Die Triade - Rollenbeschreibungen [Seite 254]
16.6.1 - 14.6.1 Der Projektmanager - Project-Lead [Seite 255]
16.6.2 - 14.6.2 Der Produktmanager - Business-Designer [Seite 256]
16.6.3 - 14.6.3 Der Team-Architekt - Technical-Designer [Seite 256]
16.7 - 14.7 Die TD-Runde [Seite 258]
16.8 - 14.8 Die Otto-Architektur in Vertikalen [Seite 259]
16.8.1 - 14.8.1 Warum die klassische IT versagt [Seite 259]
16.8.2 - 14.8.2 Warum vertikale Schnitte helfen [Seite 262]
16.8.3 - 14.8.3 Was eine Vertikale ist [Seite 263]
16.8.4 - 14.8.4 Wie vertikale Schnitte gefunden werden können [Seite 265]
16.9 - 14.9 Makro- und Mikroarchitektur [Seite 267]
16.9.1 - 14.9.1 Makroarchitektur [Seite 268]
16.9.2 - 14.9.2 Mikroarchitektur [Seite 268]
16.10 - 14.10 Werte und Leitplanken statt Richtlinien und Governance [Seite 269]
16.11 - 14.11 Das klassische Management in der agiler werdenden Organisation [Seite 269]
16.12 - 14.12 Scrum@Otto - 100 Sprints später [Seite 271]
16.13 - 14.13 Fazit [Seite 273]
17 - Glossar [Seite 274]
18 - Literatur [Seite 282]
19 - Stichwortverzeichnis [Seite 282]

Dateiformat: PDF
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie zum Lesen die kostenlose Software Adobe Reader, Adobe Digital Editions oder einen anderen PDF-Viewer Ihrer Wahl (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie die kostenlose App Adobe Digital Editions oder eine andere Lese-App für E-Books (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nur bedingt: Kindle)

Das Dateiformat PDF zeigt auf jeder Hardware eine Buchseite stets identisch an. Daher ist eine PDF auch für ein komplexes Layout geeignet, wie es bei Lehr- und Fachbüchern verwendet wird (Bilder, Tabellen, Spalten, Fußnoten). Bei kleinen Displays von E-Readern oder Smartphones sind PDF leider eher nervig, weil zu viel Scrollen notwendig ist. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.

Inhalt (1) (PDF)
Inhalt (2) (PDF)

Download (sofort verfügbar)

25,99 €
inkl. 19% MwSt.
Download / Einzel-Lizenz
PDF mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
E-Book bestellen

Unsere Web-Seiten verwenden Cookies. Mit der Nutzung des WebShops erklären Sie sich damit einverstanden. Mehr Informationen finden Sie in unserem Datenschutzhinweis. Ok